Skip to end of metadata
Go to start of metadata

Integration Repository, earlier known as Interface Documentation, was available in SAP Solution Manager 7.1 as part of the project and solution maintenance (transactions SOLAR01 and SOLMAN_DIRECTORY, respectively). For SAP Solution Manager 7.2 Integration Repository was re-designed and improved. Of course, an automated data transfer into this new application is possible. All old projects and solutions which you would like to activate for SAP Solution Manager 7.2 during the Content Activation procedure will also include the Integration Repository data. Due to technical reasons and to clean-up waste data the old content is not fully transferred into Integration Repository in Solution Manager 7.2. The details and specifics of the data transfer is explained in the following.


The general Content Activation procedure is not discussed in further detail here. If you would like to know more about it you can refer to the Content Activation Wiki in the SAP Community Network (SCN). This covers all aspects of Content Activation, including an FAQ section and a blog with detailed information. The latest version of the Solution Documentation Content Activation Guide can be found at the following location: à SAP Components à SAP Solution Manager à <current releaseà 5 Upgrade à Solution Documentation à Content Activation Guide

Interface Technologies in Solution Manager 7.2


In general, all interface technologies from Solution Manager 7.1 are available in Solution Manager 7.2, too. However, the approach has slightly changed: the number of interface technologies is reduced, but subtypes are introduced to describe variations of an interface technology. This helps to find the right interface technology faster, and still enables you to document the interface in the proper manner. Refer to appendix to find a mapping between interface technologies in Solution Manager 7.1 and interface technologies and subtypes in Solution Manager 7.2.


This flexible approach is especially useful for interface technology SAP Process Integration / Process Orchestration with its high number of adapter types. In Solution Manager 7.1 each adapter type had its own interface technology. This is now reduced to one interface technology with two subtypes which reflect the installation type of the SAP PI / PO system (dual-stack or JAVA-only installation), and a list of corresponding adapter types which can be maintained on-the-fly in the Integration Repository. Note that during the migration process installation type Dual-stack is set per default for all PI interfaces from Solution Manager 7.1.

Migration of Interface Attributes


In general, the new Integration Repository in Solution Manager 7.2 contains (almost) all interface attributes as available in Solution Manager 7.1. For some interface technologies new attributes are introduced to fill gaps in the standard attribute set, or to accommodate new developments in the corresponding interface technology. This applies especially to SAP Process Integration / Process Orchestration.


In a few cases old attributes are merged (typically because two very similar attributes existed for the same interface technology in Solution Manager 7.1) or even discarded (typically because the attribute was not meaningful enough to characterize the corresponding interface technology). Refer to Table 2 and Table 3 to find a list of all attributes which are affected by these housekeeping activities. If you still need to have one of those attributes in Solution Manager 7.2, too, you have the possibility to create it in custom namespace as described in chapter Custom Content for Integration Repository. Sometimes only the attribute names are slightly adjusted to make their meaning clearer, or to streamline attribute names in case of merging.


Table 2: Interface Attributes discarded in Solution Manager 7.2

Interface Attribute


Used in Interface Technology   (Solution Manager 7.1)

Reason for Discontinuation


Customer   Modifications Done?

All XI / PI technologies

Not relevant


DBMS Connection Name


Not relevant


Inbound: RFC   Destination (used for execution):

RFC - queued (qRFC)

Not meaningful (no inbound   RFC destination exists in qRFC inbound processing)


Proxy Type:

XI Proxy ABAP;


No longer needed since represented by PI subtype


Receiver Agency:

All XI / PI technologies

Not relevant


RFC Destination registered in qRFC outbound scheduler?

RFC - transactional (tRFC)

Not relevant


Sender Agency:

All XI / PI technologies

Not relevant


Table 3: Merged Interface Attributes

Old Interface Attribute


Used in Interface Technology   (Solution Manager 7.1)

New Interface Attribute





LogOn Group on Receiver (SMLG):


RFC Server group for immediately processed IDocs (TA OYAE):








LogOn Group on Receiver (SMLG):


RFC Server group on receiver   (RZ12):

RFC - asynchronous (aRFC); RFC - background, queued units (bgRFC);

RFC - background, transact.units (bgRFC)







Inbound: Inbound Queue   Name(s):


Outbound : Outbound Queue   Name(s):

RFC - queued   (qRFC)



The available attribute values are usually transferred unchanged to the new application in Solution Manager 7.2. In case of merged attributes only one attribute value can be kept. Table 3 shows which interface attribute is the preferred one in case of ambiguities, that is, which of the attribute values are kept in case multiple interface attributes are merged and mapped into a single interface attribute in Solution Manager 7.2. The relevant old interface attribute is underlined in the table.


Finally, a special rule applies to the migration of Solution Manager 7.1 attribute Responsible Person.


There is already an attribute called Responsible which exists globally in Solution Documentation for all objects, for example for the Interface object. So, there’s no need to have a similar attribute with same semantical meaning being maintained in Integration Repository. During migration, the attribute value from the old Responsible Person attribute is not transferred to repository. Instead, this old Responsible Person attribute shows up on the right-hand side in Solution Documentation browser under the area Technical Information from Migration.  It can be viewed there and – if necessary – copied manually into the regular Responsible attribute for the Interface object.


The regular Responsible attribute also shows up in Integration Repository as display-only attribute.




Migration of Custom Interface Attributes


Solution Manager 7.1 provided the possibility to create custom interface attributes and to assign them an interface or interface step in the project / solution structure. If available such custom interface attributes showed up for all interface technologies and could be maintained along with the SAP standard attributes.


During the Content Activation process such custom attributes are transferred into Solution Manager 7.2. However, only the custom attributes assigned to an interface in Solution Manager 7.1 show up in Integration Repository. Custom attributes assigned to an interface step in Solution Manager 7.1 are administered by Solution Documentation itself. Such custom attributes show up in the Solution Documentation browser on the right-hand side of the corresponding Interface Step object. The reason for having this distinction is simple: Integration Repository in Solution Manager 7.2 is assigned to the Interface object in Solution Documentation. Here it’s not possible to have interface steps. These are only allowed for Composite Interfaces which, in turn, don’t allow you to maintain interface attributes. Refer to the appendix to find more details on the differences between Interfaces and Composite Interfaces in Solution Documentation. These surrounding conditions require two different migration paths for the custom interface attributes.


The following rules apply during migration of custom attributes to Integration Repository:

    • A custom attribute is only re-created in Solution Manager 7.2 in case there was at least one interface in Solution Manager 7.1 where an actual attribute value was provided to the corresponding custom attribute. The assumption behind this rule is that if a custom attribute was not used anywhere in projects or solutions, it’s not relevant for transfer it to Solution Manager 7.2. On the other hand, if it’s still needed you can easily re-create it in the custom attribute maintenance transaction AGS_DCM_CUST_IFDOCU.
    • A custom attribute is only assigned to those interface technologies where it was actually used in Solution Manager 7.1 (again: where at least one attribute value was provided). The advantage in the new Integration Repository is that custom attributes can be assigned to particular interface technologies only. This was not available before. If the custom attribute is supposed to show up for other interface technologies as well you can easily assign it via the custom attribute maintenance.
    • Custom attributes are re-created in Solution Manager 7.2 respecting the following naming convention: Z_<old attribute identifier>. For example, if the old attribute had the identifier CUST_MESTYP, the attribute is created with the identifier Z_CUST_MESTYP in Solution Manager 7.2. The description of the attribute is transferred unchanged. In case the old attribute already started with Y* or Z* (which was not a must in Solution Manager 7.1), the identifier is taken over unchanged (because it already obeys the custom namespace conditions in Solution Manager 7.2).
    • The corresponding attribute values are taken over unchanged.

Target Branch for Integration Repository Data


During Content Activation procedure you can choose to which solution and target branch the old projects and solutions from Solution Manager 7.1 should be transferred to. The selected target branch is also used to store the Integration Repository data. As there is no way to define a more detailed solution context during Context Activation, the data is stored for all combinations of sites and system roles in the target branch. This means, when you open the solution the first time after Content Activation, you will find the same Integration Repository data for all sites and system roles. System-dependent attributes then might need to be adjusted by you manually to reflect specific system settings per combination of site and role.


It’s not possible to transfer the data to multiple branches during Content Activation. In case you need the data right after Content Activation in further branches, too, you can use report R_AGS_DCM_ADD_IFATTR_VALUES to copy the data from one branch to another. Note that this report is available in standard only as of Solution Manager 7.2 SP04. For SP03 version you can bring the report into your system by implementing SAP note 2343988.

Note that you must not use this report aside from Content Activation! Its only purpose is to add the interface attribute data to additional branches right after Content Activation. If you already worked with your solution productively and then start the report, you risk overwriting existing interface attributes. This interface attribute data is then lost since there are no procedures to (programmatically) return to an earlier version of your Interface Documentations.

The report works as follows:

  • In section Select source data you have to select the Solution and the Source branch from which you like to copy the interface attribute data from.
  • In section Select target data you have to maintain the Target branch to which the attribute data should be copied to, as well as the Target site and the Target role(s).



Note that all screen fields provide value helps which you should use to ensure a proper functioning of the report. Fill the screen fields from top to bottom, since the value help data always refers to the input you provide in the previous fields. Parameters Solution, Source branch and Target branch are mandatory. The value help for parameter Target branch is reduced by the branch as maintained in parameter Source branch (since the intention is to copy the interface attributes from one branch to another in the same solution). Parameter Target site can be filled with an exact value from the value help. If you would like to copy the data to all available sites in the target branch, you can also fill this field with the wildcard character (*). Parameter Target role(s) can contain multiple entries or even complex entries according to the select-options logic (providing ranges, excluding values etc.). If you leave this parameter blank or provide the wildcard character, all available roles in your solution are addressed.


When all input data is maintained you can execute the report. The system then reads on database level all interface attribute data from the source branch, and fills it into the selected targets, i.e. all valid combinations of target branch, target sites and target roles as maintained which actually exist in the solution. Note that in case the Test run flag is set the copy is only simulated, no data is stored on database. Only if you remove the flag the data is actually written to database. The report generates an output which displays all LIFOs which were created, together with the actual target data (branch, site, system role). After successful execution you can view the interface attribute data if you open the corresponding Interface Details elements in the solution contexts to which you copied the data to.





  • No labels