Overview
It's currently necessary to make code changes in edge-orders when integrating with new vendors. The type query argument informs the edge module where the request is intended for.
For instance, we have type=GOBI
which routes requests to mod-gobi, but if I were to integrate with vendor FOO we'd have to update the edge-order code to route those requests to mod-foo.
Instead it would be great if we could make this configuration driven
h2. Approach
h2. Acceptance Criteria
* A formal schema is defined and used to validate configuration files.
* Appropriate 4xx responses are returned if a request is made for a type w/o a mapping
* unit tests are udpated
* a sample mapping file is checked into git for reference - with the gobi mappings
* mappings for non-existent endpoints are ignored - a warning should be logged
* errors parsing the mappings should be logged
Approach
Define mappings, update edge-orders to read these mappings at init time, and use them to route requests based on the "type" query argument.
Making the "proxyMethod" property optional might help make these mappings less verbose, where the default method used in the proxy request is the same as the original request.
The config file would location would be passed in via the system property, similar to how the secure store properties file is specified (see edge-common)