Skip to end of metadata
Go to start of metadata

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.

Interface

Composite Interface

  • Consists of a sender, receiver and an (optional) middleware LCG.
  • No interface steps can be maintained.
  • No interface graphic is at hand.
  • Interface technology must be provided, and it’s possible to attach an Interface Details element to document interface attributes.
  • Can consist of 1…n LCGs.
  • Allows to provide interface steps.
  • Can include interfaces.
  • Interface graphic can be created.
  • No interface technology can be assigned, and consequently no Interface Documentation can be attached directly.

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

As already described in the previous chapters there are two main objects to document interfaces and integration scenarios, Interfaces and Composite Interfaces. In addition, the Middleware Logical Component on Interface level provides some more flexibility for simple 3-component integration scenarios. However, if it comes to complex integration scenarios including more than two components it’s sometimes not easy to find the best way to document the flow in the system. In the following a few sample scenarios are described, to give you some guidance for ambiguous cases. Note that this list only contains examples and makes no claim to be complete.

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.

Composite interface with two LCGs (sender and receiver):

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:

The Interfaces have the two business systems as sender and as receiver component, respectively, and SAP PI as a middleware LCG. Of course, the roles need to be set accordingly: for request, the SAP system is the sender and the non-SAP system the receiver, for response it’s vice versa. 


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.


  • No labels