POV: AIF considerations in the context of EAI
SAP Application Interface framework (AIF) is too good a solution for building business friendly interfaces.
It is so developer friendly and SAP centric that there is a chance that development teams could possibly
miss the bigger premise of EAI and middleware/ESB centric integration patterns or solutions altogether
while developing interfaces using AIF.
Performing the translation from raw data structure (inbound interfaces) to SAP structure on the destination
SAP system along with any checks, value mappings and finally calling actions to perform the business logic
is the main concept behind AIF. This is perfect for point-to-point interfaces (one source and one receiver and
one of the two being a SAP system).
However, not all interfaces are point-to-point. Numerous integration scenarios are in use which employ various
EAI patterns like Canonical data model or Content based routing etc. For instance, in a Canonical data model,
there is an intermediary structure or Canonical data model. Although we are using AIF, the complete end-to-end
Integration pattern should still be preserved and we should not be building a solution with point-to-point interfaces
using Interface Variants etc. in AIF. What could be a possible solution here is that the Canonical data model
becomes the raw data structure and the translation in AIF framework is from Canonical data structure to SAP structure.
Other Integration Patterns like Content Enrichment (in our case, say lookups are only required from destination
SAP System), Content Filter, and Message Translator etc are good cases where AIF can take over the functionality
what was previously accomplished in Middleware. To conclude, while designing interfaces using AIF and leveraging
the numerous features available in AIF, we should take a step back and see if the end-to-end integration pattern is still being preserved and we are staying away from the easy tendency to create multiple point-to-point interfaces in place of an original EAI Integration Pattern or solution.
Hi Jaya,
I do not see this challenge as a middleware/ ESB / EAI tool and AIF supplement each other.
It is not the right approach to replace a middleware / ESB / EAI tool with AIF nor not consider implementing one.
AIF will help to reduce complexity in the middleware/ESB/EAI layer and move the validations close to the data and the user which will do the troubleshooting (SAP power users ,business users, functional support users, etc).
The middleware/ESB/EAI tool will still be used e.g. to retrieve a file from a non-SAP system, do the routing mapping e.g. .to a web service SAP enterprise service or canonical format and then call the receiver system, ,e.g. SAP ECC.
You can use AIF to monitor an existing SAP enterprise service or use AIF to build your custom web service based on a conical format defined in the middleware/ESB/EAI tool.
AIF will help in such a scenario to considerably reduce the implementation (no or less coding than traditional ABAP based approaches to implement web services) and less monitoring effort.
Best regards
Jochen