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.