Some tips and tricks on migrating SOA Suite 10g to 11g

Just a few things I noticed last week when migrating BPEL and ESB projects from SOA Suite 10g to SCA composites and components in SOA Suite 11g.

Custom XSLT functions
Just like in SOA Suite 10g you can expose Java methods as custom XSLT functions and use them at designtime in the XSLT Mapper of JDeveloper 11g. An example is a custom XSLT function transforming a local bank account number into its corresponding IBAN format. While the mechanism to expose custom functions is the same as in SOA Suite 10g, the exact implementation in SOA Suite 11g is little bit different. Custom XSLT functions are packaged in a JAR file including an extension XML file describing the functions. By specifying and adding the JAR file in JDeveloper you can use these functions designtime. You then place the JAR file on the application server running SOA Suite so they can also be executed at runtime. See this blog by Peter O’Brien for more detailed steps for using custom XSLT functions in SOA Suite 10g. Migrating custom XSLT functions from 10g to 11g needs to be done manually and involves the following steps.

• Edit the extension XML file and replace the elements and namespaces according to the new XSD describing custom XSLT functions.
• Rebuild the extension JAR and add it to JDeveloper 11g using Tools –> Preferences –> SOA from the menu. Restart JDeveloper. Inspect the log window to see if JDeveloper correctly parsed the extension JAR file. There will be an error or warning in case of an incorrect configuration.
• The custom XSLT functions are now listed in the XSLT Mapper.
• Place the JAR file in the BEA_Home/user_projects/domains/domain_name/lib directory to make them available at runtime.

See OTN for more detailed information.

Sensors and tracking composite instances
There are a few ways of tracking composite instances and/or relating these to business entities such as orders or invoices that are processed by the service. End-users frequently want to know -given a particular business entity- what process instance(s) are related to it. In SOA Suite 10g -and more particularly BPEL PM- you could use the setIndex function within an embedded Java activity or use sensors to publish this information. You would of course need a subscriber to process these sensor values and store the relation between process instances and business entities somewhere.

In SOA Suite 11g you have this great new feature of using composite sensors to achieve this. See for example this blog by Demed L’Her. Another way is to set the name of a SCA composite instance. By default the instance name is not set and the corresponding name column in the EM 11g Fusion Middleware Control is empty. You can set the composite instance name at designtime from a Mediator component or BPEL component using the setCompositeInstanceTitle XPath function or equally named Java extension. Just like composite sensors you can then search for composite instances based on its name. This is documented in Oracle’s Fusion Middleware Administrator’s Guide for Oracle SOA Suite.

Note that EM 11g Fusion Middleware Control only shows sensor actions and values that are stored in the database. As stated in the Developer’s Guide: “If you created JMS sensors in your BPEL process, JMS sensor values do not display in Oracle Enterprise Manager Fusion Middleware Control Console. Only sensor values in which the sensor action is to store the values in the database appear (for example, database sensor values).”

Domain Value Maps
Another great improvement in SOA Suite 11g is that Domain Value Maps (DVM) are now available to all components in SCA and not only limited to ESB (now Mediator) as is the case for SOA Suite 10g. You store DVM’s locally in your project or use MDS for this in SOA Suite 11g. Using DVM’s from XSLT transformations has slightly changed. More particularly the namespace and XSLT function name. If you automatically migrate SOA Suite 10g projects into SCA components and composites by using the migration tool or reopening the projects in JDeveloper 11g this will be handled automatically. However, if you rebuild SCA composites manually using the artifacts from your previous SOA Suite 10g project you have to take this into account and change the namespace and XSLT function name yourself.