cancel
Showing results for 
Search instead for 
Did you mean: 

ccBPM Collect Pattern Error

Former Member
0 Kudos

All,

Im trying to do a collect pattern based on time example. This is what the BPM does,

1. Receives the IDoc from another R3 system.

2. Collects the IDocs based on a correlation and there is a timer for 3 mins.

3. Merges all these IDocs using a transformation.

4. Sends the the merged xml to an FTP location.

When i get the first IDoc message - in SXMB_MONI it says inbound side is ok and there is an error on the outbound side... and in the technical log - it gives the following error,

Work item 000000046192: Object FLOWITEM method EXECUTE cannot be executed

Error when executing work item '000000046193'

If i remove the block and just make it a straight forward collect the xml (only one XML since there is no timer), transform and write to FTP - it works fine.

Any ideas?

Thanks.

Accepted Solutions (1)

Accepted Solutions (1)

matt_austin
Explorer
0 Kudos

I had this problem after upgrading from 3.0 sp14 to 3.0 sp19. The BPM worked fine immediatly after the upgrade, but failed when I recompiled / re-saved the BPM under the sp19 IR client. I finally noticed that I had to set the "Local Correlation" paramater in the overall Block definition (named "restrict correlation scope" in the BpmPatternCollectMessage example). This correlation should be the correlation used in the Receive step within the Loop step.

Hope this helps.

henrique_pinto
Active Contributor
0 Kudos

Yeah, there were a lot of customer messages related to collect pattern BPMs, refering to not processed messages (when they were sent to the wrong BPM instance). These messages were refered as "parked messages".

In order to minimize that problem, best practices are remove all steps but receive/container operation of loop step and also define correlation used in loop as local correlation (in a block surrounding loop).

I'm not sure but maybe they have some check in SP19 where if it is not local correlation in collect pattern then it will throw an error. But I do agree if this is the case, then it is really odd. A non-zero return code would be better.

Regards,

Henrique.

Answers (3)

Answers (3)

prabhu_s2
Active Contributor
0 Kudos

Check all the messages in the BPM steps ( for this go to SXMB_MONI->PE->Technical details.. Also check the each values in the container

prabhu_s2
Active Contributor
0 Kudos

try to delete all the workitem in SWWL and process once again. look if 901047 and 903139 helps

prabhu_s2
Active Contributor
0 Kudos

check if this helps you:

/people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm

Former Member
0 Kudos

That link is almost similar to the example we have and it gives the same error as i mentioned earlier.

One more thing - we tried changing the BPM the following way,

1. Start

2. Begin Block

3. Receive IDoc.

4. Container operation to add the IDoc to multiline variable.

5. End Block

6. Transform the multiline container to an XML.

7. Send the XML file to a FTP location

8. Stop.

There is no timer or no collect pattern in above example... this also gives the same error as in post 1. But if we remove the Block (#2, #5 in the above BPM), it works without an error.

So - it looks like the block is causing an error... or are we missing something else?

Thanks.

prabhu_s2
Active Contributor
0 Kudos

after activating the bpm see what is the return code in sxi_cache for the IP

prabhu_s2
Active Contributor
0 Kudos

when u dont have any condition set for block then the transformation step will not get processed. just try to have the condition set interms timer, for example

Former Member
0 Kudos

After activating the BPM - the return code is 0 in the SXI_CACHE.

Also - i didnt get what you meant by when there is no condition set for block the transformation wont work... Actually it is working if i dont use the block. If i use the block then i get the above mentioned error.

Thanks.

prabhu_s2
Active Contributor
0 Kudos

i meant of having a collect pattern sequence involved in the block as in the blog

Message was edited by:

Prabhu S