Deploying a Process in Ode
Each deployment is a directory with all relevant deployment artifacts. At the minimum it will contain the deployment descriptor, one or more process definitions (BPEL or .cbp), WSDL and XSDs (excluding those compiled into the .cbp). It may also contain other files, such as SVGs or XSLs. The deployment descriptor is a file named deploy.xml (see the next paragraoh for its description).
During deployment, the process engine loads all documents from the deployment descriptor. Loading documents allow it to reference processes, service and schema definitions using fully qualified names, and import based on namespaces instead of locations.
To deploy in Ode, just copy the whole directory containing your artifacts (the directory itself, not only its content) in the path %DEPLOYMENT_ROOT%/WEB-INF/processes (in Tomcat it would be %TOMCAT_HOME%/webapps/ode/WEB-INF/processes).
Deployment Descriptor
To deploy your process in Ode you will need to create a simple deployment descriptor with basic information. The deploy.xml file configures one or several processes to use specific services. For each process, deploy.xml must supply binding information for partner links to concrete WSDL services. Every partner link used with a <receive> activity must be matched with a <provide> element, and every partnerLink used in an <invoke> activity must be matched with an <invoke> element in deploy.xml (unless that partnerLink has initializePartnerRole="false").
Formal definition
The root element deploy contains a list of all deployed processes from the deployment directory:
<deploy>
<process ...>*
{ other elements }
</process>
</deploy>
Each process is identified by its qualified name and specifies bindings for provided and invoked services:
<process name = QName fileName = String? bpel11wsdlFileName = String? >
(<provide> | <invoke>)*
{ other elements }
</process>
Each process element must provide a name attribute with the qualified name of the process. Optionally, a fileName attribute can be used to specify the location of the BPEL process definition (the .bpel file). The fileName attribute does not need to be provided unless non-standard compilation options are used or the bpel11wsdlFileName attribute is used to specify a WSDL document for a BPEL 1.1 process.
Each <process> element must enumerate the services provided by the process and bind each service to an endpoint. This is done through <provide> elements which associates {{partnerLink}}s with {{endpoint}}s:
<provide partnerLink=NCName>
<service name = QName port = NCName?>
</provide>
Note, that only one partnerLink can be bound to any specified endpoint.
The port attribute can be used to select a particular endpoint from the service definition.
Examples
A very simple process that would only be invoked would use a deploy.xml very similar to:
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
xmlns:pns="http://ode/bpel/unit-test" xmlns:wns="http://ode/bpel/unit-test.wsdl">
<process name="pns:HelloWorld2">
<active>true</active>
<provide partnerLink="helloPartnerLink">
<service name="wns:HelloService" port="HelloPort"/>
</provide>
</process>
</deploy>
See the complete example here![]()
.
A deployment including two processes invoking each other and whose execution would be triggered by a first message would look like:
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:main="http://ode/bpel/unit-test"
xmlns:mws="http://ode/bpel/unit-test.wsdl" xmlns:resp="http://ode/bpel/responder">
<process name="main:MagicSessionMain">
<provide partnerLink="executePartnerLink">
<service name="mws:MSMainExecuteService" port="MSExecutePort"/>
</provide>
<provide partnerLink="responderPartnerLink">
<service name="mws:MSMainService" port="MSMainPort"/>
</provide>
<invoke partnerLink="responderPartnerLink">
<service name="mws:MSResponderService" port="MSResponderPort"/>
</invoke>
</process>
<process name="resp:MagicSessionResponder">
<type>resp:MagicSessionResponder</type>
<provide partnerLink="mainPartnerLink">
<service name="mws:MSResponderService" port="MSResponderPort"/>
</provide>
<invoke partnerLink="mainPartnerLink">
<service name="mws:MSMainService" port="MSMainPort"/>
</invoke>
</process>
</deploy>
See the complete example here![]()
.
Additional settings
In memory execution
For performance purposes, you can define a process as being executed only in-memory. This greatly reduces the amount of generated queries and puts far less load on your database. Both persistent and non-persistent processes can cohabit in Ode.
To declare a process as in-memory just add an in-memory element in your deploy.xml:
<process name="pns:HelloWorld2">
<in-memory>true</in-memory>
<provide partnerLink="helloPartnerLink">
<service name="wns:HelloService" port="HelloPort"/>
</provide>
</process>
Be aware that in-memory executions introduces many restrictions on your process and what it can do. The instances of these processes can't be queried by using the Management API. The process definition can only include one single receive activity (the one that will trigger the instance creation).
User-defined process properties
