Interfaces are maintained in the Interface Library in the Library section of your solution. Note that there are two types of interfaces: Interface and Composite Interface. Interface Documentation can only be done for Interfaces. Refer to appendix to find more details on Composite Interfaces and how they integrate with Interfaces and Interface Documentation.
To create a new Interface call the context menu and select New ->Interface. Note that you can also create interface folders to further structure your Interface Library in regard to application area, regional aspects, relevance, or other logical structure elements which apply to your scenario.
Besides the Name, the newly created Interface contains mandatory parameters which you have to fill: the Sending Logical Component Group, the Receiving Logical Component Group, and the Interface Technology. Note that there’s an additional field called Middleware Logical Component Group, which you can use to document simple interface flows involving three systems. Typically, this applies to interfaces including a middleware component like SAP PI / PO. See chapter Document Interfaces with Middleware Component to find more details on this scenario. If the interface flow includes different steps in one or more components it’s better to use Composite Interfaces. A Composite Interface can also incorporate Interfaces – see chapter Interface vs Composite Interface for more details.
All fields provide value helps. Table 1 lists all interface technologies available in standard. If no interface technology describes your interface sufficiently, you can also create custom interface technologies.
Table 1: Standard Interface Technologies
Application Link Enabling / IDoc
EDI using IDocs
General file-based interface
HTTP / WebService
Java Message Service
Other, not listed technology
SAP Process Integration / Process Orchestration
(Both subtypes provide a comprehensive list of PI adapters)
Remote Function Call
Remote Database Access
Once the Interface is available in the Interface Library you can create documentation for it. To do so, call the context menu in the Elements of… box of your Interface and select entry New ->Interface Details ->Interface Details. This automatically opens the Integration Repository in a new window. There you can maintain the interface attribute data.
The main screen of the Interface Documentation application is divided into four sections:
- Interface header data
- Application help (hidden per default)
- Interface attributes section
- Custom attribute maintenance (hidden per default). See chapter Custom Content for Integration Repository for further details.
Interface Header Section
The header information of the interface is taken from the corresponding Interface object in Solution Documentation. Besides Branch, System Role and the Person Responsible (if maintained for the Interface object) the header data consists of the sender and receiver data. This is the name of the involved Logical Component Groups (LCGs) and the actual technical system data for the current context (the branch, site, and system role the Interface Documentation was created for). Note that the optional middleware LCG is only displayed if you maintained it in Solution Documentation.
Interface Attributes Section
The attribute maintenance section consists of four major areas, which are arranged in tabs:
- Technical Attributes: to classify the type of the interface in more detail
- Routing Attributes: to document the communication profile (like communication partners, destinations etc.)
- Functional Attributes: to maintain basic business-related data (like interface volume, peak times)
- Further Details: to provide additional interface information in free text format
Each interface technology has its own set of attributes which is visible in the Technical Attributes and the Routing Attributes area. Functional Attributes don’t depend on the interface technology. Every attribute is optional to maintain, except for the interface subtypes (see below). Refer to appendix for a short description of all SAP standard attributes.
The interface technology as maintained in Solution Documentation is displayed at the top of the Interface Attributes section. Optionally the processing type of the interface – the so-called Quality of Service – can be selected per dropdown menu. Possible values are:
- Best Effort (synchronous processing)
- Exactly Once (asynchronous processing)
- Exactly Once in Order (asynchronous processing)
Refer to SAP Online help for further details on the Quality of Service (for example via path Technology Platform ->SAP NetWeaver ->SAP NetWeaver 7.3 ->Application Help (Function-oriented View) ->Process Integration ->Advanced Adapter Engine ->Quality of Service).
In case an interface technology provides subtypes (see Table 1 in Create Interface in Integration Repository) the interface attribute data only show up if you select a subtype from the dropdown menu. Note that you can change the subtype afterwards, but then all already maintained attributes values are discarded!
For interface technology PI you must choose if the managed system is a dual-stack or JAVA-only installation. Then you can define which adapter types are involved in the processing on sender and receiver side. Based on this selection the interface attributes show up accordingly. Again, you can change the selection afterwards, for example you can change the adapter type if the PI interface was changed. Then all adapter-specific attribute data is lost too; common attributes which are not adapter-specific are kept, however. See chapter Document Interfaces with Middleware Component for further details.
Input help for attributes
Most attributes provide dynamic value helps or static domain values. While the static values can be obtained by dropdown menu, dynamic value helps typically retrieve the available values from the managed system per remote function call. When you call such a value help you first have to decide from which system the values should be retrieved from (can be sender or receiver system of the interface, or the middleware component if maintained). Based on this selection and further, optional filter values the managed system is called, and the corresponding values are shown in a table.
Some attributes allow you to maintain multiple values. Use the Plus (+) / Minus (-) buttons to add or remove attribute values.
System-dependency of attributes
Many attributes that you can maintain in Interface Documentation are system-independent per interface. For example, if you document an IDoc interface, the IDoc message type remains the same in all system roles (the message type doesn’t change between development and production system). Other attributes, however, depend on system-specific settings. For example, an RFC destination is different for each particular system and thus must be maintained as system-specific.
System-independent attributes are marked with the Chain icon ( ). The attribute value you provide for such an attribute in one solution context (in a dedicated branch, site, and system role) remains the same in all other contexts of the same branch. If you change a system-independent attribute in one context, it will automatically be updated in all other contexts within the same branch, too.
System-dependent attributes are not marked with the chain icon. Such attributes must be maintained in each context within the same branch independently.
Peak Times Maintenance
In Functional Attributes tab you can provide peak times of the interface. The corresponding attributes are maintained in a separate window which you open by clicking the link Maintain Peak Times.
- Peak Time 1: Peak Hour 08 - 09 am, Peak Day Monday => means: each Monday between 08 - 09 am
- Peak Time 2: Peak Hour 03 - 04 am => means: each day between 03 - 04 am
- Peak Time 3: Peak Month December => means: whole December
You can add or remove rows with the Add / Remove buttons. When finished simply press the Done button to return to the main screen. Be aware that the values are saved only when you press Save or Save and Close in the main screen.
Interfaces involving more than one interface
Sometimes the interface you like to document is not a point-to-point connection, but includes a middleware component that simply takes over the routing of the message data to the right target component. A prominent example for such middleware is SAP Process Integration / Process Orchestration. Integration Repository is optimized to incorporate interfaces including SAP PI / PO as a middleware component. This is detailed in the following section.
However, you can of course include any middleware that is used in your landscape and create simple three-component interfaces. Be aware that this could require the use of two separate interface technologies for the whole interface (from sender to middleware, and from middleware to receiver), which is not supported by Integration Repository. In this case you can:
- Create two separate point-to-point interfaces with the corresponding interface technologies and combine them in a Composite Interface or
- You could create a custom interface technology with appropriate interface attributes which describes the interface processing via the middleware in a sufficient manner. In this case you can stick to Interface objects in Solution Documentation instead of using Composite Interfaces, and you can document the interface with all the necessary attributes as usual.
PI / PO Scenario
For the SAP PI / PO scenario the setup takes place as follows:
- Create a new Interface in the Interface Library which has a Sender LCG, a Receiver LCG, and the SAP PI / PO LCG as the Middleware Component. Select SAP Process Integration / Process Orchestration as interface technology.
- Then create a new Interface Details element from the context menu. In the Interface Documentation UI you
can see all three involved system in the header section.
- Next select the PI Installation Type and the right Sender Adapter and Receiver Adapter for the current interface.
- The list of assigned attributes is then shown below. Depending on the chosen adapter types the attribute maintenance area could be divided into up to three sections, Sender Attributes, Common Attributes, and Receiver Attributes. Common attributes don’t depend on the chosen adapter type (like the PI channels used in this interface, or the sender & receiver data like party, service, interface name and interface namespace).
Sender and receiver attributes are specific for the chosen adapter type and can be used to describe additional properties of the inbound or outbound processing.
Note that the value helps for the interface attributes let you select the data source which typically is the middleware component in this kind of three-component interfaces.