This article is part of our Integration Cookbook.
When we build integration solutions, the following characteristics (principles) of application integration should be clear and defined as goals:
- Enable Connectivity by integrating heterogeneous applications (protocol/format, security, routing, reliability)
- Transparency through centralization of integration content
- Control of interface operations through centralized monitoring
- Efficiency through a standardized and pattern-oriented development process
- Decoupling of application to minimize dependencies (separate sender from receiver)
- Reuse of integration artefacts to reduce development effort and double maintenance
- Simplification of complexity through a harmonized/unified modeling
Outside-In vs. Inside Out
The main question is: Do both applications use existing (import/export) interfaces/APIs or shall new ones be created?
- Outside-In: Interfaces are modeled from scratch (typically in ESR) and both applications implement the interface structure (e.g. defined by a WSDL) or
- Inside-Out: Connecting existing interfaces via mappings. Most of the time we find existing structures like XSDs or WSDLs, IDoc/RFC, DTDs as well as File/CSV structures and database tables. The best is to import those structures as External Definitions. However, it is much more pragmatic to simply create a Data Type and Message Type in the ESR (although this is not an outside-in approach) based on an existing file as we do not have an equivalent XSD available.
Usually mixed versions exist, e.g. the sender side has an existing CSV export format and the receiver is an SAP sytem with an Enterprise Service (ABAP Proxy)
To consider:
- Where does the business logic and integration logic take place?
- Are enrichments necessary in the sender system/middleware?
- Does the middleware have to calculate values in the mapping?
- Are look-ups needed (e.g. to convert code lists)?
Integration Considerations
Which aspects are relevant for an interface?
- Processing Time
- Realtime (Event-based/manually) vs. Batch (Job)
- Data-/Message-Volume
- How business critical is the interface? (high availability)
- Queuing/Serialization
- Error-Handling
- Usage of Acknowledgements
- Retry & Correction methods
- Archiving of messages
Business Logic in Interfaces
We hear this sentence many times: “the business logic should not be in PI / in the middleware”. Why? Where does it come from? It is a 1990´s mentality where all the integration logic was programmed into the (file) export or import program. This time is over!
It makes absolutely sense to put intelligence and integration logic into a middleware.
Sender and receiver systems/applications are typically not harmonized, so it is key to have a smart middleware to covert whatever is necessary and make them speak to each other.
Examples:
- Simple Currency/Language Code conversions
- Status Code derivation (e.g. SAP knows 80, XYZ knows only 5)
- Account determinations (G/L account, cost center, etc.) based on different criteria only the sender knows
- Apply 20% discount on an amount
- Summarize quantities of line items into a total value
- Aggregate/Split positions of (bulk/compound) messages
Those are typical mapping tasks of a middleware, not only moving field values from one structure to another and make sure the data is transported.
Another aspect is to have a clearly defined responsibility on the maintenance of a mapping table. That´s why it makes sense to have the functional IT team controlling the value mapping table (and the middleware is accessing the table e.g. remotely via lookups).
