Today I found something curious in a composite upgraded from 11g to 12c, regarding DVMs. I sometimes use DVMs in BPEL to prevent the use of complex xpath expressions with many conditions. For instance, if I need to know if a JMSType is in a certain range and if it is I need to continue, I can create a DVM that has those JVMTypes correlated to an indicator.

Now, in 12c we have a new project structure. Where in 11g, about every component is in the root of the project, in 12c those are moved to a subfolder. That is, if you would create a new project:

Folder like xsd, wsdl, xsl in 11g are renated to Schemas, WSDLs and Transformations in 12c. We decided to refactor the upgraded projects to the new structure in 12c. So our BPEL processes are moved to the BPEL subfolder. This means that when referencing a transformation (xsl) you would adapt your xslt functions as:

        <assign name="Transform2MessageProperties">
          <bpelx:annotation>
            <bpelx:pattern>transformation</bpelx:pattern>
          </bpelx:annotation>
          <copy>
            <from expression="ora:doXSLTransformForDoc('../Transformations/Transform2MessageProperties.xsl', $Receive_InkomendBericht_InkomendBericht_InputVariable.InkomendBericht)"/>
            <to variable="messageProperties"/>
          </copy>
        </assign>

Here you see that the reference to the transformation is relative to the BPEL process, and thus '../Transformations'.

Keeping things transparant and uniform, we adapted the DVM references accordingly:

              <assign name="Assign_JmsType">
                <copy>
                  <from expression="dvm:lookupValue('../DVMs/DWN_Types.dvm', 'Type', bpws:getVariableData('messageProperties','/ns1:messageProperties/ns1:type') , 'JmsType', 'onbekend')"/>
                  <to variable="jmsType"/>
                </copy>
              </assign>

However, we got exceptions like:

<bpelFault><faultType>0</faultType><subLanguageExecutionFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>XPath expression failed to execute.
An error occurs while processing the XPath expression; the expression is dvm:lookupValue('../DVMs/DWN_Types.dvm', 'Type', bpws:getVariableData('messageProperties','/ns1:messageProperties/ns1:type') , 'JmsType', 'onbekend')
The XPath expression failed to execute; the reason was: oracle.fabric.common.xml.xpath.XPathFunctionException: Unable to get Metadata Manager for DVM "oramds:/deployed-composites/default/DVMs/DWN_Types.dvm"
Please ensure the Metadata Manager is available.
Check the detailed root cause described in the exception message text and verify that the XPath query is correct.
</summary></part><part name="code"><code>XPathExecutionError</code></part></subLanguageExecutionFault></bpelFault>

After some investigation and trial&error, I found it very peciuliar, that the reference apparently evoluated to: oramds:/deployed-composites/default/DVMs/DWN_Types.dvm. This actualy means that it searches for the DVM in the MDS relative to the deployed composite, but outside it's own folder. After the ../default/.. folder reference it should have the composites name and version/id. 

I tried it without the '../' reference in the path, and that worked!

Conclusion:

• In SOA 12c the ora:doXSLTransformForDoc() function is apparently executed in the context of the BPEL process and thus relative references to the XSL file should be done relative to the BPEL process.
• In SOA 12c the dvm:lookupValue() function appears to be executed in the context of the composite, so the reference to the DVM file should relative to the composite (composite.xml).