What is a Transformation Process?
A transformation process is a lightweight, simplified alternative to a business process (i.e. BPEL). Activities are defined in the process and executed sequentially at runtime. Two activity types are supported by default: 1) transform
- applies a transformation and assigns the result, and 2) invoke
- invokes a service endpoint. For those familiar with BPEL, correlations, partner links, logical/iterative constructs... none of these activities exist in a transformation process.
How to define a Transformation Process
Each transformation process is the implementation of a web service operation. Therefore, a transformation process is defined by an operation
element in the transformmap.xml configuration file
. Activities are added based on the needs of the operation. For example, a Service Bridge process (described below) would require transform and invoke
activities, whereas a Request-Reply process would only need transform
How to Invoke and Reply
One of the primary responsibilities of a transformation process writer is to ensure all outgoing message exchanges are initialized correctly. An outgoing message exchange (OME) is either 1) input to a service invocation (via an invoke
activity) or 2) at the completion of a transformation process implementing a two-way operation (an implicit Reply activity). To initialize an OME, all defined parts of the message must have values assigned. Values are assigned by assigning the result of a transformation in a transform
For example, in a Request-Reply process where the reply is a two-part wsdl message, there will likely be two transform
activities as follows:
<operation opName="myXsltOp" inputVariable="msgIn" outputVariable="msgOut">
<transform file="firstPart.xsl" source="$msgIn.part1" result="$msgOut.part1"/>
<transform file="secondPart.xsl" source="$msgIn.part2" result="$msgOut.part2"/>
Common Usage Scenarios
Transformation processes support, but are not limited to, the following usage scenarios:
The transformation process acts as a service provisioner only, performing one or more transformations as needed. The "reply" can be a message or a status, meaning that both two-way and one-way operations are supported, respectively.
The transformation process acts as a service provisioner and consumer. This scenario typically starts with zero or more transformations, followed by a service invocation and (optional) additional transformations, and concludes by sending a message as reply. The initial transformations are used to initialize the invoke
activity's outgoing message exchange. The subsequent transformations are responsible for initializing the reply message, if the implemented operation is two-way.
For a summary of TransformSL wiki pages, please see the TransformSL Links wiki