You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by ZHAO Wenfeng <zh...@gmail.com> on 2009/07/09 02:45:34 UTC
Re: Re: Re: Prefix problem in the request message for an external webservice
I don't understand the problems very clearly. The following might helps for case 3:
In xpath /ns1:codServicoFiancas will look for an element with that exact tag name. However it is possible that the message is using a different namespace prefix in which case, even if both prefixes resolve to the same namesapce, the selection will fail. Instead try using //*[local-name()='codServicoFiancas'] which will only compare the local part.
--It's from Bill McCusker's discussion in the thread "selectionFailure invoking the BPEL process HELP" on Jun 20.
Regards,
Wenfeng
=======On 2009-07-09 at 02:38:13 Myunghwa Hwang wrote: =======
>Zhao and Rafal,
>I solved this problem by following Zhao's advice.
>When I initialize the outgoing message, I added an attribute like xmlns=""
>to explicitly indicate that the message should be unqualified, as Zhao told.
>
>Rafal, the keepSrcElement is not what I want, although that might be a
>solution for my current test case.
>Thanks for all of you.
>
>However, I am still not sure of how ODE generates outgoing messages and how
>this is related to the initial literal.
>These are my experiments:
>
>1. Case 1: only one external service
>--- initial literal
> <ns:getCntyOperation xmlns:ns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName/>
> </ns:getCntyOperation>
>--- query
><query
>queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[stateName]]></query>
>--- initialized message
><message><parameters><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName xmlns=""/>
> </getCntyOperation></parameters></message>'
>--- generated outgoing message
><soapenv:Body><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName xmlns="">Ohio</stateName>
> </getCntyOperation></soapenv:Body>
>--- result: successful
>
>2. Case 2: multiple external services
>--- initial literal
> <ns:getCntyOperation xmlns:ns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName/>
> </ns:getCntyOperation>
>--- query
><query
>queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[stateName]]></query>
>--- initialized message
><message><parameters><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName *xmlns="
>http://docs.oasis-open.org/wsbpel/2.0/process/executable"/*>
> </getCntyOperation></parameters></message>
>--- result: selection failure. ODE could not find stateName
>
>3. Case 3: multiple external services
>--- initial literal
> <ns:getCntyOperation xmlns:ns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <ns:stateName/>
> </ns:getCntyOperation>
>--- query
><query
>queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[ns2:stateName]]></query>
>--- initialized message
><message><parameters><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <ns:stateName xmlns:ns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl"/>
> </getCntyOperation></parameters></message>'
>--- generated outgoing message
><soapenv:Body><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName>Ohio</stateName>
> </getCntyOperation></soapenv:Body>
>--- result: failed. my external service could not consume the above outgoing
>message.
>
>4. Case 4: multiple external services
>--- initial literal
> <getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName xmlns=""></stateName>
> </getCntyOperation>
>--- query
><query
>queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[stateName]]></query>
>--- initialized message
><message><parameters><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName xmlns=""/>
> </getCntyOperation></parameters></message>'
>--- generated outgoing message
><soapenv:Body><getCntyOperation xmlns="
>http://localhost:8080/getCntyBnd/getCntyBnd?wsdl">
> <stateName xmlns="">Ohio</stateName>
> </getCntyOperation></soapenv:Body>
>--- result: successful
>
>Why do these differences occur? Is this a bug to be filed?
>
>from Myunghwa
>
>
>On Tue, Jul 7, 2009 at 5:45 PM, ZHAO Wenfeng <zh...@gmail.com> wrote:
>
>>
>> Or, override the default namespace to be empty value, i.e. "", in your
>> message, in order to tell the message processor that stateName is indeed an
>> unqualified element.
>>
>> That is:
>> <getCntyOperation xmlns="some URI">
>> <!--Optional:-->
>> <stateName xmlns="">?</stateName>
>> </getCntyOperation>
>>
>>
>>
>> Regards,
>> Wenfeng
>>
>> =======On 2009-07-08 at 07:36:46 Rafal Rusin wrote: =======
>>
>> >You can try keepSrcElementName=true on copy inside assign if you want.
>> >Alternatively, we can think about implementing element creation in ODE
>> >in a way that it creates some other prefix than empty, which is now
>> >default and is quite annoying.
>> >For example it could be taken from prefix map declared on top of bpel
>> process.
>> >
>> >As for qualified stateName, it looks like a bug, so you can file
>> >request including reproduction steps (example process).
>> >
>> >2009/7/8 Myunghwa Hwang <mh...@gmail.com>:
>> >> Hi, list!
>> >> I've encountered another problem.
>> >> My process invokes three external web services whose messages are
>> >> unqualified XML instances.
>> >> An example request message should be like the following:
>> >> <soapenv:Body>
>> >> <get:getCntyOperation>
>> >> <!--Optional:-->
>> >> <stateName>?</stateName>
>> >> </get:getCntyOperation>
>> >> </soapenv:Body>
>> >>
>> >> However, when this service is invoked by my bpel process, the generated
>> >> message is a qualified XML message as follows:
>> >> <soapenv:Body>
>> >> <getCntyOperation xmlns="some URI">
>> >> <!--Optional:-->
>> >> <stateName>?</stateName>
>> >> </getCntyOperation>
>> >> </soapenv:Body>
>> >>
>> >> This difference raises errors in running my bpel process.
>> >> I am using ode-2.0-beta on Tomcat 6.0.20.
>> >> The orchestration service provided by the process is also using
>> unqualified
>> >> messages.
>> >>
>> >> Any advices are welcome.
>> >>
>> >> from Myunghwa Hwang
>> >>
>> >>
>> >> --
>> >> Myunghwa Hwang
>> >> GeoDa Center
>> >> School of Geographical Sciences and Urban Planning
>> >> Arizona State University
>> >> mhwang4@gmail.com or Myunghwa.Hwang@asu.edu
>> >>
>> >
>> >
>> >Regards,
>> >--
>> >Rafał Rusin
>> >http://www.touk.pl
>> >http://top.touk.pl
>> >http://www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>>
>> = = = = = = = = = = = = = = = = = = = =
>> Wenfeng ZHAO (赵文峰)
>> Ph.D. Candidate
>> http://www.bupt.edu.cn
>>
>>
>
>
>--
>Myunghwa Hwang
>GeoDa Center
>School of Geographical Sciences and Urban Planning
>Arizona State University
>mhwang4@gmail.com or Myunghwa.Hwang@asu.edu
= = = = = = = = = = = = = = = = = = = =
Wenfeng ZHAO (赵文峰)
Ph.D. Candidate
http://www.bupt.edu.cn