We have been using 10.5 IS in our company. Of late, we decided to upgrade to 10.15 with extended product suites which include APIGW, ATS, TN etc…
As per our systems design, both, APIGW and TN have their own IS instances (nodes) APIGW-IS and TN-IS consecutively.
We have recently started designing and coding our API based solution using APIGW.
As per the attached application design, consumers would call our APIs which are virtualized on the APIGW.
We also have an IS component (Flow service(s)) in-between the APIGW and native apps for more involved transformation, enrichment & logging etc. This IS component then in-turn calls our Native app APIs to fulfill the consumer request.
My question is; we have been advised to use TN-IS to create that IS component. However, we realized that APIGW doesnt have a direct connectivity with TN-IS and hence we are calling the TN-IS rest service over HTTP from APIGW to pass the traffic to TN-IS.
On the other hand, APIGW is on the same server as APIGW-IS and has a capability to direct invoke an APIGW-IS flow service / IS component.
Would it not be more practical to create that IS component / flow service for transformation etc. on APIGW-IS itself instead of TN-IS or are we missing something?
Kindly provide guidance based on your experience as you might have implemented such solutions in your projects / companies.
Any pros/cons would greatly help us to determine the right solution.
Thanks for your reply. Please se my response inline…
So, when you explicitly say APIGW-IS, I assume that it’s just an IS that has your business Packages/Flow/Java services - is this correct?
Yes, its the Integration server (port 5555) where the APIGW is running (Port 9072)
Do you have 1 APIGW instance that performs both Threat Protection (DMZ) and Virtualization/Mediation (internal Green Zone network)?
We have 2 GWs; external and internal. The one in discussion here is the Internal GW.
Or, is the APIGW-IS another APIGW with APIs deployed on it with Policies, etc.? Answered above
What was this advice based on? What is the problem you are trying to solve?
As depicted in the diagram, we are trying to determine a pattern for our API based traffic flow. As you might be aware of by now, there are two integration servers TN-IS and APIGW-IS. The question is, which one we should use to create our flow services etc. so that when APIGW hands over an inbound request to the IS, there shouldn’t be any lag or latency in the end-to-end process considering there isnt any direct connectivity between APIGW and TN-IS while APIGW is hosted on the same server as APIGW-IS and can directly involve an APIGW-IS flow service.
@DT30 Your questions are valid. Let me try to answer part by part.
API-GW-IS and Normal-IS - both are Integration servers and both have the same capability of writing transformation logic, so why to separate transformation in a different instance rather use the API-GW-IS itself?
It is to have a separation of concern, not to combine all logic in one bucket. It helps you to scale independently.
API-GW-IS as a Gateway component, focuses on using API features such as API authentication, authorization, API logging, API Rate limiting, API policies etc., These are typical API features.
This is the entry point of your API experience, focusing on how you expose Business APIs for your API consumers.
Also, API-GW-IS component could also be installed in DMZ layer in organizations. You don’t write business logic in DMZ instance.
Transformation logic in Normal-IS or TN-IS?
Trading networks is used for B2B partner communication. If it is internal application to application integration inside your organization, then a Normal-IS (traditional IS) for writing business logic of transformation and transportation using adapters is more an apt. What is the reason called out for recommending TN-IS for writing transformation logic if it is internal app-to-app integration?
Why not have one instance API-GW-IS1 for API, and another instance API-GW-IS2 for business transformation logic instead of Normal-IS?
Its an overhead, unnecessary components and additional maintenance. API-GW-IS2 cluster would have to run with additional 3 Elastic nodes behind, this also means additional compute. If you try to use same Elastic node as of the first cluster, then its another way in which you have put all logic’s in one bucket.
Is IS-TN not recommended at all?
If you have B2B partner involvement along with the need of exposing API, then
IS-TN as a component face your B2B partner
IS-API-GW as a component becomes a face for your Business APIs
IS-Normal as a component that has business logic of transformation, transportation using multiple adapters, and more.
Independently all the above components could scale horizontally per your needs, and with separation of concern of what logic resides where.
Trading Networks is what I’ve referred to as “document-based” interactions. (Indeed, in the long ago I had created a package with “Dx” as part of the name indicating “document exchange” but that’s another topic.) The focus here is on invoices, bills of lading, payment advice, etc. All the document types that standards such as X12, EDIFACT, xCBL, cXML, and the gazillion others define. Typically for interactions with other orgs but can be (and has been) used for internal interactions.
It is tempting to put the TN entry points in the “API management” bucket too because everyone is focused on “API”. (Side note: these days it seems that many view any call using HTTP is an “API” and if that call uses JSON, it must be “REST” right? ). Certainly TN endpoints can be put in API GW. The deciding question might be: “would doing so add meaningful value to the solution?”
Keep in mind that API GW also hosts the previous “Enterprise Gateway” function, which was previously the “Reverse Invoke Server”. Same API Gateway product, different communication path. We still use this path for “non-API” connectivity. This could be something you could do as well (and perhaps are doing?) with your TN infrastructure for outside callers to reach your custom TN entry point – I assume you’re using your own service for TN entry, and not exposing the receive service directly. Other threads on the forums cover that.
API management is really just a security proxy. “Is this caller allowed?” “Is this endpoint permitted for this caller?” “Is this caller making too many calls?” Keeps a log of all who enter and what they do. Sure, it can do additional things – transformation functions are built-in, calling services on the IS that is hosting GW is availalble, etc. But in general, this should be considered just the “bouncer at the front door.” Or the agent at the lobby front desk asking “who are you, who are you here to see, please sign the log book – thank you, please proceed to floor 21”. They don’t do any of the other “heavy lifting” of transformation or logic. Even the routing logic should be very basic.
@Senthilkumar_G comment about “separation of concerns” is the main focus.
Putting any kind of business logic on an API GW is a very bad idea. As its name very clearly says, it is a gateway for calling an API endpoint. This often has implications on its position in the network (DMZ vs. internal). But you may often also find purely internal API GWs.
Putting custom code into the same “container” (=IS) that hosts the API GW, increases the attack surface, and will likely impact the performance and stability.
Also, the auditors will probably have to say something about it as well.
). Certainly TN endpoints can be put in API GW. The deciding question might be: “would doing so add meaningful value to the solution?”