Handling No Namespace Schemas within your BPEL Processes

Ramkumar Menon
Director, Product Strategy

There could be cases where you might end up referring to unqualified elements/attributes in yout BPEL Processes. Unqualified means that the elements/attributes are defined in null/no namespace.
These elements could be defining messageTypes in your process WSDLs, or referred to within BPEL assign activities or XSL Transformations.
For handling these use-cases, the following approach is suggested.
The approach is explained in the following sub-sections.

a) Declaring a WSDL message referring to an unqualified element or type
WSDL Message Parts refer to elements or types through an  element or  type attribute. These attributes are of a xsd:QName datatype.
For e.g.
<definitions xmlns=" http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.loan.com/">
. . . .
<xsd:schema targetNamespace="
<xsd:import namespace="
http://www.loan.com/" schemaLocation="LoanRequest.xsd"/>
<xsd:import namespace="
http://www.response.com/" schemaLocation="LoanResponse.xsd"/>
<message name="LoanServiceRequestMessage">
<part name="payload" element="tns:LoanRequest"/>

Few things are worth noting here.
The wsdl components [messageType, part etc] are defined in the namespace "http:schemas.xmlsoap.org/wsdl/" , that is defined to be the default namespace using the "xmlns" attribute on the <definitions> root element of the wsdl.
Default namespace URI is the umbrella for all unprefixed global declarations in the document.
The message part in this case points to a qualified element named "LoanRequest" that is defined in the namespace http://www.loan.com/ aliased by the prefix "tns".
Coming to the point, if the LoanRequest is defined in a null/no namespace, then the WSDL document needs to undergo a few changes. The following are the list of things that need to be considered while making changes.
a) Unqualified elements are always unprefixed. You cannot have a prefix that resolves to a null namespace URI.
b) If a default namespace declaration is specified on the document, then all unprefixed nodes shall resolve to the default namespace. If there are null namespace components that need to be referred, then there should not be a default namespace declaration in the document, as a result of point (a) above.
c) Prefixed namespace declarations cannot declare a null namespace URI., i.e., you cannot define xmlns:ns1="" in your document

Applying these rules on the WSDL document, we need to
a) Remove the xmlns=http://schemas.xmlsoap.org/wsdl/ from the <definitions> element.
b) Now that there is no default namespace, we need to explicitly prefix all the wsdl components like definitions, message, types etc. You need to define a prefix lets say xmlns:wsdl on the definitions element, and explicitly prefix all wsdl components including <definitions> with the <wsdl:?> prefix.
c) The element/type attribute of the message part now needs to point to the unprefixed element/type reference. I.e. in this case, it would be</DIR></DIR> 
<wsdl:definitions xmlns:wsdl=" http://schemas.xmlsoap.org/wsdl/" >
. . . .
  <xsd:schema targetNamespace="
http://www.oracle.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:import schemaLocation="LoanRequest.xsd"/>
    <xsd:import namespace=
http://www.response.com/" schemaLocation="LoanResponse.xsd"/>
<wsdl:message name="LoanServiceRequestMessage">
   <wsdl:part name="payload" element="LoanRequest"/>

b) Handling unqualified elements within BPEL Assigns/XSLTs

In exactly the same way as mentioned above, you need to explicitly prefix all BPEL components using the bpws prefix, and remove the default namespace declaration from the BPEL document.
Then proceed to refer to any unqualified elements without using a prefix.
The same applies for XSLT. Do not explicitly declare a default namespace in the XSLT. Refer to all unqualified elements without using a prefix.
There is a slight difference in the way our JDev designer generates code for BPEL and XSLT. BPEL designer generates all BPEL components in the default namespace, whereas XSLT mapper does not define a default namespace. Hence, you need to explicitly change the source code to remove the default namespace declarations and add the prefixed references to all bpel components like <bpws:assign>, <bpws:process>, <bpws:invoke> etc, just as you would have done for the WSDL.
After you make these changes, things will look good. But the bad part is that if you add a new variable/activity etc into the BPEL using the design view, BPEL designer again adds a default namespace declaration, and adds the entity in the default namespace.
i.e. <variable name=".."/>
In this case, you need to re-edit the source code to remove the default namespace declaration, and would need to explicitly prefix the activity using a prefix.

Join the discussion

Comments ( 3 )
  • Gerhard Kersten Wednesday, February 10, 2010
    Thanks for the great contribution. I could easily reproduce your WSDL example, but adapting the same technique to BPEL ends in "no such element" errors.
    Relevant code lines:

    xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" ... >
    <bpel:import location="ATA_SparesOrder.xsd" importType="http://www.w3.org/2001/XMLSchema"/>
    <bpel:variable name="order" element="ATA_SparesOrder"/>

    Error message:

    ERROR: Element "variable" has reference to another element via attribute "element" and this element cannot be found. Please check namespace declarations, "import" elements, attribute value or the name of the referenced element.

    Any idea? Any validated code example?
  • landscaping perth Tuesday, April 26, 2011
    house design perth
  • Christian Louboutin shoes Tuesday, April 26, 2011
    It's great infomation for me,thanks really significantly! Hope do one thing much more like th is!
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.