Skip to Content


After creating a Netweaver Gateway service, you activate it on a Gateway Hub system and you specify the Backend System, from where the service will get its data. This Backend System is specified via a “System Alias”. In the transaction /IWFND/MAINT_SERVICE (on the Hub system), it is possible to specify more than one “System Alias” for a single service (see screenshot in below section). This ability is called “Multiple Origin Composition” (abbr. “MOC”, also known as “Multi Destination”).
When calling such a service which is configured to use MOC, it will collect the data from all backend systems and aggregate them in one service call.
The description about MOC can be found in the SAP Documentation:
Configuration Guide -> OData Channel Configuration -> Settings … on the Hub System -> Multiple Origin Composition
As per default, the calls to the configured Backends are executed one following the other, combining the collected data afterwards.
Since Netweaver Gateway 2.0 SP06 it is possible to define parallel execution for these Backend calls.
As you might assume: this will speed up the operation significantly!
Parallelization is used for QUERY operations, since this kind of operation might deal with huge amount of data.
Obviously, parallelization is only available for the MOC scenario.
Within the following step-by-step Guide, we will execute a simple QUERY operation two times:
First in the default mode and a second in parallel mode.
Afterwards, we compare the duration of both calls using the SAP Netweaver Gateway Performance and Trace Tool.
The prerequisites for following this guide are
– SAP Netweaver Gateway 2.0 SP06,
– an activated Gateway service with at least an implemented QUERY operation,
– at least 2 Backend Systems (to be configured for MOC)

1) Prerequisite: Multiple Origin Composition

Since parallelization of service calls makes only sense in a scenario, where multiple Backends are used, we have to configure our sample service to use Multiple Origin Composition
Go to transaction /IWFND/MAINT_SERVICE.
Choose your service and configure at least 2 System Aliases.

2) Check if parallelization is disabled

First we want to execute the default mode, which is not parallelized.
Go to transaction SPRO
Expand the IMG-tree as follows:
SAP Netweaver -> Gateway -> OData Channel->Administration->General Settings
Open the activity: Define Parallelization for Multiple Origin Composition
The following screen is displayed:
On the screen “Parallelization for Multiple Origin Composition”, the default settings are: the fields are empty, which means that the calls to the Backend are not executed in parallel mode (obviously, for parallel execution, at least two “Backend Systems” would be necessary).
For the moment, we don’t change the default settings and leave the transaction.

3) Enable tracing

In order to be able to afterwards compare the speed of the parallelized call versus the serialized mode, we need to first enable the tracing:
Start transaction /IWFND/TRACES
On the left pane, open context menu on “Users & Request URI Prefix”.
Add your user name.
On the right pane, the “Configuration” tab is displayed.
Within the drop-down field for “Performance Trace”, choose “Active”
Press “Save Configuration”.
From now on, all service requests for the specified user will be traced.
Open the tab “Performance Trace” in order to monitor the traces of the requests which will be sent in the following steps.
Find more information about the SAP Netweaver Gateway Trace Tool in the official SAP documentation:
Technical Operations Guide -> Supportability -> Performance Trace

4) Run the service in default mode

Now we run the service, i.e. we execute a QUERY operation.
You can use your favorite browser or the built-in Gateway Client for executing the service request.
In order to use the SAP Netweaver Gateway Client, go to transaction /IWFND/GW_CLIENT
Enter the URI for invoking a collection of your service.
In our sample, we execute
Note: don’t forget to specify  ;mo right after the service name, in order to indicate that multiple origin composition should be used.
Specify the HTTP Method GET, execute the request pressing the toolbar button “Execute” (or pressing F8)
The result is displayed in the “HTTP Response” pane.
In order to make sure that the response body contains data from all configured Backend Systems (as defined in step 1), we should have a look at the entries of the collection:
There should be an attribute with name  SAP__Origin.
The value of this attribute is one of the System Aliases specified in step 1).
Search for a different entry, which contains the SAP__Origin-Attribute with the second System Alias.
In our example:

5) Enable Parallelization

Now we run the service again, but this time in parallel mode.
Inorder to enable the parallelization go to the parallelization screen, as described in step 2, and enter the number of configured Backend Systems in the first field.
In our example, we have configured the service RMTSAMPLEFLIGHT with 2 System Aliases (see step 1), therefore we enter 2, as depicted below:
Leave the second field empty and don’t forget to press Save.

6) Run the service in parallelized mode

Go back to your browser or Gateway Client and execute the same service request again.

7) Analyze the performance trace

At this point in time, we have run our service two times and we have collected the performance data for both requests.
Now it’s time to have a look at the performance data.
Note: The following section is going to be a bit strenuous, you may skip it and jump directly to the summary at the end…;-)
Start transaction /IWFND/TRACES.
Open the tab Performance Trace.
There should be (at least) 2 entries, for both calls which have been executed above.
Select both lines, then press the button “Display selected entries”.
See below:
The following screen allows comparing the performance trace of both calls:
Let’s have a closer look at the details of the screenshot:
Line 1 and 19 are highlighted as they represent our two service requests.
The following line respectively prints the “Response size”. 
No matter in which mode the service call has been executed (parallel or serialized), the amount of collected data has to be identical (same response size).
Accordingly, the “Response size” of our service calls, printed in line 2 and 20, is equal.
Starting from line 8 (resp. line 26 for the second call), the operation itself is being measured (method “READ”).
7.1) Let’s focus on the READ section of the serialized mode
This is the relevant excerpt from the above screenshot:
We can see that the complete READ method took 590 milliseconds.
This is an aggregated number and it is calculated as follows:
1) The duration of the implementation of this “READ” method (line 8) is 152 ms (Net Time).
2) Within the “READ” method (line8), we’re in a lower level (compared to the starting point in line 1), which is level 2.
     The “READ” method aggregates the durations of the subcalls of the lower level 3 (line 9 to 17).
     Meaning that we have to sum up the duration of all level 3 methods:
     line 9 (7 ms) + line 10 (34 ms) + line 13 (183 ms) + line 17 (214 ms)
     Note: the method “Call Remote BEP” is invoked for every configured Backend system.
3) The total duration of the “READ” method:
     152 + 7 + 34 + 183 + 214 = 590
     Which is the expected result, just like it is printed in line 8
     In words:

+ Call Remote BEP
+ Call Remote BEP
+ GetEntityProv
7.2) Now let’s have a closer look at the READ section for parallelization

The complete READ method took 436 milliseconds.

This aggregated number is calculated as follows:

1) The duration of the implementation of this method is 124 ms (Net Time, line 26).

2) Again, we sum up the duration of all level 3 methods:

     line 27 (2 ms) + line 28 (134 ms) + line 36 (176 ms)

     124 + 2 + 134 + 176 = 436

3) But this time we have to dive one level deeper.
    One of the level-3-methods was “Parallelize Read EntitySet”

    This method is responsible for computing the parallelization of every call to the Backends.

    Now we have to check its subcalls (level 4)

    Within level 4, we have the same two calls to the Backends, one for each System Alias, with quite similar durations as above.

    But this time, both calls are executed in parallel, therefore the duration of the complete READ is not calculated as sum of both calls ❗
    Instead, the duration of the READ is equal to the duration of only one “Call Remote”,

    to be more precise: the duration of the longest call, which in our example is line 32.

    To be even more precise, we have to add the (short) time which is spent for computing the parallelization.

    This can be seen in line 28, method “Parallelize Read EntitySet”, the “Net time” is: 9 ms

    Finally, the duration of the “Parallelize Read EntitySet” is calculated as follows:

    125 + 9 = 134

4) The total duration of the “READ” method:

     124 + 2 + 125 + 9 + 176 = 436

     This is the expected result, as it is printed in line 26

     In words:


+ Parallelize
+ (maximum)Call Remote BEP
+ GetEntityProv

7.3) Comparing both calls

Some of the numbers are expected to be the same, or at least similar, since it is the same code, the same call.

For example the “net time” of the “READ” method, the duration of the “Call RemoteBEP”. But since these methods are remote calls, the numbers cannot be 100% identical.

Most important, the duration of the parallelized request is expected to be faster.

Indeed: this is the case, as we can see comparing the lines 8 and 26 (Method READ, level 2)

8) Advanced Topics

8.1) Configuring parallelization

Within the spro activity described in step 2, there are 2 configuration options:

  1. “Minimum Number of Backend Systems”
    Leaving the input field empty is equivalent to entering 0, which is also the default number.
    This means, no backend system call is executed in parallel mode, parallelization is disabled.
  2. “Maximum number of parallel Backend Calls
    This setting only makes sense if parallelization is enabled.
    The maximum number of parallel backend calls always bases on current resources of the gateway hub system.
    Additionally, this field can be used to limit the use of current system resources.
    Zero (0) means it only depends on current system resources.
    This is also the default.
8.2 Parallelization and Skiptoken

If server paging is realized in any backend data provider than the odata consumer will only receive a result up to this backend including a skip token. The next call with this skip token or any other call with a skip token won’t be parallelized because the result has to be continued by the backend system returned the skip token before.

8.3 Misc notes

– Parallelization is not cross-client.

– Parallelization is applied to all services which are configured with multiple System Aliases.

– Parallelization is only applied if the services are invoked with ;mo in the URL.

– as from SAP Netweaver Gateway SP07, the path in SPRO will change and the TRACE-tool will have simplified functionality

9) Summary

Within this blog we’ve seen that with just one little setting it is possible to significantly increase the speed of QUERYs in multiple origin scenarios.

We’ve proven this expectation with a detailed analysis of the performance traces.

Thanks for your interest!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Carlos Roggan Post author

    One more note:

    The “parallelization”-feature relies on having a service configured for “Multiple Origin Composition” (MOC).

    This MOC is only supported in “Standard Mode”, means it isn’t available for “Generic Channel”. As such, parallelization is only possible in “OData Channel”.

  2. Syam Babu

    Nice Blog.

    When we are planning to implement MOC with using different Back-end Systems these are all the steps are required other than these steps anything is required.

    Is it possible to implement in SAP NW GW SP04 System.



    1. Carlos Roggan Post author

      Hi Syam, thanks;-)

      Regarding your second question, MOC is already available in SP04, see the SAP SP4 help page here:

      Regarding the steps required to do in order to have MOC running:

      This feature is a Gateway-feature: instead of having a service which fetches data from one Backend System in e.g. Europe and another service fetching similar data from a second Backend System in e.g. Asia – with MOC this can be combined in one service.

      Thus, from Gateway side, nothing else needs to be done.

      However, there might be some administrative prerequisites:

      Since the Service has to be configured with several “System Aliases”, these additional “System Aliases” have to exist or have to be created before.

      In order to create a System Alias pointing to a Backend System, there has to be an RFC destination created before.

      This step might imply granting authorization, etc

      On the configured Backend, the used User has to be created and granted permissions, etc

      And of course, the pieces of software, which are called in order to fetch the data, have to be in place, etc

      Kind regards,


      1. Syam Babu

        Hi Carlos,

        Thanks for the quick response.

        Seee when i am developing data model using Generic Model at that time i will get one system alias for that model rite.

        Suppose if i want to add the 2 system alias for the same data  model it possible ?

        What is the possible way when we are achieving the Generic channel using MOC.



        1. Carlos Roggan Post author

          Hi Syam,

          sorry for the late reply, I didn’t receive a notification mail;-(

          Regarding the Generic channel: a Gateway model based on the “Generic Channel” cannot be configured with multiple system aliases. Only the “OData Channel” supports MOC.

          Anyway, it is recommended to use the “Odata channel” which is the “Standard Mode” and not the “Generic Channel”, which remains available for compatibility reasons, but isn’t further enhanced.

          Kind Regards,



Leave a Reply