Skip to end of metadata
Go to start of metadata

Solution Administration and Solution Documentation in Solution Manager 7.2 works with branches, to enable you to separate your productive solution content from new content that is currently being worked on. For example, if you run an implementation project to include new systems into your landscape, you can document the project in a separate branch (for example Development branch). When the project is finished and the new solution goes live, the contents of the Development branch can be brought into and merged with the contents of the Production branch. Please refer to SAP online help available at to find more details on the branch concept itself (follow the path Technology Platform -> SAP Solution Manager -> SAP Solution Manager 7.2 -> Application Help (SAP Library) -> Process Management -> Solution Administration -> Solution -> System Landscape) and the lifecycle management in Solution Documentation (Technology Platform -> SAP Solution Manager -> SAP Solution Manager 7.2 -> Application Help (SAP Library) -> Process Management -> Solution Documentation -> Lifecycle Based on Branches).

Integration Repository participates in this lifecycle. When you release an Interface Details element or a superior element which contains Interface Details elements (like a dedicated folder in the Interface Library, or the Interface Library itself), a corresponding Interface Details element is created in the target branch in the same place.         


Please note the following points on Lifecycle Management of Interfaces:

  • The original element in the source branch and the newly created object in the target branch are physically separated. Both objects carry their own LIFO ID (see chapter Technical Aspects). 
  • This means all changes you do in one branch won’t affect the corresponding object in the other branch. 
  • This applies especially to interface attributes which are system-independent. As described in chapter Maintain Interface Attributes those attributes are synchronized across all contexts (sites and system roles) in the same branch. However, they are not synchronized across different branches. This enables you to document a new version of the same Interface (for example in Development branch) without interfering with the currently active version of this Interface in the Production branch.







Generic Export / Import of Integration Repository Data

Integration Repository is part of the general Export / Import feature provided by Solution Administration. Export / Import enables you to bring selected Solution Documentation content to another context, for example to another solution in the same Solution Manager system, or to a different Solution Manager system. All details of the Export / Import functionality are described in the SAP online help available at Follow the path Technology Platform -> SAP Solution Manager -> SAP Solution Manager 7.2 -> Application Help (SAP Library) -> Process Management -> Solution Administration -> Import and Export of Content.

Export of Integration Repository Data

If you want to export your Integration Repository data, too, you have to add the corresponding Interface objects to the scope you are going to export. The Interface Details elements are then automatically included into the export file. By importing the file into the target context the Interface Details elements are again automatically created and assigned to the right Interface objects. Note that all attribute data remains the same in the target context, however, for technical reasons a new LIFO ID is generated for the Interface Details elements during import.

Import to Integration Repository

As of Support Package 07 of Solution Manager 7.2 it is possible to import interfaces and their related interface attribute data from an external source. There are two options for importing Integration Repository data: importing from the Enterprise Service Repository (ESR) of SAP Process Integration (PI) and importing from an external file.

For importing data from the SAP PI/PO, please check this page.

Import from External File

With SP07 of Solution Manager 7.2, the import of interface documentation data from external files is available. The supported file format is Microsoft Excel (.xlsx) which has to be converted to comma-separated format (.csv) with UTF-8 encoding before using the import application.

To start the import, the interface data has to be available in the prepared Excel template. You can get excel template from here. After the excel template is filled with the interface documentation data, it has to be saved in comma-separated format (.csv).

Next, you can start the External Interface Import application with transaction AGS_DCM_EXT_IMPORT in Solution Manager and switch to tab External File.

With Browse, you can select the CSV file. Clicking Import will upload the file and create the JSON file which is required for the Solution Documentation import. Download the file to your local PC.

Afterwards you follow the process for importing the interface documentation data into Solution Documentation. The process is already described at the end of section Import from Enterprise Service Repository of SAP Process Integration.


As outlined at the beginning of this guide it’s recommended to follow the best practice approach for Interface Management in SAP Solution Manager. After having documented the interfaces and their attribute data in Interface Documentation (typically done during design phase of a project) it’s recommended to configure interface monitoring at least for the most critical interfaces in the landscape (to be done prior to go-live of the project). An integration between Interface Documentation and the Interface & Connection Monitoring (ICMon) setup tool is available via the Default Values functionality which supports the smooth transition between those two phases. Attribute values which were maintained in Interface Documentation can be loaded into the ICMon setup tool into respective Interface Channels, to avoid having to configure the same data another time to get the monitoring running. This integration is independent of the entry point for monitoring setup. You can use it if you start from Solution Documentation (to configure monitoring in a business process context), or if you call ICMon setup in the context of a Technical Scenario.


There’s no 1:1 relation between the two tools, Interface Documentation and ICMon. Firstly, not all interface technologies which are available in Solution Documentation are reflected in ICMon, and vice versa. See Table 6 to find a mapping between monitoring templates in ICMon and interface technologies in Solution Documentation. All monitoring templates listed here can use the Default Values functionality and thus benefit from data already maintained in the system.

Table 6: Mapping between Monitoring Templates and Interface Technologies

Monitoring Template(s) in   ICMon

Interface Technology (with   Subtype) in Interface Documentation

Background RFC (bgRFC)

RFC (transactional bgRFC, queued bgRFC)

Batch Input


BDoc (Analyis), BDoc   (Real-time Monitoring), CRM Middleware


File (ABAP), File (Diagnostic Agent), File   (Remote)



HTTP (OData)

HTTP Client (from Introscope)

HTTP (ABAP, JAVA,   General)

HTTP Server (ABAP)


IDoc (Analysis), IDoc (Real-time Monitoring)


Process Integration (PI),   Process Integration (PI – ABAP only)



RFC (queued RFC)


RFC (synchronous RFC)


RFC   (transactional RFC)

Web Service ABAP


Web Service   (from Introscope)

HTTP (ABAP, JAVA,   General)




Secondly only selected attribute values can be loaded into the respective setup parameters in ICMon. Some attributes which are used in Interface Documentation don’t appear in the configuration of the respective monitoring templates since they are only used to describe the interface. Thus, they are not useful when configuring monitoring and feeding a data collector to select appropriate data for monitoring & alerting (example: the RFC Logon group). Vice versa, the monitoring templates contain a couple of parameters which are actually needed to check the status of an interface (like IDoc Status). This kind of information isn’t needed in Interface Documentation as it represents runtime data of single instances of the interface which is not relevant for documentation.


Rules for Default Values


If the Default Values button is greyed out in ICMon setup the functionality is not available for the corresponding interface or metric (as no mapping exists for the current context between interface attributes and monitoring configuration parameters). 


When you call the Default Values functionality in ICMon setup for one of the above mentioned monitoring templates all Interface Documentation objects  are listed which exist in the system and fulfill the following rules:

  • The interface technology of the Interface Documentation object matches the monitoring template according to Table 6.
  • Source and target system of the Interface Channel correspond to the sender and receiver system of the Interface Documentation object.

    Note that the Interface Documentation object can exist in different solution contexts depending on branch, site and system role of the solution. It can happen that the Default Values don’t show a documented Interface although you expect it to (because the same systems which you used for the Interface Channel exist in your solution, too). However, it could be that you have configured the Interface Documentation in a different solution context. In this case go to the same context in your solution where the systems behind the LCGs correspond to the source and target system of the Interface Channel, open the Interface Documentation object and explicitly save it. Afterwards the Default Values will show the Interface Documentation.
  • The client of the measuring point of the Interface Channel must be identical to the client of the respective system in the Interface Documentation. For example, if the Interface Channel measures the source system, the client of the sender system in the Interface Documentation must be identical to the source client of the Interface Channel.

    Note that this rule only applies if the monitoring template monitors ABAP systems which require you to provide a client for the measuring point. Other monitoring templates which are used for different system types (for example JAVA-based systems) don’t require you to provide a client. In this case the Default Values ignore the client of the respective systems in the Interface Documentation object.

Using Default Values in ICMon


You have to perform the following steps to use the Default Values functionality in ICMon setup:

  • Create an appropriate Interface Channel in ICMon setup. Then navigate either to the Interface or the Metric configuration tab. Press button Default Values.


  • A new window opens which shows all Interface Documentation objects matching the current Interface Channel. By selecting one of the Interface Documentation objects from the list you can view all attribute values maintained in the Interface Documentation, and to which monitoring configuration parameters they will be transferred. When you have decided which Interface Documentation data should be imported press OK.


  • You return to the ICMon setup main screen where you can view the imported attribute values. Note that importing data via Default Values overwrites all existing configuration for the current interface or parameter set, respectively. So, the recommended procedure is to import all available attribute values via Default Values first, and then add missing configuration data which was not available in the Interface Documentation. It’s possible to adjust all imported attribute values at any time.

Note: For the following scenario only a single Interface Documentation shows up in the Default Values selection dialog:

  • In Solution Documentation you have assigned an Interface object for which Interface Documentation exists to a business process.
  • Then you configure monitoring for this Interface using a monitoring template which corresponds to the interface technology of the Interface according to Table 6.

In that case it’s clear from the business process context that the monitoring you’re about to configure targets the Interface which is assigned in Solution Documentation. That’s why Default Values only provides the Interface Documentation which is attached to this particular Interface. Other documented Interfaces which technically would match the Interface Channel settings according to the rules listed above are ignored.













You can perform Impact Analysis for the interfaces in your Integration Repository to check which interfaces in your landscape would be affected when you transition to SAP S/4HANA.

Impact Analysis is performed on the caller programs of the interfaces. 

For technical prerequisites, please follow this link under the section "S/4HANA ATC Check using Custom Code Analysis'"

How to perform Impact Analysis?

  1. Take the caller programs of your interfaces documented in your Integration Repository using the Interface Search and Mass Maintenance application. For information about Interface Search and Mass Maintenance application, please follow this link.
    1. Apply filter on 'Interface Technology' and list all interfaces per solution-branch
    2. On the table listing interfaces, select all fields for display
    3. Take the attribute value that holds the caller program name for the Interface Technology in scope and copy it for all the interfaces
    4. Repeat the steps for all interface technologies and maintain a list of all caller programs in a note pad
  2. In the managed system, where the caller programs are, create a global object set in Code Inspector following the below steps:
    1. Launch transaction SCI and create an object set as shown below. Remember to create the object set with 'global' scope
    2. Under the section 'Object Selection', enter the copied caller programs and select the option using checkbox
    3. Save the object set
  3. In the Hub system (SAP_BASIS 7.51 or higher) where you perform the ATC check, create an RFC Destination to the Managed System in scope.
    1. Launch transaction ATC and choose 'Schedule Runs' under the category 'Runs'
    2. Choose 'Create' option on the toolbar and create a configuration as shown below. Enter a Series Name as per your choice.
      1. Choose a Check Variant of S4HANA_READINESS as per the intended target release of your SAP S/4HANA. For example, if your target release is 1709, choose the variant S4HANA_READINESS_1709. 
      2. On the Object Provider, choose the managed system in scope.
      3. Under the section 'Checkable Namespaces' choose 'By Object Set' and select the global object set created in your manged system.
      4. Then, press 'Save' to save the run configuration.
    3. Now, schedule the run by clicking 'Schedule' on the toolbar.
    4. Choose the Series Name using F4 Help and press 'Execute'
    5. You can monitor the scheduled run by clicking 'Monitor and Control Runs' under the category Runs on the ATC screen. Once it is completed, you can display the result by clicking the button Display Result.

How to adapt your code after finding the impact?

To get insights on the process to adapt your custom code for a successful migration to SAP S/4HANA after finding the impacts, please follow this blog.

  • No labels