cancel
Showing results for 
Search instead for 
Did you mean: 

ccBPM - ParForEack block not processed in parallel

Former Member
0 Kudos

Hi Experts,

I am using a par for each block in my integration process.

Within the block I send several synchronous calls to a JDBC adapter to execute stored procedure calls.

The stored procedure calls need to be executed in parallel.

In the process list ( Transaction SWF_XI_SWI1 ) I can see, that all the workitems are creat at the same time.

However they stay in status READY and are getting processed by PE runtime only sequentially.

Any idea, what is the reason of this system behaviour? Are there any workflow setting missing?

thanks

Barbara

Accepted Solutions (0)

Answers (8)

Answers (8)

Former Member
0 Kudos

Abhishek,

bad news. However thanks for confirming the statement of SAP.

regards

Barbara

Former Member
0 Kudos

Abhishek,

thanks for your reply. SAP told me the same. So it seems, that real parallel processing ( concerning the execution time ) is not possible in ccBPM.

regards

Barbara

former_member200962
Active Contributor
0 Kudos
So it seems, that real parallel processing ( concerning the execution time ) is not possible in ccBPM.

If you say that Parallel Processing should mean that you get three entries at the same time in SXMB_MONI....then this is not how the processing will work

However Parallel Processing means that the steps are executed independent of the other

Regards,

Abhishek.

Former Member
0 Kudos

Thanks for the hints.

@Ray, the Flag "maintain order at runtime" is unchecked. Me too, I alredy had the hope that unchecking the field might solve my problem. Unfortunately a false hope.

@Viyaja, we also tried this. The parameter "Maximum Concurrency" is set to "10". But the configuration of the communication channel has no impact on the behavior of the integration process.

Barbara

Former Member
0 Kudos

I tested out how the workflow log looks like in case I use fork.

The workitem is created at the node level of the send step.

--> Begin of fork

--> Branch 1

--> <my synchronous send step>

--> Branch 2

--> <my synchronous send step>

...

...

The creation time of the workitem is identical. But then they are getting processed sequentially. ( same case as using parForEach block )

former_member200962
Active Contributor
0 Kudos

Check this help section: http://help.sap.com/saphelp_nw04/helpdata/en/ce/bb2c421f3fda2ce10000000a1550b0/content.htm

From the above help section:
A ParForEach will not result in a split into threads.

In a ForEach mode Send2 is dependent on the execution of Send1....ParForEach mode will ensure that the send steps happen independent of the other....and the parallel processing would mean same i.e. inside the BPM the process will be executed as the branches of a Fork....however in SXMB_MONI you will find it in a sequential manner.

I have not compared the two modes in SXMB_MONI....but if not wrong you might be experiencing the same type of entry for ForEach and ParForEach.

Any correction to above understanding is most welcome.

Regards,

Abhishek.

Former Member
0 Kudos

Hi,

in case of ParForEach, the workflow log ( view with technical details ), my the node strucure of my block looks like this.

-->Block1

--> Branch 1

--> Block1

--> <my synchronous send step>

--> Branch 2

--> Block1

--> <my synchronous send step>

--> Branch 3

--> Block1

--> <my synchronous send step>

--> Branch 4

--> Block1

--> <my synchronous send step>

--> Branch 5

--> Block1

--> <my synchronous send step>

--> Branch 6

--> Block1

--> <my synchronous send step>

The nodes printed bold are the nodes, where a workitem is created. So I have 6 different workitems created in my example.

All these workitems have the same creation timestamp. But the nodes below ( send steps ) have different ( ascending) timestamps, which means, that these nodes are processed sequentially.

In case I change the mode to ForEach, the workflow log looks like this:

-->Block1

--> Block1

--> Loop 1

--> my synchronous send step

--> Loop 2

--> my synchronous send step

--> Loop 3

--> my synchronous send step

--> Loop 4

--> my synchronous send step

--> Loop 5

--> my synchronous send step

Barbara

justin_santhanam
Active Contributor
0 Kudos

Barbara,

Small hint, I might be wrong too. Can you see if you checked the Maintain Order at runtime option in Interface Determination (from BPM to JDBC) ? If yes, then can you please un check and try again.

Just a guess.

Raj.

VijayKonam
Active Contributor
0 Kudos

If you are using 1..n mapping inside BPM, maintain order at run time does have an impact on it as PI would try to maintain the order of the split messages. Otherwise, it might have to do with JDBC adapter thread count in the PI AE configuration.

VJ

Former Member
0 Kudos

Hi guys,

when I change the mode of the block step to ForEach, the steps defined within this block get processed sequentially. In the process list (SWF_XI_SWI1) I can watch how the workitems are created one after the other as soon as the preceeding workitem was processed. This is the expected behaviour for ForEach mode.

However, when changing to ParForEach all workitems of the block are created simultaneous. This is what I am expecting. But the problem is, that the created workitems only get processed sequentially one after the other.

The cache status in SXI_CACHE is ok.

Barbara

former_member200962
Active Contributor
0 Kudos

How is the Block getting processed? It will be shown as Branches (like a Fork)...are you able to see Branch(es) being created equivalent to the number of times the file is send?

former_member181985
Active Contributor
0 Kudos

check the IP status(return code) using SXI_CACHE tcode, if you have done changes to IP couple of times. return code should be zero. otherwise perform "repeat activation".

sunil_singh13
Active Contributor
0 Kudos

Barbara,

For time being switch the design to Sequential and see how the process is getting handled. Might be some miss interpretation.

Thanks,

Sunil Singh

Former Member
0 Kudos

Hi,

any hints concerning this ccBPM problem?.

It's really important.

Thanks

Barbara