I have a scenario to implement in API Gateway as following:
Scenario Details - Start:
I want to expose a REST API in webMethods API Gateway (v 10.11) which will take few input parameters e.g. OrderNumber, CustomerId and OrderStatus and it will then return a JSON response for order status email. The JSON response (by API) will contain a string element whose value will be later used as email text (For example: “Dear Customer, Your Order# having [some status] is under processing and will be delivered soon”)
Suppose there is a requirement that our API will have to return a particular email text (out of three different email text templates) depending upon the value of OrdersStatus input param.
Scenario Details - End:
I would like to know what is the easiest or what is the best way of achieving this functionality in API gateway?
Should I try to invoke flow service in Response Tranformation policy or Routing policy and have required logic implemented in flow service? - E.g. flow service may read input payload, extract required params from JSON, perform logic (i.e. template selection based upon required input param) and then return email text as string in JSON
Or should I try to do it without using flow service? E.g. by utilizing some specific policy (e.g. response transformation policy) in API gateway to achieve this functionality?
I am new to webMethods and API gateway and have limited knowledge about API gateway features/capabilities.
I would appreciate if experts in community can let me know one (or more) ways of implementing this scenario/functionality in API gateway. If I can get some high level idea or direction about how to do it in API gateway then I can explore & learn further in that particular direction
Whether an approach is “easiest” or “best” will depend upon a number of factors. Any responses you get in this forum should be viewed as “might work for your scenario”.
Here are my thoughts for your consideration.
API client and server only. Assuming there is an application of some sort that accepts order requests. API clients want to know the order status. The client calls the application via its API to get the status. No intermediiary.
Perhaps the application is unable to expose an API in the desired manner. Can introduce an intermediary to help. wM Integration Server is pretty good at this. Can provide payload transformation, protocol translation, etc. For example, application (back end) might only be capable of supporting SQL statements or having stored procs called to do something. The intermediary would expose, perhaps, a JSON over HTTP interface on behalf of the application. It would pass the data from the JSON payload as needed to the SQL statement or stored proc inputs, make the DB call, then return the response data in the response JSON. Or could use XML instead of JSON. Or whatever. The intermediary is between the client and the server (back end) providing a path for them to interact.
Perhaps there is no obvious/existing application that provides the desired function that would be accessed via API. Where to put that functional implementation? Many put what I would consider “application function” into the middleware tool. Certainly, the middleware tool vendors encourage this as well. And can be effective. In this case, the intermediary is also the back end.
Now that there is an API available, might want to manage that in some way. Access control. Track usage. Other fun stuff. Can introduce an API gateway (another intermediary) for these functions. Integration Server can perform some of these things but API Gateway is ready-made for such activity. Generally, the API hosts the interface definition not the implementation. The gateway passes the data on to something else that does the actual work.
The fun part of this is sometimes it is not clear which tool should/could be used for 2, 3 and 4. The functional part of “get order status” would normally be in the order application, accessed via API. But in the absence of an order application, should the intermediary host that? If so, which one, the “transformer/translater” or the “gateway”?
What to do depends entirely on your environment in terms of applications, infrastructure and available skill sets.
Client → API GW (API interface) → Application (API implementation)
Client → API GW (API interface) → Integration Server (API interface translation) → Application (API implementation)
Client → API GW (API interface) → Integration Server (API implementation)
Client → API GW (API implementation)
For your specific scenario regarding filling in email text templates, I would avoid doing that in the intermediary. An application where users can more readily update the template(s) as needed is what I would suggest. IMO, make every effort to use API GW as a pass-through only. Use it for access control and tracking and put transformation/translation elsewhere when possible.
Of course, just my POV. Others undoubtedly will have additional suggestions.
Thank you @Arundev_Chidambaram1 for your response. I will go through the links you shared in your post and get back to you in case of any question/query.
Meanwhile I have a question here, if I am going to use response transformation policy to select and return desired email text template then in that case can I leave routing policy empty?
Because in this case, my output/response will be determined by response transformation policy and hence I don’t need to call any native API etc in routing policy section. In fact I don’t have any native API to call in this case. All I need to do is to check/read input params in routing transformation policy stage and then set/update payload accordingly (e.g. by invoking IS service may be)
I am asking it because I am not sure if we can leave routing policy empty (i.e. we don’t specify any routing url/endpoint at all) or not? I never tried it before.
So if you know it, then can you please confirm me if we can leave routing policy empty (no endpoint specified) or is it mandatory to specify some routing endpoint (may be dummy one) under routing policy in API GW?
This could be viewed this way – this is not using API Gateway as a gateway. Using it as the API provider. Technically doable (though I do not recall if routing policy can be empty – I suppose you could create a dummy “backend” that does nothing on the GW IS itself and call that) but will this lead to scalability or maintainability issues later as the use the GW grows?
My .02 is that I would not do it this way. I would not have the GW create the response via the response transformation. API GW is not an “email template formatter”. That function should be implemented elsewhere. Use GW as a passthrough, not as the API implementation provider.
Thanks all for your valuable feedback. I can understand the points being highlighted in different responses related to to API gateway. Will explore alternative solutions.
