on 07-19-2013 2:42 PM
Hi,
I have always done with my BPM scenario getting database rows via jdbc sender (async), doing 1:N mapping, calling some Webservices (sync) within the loop (ForEach block).
The last steps in the loop are the transformation of the response message from the webservice to the answer message of the database and sending this answer message via jdbc(async) back to the database.
It seems to be everything in the right sequence til the transformation of the answer message. But the send step always contains the first message of the loop.
The first database row is then updated multiple times.
The process flow looks right and I can see that several loops are performed.
Looking into the end times in SXMB_MONI I can see that those the sender steps are at the end and not in the sequence I have it in the BPM.
What do you think is wrong?
Thanks and Regards
Michael
Hi Ambrish, hello Mark,
thanks for your replies.
Marking the synch steps with a new transaction helped me to see the actual valies in monitoring and I think it is also besser for reprocessing capabilities.
But basically it was my fault because in the last transformation of the BPM loop i took the wrong message (unbounded) and not the result of my first split.
Now it is working but only in case I use a ForEach (sequential) in the Block after the message split.
If I change it to the ParFor Each then again only the first message of the multiline container after the split is processed n times.
I have no end condition or correlation within my loop because a want to process every single row which comes from the database seperately.
With usage of the ForEach sequential mode I have the problem that the entire process is cancelled in case I throw a cancel process action after a system alert. In parallel mode only the loops with error would be cancelled.
1. What might be the reason that the ParForEach is processing only the first message?
2. Is there a possibility to continue the loop with the next message in ForEach mode in case of a system error? I would like to stop processing for the remaining steps of the current message and continue with the next one.
Thanks and Regards
Michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Michael,
I did some reading and found a good link which explains
http://help.sap.com/saphelp_nw04/helpdata/en/f6/e1283f2bbad036e10000000a114084/content.htm
If you use ForEach then the block will send msg only after it receives a response while in ParForEach the block will send all messages in parallel without waiting for a response.
You can search on SCN for parForEach Vs ForEach and there are multiple discussions.
hope it helps!
Ambrish
Hello Michael,
I've tried to replicate your scenario, but it is working properly on my part. In the scenario below,
1. an async message is sent
2. a sync request is sent to a calculator webservice.
3. response of sync request is written to al11
So here:
1. Receive step
2. Mapping (1:N) with create new transaction (since the values would be different)
3. Sync send step with create new transaction (since the values would be different)
4. Async send step (with create new transaction) containing the response message of 3
Start and End of block also has create new transaction
The difference between parForEach and forEach is the time the message will be sent. In the scenario above, using 1:2 mapping the messages are sent 1 sec apart when using ForEach; when using ParForEach the resulting messages are sent at the same time.
Hope this helps,
Mark
Hi Ambrish, hello Mark,
thanks to your replies I understood now the difference between ForEach and ParForEach. I do not need the ParForEach to get what I want. I go with the ForEach which is working. Here is my BPM:
The yellow marked block is the ForEach. I stopped searching why it is not working in ParForEach mode althoug it should work as well.
Thanks for your help
/Michael
Hello Michael,
Just a thought, did you check the create new transaction option in your send step for the synch message?
Regards.
Mark
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
HI Michael,
I hope if the key fields are not common for the multiple records you are updating. This might result in same row getting overwritten.
Ambrish
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Since it was released at weekend it might be overlooked by the community members.
Any ideas?
/Michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
89 | |
10 | |
9 | |
9 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.