JBoss.orgCommunity Documentation

Chapter 23. Portal Workflow

23.1. jBPM Workflow Engine Integration
23.2. CMS Publish/Approve Workflow Service

JBoss Portal packages a Workflow Service based on jBPM. This service provides you with the jBPM services that your portal can use to build out the end-user/application workflows that should meet your portal's requirements.

The jBPM Workflow service is packaged as an mbean and takes care of all the low-level jBPM related functions. The configuration is found in portal-workflow.sar/META-INF/jboss-service.xml.

The CMS Publish/Approval Workflow feature is turned on by default, so that every file that is created or updated needs to go through an approval process before it can be published to go live. The current implementation creates a pending queue for managers. The managers can then either approve or reject the publishing of the document in question.

The workflow service can be configured by editing the portal:service=ApprovePublish,type=Workflow mbean found in portal-cms.sar/META-INF/jboss-service.xml.

   
<!-- ApprovePublish workflow service -->
   <mbean
      code="org.jboss.portal.cms.workflow.ApprovePublishImpl"
      name="portal:service=ApprovePublish,type=Workflow"
      xmbean-dd=""
      xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
      <xmbean/>
      <depends optional-attribute-name="WorkflowService" proxy-type="attribute">
      	portal:service=Workflow,type=WorkflowService
      </depends>
      <depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">
      	portal:service=Module,type=IdentityServiceController
      </depends>
      <!-- JBPM process definition -->
      <attribute name="Process">
         <!-- cms approval workflow -->
         <process-definition name="approval_workflow">
            <start-state>
               <transition to="request_approval"/>
            </start-state>
            <task-node name="request_approval" signal="first">
               <task name="approve_publish">
                  <assignment class="org.jboss.portal.cms.workflow.PublishAssignmentHandler"/>
                  <event type="task-start">
                     <action class="org.jboss.portal.cms.workflow.FinalizePublish"/>
                  </event>
                  <exception-handler>
                     <action class="org.jboss.portal.cms.workflow.TaskExceptionHandler"/>
                  </exception-handler>
               </task>
               <transition name="approval" to="end"/>
               <transition name="rejection" to="end"/>
            </task-node>
            <end-state name="end"/>
         </process-definition>
      </attribute>
      <!--
         overwrite = false creates the process first time if does not exist, for
         subsequent server restarts, this process definition remains in tact

         overwrite = true creates the process first time if does not exist,
         for subsequent server restarts, it creates a new version of the process definition
         which will be used for processes created from then onwards. Old processes created
         for an older version of the definition remain in tact and use their corresponding
         process definition.

         Typically use overwrite=false and overwrite=true only when a new process definition
         related to this workflow needs to be deployed
      -->
      <attribute name="Overwrite">false</attribute>
      <!--
         A comma separated list of portal roles that are designated
         to act as workflow managers. They are allowed to
         approve/reject content publish requests
      -->
      <attribute name="ManagerRoles">Admin</attribute>
      <attribute name="JNDIName">java:portal/ApprovePublishWorkflow</attribute>
   </mbean>

Of note in this configuration are the Process and ManagerRoles attributes. The Process attribute is used to provide the jBPM process definition to be followed by the workflow service during the approval process. This follows the standard jBPM syntax for process definition. ManagerRoles, on the other hand, is a comma-delimited list of user roles that are being marked as "managers" who can approve the publication of CMS documents.