Creating a Process

Overview¶

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 activity must be matched with a element, and every partnerLink used in an activity must be matched with an element in deploy.xml (unless that partnerLink has initializePartnerRole="false").

Formal definition¶

The XML schema describing ODE's deployment descriptor is available here. 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 partnerLinks with endpoints:

<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¶

User-defined process properties provide means to configure process models and their instances. They are either statically declared and set in the deployment descriptor deploy.xml or can be set using the process management API. All instances of a process model share the same set of process properties. If a process property changes, it changes for all instances.

A process property is identified by a QName and can carry a string as value. To set a process property statically in the deployment descriptor, add the following snippet to your deploy.xml:

<process name="pns:HelloWorld2">
    ...
    <property xmlns:loan="urn:example" name="loan:loanThreshold">4711</property>
    ...
</process>

It is also possible to set or change a property by calling the PM API function setProcessProperty(final QName pid, final QName propertyName, final String value).

Once set, process properties can be used in two different ways: * Using XPath in process models * Using Java in ODE extensions

For instance, instead of hard coding the amount of money that triggers an in-depth check in a loan approval process, you could read a process property instead. That way you can reconfigure your process without having to redeploy the process again.

To read process properties in a BPEL process, you can use the non-standard XPath extension bpws:process-property(propertyName), e.g. in a transition condition or in an assign activity:

...
<assign>
    <copy>
        <from xmlns:loan="urn:example">bpws:process-property(loan:loanThreshold)</from>
        <to>$threshold</to>
    </copy>
</assign>
...