Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
CarlosRoggan
Product and Topic Expert
Product and Topic Expert

Background



After creating a SAP 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!


Note:

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

/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT;mo/FlightCollection


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 😎 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:


















   GetDataProvider
+ Call Remote BEP
+ Call Remote BEP
+ GetEntityProv
=  READ





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:

 


















  GetDataProvider
+ Parallelize
+ (maximum)Call Remote BEP
+ GetEntityProv
= READ

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)

😎 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!


7 Comments