
Describes the ability to collect data from different backend systems, aggregate them in one single service and update different backend systems while using the same user.
Multiple origin composition (MOC) is the ability to collect data from different backend systems, aggregate them in one single service and update 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).
To use the MOC, proceed as follows:
Customize your service to support MOC.
From the SAP NetWeaver Gateway system, activate the desired service. For more information, see Activate and Maintain Services.
Open transaction SPRO and choose SAP Reference IMG.
Navigate to to 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.
In the SAP NetWeaver 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 an IMG activity is available: In the SAP NetWeaver 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 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 NetWeaver 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.
Performance Improvement
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.
Changesets
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
.