cancel
Showing results for 
Search instead for 
Did you mean: 

BPM multi-mapping

Former Member
0 Kudos

Hi guys,

I'm doing a multi-mapping in a BPM (I need the BPM for other validations). This multi-mapping is 1x2 and the messages are created based on payload fields(both are optional 0..1). the mapping is working fine, the problem is at the fork step, I've two send steps and whenever the message1 or 2 doesn't have occurences, I got an error that stops my BPM. But this is not an error as the messages are optional and don't need to occurs everytime.

Anyone know how to solve this?

Thanks in advance & regards,

Ricardo.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Ricardo,

maybe my reply seems a little stupid. But Do you have the send step in the appropriate branch?

Backgound: We migrated from 3.0 to 7.1 and after the migrations our steps where in the otherwise-branch (and that is wrong)

Regards Mario

Former Member
0 Kudos

that's ok!

After the multi-mapping I've a fork with two branches, each one has one send step (send1 = message1 and send2 = message2). As I said I already tested the option "necessary branches = 1", but it doesn't works apparently.

Any idea?

Thanks & regards,

Ricardo.

Former Member
0 Kudos

Hi Ricardo,

take a switch-step, NOT a fork step.

regards Mario

Edited by: Mario Müller on Mar 25, 2009 4:49 AM

Former Member
0 Kudos

Thanks Mario.

Definitely this can only be handled with a switch step and not only with a fork step.

Thank you all & regards,

Ricardo.

Answers (1)

Answers (1)

prateek
Active Contributor
0 Kudos

In the fork step properties, provide the number of necessary branches = 1.

Regards,

Prateek

Former Member
0 Kudos

Hi Patreek,

Necessary branches = 1.

I already did it. It works if only one message is generated (message1 or message2). If both messages are generated I get no error at the BPM, but only one message arrives ERP and when I check at BPE moni one of the send steps is logical finished.

Any idea? maybe I'm missing something...

Regards,

Ricardo.