Greenbids: Add account level config for modules RTD, analytics

[EvgeniiMunin]

🔧 Type of changes

• new bid adapter
• bid adapter update
• new feature
• new analytics adapter
• new module
• module update
• bugfix
• documentation
• configuration
• dependency update
• tech debt (test coverage, refactorings, etc.)

✨ What's the context?

As discussed with @bretg and @jbogp we need to add extraction of modules params from account level config for both RTD module and analytics reporter. At the same time if the params are defined in BidRequestExt it should take precedent before account level config. This makes modules integration more publisher friendly

🧠 Rationale behind the change

account/id identifies account for specific publisher -> so if we define a config for a specific account it means it should correspond to the unique publisher id = pbuid.

Setup of default-account-config for Greenbids example in prebid-config-with-module.yaml should look like this

settings:
  enforce-valid-account: false
  generate-storedrequest-bidrequest-id: true
  filesystem:
    settings-filename: sample/configs/sample-app-settings.yaml
    stored-requests-dir: sample
    stored-imps-dir: sample
    stored-responses-dir: sample
    categories-dir:
  default-account-config: >
    {
      "auction": {
        "price-floors": {
          "enabled": true,
          "fetch": {
            "enabled": false,
            "timeout-ms": 5000,
            "max-rules": 0,
            "max-file-size-kb": 200,
            "max-age-sec": 86400,
            "period-sec": 3600
          },
          "enforce-floors-rate": 100,
          "adjust-for-bid-adjustment": true,
          "enforce-deal-floors": true,
          "use-dynamic-data": true
        }
      },
      "hooks": {
          "modules": {
              "greenbids": {
                  "pbuid": "PBUID_FROM_GREENBIDS",
                  "targetTpr": 0.95,
                  "explorationRate": 0.001
              }
          }
      },
      "analytics": {
          "modules": {
              "greenbids": {
                  "pbuid": "PBUID_FROM_GREENBIDS",
                  "greenbidsSampling": 0.001
                }
            }
        }
    }

The modules can extract fields of Account class from AuctionContext at hook call (not on spring boot)

Optional.ofNullable(invocationContext)
	.map(AuctionInvocationContext::auctionContext)
	.map(AuctionContext::getAccount)

Then depending on the calling module we get analytics or RTD Map[String, ObjectNode] modules and parse it from json.

🔎 New Bid Adapter Checklist

• verify email contact works
• NO fully dynamic hostnames
• geographic host parameters are NOT required
• direct use of HTTP is prohibited - implement an existing Bidder interface that will do all the job
• if the ORTB is just forwarded to the endpoint, use the generic adapter - define the new adapter as the alias of the generic adapter
• cover an adapter configuration with an integration test

🧪 Test plan

I have introduced a specific test case in Greenbids analytics reporter test to fallback to account level config if bid request ext config is not defined: shouldReceiveValidResponseAndFallbackToAccountLevelConfigWhenPartnerNotActivatedInBidRequest

For RTD module have modified the existing test case when partner not activated on bid request ext -> then fallback to account level config and proceed with the filtering callShouldFilterBiddersAndFallbackToAccountLevelConfigWhenPartnerNotActivatedInBidRequest

🏎 Quality check

• Are your changes following our code style guidelines?
• Are there any breaking changes in your code?
• Does your test coverage exceed 90%?
• Are there any erroneous console logs, debuggers or leftover code in your changes?

[AntoxaAntoxic]

you can skip this parsing, and just call toPartner(invocationContext.accountConfig()) and you'll get what you need (of course some null checks and json parsing exception should be handled)

also if the Partner is considered to be a representation of the account config, I suggest rename it to the Config or GreenbidsConfig (something like that)

[EvgeniiMunin]

Modified to

private GreenbidsConfig parseAccountConfig(Account account) {
    return Optional.ofNullable(account)
            .map(Account::getHooks)
            .map(AccountHooksConfiguration::getModules)
            .map(modules -> modules.get(name()))
            .map(this::toGreenbidsConfig)
            .orElse(null);
}

private GreenbidsConfig toGreenbidsConfig(ObjectNode adapterNode) {
    try {
        return mapper.treeToValue(adapterNode, GreenbidsConfig.class);
    } catch (JsonProcessingException e) {
        return null;
    }
}

The NPE is handled by the optional chain and JsonProcessingException is handled in toGreenbidsConfig

[AntoxaAntoxic]

You haven't followed my suggestion. The idea of the account config is that the module has it already as the invocationContext.accountConfig()

[AntoxaAntoxic]

@EvgeniiMunin ^

[osulzhenko]

Depends on PR: #3596

[osulzhenko]

@EvgeniiMunin fix was merged, this PR should be unlocked

[AntoxaAntoxic]

as I can see it's never checked that properties of configs are required or can't be null, so this is a NPE potentially

check other properties as well and handle them if it's necessary

[AntoxaAntoxic]

I think the execution shouldn't proceed of the config is null

yes, it shouldn't be the problem if the account config is required to invoke the module, but I guess it's still better to return the failed future in the null case

[AntoxaAntoxic]

make sure the nullable properties won't cause NPE if they're underconfigured