Hello Team,

We are planning to create  generic services specific to different target applications. Here one target application can have multiple different services for which there will be only one generic wrapper service is required to create in API Manager. The same service should automatically scan the requested method and the relative path of the request to call the respective target service.

Here again the URL pattern of target service will remain same as generic wrapper service created in API Manager except the context path. Also it should capable to trace the requested URLs and methods (Get/Post) of wrapper service and accordingly create exact target endpoint and methods by reffering the same before calling it.

The Idea behind this approach is to reduce the development overhead and maintenability for each specific end point of  a single target application.

Below are few sample cases to understand more.

For example:
Generic wrapper URL - https://devapi.sbigeneral.in/BaNCSO2MS/MotorPolicyService/Policy/14.0/getPolicyDetailXML?proposalNumber=922745215107022

Here below are the further breakups of Generic wrapper URL, which can be reffered to further dynamically create the target end points before calling it inside the wrapper service.

Context Path - https://devapi.sbigeneral.in/BaNCSO2MS
Application Name - BaNCSO2MS
Relative path of end point - /MotorPolicyService/Policy/14.0/getPolicyDetailXML?proposalNumber=922745215107022
Method type - Post / Get (Note - will be decided at run time based on the request)

Expected Target URL should be prepared based on above artifacts received at generic wrapper service request.

Target URL - https://uat2-udaan.sbigen.in/BaNCSO2MS/MotorPolicyService/Policy/14.0/getPolicyDetailXML?proposalNumber=922745215107022

Context Path (Static) - https://uat2-udaan.sbigen.in/BaNCSO2MS
Application Name - BaNCSO2MS
Relative path of end point - /MotorPolicyService/Policy/14.0/getPolicyDetailXML?proposalNumber=922745215107022

Hi Nrusingha,
If your input request has information that could be used as a lookup key in some table, you should be able to parse out that information from the request, look it up in your table to set a context variable for your invoke policy target-url, and then just reference that variable in the invoke policy.  As to where that lookup routing table lives, your choices would be off box where you'd have an invoke that retrieves it via an invoke policy and has a document cache policy so you don't hammer your backend all of the time, or if the data is more static, you could have it in a local file that is provided via a Gateway Extension.  You'd read the file, also suggest that the local file be in your document cache rules, and then do your lookup.

Best Regards,
Steve Linn