Multiple origin composition (MOC) is the ability to collect data from different backend systems, aggregate them in one single service and updating different backend systems while using the same user. Thus a service can be made available for several system aliases. For example, you could have two identical systems, one located in America and one in Europe, and combine them. MOC is also used for CREATE calls and the metadata. At present, CREATE calls cannot be done in all configured backend systems, but only in the default system.
This feature is only supported in Standard Mode.
This feature is relevant only for entity sets with an annotation of addressable=true.
Implementing this feature creates a different version of the service (the SAP_Origin field is added).
Proceed as follows to use the MOC:
Customize your service to support MOC.
From the SAP Gateway system, activate the desired service. For information on how to activate your service, see Register your Service in the SAP Gateway System.
Open transaction SPRO and choose SAP Reference IMG.
Navigate toto add the system aliases for the relevant backend systems and define the desired default system.
In the Service Catalog list, select the desired service. The service appears in the ICF Nodes section on the lower left corner of the screen.
In the ICF Nodes section, select the Standard Mode ICF Node.
In the System Aliases section, choose System Alias to add the system alias.
Choose New Entries or select an existing entry and choose Copy.
In the Service Doc. Identifier field, enter the ID of the service document followed by an underscore and the 4–digit version number (for example, _0001).
In the SAP System Alias field, enter the relevant system alias. Only one system is to be defined as the default.
Repeat as necessary to add the desired backend systems.
The default system is used whenever the service is not called as MOC. If you have defined more than one default system alias, the first system is used as the default.
Test the service.
On the SAP Gateway system, open the SAP Reference IMG in transaction SPRO and navigate to .
Search for the desired service with the Filter icon.
Select the desired service and choose Call Browser under ICF Nodes.
An example URL for RMTSAMPLEFLIGHT looks as follows: http://<host name>:<port>/sap/opu/odata/iwfnd/RMTSAMPLEFLIGHT;mo/
Make sure that the SAP_Origin field appears in the service's metadata.
When using multiple origin composition you can determine both the minimum number of backend systems and the maximum number of parallel backend calls. For this a new IMG activity is available: On the SAP Gateway system, open the SAP Reference IMG in transaction SPRO and navigate to .
You can use this parallelization of READ_ENTITYSET to several backend systems to achieve optimized performance. In the IMG activity you can set the following configuration parameters:
Minimum Number of Backend Systems can have the following values:
0: No parallelization
n: Parallelization will only be done from n backend systems onwards
The maximum number of parallel backend calls is always based on current resources of the SAP Gateway hub system. Additionally, you can use parameter Maximum Number of Parallel Backend Calls to limit the use of current system resources. The default value zero (0) means it only depends on current system resources.
In case of serialization the duration of a READ_ENTITYSET within a hub system is the sum of all backend calls. Contrary to this, the duration in parallel mode is just the maximum duration of all backend calls and means a minimal overhead for parallelization.
Parallelization and Skiptoken
If server paging is realized in any backend data providers, then the OData consumer will only receive results up to this backend including a skiptoken. The next call with this skiptoken or any other call with skiptoken will not be parallelized because the result has to be continued by the backend system which returned this skiptoken before.
In the context of multiple origin composition, changesets are also supported. All changeset operations for one backend are collected and sent to this backend via one RFC. You can find an example in SAP Note 1890049 .
You can flag READ feed requests of a service in MOC mode error-tolerant.
If a feed of a service is called in MOC mode, the service composes the data from all backend systems assigned to it. More precisely, all system aliases assigned for the current user and service are identified. Then the backend system of each of these system aliases is called reading the data from each system. Finally the results of each backend system are composed into one feed that is returned to the client.
To call a service in MOC mode the segment parameter ;mo is added to the service name of the request URI.
The default error behavior is not error-tolerant. If the data retrieval from any of the backend systems causes an error the READ feed request returns that error. If a service is marked to be error-tolerant this behavior changes:
An error is returned only if the data retrieval from all backend systems causes an error. Otherwise if only some of the backend systems causes an error a feed is returned to the client.
The data retrieved successfully from some of the backend systems is composed into that feed.
The data missing form those backend systems that caused an error can be requested again. For that an OData skiptoken is added to that feed.
<link rel="next" href=" TravelagencyCollection?$skiptoken=MISSING_DATA_FROM__1_2"/>
For this an IMG activity is available: On the SAP Gateway system, open the SAP Reference IMG in transaction SPRO and navigate to .
If a service is not listed in this configuration the service is not error-tolerant. You can create an entry for each service that shall be error-tolerant.
Customers might have different timelines in updating their backends. In this context internal policies of customers might prevent the upgrades of certain backends simultaneously. Thus, an enhancement might reach one of a number of backends at a later point of time. When multiple origin composition is used in such a scenario this might lead to issues because of a mismatch in the metadata. The metadata in single backends differs due to inhomogeneous extensibility or maintenance cycles.
To remedy this, a service sub-version is available. This sub-version can be used within multiple origin composition to load the metadata of the minimal service sub-version from the cache, in order to work on the basis of this minimal sub-version.
In the central transaction for activating and maintaining services the flag Metadata is available for an SAP system alias. For requests in multiple origin composition mode this flag specifies the backend system from which to retrieve the metadata. The processing mode is as follows:
The system searches for all system aliases assigned to a service for a user.
If more than one system is found, the one system with the Metadata default flag is chosen.
If none of the found systems has the Metadata default flag assigned the one with the Default System flag is chosen.
If none of the found systems has the Default System flag assigned an error is triggered.
In addition, developers can use method SET_SERVICE_SCHEMA_VERSION of interface /IWBEP/IF:MGW_ODATA_MODEL to set the SAP schema version.