SAP AIF: So what is it all about?

[arijitkumardas]

Background

For years businesses have wanted a central cockpit to monitor and correct interface errors. In the past most interfaces were IDoc centric. IDoc errors were easy to monitor and with some training a business SME could correct the error and repost/reprocess it using a suite of transactions and mechanisms. One could implement a bespoke Workflow to notify an user or an Organisation Unit if a specific Business Object failed to post. Transactions like BD87 would allow you repost the failed IDoc once the underlying data issues were resolved. Often this would be a missing customising entry or missing/incorrect master data which the SME could fix easily and then repost the IDoc. Or if the data sent by the source system itself was incorrect you could request your Customer/Vendor to fix the data on their end and resend the message (and hopefully the IDoc would post successfully this time round).

However as SAP and organisations moved more towards an SOA centric approach to interface applications and do business with their partners there seemed to be no genuine tools for business users to correct errors in the system. SAP then introduced Forward Error Handling (FEH) and Error and Conflict Handler (ECH). This was aimed at empowering end users who had the business and process knowledge but limited technical know how to correct errors on their end. FEH was based on the concept of Forward Error Recovery

Forward Error Recovery states that “The receiving system must not send an error to the calling system if that error could be handled closer to the receiving system” (SAP® Guidelines for Best-Built Applications That Integrate with SAP Business Suite by Richard Probst).

SAP AIF is a product from SAP's CDP group (Custom Development Projects) that enables organisations to achieve all this and more. It is essentially a framework that provides a business user (who may or may not be technology savvy) tools to easily monitor errors and rectify them.

"AIF" stands for Application Integration Framework; but don't confuse this with Adobe Interactive Forms (the correct term for which is of course SIFbA - SAP Interactive Forms by Adobe).

Architecture Overview

The above diagram has been taken from an SAP presentation - SAP Application Interface FrameworkOverview and Outlook (Markus Gille, SAP AIF Global Solution Owner, SAP AG and Nadia Jenkins, Business Mgr, SAP Custom Development ANZ).

Out of the box, SAP AIF currently supports only Enterprise (and Web) Services that are based on the Proxy framework. However, you can expect to see other interfacing protocols (like IDoc, BAPI, RFC) in future releases.

Use Case

I have covered some of the more common features of SAP AIF here based on what an organisation is most likely to implement. More such features will follow soon.

Error Correction

SAP AIF is a business tool that is used primarily by business users to correct interface errors.

Translation - Fix Values

Fix Values are used when a one-to-one translation is required from old to new (and new to old) field contents. In an inbound interface scenario a legacy application may continue with their old code set and pass that to the SAP system which would be based on the new code set. The reverse is also true. SAP would pass the new code set data to a legacy application and the translation from new to old will be handled by SAP AIF.

Translation - Value Mapping

Value Mapping is a complex derivation of data based on the source field contents. It may be dependent on a single or multiple interdependent data sets. Value Mapping offers a framework to configure SQL statements, Conversion Exits or a Default Value (if nothing is returned). Custom Function Modules can be configured for more complex requirements.

Data Checks

Various checks can be implemented for an interface. A check could be to allow the interface to succeed if field A = a variable or a constant, or else fail the message. This is where the business user will come in and change the contents of field A to the correct value and reprocess the interface. Of course simple (no code) and complex checks (Function Module) can be implemented.

Actions

An Action is linked to a processing step of an interface in SAP AIF. An Action results in the triggering of at least one Function Module call. An example of an Action is inserting a Balancing Line Item in an FI document (if the credits do not tally with the debit entries) prior to posting. Similarly an Action can also be used to invoke a post-processing step.

Non-Interface Scenarios

SAP AIF is not restricted to just interfaces. It can be hooked to custom built applications via APIs.

Value Add

Although majority of SAP customers would use SAP PI for interfacing it is however not a pre-requisite. SAP AIF can function just as well with interfacing protocols IDoc, BAPI, RFC, Enterprise/Web Service calls without SAP PI as a middleware broker (or for that matter any other middleware solution). The current version of SAP AIF supports Enterprise Services out of the box. To support the other mentioned protocols in the current version, the framework needs to be extended using custom code. The product roadmap however looks promising, and future releases of SAP AIF will cater for these protocols as well.

References

http://help.sap.com/saphelp_aif10/helpdata/en/5a/3eacf824e74542abbd2271238dc70b/content.htm

A Word of Thanks

Last but not the least; a word of thanks to friend and SAP Mentor sufw for his timely and tireless help on this.

Please note that this document is work in progress. It highlights the core (and more commonly used features of SAP AIF). More to follow in the next few days.