BPM: Workflowsystem

The Aim: Workflows and DMS LogicalDOC

A Workflow-Plugin is an essential part of an Document-Management-System. Workflows are translated by a standard-process given from an organization, it is possible to cut-through the line of processes being processed „offline paper by paper“ into system-based processes. User-Centric processing of relevant documents is the main purpose if were talking about digital workflows. For instance, an user can create a workflow that is responsible for approving a document within the company that would get sent to a particular customer. We have the opportunity to control all instances of tasks, execution lines that can be paced by a user being available through such a workflow. Document-Management is not only about storing a bunch of documents, it's a process involving tasks that revolve around the document as it's normally performed in the analog-world. Therefore its indispensable to introduce a workflow system to achieve a status of a more „realistically/robust“ DMS.

Features we want to implement

In the first version of the workflow system only a few workflows will exist that can be processed. Of course, its possible to deploy (register) workflows through an UI-Element to design workflows with an external editor (e.g. Workflow Design from RedHead).

This includes in detail the following aspects:

• deploying (registering) of process definitions through a Web-Interface
• governing of Tasks supported by UI (all User-handled Tasks can be processed from the underlying UI)
• Predefined Workflows includes the first version of the Workflow-Engine
• i´ve forgot

Open (common) questions

How can workflows be started?

Answer: It can be started from the documents browsing page, the user can select multiple documents and use a proper command in the toolbar to start the workflow. A new permission 'workflow' will be added so that only granted users can manage workflow-related tasks. Then a wizard starts which will allow the user to start a workflow on setting up default values for separate properties.

What about workflow-startup properties should they exist?

Pre-Answer:

• Due Date: amount of Time where the workflow is in time
• Reminder: should a user be remind via email about a task that is still open (AND OVER TIME)
• Priority
• Description: What we have to do in this workflow
• Comments: some notices/hints about the current workflow
• Assigns: Predefined Icefaces-Sites for the predefined workflows to assign all assignees to the right task

As described earlier LogicalDOC handles in the first line documents and in the second objects against them. Templates or Users have an impact on documents, respectively against the scope of view. But its actually unclearl in which kind of interaction a workflow can be used. What does this mean?

Well, if you process a workflow, its important to retrieve some information about the document, and the surrounded environment. For instance metadata that belongs to this document.

Pre-Answer:

Another question belongs to the display-part in which we must find a way to display a task in a user-friendly way.

Pre-Answer:

What about Task-Types? Are there predefined Task-Types that can be used? For Instance: upload-Task

Pre-Answer:

Before we can answer this question we must decide which scope we want to have. What does this mean?

First of all it's important to introduce a particular Workflow-Engine in LogicalDOC. Secondly we have to implement a basic UI so we can govern all tasks through the UI. Third, it must be clear which parts of the elements will exist as defaults within the workflow (e.g. metadata of the document).

Pre-Answer:

Is it possible to interact with a workflow via Web service? If yes, should we use the web service plug-in from LogicalDOC?

Pre-Answer:

Technique on how to implement JBPM

JBPM is targeted as the framework we want to use with LogicalDOC. JBPM offers a sophisticated way to bring Java and Workflows together in a really clean-written descriptive way. Every workflow that is created from scratch will be within one XML-File. The language is called JPDL and describes all tasks, and execution-lines we can make. After we have "painted" our workflow with JPDL (its also possible to use a Workflow Design like JBoss Designer), the workflow must be registered against the Workflow-System in order to use it (we now have a process definition stored). This stage is called Deployment (deploying a workflow). After a workflow has been deployed we can make the workflow take the uniquely used process-definition id. If a workflow is started, the created tasks will be processes via an Token/Tokens(if we have parallel tasks).

Spring offers a more sophisticated way use JBPM - Spring-modules JBPM. In the current SVN-Repository all this has been setup in the spring-module. Now we can harness all the power that comes from spring to create powerful workflows.

Problems and Troubleshooting

The Spring-Module of JBPM comes with version 3.1 which is not state of the art as well as creates errors with dependencies. For instance, it will not be used with the current Hibernate-Version. So some errors may arise if you try to delete or update some process instances for that instance. Thus we can not use these libraries. I've primarily tested Version 3.2 and it works very well, despite the spring-jbpm-module that gets created for version 3.1.X. More tests must be performed.

Examples

We´d like to provide two examples in which way a workflow system can help and guide us for achieving a higher business value on optimiziation and accelerating processes.

Purchase Order

A more complex workflow is introduced right here. For sure, convenient issues we´ve purged some logical behaviours within the upcoming workflow.

Puchase Order - as a centric and system-critical processes handles all the fine-grained steps that must be made to order new components for a manufacturing company. In this example we´ve got a semiconductor-company with an output of boards for smartphones. Some technical engineers have the opportunity to order new components for its production-process (being called line manager). The Testengineer writes down all components that must be ordered so a functional-leader (a department leader) can review this list and check whether something got missed. If its so, the Testengineer must edit the purchase-order list to postedit these appropriated entries being noticed by the Functional-Leader. If the leader does not complain the list of purchasing items an approvement will be taken as well from this person.

Now we´ve got still achieved a first important step. The operative-unit responsible for producing the output have approved the list so we could "mark" the first processline as resolved. Next some management decision must be made which can be beatefully detached from the operative responsibilities. Depending on the costs of the order other swimlanes (responsibilities) are affected to approve and continue the purchase order process. Of course, in every company there is an apparted approach about "external" costs-creating. In this example the systems checks the costs and routes the handling to the right persons. For instance, if a order for about 30.000 € have been set, the order will be processed by the unit-leader of manufacturing. If its got higher (over 40.000 €) the management-board must directly approving this order-request. Its an common approach in companies.

Its important that every person can revoke the order-request and set comments as well to to it so the initiator can make appropriated changes.

If all swimlanes does approving the the order-process, financial services gets a generated order-request file being created based on a template file and setted up with all of the informations that needs the supplier.

The whole flowchart can be downloaded right here: Media:LogicalDOC-Workflow.pdf‎

Review and Approval

A institution reveals quarterly new qualitiy-tests regarding wholefood-products. All releasable documents will be stored in a particular "Documents Release" folder. Therefore a process has been made to made up one review-approach for these tests. Initially an Editor must write an article followed by an review of two reviewers. If one of these reviers revokes an approvement the editor gots back the document for reediting.

But if both reviewers complains on the document, its inepting to process any further tasks based on this state of document as to much failures appears to be on it. The workflow ends unsuccesfuly. If both reviewers approve the document all seems okay with this document so we can route the document to a final-review - to a editor-chief. The editor chief can decide - other than the reviewers - witch path should be taked based on the document. For instance, if editors-chief decides do reedit the document, he can do this by simply processing that state so documents routing comes back to the editor. If all seems okay, he can approve the document so the document can stored in a safety place - being named "Documents Release" - without write-permission to everyone.

The whole flowchart can be downloaded right here: Media:LogicalDOC-ReviewAndApproval.pdf‎

Benefits from a Workflow managed by LogicalDOC-System

• As a DMS describes the approach of a centralized-storage approach for all business-documents, all the more for the business its logical that the workflows will be managed with the same system for convenient matters as LogicalDOC provides full access to all functionalities to the underlying documents
• Management-Size will be greatly downsized but return on invest is increased rapidly as we don't have to manage offline-documents within multiple file-directories, emails or even analogous papers. All is managed within LogicalDOC so the User only needs to login to LogicalDOC
• Focusing on object: Every user will see there tasks and what must be processed. All information is within the workflow, within one screen. The user just has to read the instructions given from the workflow or another person. No more frustrations!
• We don't need to know the approach: The User doesn't needs to know which person must be delivered with own output of the task. By simply finishing the task the Workflow-Engine finding out the right way to go.
• Management of all Workflows/Tasks from project managers (tasks can be seen from a manager)
• Historization of activities: All changes to the tasks/workflows will be logged and easily reviewed from every person
• Time is over for overdue tasks: The Workflow-Engine checks automatically for due dates all of the tasks. Users that have overdue tasks will be informed about this issue.
• It is easy to understand: for all ages. Only one click must be made to retrieve all information
• keep an eye on business times (which times got worked), tasks will be routed only in this time*

The completed flowchart of the purchase-order-request can be downloaded here: Media:LogicalDOC-Workflow.pdf

Relases Features that comes around with 4.6 of LogicalDOC

• jBPM 3.2.3-Integration into LogicalDOC
• Supports Workflow-Design within LogicalDOC using sophisticated UI-Library ICEFaces
• WorkflowTasks, Endstates, Forks, Joins can be designed, made up together through sophisticated Workflow-Designer within LogicalDOC
• Take use of this feature via Drag-&-Drop-Support to model-up your Workflow
• Workflow-Transitions can be fully entered
• Escalation-Management_ Taskassignmentemails as well as Reminder-Emails are possible (text can be dynamized on using wildcards like ${taskname} to personalize an eMail)
• Reassignment of tasks
• Startworkflow-Wizard with editable assignments as well as preview about the workflows
• Dividing of Responsibilities: Admins can edit workflows whereas endusers can start that workflows through the document-browser