As outlined in the previous chapters Solution Documentation provides two different object types to describe data exchange: Interfaces and Composite Interfaces. The main differences between the two types are as follows.
The purpose of an Interface is to describe a point-to-point connection (and for simple cases also three-component interfaces) with all technical and functional attributes using the Interface Documentation functionality. A Composite Interface, however, is the preferred solution to document complex interfaces and integration scenarios running over multiple components, using different point-to-point data exchanges between the single components, and having additional processing logic which can be described with interface steps. Interface and Composite Interface complement one another and can be integrated with each other seamlessly.
Creation of Composite Interfaces and Interface Graphics
To create a new Composite Interface add the corresponding element from the context menu using New -> Composite Interface in the desired place in Interface Library. Name the Composite Interface and save.
Next you can add Interfaces and Interface Steps via New -> Interface or Interface Step to the Composite Interface, to create the processing logic in your integration scenario
When you have created all elements you should also draw an interface graphic. Switch to the Composite Interface level and select entry New -> Interface Diagrams -> Interface Diagram
This opens the graphical editor where you can arrange the Interface Steps in the desired sequence, draw connection lines between the respective Interface Steps, and assign Interfaces to Intermediate Message Events (see next chapter).
Integration between Interfaces and Composite Interfaces via Intermediate Message Events
The graphical editor in Solution Documentation is based on the Business Process Model and Notation (BPMN) concept. For more information about BPMN in general, see http://www.bpmn.org. You can obtain more details about the graphical editor in Solution Documentation from the respective end user guide.
The connection between two Interface Steps running on two separate LCGs – which represents a point-to-point interface – can be achieved by adding so-called Intermediate Message Events (IME) to the graphic. The IME is the anchor point for further elements and thus can be used to attach Interfaces to the Composite Interface. Click the Assign ( ) button next to the IME to open a dialog box. All Interfaces from the current Interface Library show up which have the right sender and receiver LCG. You can create multiple assignments to realize variants of the integration scenario. Already assigned Interfaces are listed, and you can remove them if necessary.
You can assign both Interfaces and Composite Interfaces to business processes in the Business Processes section of Solution Documentation.
Often it’s not desired to have all technical details of the data exchange on interface level visible in the process diagram directly. Therefor you can assign Interface and Composite Interface IMEs in the process diagram which “hides” the technical interface details from the process flow. Still all interface data is available, and you access it via forward-navigation if needed.
How to Document Integration Scenarios
Sample scenario 1: Synchronous retrieval of Business Partner data from an external system, including middleware system
An SAP ECC system needs business partner information from a non-SAP component. To facilitate the message transfer SAP PI/PO is used as a middleware component. The data is retrieved in synchronous manner, which means the caller (SAP ECC) requests the data from the non-SAP system and awaits the response in the same session. As it’s synchronous processing this scenario should be regarded as a single “interface” (or better: integration scenario) and should be documented accordingly. There are two options to achieve the same in Solution Documentation.
Use a Composite Interface and hide the PI system behind two Interfaces. These two Interfaces represent the request and the response track of the integration scenario. In an Interface diagram in Solution Documentation this could look like the following:
Composite interface with three LCGs (sender, receiver, middleware):
Here the SAP PI system is directly contained in the Composite Interface. In addition, you have to create 4 simple interfaces, to cover the communication SAP->PI, PI->non-SAP, and backwards, accordingly.
For those Interfaces no middleware LCG is needed. However, it’s questionable what to provide as an Interface Technology: the communication between ECC and PI is only a part of the whole PI interface, as well as the communication between PI and non-SAP. So, it’s not fully correct to provide Interface Technology SAP PI/PO to all Interfaces in this approach since redundant information would be maintained if you like to provide interfaces attributes, too.
In this case the first option might be favourable as it is less effort to maintain the data in the system, and interface attributes can be provided in a proper manner. The second option can make sense if you need to maintain additional processing logic on the different LCGs using interface steps.
Sample scenario 2: Asynchronous exchange of Business Partner data between two systems, including a middleware system
Basically, this is the same integration scenario as scenario 1), however, this time the data is exchanged in asynchronous manner. In this case, request and response are two different interfaces (one running from sender to receiver, one from receiver to sender). If additional processing logic is at hand (like Interface steps in the middleware) two Composite Interfaces have to be created for request and response. Otherwise it’s recommended to create two Interfaces for request and response and add the middleware system as a middleware LCG. Finally, you can still bind the whole integration scenario (the interfaces for request and response) in a Composite Interfaces, to visualize that those two tracks belong together.