JBoss.orgCommunity Documentation
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 CMS Publish/Approval Workflow feature can be activated by uncommenting the
ApprovePublishWorkflow
attribute of the portal:service=CMS
mbean in
portal-cms.sar/META-INF/jboss-service.xml
:
<mbean code="@cms.service.code@" name="portal:service=CMS" xmbean-dd="" xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean"> <xmbean/> ... <!-- Add this to activate publish/approval workflow integration --> <!-- <depends optional-attribute-name="ApprovePublishWorkflow" proxy-type="attribute">portal:service=ApprovePublish,type=Workflow</depends> --> ... </mbean>
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.