Cannot Assign Dynamic EPRs To Partner Links

• Key: ODE-601
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Karthick Sankarachary
• Reporter: Ciaran Jessup
• Affects Version/s: 1.3.2, 1.3.3

Description

My BPEL flows (I *think*, although its possible this hasn't been function as expected) used to work before changeset [765432] (on the ODE 1_XXX branch), they no longer do (and continue to work when I rever that changeset out.
I think its something to do with the 'location' property now being set on the variable reference where it previously wasn't, but I'm very very out of depth. I've attached what I think is the relevant snipped of BPEL that I'm using for doing my invoke:

<!-- in the bpel:variables section -->
<bpel:variable name="DynamicEndpointRef" element="wsa:EndpointReference" />


<!--- Trying to invoke a service call -->
<bpel:assign name="proxyPreparation">
<bpel:copy>
  <bpel:from>
    <bpel:literal>
      <wsa:EndpointReference xmlns:swsdl="uri:swsdl">
        <wsa:Address />
        <wsa:ServiceName PortName="PPSSoap">swsdl:PPS</wsa:ServiceName>
      </wsa:EndpointReference>
    </bpel:literal>
  </bpel:from>
  <bpel:to variable="DynamicEndpointRef" />
</bpel:copy>
<bpel:copy>
  <bpel:from>bpel:doXslTransform("GetNextAddress.xsl",$DynamicEndpointRef/wsa:Address)</bpel:from>
  <bpel:to variable="ProxyAddress" />
</bpel:copy>
<bpel:copy>
  <bpel:from variable="ProxyAddress" />
  <bpel:to variable="DynamicEndpointRef">
    <bpel:query>wsa:Address</bpel:query>
  </bpel:to>
</bpel:copy>
<bpel:copy>
  <bpel:from variable="DynamicEndpointRef" />
  <bpel:to partnerLink="PPS" />
</bpel:copy>
<bpel:copy>
  <bpel:from>
    <bpel:literal>
      <swsdl:PPI>
        <swsdl:processId>9f538fdb-ca36-4d5d-a056-d6bf92632f75</swsdl:processId>
      </swsdl:PPI>
    </bpel:literal>
  </bpel:from>
  <bpel:to variable="ppIn" part="parameters" />
</bpel:copy>
</bpel:assign>
<bpel:invoke name="InvokePPS" partnerLink="PPS" portType="swsdl:PPSSoap" operation="PPI" inputVariable="ppIn" outputVariable="ppOut" />


And when the flow executes I see an error along the lines of :

ERROR - GeronimoLog.error(104) | Couldn't find endpoint for partner EPR <?xml version="1.0" encoding="UTF-8"?>
<service-ref xmlns="http://docs.oasis-open.org/wsbpel/2.0/serviceref">
                            <Address xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">http://server/myaddress.asmx?wsdl&lt;/Address>
                            <wsa:ServiceName xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing" PortName="PPSSoap">swsdl:PPS</wsa:ServiceName>
                          </service-ref>

I do not get this error, and the correct web service seems to get called when I revert the change.. any ideas, is my BPEL flawed, or has an issue been introduced?


Please find attached a fully deployed process, this will require you to mock a service that adheres to the wsdl in proxy.wsdl.

A request such as :
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:wor="http://www.myco.com/xml/sa/4.0/Workflow/"
     xmlns:smf="http://www.myco.com/xml/sa/4.0/smf">
   <soapenv:Header/>
   <soapenv:Body>
      <wor:ExecuteWorkflow>
         <wor:userCredentials>
            <smf:userId>03d27fc0-5ede-4cb8-89d7-6bf7510e16c6</smf:userId>
            <smf:applicationName>NA</smf:applicationName>
         </wor:userCredentials>
         <wor:workItem version="54">
            <smf:state>BECE5689-A575-4531-86B6-15176D827C08</smf:state>
         </wor:workItem>
      </wor:ExecuteWorkflow>
   </soapenv:Body>
</soapenv:Envelope>

Will cause the error to occur on trunk head, but the error won't occur if you revert changeset [765432] I do believe its to dow with the dynamic addressing breaking the partnerlink stuff, but I'm not clever enough to pin it down :(

Comments

[Ciaran Jessup]

A full BPEL and all relevant dependencies that exhibits the described fault.

An example test (and now deployable) BPEL that exhibits the afore-mentioned issue.

[Ian Harrigan]

Hi there - im getting the exact same issue as this. Is there a fix (or work around) available that doesnt involve reverting to an older version?

Ill investigate more tomorrow - if required i can post an example project to illustrate this issue. It seems like a pretty fundemental thing...

Cheers,
Ian Harrigan

[Karthick Sankarachary]

It appears that there was a latent bug in the piece of code that handles assignments of dynamic EPRs to partner links, which apparently surfaced after revision 765432. I believe that that was the underlying cause of this issue, which has now been resolved (see revision 779324).

Ciaran, You may want to read our documentation on EPRs available here: http://cwiki.apache.org/ODExSITE/endpoint-references.html. In particular, note the namespace that we use for WS-Addressing, which is not the same as what your BPEL process assumes. Also, your BPEL project still tries to invoke your internal .NET service, so unfortunately, it still doesn't make for a good test case.

Regards,
Karthick

[Ciaran Jessup]

Thanks Karthick,
I can confirm with your changes (and if I change the ws-addressing namespace I use) my BPEL now works with ODE. I take it there's no intention to support multiple WS Addressing versions then ? ... I'm puzzled as to how it seemed to work previously without the namespace change however , any ideas?

[Karthick Sankarachary]

That's a good question. I believe that was a case of two wrongs making a right. Even though your intention was to assign a <wsa:EndpointReference> to the partner link, it ended up assigning the value of the wsa:EndpointReference/wsa:Address instead. It so happens that the value is a valid URL endpoint, and is processed as such. Now, the engine does the right thing, which is to assign the <wsa:EndpointReference> itself to the partner link, provided, of course, that you are using the latest version of WS-Addressing.

To answer your question about WS-Addressing versions, we currently only support the latest version of WS-Addressing as specified here: http://www.w3.org/Submission/ws-addressing/. Do you have a good justification for using the older version over the latest one? If so, please file a request for enhancement that describes your use case.

[Ciaran Jessup]

Ah, I see, oddly this error also works in ActiveBPEL :) But I'm glad we uncovered the problem, and I'll remedy our BPEL generation code asap!

With regards to mulitple WS-Addressing styles, I don't believe I currently have a relevant use-case, it was more a point of interest :)