Before deploying a business process in the WSO2 BPS, all relevant deployment artifacts need to be bundled in a zip file. At the minimum, the zip should contain
- The deployment descriptor
- One or more process definitions (BPEL), WSDL and XSDs
Additionally, the zip file can also contain other files such as SVGs or XSLs.
The deployment descriptor is a file named deploy.xml which resides at the root of the zip file. During deployment, the process engine loads all documents from this file. Loading documents allows it to reference processes, service and schema definitions using fully-qualified names, and import based on namespaces instead of locations. WSO2 BPS and Apache ODE use deploy.xml to configure one or several processes to use specific services.
The deploy.xml file configures one or more 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 partner link used in an
<invoke/> activity must be matched with an
<invoke/> element in the deploy.xml, unless that partnerLink has initializePartnerRole="false". Without a deploy.xml, a BPEL engine cannot determine the concrete-level details of the partner services. In the deploy.xml, the
<service/> element determines the concrete-level details of all partner services that interact with the BPEL process.
An example of a deploy.xml configuration is shown below:
Note that, in the above example, every process and service is namespace-qualified, and the locations of each .bpel or .wsdl are not mentioned. The deploy.xml supplies binding information for each partnerLink, to create WSDL services with the
<service/> element for each
<invoke/> element. During the deployment of a process in the BPEL engine, it loads all required documents from the deployment descriptor.
The XML schema describing the deployment descriptor is available here. The root element, deploy, contains a list of all deployed processes from the deployment directory:
Each process is identified by its qualified name and specifies bindings for provided and invoked services:
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 associate partnerLinks with endpoints:
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.
For example, a simple process that will only be invoked will typically use a deploy.xml configuration similar to the following:
The complete example can be downloaded from here.
A deployment including two processes typically look as follows:
Download the complete example from here.
Process Container Structure
In both WSO2 BPS and Apache ODE, the exact same flat file structure is used for a process container. XSDs may be contained in directories inside the process container. For example, the structure of the "FunctionProcess" is shown below.