Table of Contents
TODO
A workflow definition is designed for a given workflow engine backend and not for the Nuxeo workflow service itself. Nuxeo workflow doesn't specify a new process definition language. Thus it has no Nuxeo specificities speaking of format or process definition language. For instance, if you use jBPM as a backend with Nuxeo 5 then the workflow definition should be a standard jpdl file that you may have designed using your favorite editor or still if you are using Shark as a backend then the workflow definition will be a standard WFMC process definition.
Once your workflow definition has been designed and is ready you can deploy it in Nuxeo workflow. Of course, the target workflow engine backend plugin should be deployed and registered against the workflow service.
The Nuxeo workflow service provides a dedicated extension point for workflow definition deployment. The extension point is called definition.
In this case, the workflow definition will be deployed at application server deployment time (For now, this is the case when the application server is starting up since hot deployment is not yet possible using Nuxeo Runtime at the time of writing this document).It means this way of deploying workflow definition is not suitable for all cases. See the next subsections for other ways of deploying workflow definitions.
Below is an example of a jPDL workflow definition contribution for the jBPM backend. This XML fragment would be defined in a contribution registered as a component in a bundle:
<?xml version="1.0"?>
<component name="com.company.workflow.sample.contributions">
<extension target="org.nuxeo.ecm.platform.workflow.service.WorkflowService"
point="definition">
<definition>
<engineName>jbpm</engineName>
<mimetype>text/xml</mimetype>
<definitionPath>workflows/process_definition.xml</definitionPath>
</definition>
</extension>
</component>
engineName: name specified for the target backend at workflow service registration time (see workflow service backend extension point)
mimetype: mimetype of the workflow definition. This is especially interesting in case of the format is binary. (serialization issue at deployment time)
definitionPath: bundle relative path of the workklow definition to deploy.
In this situation here is how would look the tree:
com.company.workflow /
META-INF /
workflows /
process_definition.xml
MANIFEST.MF
OSGI-INF /
workflow-definitions-contrib.xml
TODO
The versioning information are stored in the DocumentModel under the
fields major_version and minor_version of the uid.xsd
schema. Set the version as you would any other field:
documentModel.setProperty("uid","major_version",1);
documentModel.setProperty("uid","minor_version",1);
The field used for version is adaptable via the
properties extension point of the
org.nuxeo.ecm.platform.versioning.service.VersioningService
component. It allows to define which properties should be used to set
versions for a given document type.
<versioningProperties> <majorVersion>my:major_version</majorVersion> <minorVersion>my:minor_version</minorVersion> <documentType>File</documentType> <documentType>Note</documentType> </versioningProperties>
Event such as saving a document or following a life cycle transition can change the document's version number. To use this feature you need first to define which event should be listened to and then how the version number should behave.
The CoreEventListenerService is used to define which
event to listen to. The default declaration is in
nuxeo-platform-versioning-core:
<listener name="versioninglistener"
class="org.nuxeo.ecm.platform.versioning.listeners.DocVersioningListener">
<eventId>lifecycle_transition_event</eventId>
<eventId>documentCreated</eventId>
<eventId>beforeDocumentModification</eventId>
<eventId>documentUpdated</eventId>
<eventId>documentRestored</eventId>
</listener>
<listener name="versioningChangelistener"
class="org.nuxeo.ecm.platform.versioning.listeners.VersioningChangeListener" />
The class
org.nuxeo.ecm.platform.versioning.listeners.DocVersioningListener
implements the behavior of the versioning when those events happen.
To modify the version of a document when a life cycle state is reach
you need to define rules with the behavior(increment major, minor or do
nothing) using the extension rules from
org.nuxeo.ecm.platform.versioning.service.VersioningService:
<versioningRuleEdit name="sampleEditRuleProject" action="ask_user"
lifecycleState="project">
<option value="no_inc" default="true" />
<option value="inc_minor" />
<option value="inc_major" />
</versioningRuleEdit>
The default behavior for all type but File and Note is to increase the minor version for each life cycle change. You need to override one of the default rules if you add a new type. The order is important, the list of rules is read and the first match is used.
<versioningRuleEdit name="sampleEditRuleAnyState" action="ask_user"
lifecycleState="*">
<includeDocType>File</includeDocType>
<includeDocType>Note</includeDocType>
<includeDocType>MyNewType</includeDocType>
<option value="no_inc" default="true" />
<option value="inc_minor" />
<option value="inc_major" />
</versioningRuleEdit>
The CoreSession or the seam component
documentVersioning and versionedActions allow
to access document from previous version. On CoreSession, the
method getVersions return all the versions of a document.
The versioning service manages the version inside Nuxeo. Two implementations are available:
The custom Nuxeo service, more flexible and used by default
The default JackRabbit implementation.
To modify this setting edit the file
config/default-versioning-config.xml:
<!--property name="versioningService" value="org.nuxeo.ecm.core.repository.jcr.versioning.JCRVersioningService"/--> <property name="versioningService" value="org.nuxeo.ecm.core.versioning.custom.CustomVersioningService"/>
This section shows how to use the versioning module, how to modify the version of a document automatically or manually and how to use a document from a previous version.
TODO
jBPM comes with a simple servlet allowing one to deploy jPDL process definitions and monitor running process instances. (NB: this is not yet activated on stock Nuxeo 5 instance).
