Module Configuration Documentation

prebid-server/developers/add-a-module-java.md

@@ -93,6 +93,18 @@ The structure of your module source code inside the modules directory must have
 +- README.md <- documentation
 ```
 
+## Module Configuration
+There are several places to configure a module:
+
+- **Host/Bean config** is stored in one of the YAML files (generally application.yaml), primarily used for enabling the module at the server level with `hooks.<MODULE_CODE>.enabled`. It should only contain static config which applies to initial startup independent from any account. Most modules have no host-level config at all, apart from enabled flag.
+- **Default account config** is stored in a YAML file, but only used when account config is available (i.e. it's not seen at the entrypoint stage). It is used to define defaults for all accounts.
+- **Account/Runtime config** is stored in the database, YAML file, or whatever other account backend used. It is used to define individual account configuration.
+
+Important Notes:
+
+- Host config will be provided to module once on application start.
+- Account config will be provided to module on each request.
+
 ## Module Code
 
 The quick start is to take a look in two places:

prebid-server/pbs-modules/greenbids-real-time-data.md

@@ -145,22 +145,39 @@ per bid requests and is not filtered by the RTD module.
 Here's an example analytics tag that might be produced for use in an analytics adapter:
 
 ```json
-[{
-    "pub_banniere_haute": {
-      "greenbids": {
-        "fingerprint": "ad63524e-b13f-4359-a975-dba9b5dc08f4",
-        "keptInAuction": {
-          "improvedigital": false,
-          "appnexus": true,
-          "pubmatic": false,
-          "rubicon": true,
-          "teads": false
-        },
-        "isExploration": false
-      },
-      "tid": "2c445309-06b2-47b2-a724-4aeef15faeb8"
+{
+  "activities": [
+    {
+      "name": "greenbids-filter",
+      "status": "success",
+      "results": [
+        {
+          "status": "success",
+          "values": {
+            "pub_banniere_haute": {
+              "greenbids": {
+                "fingerprint": "ad63524e-b13f-4359-a975-dba9b5dc08f4",
+                "keptInAuction": {
+                  "improvedigital": false,
+                  "appnexus": true,
+                  "pubmatic": false,
+                  "rubicon": true,
+                  "teads": false
+                },
+                "isExploration": false
+              },
+              "tid": "2c445309-06b2-47b2-a724-4aeef15faeb8"
+            }
+          },
+          "appliedTo": {
+            "bidders": "bidderA",
+            "impIds": "impId1"
+          }
+        }
+      ]
     }
-}]
+  ]
+}
 ```
 
 ## Maintainer contacts

prebid-server/pbs-modules/index.md

@@ -132,9 +132,11 @@ hooks:
   }
 ```
 
-{: .alert.alert-info :
-Execution plans can be placed in account configuration, but depending on how modules are enabled in your environment, it can be inconvenient to provide instructions to place the highly technical execution plan into the account config. Some organizations have
-chosen to keep all execution plans in host-level config, then enabling the `require-config-to-invoke` option as described in the next section.
+{: .alert.alert-info :}
+Execution plans may be placed in account configuration, but depending on how modules are enabled in your environment, it can be inconvenient to provide instructions to place the highly technical execution plan into the account config. Some organizations have chosen to keep all execution plans in host-level config, then enabling the `require-config-to-invoke` option as described in the next section.
+
+{: .alert.alert-warning :}
+Note that if there is more than one execution plan (e.g. one the host level and one the account level) all of them will be triggered and the module invoked processed several times. 
 
 ### 3. Supply the module with configuration