Migrating dynamic lookups from ESB 10g to Mediator 11g

There are 2 approaches to migrating dynamic lookups via DVMs from ESB 10g to Mediator 11g.

For example, your XSL transformation in ESB 10g may look something like this:

<xsl:variable name="LocationIn" select="orcl:lookup-dvm('AhmedDVM', 'Domain1', /client:process/client:input, 'Domain2', 'US')"/>

<xsl:variable name="LocationOut" select="ehdr:setOutboundHeader('/shdr:ESBHeader/shdr:location', $LocationIn, 'shdr=http://xmlns.oracle.com/esb;')"/>

The first statement performs a DVM lookup, and stores the dynamic endpoint in a variable called $LocationIn. Then, you use the header function ehdr:setOutboundHeader to set the outbound header, thus dynamically routing to your endpoint based on the URL retrieved from the DVM.

However, that the ehdr:setOutboundHeader function is no longer supported in OFM 11g.

Approach #1: Use 'Assign Values' to set endpoint property

1. When the ESB 10g code is migrated, only 1 of the 2 statements above will be migrated. So your 11g project will look like this.

<xsl:variable name="LocationIn" select="orcl:lookup-dvm('AhmedDVM', 'Domain1', /client:process/client:input, 'Domain2', 'US')"/>

Unfortunately, as you can see, it is still using the now obsolute orcl:lookup-dvm function.

2. Delete this statement from your XSL file.

3. Find out the full path to the migrated DVM (from SOA Composer).

Once you locate your DVM, hover over the DVM name to get it's location. You will use this when using the new dvm:lookupValue function.

For example:

/deployed-composites/default/XrefDvmFiles10g_rev1.0/AhmedDVM.dvm

4. Go to your .mplan file, and click on the "Assign Values" button.

5. Add the following assignment:

From expression:

dvm:lookupValue("oramds:/deployed-composites/default/XrefDvmFiles10g_rev1.0/AhmedDVM.dvm", "Domain1", $in.payload/client:process/client:input, "Domain2", "US")

To property:

endpointURI

6. That's it!
Approach #2: Use the mhdr:setProperty function

1. When the ESB 10g code is migrated, only 1 of the 2 statements above will be migrated. So your 11g project will look like this.

<xsl:variable name="LocationIn" select="orcl:lookup-dvm('AhmedDVM', 'Domain1', /client:process/client:input, 'Domain2', 'US')"/>

Unfortunately, as you can see, it is still using the now obsolute orcl:lookup-dvm function.

2. Find out the full path to the migrated DVM (from SOA Composer).

Once you locate your DVM, hover over the DVM name to get it's location. You will use this when using the new dvm:lookupValue function.

For example:

/deployed-composites/default/XrefDvmFiles10g_rev1.0/AhmedDVM.dvm

3. In your XSL file, modify the function so that the statement above looks like this, and set the endpointURI using the function mhdr:setProperty:

<xsl:variable name="LocationIn" select="dvm:lookupValue('oramds:/deployed-composites/default/XrefDvmFiles10g_rev1.0/AhmedDVM.dvm', 'Domain1', /client:process/client:input, 'Domain2', 'US')"/>

<xsl:variable name="LocationOut" select="mhdr:setProperty('out.property.endpointURI',$LocationIn)"/>

4. That's it!
Preferred approach?Both approaches are entirely valid. However, you may want to use the second one if you have additional complex XSLT that you want to perform, as the "Assign Values" is somewhat limited in its XPath support.