Skip to Content
Author's profile photo Former Member

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.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jochen Bayer
      Jochen Bayer

      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