ODE
  1. ODE
  2. ODE-601

Cannot Assign Dynamic EPRs To Partner Links

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.2, 1.3.3
    • Fix Version/s: 1.3.3
    • Component/s: None
    • Labels:
      None
    • Environment:
      n/a

      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</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

        Activity

        Hide
        Ciaran Jessup added a comment -

        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

        Show
        Ciaran Jessup added a comment - 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
        Hide
        Karthick Sankarachary added a comment -

        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.

        Show
        Karthick Sankarachary added a comment - 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.
        Hide
        Ciaran Jessup added a comment -

        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?

        Show
        Ciaran Jessup added a comment - 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?
        Hide
        Karthick Sankarachary added a comment -

        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

        Show
        Karthick Sankarachary added a comment - 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
        Hide
        Ian Harrigan added a comment -

        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

        Show
        Ian Harrigan added a comment - 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
        Hide
        Ciaran Jessup added a comment -

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

        Show
        Ciaran Jessup added a comment - An example test (and now deployable) BPEL that exhibits the afore-mentioned issue.
        Hide
        Ciaran Jessup added a comment -

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

        Show
        Ciaran Jessup added a comment - A full BPEL and all relevant dependencies that exhibits the described fault.

          People

          • Assignee:
            Karthick Sankarachary
            Reporter:
            Ciaran Jessup
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development