SMILA/Documentation/BPEL Workflow Processor

This page describes how to configure the SMILA BPEL workflow processor and how to call SMILA pipelets from BPEL processes. We do not assume any BPEL knowledge here, i.e. this page should contain everything to enable you to create at least simple BPEL processes for being used in SMILA.

Contents

Basic configuration

The BPEL WorkflowProcessor expects its configuration in configuration/org.eclipse.smila.processing.bpel. In this directory it expects a file named processor.properties that describes the main configuration. This file can contain the following SMILA specific properties:

pipeline.dir (default="pipelines"): The name of a folder below configuration/org.eclipse.smila.processing.bpel which contains the BPEL process files (together with all needed XSD and WSDL files) and the ODE specific deploy.xml file. See below for details.

pipeline.timeout (default="300"): Maximum time in seconds allowed for processing a pipeline. If a pipeline invocation takes longer, it is aborted with an error. You may want to increase this value in case you expect longer processing times in your application (e.g. when analyzing very large documents).

record.filter (default = none): A record filter defining the attributes and annotations that should be contained in BPEL workflow objects. If none is set, the workflow objects will contain only the record IDs to be processed. Add only those attributes and annotations to the filter that are actually used in any pipeline, because adding too many (and too huge) elements to the workflow object may decrease performance and use more memory. As the WorkflowProcessor uses the Blackboard to filter objects, you must define the filters in org.eclipse.smila.blackboard/RecordFilters.xml.

As the BPEL WorkflowProcessor is based on the Apache ODE BPEL engine, you can also add all ODE specific configuration properties to this file, just use the prefix ode. See ODE documentation for details. You have to add at least the configuration for a database connection which ODE needs for internal purposes (e.g. storing process definitions). For SMILA purposes usually an in-memory Apache Derby instance is completely sufficient, the required Derby library is includedn in SMILA. To use it, set the following properties:

You can now add pipelet invocations to your pipeline BPEL. To add another pipelet you have to add only another BPEL file and copy the <process> element in deploy.xml for the new pipeline.

Pipelet invocations

Pipelets (aka Simple Pipelets) are classes that implement interface org.eclipse.smila.processing.SimplePipelet (in bundle org.eclipse.smila.processing) and have a corresponding definition file (the name must end in ".json") in the SMILA-INF directory of the bundles that contain them. They are configured by the WorkflowProcessor on pipeline initialization. One instance is created for each time they occur in any pipeline, instances are not shared between multiple pipelines.

The json file must at least contain the class name of the class that implements the Pipelet interface. E.g.

{"class":"org.eclipse.smila.processing.pipelets.AddValuesPipelet"}

In Versions up to SMILA 0.9 the Pipelets must be registered in the SMILA-Pipelets manifest header of the bundles that contain them! In these versions the pipelet definition files in the SMILA-INF folder are ignored!

Examples that come with the base SMILA distribution are

in bundle org.eclipse.smila.processing.pipelets:

org.eclipse.smila.processing.pipelets.AddValuesPipelet: add some attribute values to each record.

org.eclipse.smila.processing.pipelets.HtmlToTextPipelet: Extract plain text and metadata from an HTML document in an attribute or attachment of each record and writes it to configurable attributes or attachments.

Replace the class name with the class name of the pipelet to use and add configuration parameters as needed - this should be documented by the pipelet provider. The configuration is a generic AnyMap object like the one used as record metadata, see SMILA/Documentation/Data Model and Serialization Formats for details. If the output variable is the same as the input variable (which is usually sufficient), you can omit the output attribute.

In versions later than 0.9 the invokePipelet activity supports to give an additional "index" variable. This is to support advanced pipelines that can be invoked with multiple records at once (usually used in the PipelineProcessingWorker to reduce BPEL overhead) and still can use conditions to invoke pipelets based on attribute values. You can then do forEach loops on the record list and evaluate conditions on each record. For example the following loop would invoke the HtmlToTextPipelet only for records that have the mime type "text/html":

The invokePipelet activity assumes that the index variables takes the values 1 to (number of records).

If an output variable would be specified it would be assigned a list with only the one processed record in it. This can be usefule if more than one pipelets would be invoked. If no output variable is specified, the input variable is not modified in this case.

Note that the pipelet is invoked in parallel for each record in this example.

Pipeline invocations

You can also invoke one pipeline from another to group pipelet invocations that belong together. To do this you have to use the standard BPEL invoke activity to invoke a BPEL partner link for the sub pipeline:

define a partner link in the <partnerLinks> section of the BPEL file, replace $SUBPIPELINENAME with the name of pipeline to invoke as defined in its <process> element:

add an BPEL <invoke> activity between <receive> and <reply>, replace $SUBPIPELINENAME with the pipeline name and adapt the inputVariable and outputVariable attributes if necessary (omitting outputVariable is not allowed here!):

Advanced process definition

You can of course use all other BPEL elements, too, to create your pipelines like conditions, iterations, parallel flows, invocation of external Web Services, etc. However, to describe them is beyond the scope of this introduction and requires "real" knowledge about BPEL (and WSDL, for invoking Web Services).