BPM performance question

[Former Member]

Guys,

I do understand that ccPBM is very resource hungry but what I was wondering is this:

Once you use BPM, does an extra step decreases the performance significantly? Or does it just need slightly more resources?

More specifically we have quite complex mapping in 2 BPM steps. Combining them would make the mapping less clear but would it worth doing so from the performance point of view?

Your opinion is appreciated.

Thanks a lot,

Viktor Varga

[Shabarish_Nair · Accepted solution]

there are scenarios which req. BPM and it becomes unavoidable. It true that more complex the BPM more resource it wud comsume. try to avoid mappings in BPM or else optimise the mappings for performance.

Also ref this checklist when BPM sud be used or Not.

http://help.sap.com/saphelp_nw04/helpdata/en/43/d92e428819da2ce10000000a1550b0/content.htm

[Former Member]

Hi,

In SXMB_ADM you can set the time out higher for the sync processing.

Go to Integration Processing in SXMB_ADM and add parameter SA_COMM CHECK_FOR_ASYNC_RESPONSE_TIMEOUT to 120 (seconds). You can also increase the number of parallel processes if you have more waiting now. SA_COMM CHECK_FOR_MAX_SYNC_CALLS from 20 to XX. All depends on your hardware but this helped me from the standard 60 seconds to go to may be 70 in some cases.

Make sure that your calling system does not have a timeout below that you set in XI otherwise yours will go on and finish and your partner may end up sending it twice

when you go for BPM the whole workflow

has to come into action so for example

when your mapping last < 1 sec without bpm

if you do it in a BPM the transformation step

can last 2 seconds + one second mapping...

(that's just an example)

so the workflow gives you many design possibilities

(brigde, error handling) but it can

slow down the process and if you have

thousands of messages the preformance

can be much worse than having the same without BPM

see below links

http://help.sap.com/bp_bpmv130/Documentation/Operation/TuningGuide.pdf

http://help.sap.com/saphelp_nw04/helpdata/en/43/d92e428819da2ce10000000a1550b0/content.htm

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/sap%20excha...

Regards

Chilla..

[henrique_pinto]

Transformation and Send/Receive steps are very resource-consuming. Container operation and Switch steps are less consuming.

I'd would strongly recommend you to use one single mapping program in order to avoid unnecessary processing (and increase BPM performance).

[moorthy]

One of the parameter for the perfromance is , tranformations inside the BPM. If you have huge Tranformations/Mapping inside the BPM it will hit the performance. If you have 2 tarnformation steps , then it will be a point to consider.

First try to do the Transformation/Mapping outside the BPm.

If it is not meeting your requirements, then try to combine the mapping ..

Other parameters are :

1) Volume of messages

2) Mode of communication - SYnc/Async

4) Business Logic inside the BPM if it is very complex

5) Sizing

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/70ada5ef-0201-0010-1f8b-c93...

Also BPM checkList-

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3bf550d4-0201-0010-b2ae-856...

Hope this helps

Regards,

Moorthy

[bhavesh_kantilal]

Viktor,

Mapping inside a BPM does cause performance issue , cause every mapping would need to call from the BPE to the J2EE stack of XI.

From this link,

http://help.sap.com/saphelp_nw04/helpdata/en/43/d92e428819da2ce10000000a1550b0/content.htm

<i>Different step types consume different amounts of system resources:

Step types with high resource consumption:

Receive step

Send step

Asynchronous send steps with acknowledgments in particular consume a lot of system resources. In the case of synchronous send steps, consumption depends on the target system.

Receiver determination

<b> Transformation step

In transformation steps, resource consumption is dependent on the mapping called.</b>

Block

Wait step</i>

Regards,

Bhavesh