Tutorial
This tutorial will guide you through different scenarios to explain the behavior of the Imixs IX Workflow Technologies and the idea behind. We will see a typical business process from the view of the user who starts a process and from the view of the modeler who is responsible for the design of the process
The tutorials assumes that you have installed the IX JEE Workflow Example and also the IX Workflow Modeler. So the tutorial will make you familiar with the usage of the business processes defined by the IX Workflow System.
This workflow is visible as well in the Online Demo. To start the demo you have to login. Use the username "Manfred" and password "demo".
Start the IX Work Suite GlassFish Demo here.
Or install the example on your own JEE Server. See the installation guide for further informations.
To understand the modeling it is useful to install the IX Workflow Modeler too. So can easily change details of the workflow model and understand the usage of the modeling techniques.
The Model used in this tutorial can be downloaded here .
The "Open Issue Management" Business Process
The following tutorial shows a business process which supports an open issue workflow. This workflow is typical in a team orientated working situation where a problem should be shared and solved by different team members. So this business process passes an open issue document through a simple process as shown in the following illustration:
A user opens a new issue and delegates the issue directly to another member of his team. An open issue consists of the following informations:
- Name - a short description of the open issue. The name will be displayed in the worklist
- Description - a long description containing all necessary informations collected during the process
- delegate to - a person or chat partner who will be responsible for the workitem
Roles & Users
In the tutorial we will switch between different users to see the process from the view of different actors. The users in the tutorial are
- Manfred - he has a manager role and may access any workitem without security restrictions
- Eddy - he is editor and may also create and work on all workitems
- Anna - she is author and may only work on workitems which are assigned to her. This is the typical production role.
1.) Open the working list
We start the tutorial with the user "Manfred". So let's login to the system with user "Manfred" and password "demo".
When Manfred first starts the workflow client, he will see an empty list. This is because he has no actual workitems to be processed. If we did not create a new workitem this list is empty.
You may also login in again with another user (e.g. Anna) to see her worklist. But as we start in an empty database this list is also empty.
2.) Starting a new Open Issue Process out of a chat
Now let's start a new process. On the bottom of the worklist you see the button "start new process". This action creates a new empty workitem which is automatically assigned to our workflowmodel Process ID 1000. It is important that our workflow model supports this process because the Process ID 1000 is a fixed ID in this example..
Now you get the form on the right hand side of our working list to describe the open issue. You can fill in the following informations:
- Title: short description of the issue. This title will be displayed later in our worklist
- Description: long description of our issue
- Priority
- Department
- Responsible - to this person the issue is delegated
Now fill in the fields but leave the field "Responsible" blank.
Click the "accept" button. This first workflow action is assigned to your model and the activity 20. It says that we want to accept this issue and work on it. The ProcessID or the workflow status will now change from "1000=open issue" to "1020=progress".
This is the corresponding section when you open the model file in the IX Workflow Modeler:
Now you see your first issue in your worklist on the left side. The workitem is now in our worklist because we are the last editor of this issue and we did not yet delegate the issue.
3.) Delegate the Issue
Now lets delegate the issue to another person. So we open the issue again using our working list and change the responsible person.
In the field "Responsible" we select the user "Eddy" and press the button "delegate".
This action is assigned to our Workflow Model Activity 10. It changes the access control of this issue to Eddy. So we will no longer be author of this issue but we delegate this access right to Eddy.
The ProcessID of the Issue will not be changed and still stays in 1020.
See the Access Property of the "delegate" Activity 1020.10 to see what will happen with the write access. We replace the existing access with the new Delegate field of our workitem. So the selected person will get the write access.
As a result of that the issue disappears from our working list.
4.) Login with another User
Now lets find the issue. For that we need to login with the user "Eddy". Open a new browser window and log in again to the workflow client with the user name "Eddy" and password "demo" (depending on your webbrowser you may first need to close all browser windows to get the login dialog).
After a successful login we see our issue in the working list of "Eddy"
Now Eddy may open the issue and maybe solves the problem (this is what we would expect from Eddy) or delegate it to another person.
When you open the issue you see new actions on the bottom of the form.
This are the activities assigned to the new ProcessID 1020 defined in our workflow model:
Ok we solve the problem and press the button "solve". Now the issue will be reassigned to Manfred who was the creator of this issue. To understand this look at the solve activity in the model - section Access:
We change the write access back to the creator. So Manfred will now be again the owner of the workitem.
In a result of that the issue disappears from Eddies working list.
5.) complete the open Issue
When we now login once more as user "Manfred" we will see the issue again in his workinglist. The issue has now the status "verification".
In this status with the processID 1030 we can verify the solution from Eddy and decide to close the issue - this will finish the process - or to decline it and give it back to Eddy or a any other person in our team.
See the corresponding section in the Modeler:
