I’m fairly new to the SoftwareAG Integration stack and components (specifically Trading Network).
Currently our organization uses only API gateway and Integration server to manage the E2E transactions.
Recently we subscribe to use Active transfer server and trading partner as part of the stack.
Our business mostly support batch (via API and File) request submissions.
I understand that the Trading Networks and ActiveTransfer form the primary components of the B2B solution.
That means the Batch processing via file is well supported by ATS and TN, and one can leverage the B2B capabilities of Trading Networks to manage and deliver documents to partners securely and efficiently.
Question is - Should Trading partner be use only for partner integration to deliver documents? Or should it be used for internal systems (within the org) as well? Assuming all internal systems are onboarded as partners in TN.
(If one internal system wanna makes an API call to another internal system via API gateway (A2A), should one use Trading network to exchange payload/document? or should we limit ourselves to use TN for B2B only?)
A couple of years ago I was responsible for the Software AG-internal integration platform for everything that was related to sales. And in fact I used Trading Networks exactly like you describe (at least that is how I understand it).
All connected system were modeled as Partners and the various transaction types were represented by the TN Document Types. Esp. with TN’s capability to link transaction (parent-child) it was extremely easy to set up a business-level auditing.
Whenever something went wrong, and it was rare, it took less than a minute to find out exactly what had happened.
You can probably feel how much I still like this approach.
A word of caution though: You provide no details about your systems etc. So whether this makes sense here, needs additional consideration. But in general it is a fantastic use-case for TN in my opinion.
Additional Question : The softwareAG documentation clearly articulated the ATS to TN integrated B2B solution.
However, i couldn’t find anything thus far on the API gateway to TN A2A / B2B integration solution. I have attached the diagram whereby API GW routes the request to TN for Application to Application integration. Is this a great way to integrate A2A? Or should we NOT use TN for API integration for Application to Application?
My personal view is that TN makes a great addition, if you want to have the ability to easily trace payloads and result of transactions with very little additional coding. Especially so, if your transactions are nested and you need to able to find out exactly where in the process and because of which part of the payload things went south.
If you already have something in that direction, e.g. built on the ELK stack or similar, I would probably look into the direction of the latter.
Can you provide more information about those aspects?
This varies for everyone, but for me there is no value in distinguishing between “A2A” and “B2B”. IMO, there was some value long ago to treating these differently but not any longer. Both are simply “integration.” For any integration, one needs to consider the same characteristics. There is nothing inherently unique to one or the other. For example, if I shared the characteristics of a given integration (protocol, payload, security, etc.) would you be able to tell if it was A2A or B2B? And be certain about the conclusion? IMO, no. They each have the same things that need to be addressed in some way.
Can TN be used for internal applications? Certainly. Similar to what @jahntech.cj shared, I also used TN in the past for connecting internal systems. And of course internal with external systems. We used it as a generalized “document broker” and even added a simple form of “pub/sub” to it so that a document from one app could readily be “fanned-out” to multiple targets if needed.
One guideline to consider: does the component (TN, ATS, IS, API GW, etc.) add value of some sort. If not, don’t use it.
TN is awesome for doc exchange. I would never attempt EDI (or cXML, or the many other document-oriented solutions) without TN. For other things, as long as the main focus is a document of some sort, it is compelling. For other types of interactions, it is less so. Consider too that not all payloads are “documents”. TN as a go-between for the typical request/response call over HTTP is not a good fit.
For the “run everything through API gateway” I would offer a qualified “no.” In my current situation, we use API GW only for custom APIs that we define/control. We do not put it in front of out-of-the-box APIs of applications unless there is a specific and compelling need/value in doing so. API GW in front of TN may be useful to some degree for account management and security. Particularly if you create your own TN entry-point service (as you should) instead of having callers access wm.tn:receive directly.
As always, Very insightful information shared by Reamon and 200% agree the way we look with in B2B/TN integrations perspectives (hub/spoke/internal/external API lifecycle) :slight_smile
, it depends on your requirements.