Ramkumar Menon's Blog

I had been struggling with OC4J Classloading issues for a while, and this doc seemed to help me through with a lot of those issues.

Click here to access the doc.

    The best practices for Oracle BPEL 10.1.3 HA is available at this link.

When you use an XML fragment to initialize a variable or a parameter, then the variable or parameter is of the

a) In XSLT 1.0

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:p1="http://example.org"
xmlns:exsl="http://exslt.org/common"
extension-element-prefixes="exsl">
<xsl:param name="param1">
  <FileList>
    <File Name='a' valid='true' automated='false'/>
    <File Name='b' valid='true' automated='false'/>
    <File Name='c' valid='true' automated='false'/>
    <File Name='d' valid='true' automated='false'/>
    <File Name='e' valid='true' automated='false'/>
    <File Name='f' valid='true' automated='false'/>
  </FileList>
</xsl:param>
<xsl:template match="/">
  <ExternalAccess>
    <Query>
        <Parameters>
            <xsl:for-each select="exsl:node-set($param1)/FileList/File">
                <xsl:variable name="secondary" select="."/>
                <RetrievedFile>
                    <xsl:attribute name="Name">
                        <xsl:value-of select='@Name'/>
                    </xsl:attribute>
                    <xsl:attribute name="valid">
                        <xsl:value-of select='@valid'/>
                    </xsl:attribute>
                    <xsl:attribute name="automated">
                        <xsl:value-of select='@automated'/>
                    </xsl:attribute>
                </RetrievedFile>
            </xsl:for-each>
        </Parameters>
    </Query>
  </ExternalAccess>
</xsl:template>

</xsl:stylesheet>

b) Use XSLT 2.0

You can code your transformations in XSLT 2.0.  XSLT 2.0 deprecates ResultTreeFragments i.e. if you are modeling an XSLT 2.0 transformation, and you create a variable or a parameter that holds a tree fragment, it is implicitly a node sequence. You could then use path expressions against these variables and parameters. To make your transformations executed by an XSLT 2.0 processor, simply change the "version" attribute on the &lt;xsl:stylesheet> to "2.0".

With this approach, you can use the select expression "$param1/FileList/File" to iterate over the File elements witihn the XSLT parameter.

Here is the XSLT 2.0 code for this approach.

<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:p1="www.example.org">
<xsl:param name="param1">
<FileList>
<File Name='a' valid='true' automated='false'/>
<File Name='b' valid='true' automated='false'/>
<File Name='c' valid='true' automated='false'/>
<File Name='d' valid='true' automated='false'/>
<File Name='e' valid='true' automated='false'/>
<File Name='f' valid='true' automated='false'/>
</FileList>
</xsl:param>
<xsl:template match="/">
<ExternalAccess>
      <Query>
            <Parameters>
                <xsl:for-each select="$param1/FileList/File">
                       <xsl:variable name="secondary" select="."/>
                               <RetrievedFile>
                                       <xsl:attribute name="Name">
                                           <xsl:value-of select='@Name'/>
                                       </xsl:attribute>
                                       <xsl:attribute name="valid">
                                           <xsl:value-of select='@valid'/>
                                       </xsl:attribute>
                                       <xsl:attribute name="automated">
                                           <xsl:value-of
select='@automated'/>
                                       </xsl:attribute>
                                 </RetrievedFile>
                </xsl:for-each>
      </Parameters>
  </Query>
</ExternalAccess>
</xsl:template>
</xsl:stylesheet>

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/">
. . . .
<types>
<xsd:schema targetNamespace="http://www.oracle.com/">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://www.loan.com/" schemaLocation="LoanRequest.xsd"/>
<xsd:import namespace="http://www.response.com/" schemaLocation="LoanResponse.xsd"/>
</types>
<message name="LoanServiceRequestMessage">
<part name="payload" element="tns:LoanRequest"/>
</messageType>
</definitions>
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/" >
. . . .
<wsdl:types>
  <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"/>
   </xsd:schema> 
<wsdl:types>
<wsdl:message name="LoanServiceRequestMessage">
   <wsdl:part name="payload" element="LoanRequest"/>
<wsdl:message>
</wsdl:definitions>

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.