2

I am new in BPEL writing. I have realized the simple process below:

receive1 | | invoke1 | | receive2 | | invoke2

The problem is that the process correctly runs till to the "receive2" but when I invoke, via soapUI, the operation associated to the "receive2" nothing happens. I have read other posts about BPEL but nothing matching with this question. Below the real activities (I omitted the Assign ones) involved.

    <bpel:receive name="receiveInput" partnerLink="client"
             portType="tns:HealthMobility"
             operation="initiate" variable="input"
             createInstance="yes"/>

    <bpel:invoke name="getTreatmentOptions" 
     partnerLink="treatmentProviderPL" operation="getTreatmentOptions"  
     inputVariable="getTreatmentOptionsReq" outputVariable="getTreatmentOptionsResp"> 
    </bpel:invoke>

    <bpel:receive name="bookMobility" partnerLink="client" operation="bookMobility" 
     variable="bookMobilityReq" portType="tns:HealthMobility"/>

    <bpel:invoke name="getTripOptions" partnerLink="mobilityMultiProvidersPL"  
     operation="getTripOptions" inputVariable="getTripOptionsReq" 
     outputVariable="getTripOptionsResp"></bpel:invoke>

I have tried to make debugging simply by deleting the receive and initializing statically the input variable required by the getTriOptions invoke. In this case all works fine so it means, necessarly, that the process continue to wait on the receive also if I invoke bookMobility via SOAPUI. My question is: Why? I'm missing something?

Thanks

user716658
  • 61
  • 1
  • 1
  • 4

1 Answers1

3

You need to define a correlation set for the second receive. Each message that is sent to the operation that is connected to the first receive activity will create a new process instance. This means you may have multiple instance running in parallel. When these instances have reached the second receive, they are waiting for the second message, but in your example, there are no means to distinguish, which message is targeted to which process instance. I assume that your BPEL engine also logged that it could not route the message to a target instance.

To solve this problem, you need to find an identifier in the payload of a message and initialize a correlation set with this value. Then, when using the same correlation set with the second receive, all messages that contain the same identifier will be routed to this particular process instance. For further information about correlation sets I recommend reading the BPEL primer, section 4.2.4.

vanto
  • 3,134
  • 18
  • 28
  • Thanks vanto for your answer, I have figured out it was somthing like that. Anyway I was a bit puzzled by another sentence in the BPEL specification: "A business process instance MUST NOT simultaneously enable two or more activities for the same partnerLink, portType, operation and correlationSet(s)". Now the second receive of my process use the same partnerLink of the first one and the same partner role and port type but, naturally a different operation. Honestly it seems to me the best way to proceed. Anyway I will try with correletion set. Thanks again – user716658 Apr 20 '11 at 12:32
  • The restriction that partnerLink, portType, operation and correlation sets must be unique has the same reason. Actually, it is not about the correlation set definition but about its instance. The goal of the restriction is to make sure that there is always just a single instance associated with a certain correlation token. So let's think of a simple process that first receives a login message (username, password), performs a lookup in the user database and creates a session. The session id is sent back to the client and then a receive or pick is waiting for e.g. an order (cont. next comment). – vanto Apr 20 '11 at 15:45