Java Reference
In-Depth Information
NOTE
The
doXslTransform
function is terrific if you need to maintain different versions of messages that
route to the same service. For example, say that you have defined a service that accepts customer
address information, but industry restrictions or some new business partner now requires you to send
them additional information that your source service does not provide. A cardinal virtue of a prof-
itable SOA is interface stability. You don't have the time or ability to change every client of your
service to provide this additional data, or data in the newly required format. This is where XSLT may
offer a good solution. Using the
doXslTransform
function allows you to provide your business
partners with the right data (say, in the form of defaults) in the right format, but in a way that doesn't
force you to change your client-facing interface.
Here is a quick example of how to use the
doXslTransform
function:
<invoke partnerLink="Warehouse"
outputVariable="inventoryItems" ...>
</invoke>
<!-- Reformat the items coming from the warehouse
for another system in the process -->
<assign>
<copy>
<from>
bpel:doXslTransform("orderItems.xsl", $inventoryItems)
</from>
<to>
$orderItems
</to>
</copy>
</assign>
...
The XSL stylesheet will be applied to the items that are returned by the invocation of the
warehouse partner service, massaging them into a format that is consumable by another part
of the process. This could be a different partner operation you're going to invoke, or some
other activity. The point is that you copy from the transformation to a variable (here,
$order-
Items
) that will hold the result of the transformation.
