Flexible way to specify Layer 2 Config

[vbabuEM]

Problem
Protocol Server currently has a mechanism to specify a different validation file other than core validation file to validate the messages it receives (search, select, on_search, on_select etc). Typically this facility is used by networks which have Layer 2 config file(Beckn ONIX networks mandate layer 2 config)

Currently when layer 2 config is enabled, the logic to choose the layer 2 config file is fixed.

1. The context.domain and context.version field values in the message are concatenated, separated by underscore.
2. Any colon in the string is replaced by underscore
3. An extension of .yaml is added to it and the file of this name is searched in the schemas folder.
   For example if the context.domain is "dsep:jobs" and context.version is "1.1.0", then the layer 2 config is assumed to be at schemas/dsep_jobs_1.1.0.yaml.

This method is fixed and is not flexible. Some examples where it falls short are:

1. If a layer 2 config is specific to country/city
2. If multiple domains want to use the same layer 2 config
3. The file to be used depends on any other field in the payload.

Some initial proposals

1. In the config, we can use a template mechanism similar to the one used in JavaScript strings. For example layer2ConfigTemplate: "${context.domain}_{context.version}.yaml" . This example gives the same value as what we currently use, but since we can specify any field, it takes care of problems 1 and 3 mentioned in the problem section. However this scheme does not allow a way to map multiple criterion to a single file.
2. Have a list of key value pairs (filter-filename). Filter can specify the conditional in JavaScript and filename can provide a template literal string like in solution 1. Using code snippets in the filter might expose us to unintended behaviour. An example that gives the current behaviour would probably look like this.

{
  "layer2ConfigFileMap":[
    {
      "filter": "true",
      "filename":"${context.domain}_${context.version}.yaml"
    }
  ]
}

3. A third solution could be similar to option 2, but replacing the JavaScript in the filter, with a Query DSL. It might be an over engineered solution for this problem.

cc: @ravi-prakash-v @faizmagic @em-abee @shreyvishal

[rajaneeshk90]

HI All,

Can we please have this discussion and finalise a solution for this ? This would soon be needed for the Onix layer2 validations.

Thanks,

[vbabuEM]

This discussion also came up in the ONDC initiative. Restarting the discussion on this including them

cc. Tanya
cc. Binu (I will send a link to them)

[vbabuEM]

cc @rajaneeshk90 @ravi-prakash-v

[viraj89]

Same topic on this ticket - beckn/beckn-onix#94

[vbabuEM]

Tagging @binrange @tanya-ondc since this has come up in the ONDC discussions.