This chapter introduces the modules in charge of the BPM functionality inside the Kie Workbench. These modules were grouped under the name of JBPM Console NG and they can be found here: http://github.com/droolsjbpm/jbpm-console-ng . Inside the GitHub repository will also find a standalone version of these modules integrated with some authoring tools, like for example the Process Designer and the Form Designer, as well as some common tooling to explore the business repositories. If you are interested in a full integrated environment that provides Form Modeling, Data Modeling, Rules Authoring, etc, you should take a look at Kie Workbench which provides all the functionality discrived in these docs plus all the mentioned above.
This documentation is organized into different sections that reflect the project internal structure. The main goal of this document is to explain the functional aspects of each of the following modules as well as to server as reference for developers that wants to customize or extend the provided functionalities.
Process Runtime: This module contains all the tools to create and manage process definitions and process instances.
Tasks: This module provides all the Human Tasks related functionality. This module is integrated with the Form Modeller to provide a unified experience, so users can work on the tasks that are assigned to them.
Deployments: This module contains all the functionality related with the management of deployment units, that represent packaged business assets ready to use in runtime environments.
Jobs: This module provides all the functionality to schedule async Jobs using the jBPM Executor module.
Notice that on these documents the common infrastructure screens are not explained. If you are interested in finding more information about Process Designer, Project Explorer, Form Modeller and other modules please check the jBPM Documentation.
This chapter describes the screens related with the creation and management of process definitions and process instances.
Once you have modelled and configured all the techncial details to run a process definition your process definition will appear in the Process Definitions List. Once you have the process in the Process Definition List, you can start new instances of it. The following sections describes the features provided by each of these screens. You can find these screens under the Process Management Menu, in the jBPM Console NG or in Kie Workbench.
You can find the source code for this module here: https://github.com/droolsjbpm/jbpm-console-ng/tree/master/jbpm-console-ng-process-runtime
The process definition section is composed by two main screens: the Process Definition Lists and the Process Definition Details.
The process definition list shows all the available process definitions that were deployed into the platform. Look at the Deployments section for more information about how to check all the deployment units available.
You can click in the list rows to access to the details of the process definition.
The process definition details shows all the available information about the process definition. You can consider this screen as a brief about the process model. You can quickly see if there is a Sub Process associated with it, or how many users and groups are participating in the selected definition.
Notice that you can View the Process Model (Read Only mode) using the Options Menu in the top bar. You can also look at all the process instances for the selected process definition goint to Options -> View Process Instances.
You can create new Process Instances from the Process Definition List or from the Process Definition Detail view.
When you want to create a Process Instance usually a Form will be presented to introduce the information required by the process to be started. Once you complete the form and click into the Start Process button, the instance will be created and the details of the Process Instance will be displayed on top of the Process Definition Details.
This chapter introduces the Task Management screens and the its integration with the Form Modeller component to allow users to work on their assigned tasks. You can find the source code of these screens here: https://github.com/droolsjbpm/jbpm-console-ng/tree/master/jbpm-console-ng-human-tasks
Every user with access to the platform will have access to its personal task list where tasks assigned to him/her will be displayed. Each user will be able to create its own personal tasks or work on tasks that were create as a result of a business process execution.
You can access to the Task List under the Work main menu:
Pending tasks can be displayed using different methafors depending on what the user is interested on. We are currently providing two different views explained in the sections below: Grid and Calendar View.
If you are interested in having a tabular view of all the pending tasks for a specific person or group you can use the Grid View. The list will show all the pending tasks ordered by the columns presented. You can change the default ordering clicking on the column header.
If you want a more time oriented view of your pending tasks you can use the Calendar View. This view arrange the tasks based on the Task Due Date. You can switch between three different ranges: Day, Week or Month.
The Day view shows all the tasks that Due Today. Notice that you can change the selected date using the calendar or using the Next and Previous button. The Today button will be enabled when you are in a different day than today, and when you click it it will return the selection to the current date.
The Week view shows all the tasks pending for the current week. You can change the selected week using the calendar or the Next and Previous button. If you click on the Today button, you will be moved to the week the current week.
The Month view shows all the tasks that due on the selected month. You can change the month using the calendar or the Next and Previous button. If you click on the Today button the calendar will show all the tasks that due in the current month.
You can access to the Task Details by clicking in a task row (in both Grid and Calendar Views). The details associated with a task can be changed, like for example the Due Date, the Priority or the task description.
You can also view the Process Context for a specific task. If the task was created by a Business Process, you will have access to see the Process Instance status that has created it.
Finally you can see the Task Log, which allows you to see all the operations that has been executed on the task since its creation.
Tasks can have associated a Form to store data. If tasks are part of a Business Process, usually some data needs to be collected and propagated to the business process for further usage. For that reason, tasks has to provide a way to gather and store data. Forms can be created for specific tasks using the Form Modeller. If no form is provided a dynamic form will be created based on the information that the task needs to handle. If a task is created as an ad-hoc task (not related with any process) there will be no such information to generate a form and only basic actions will be provided.
You can Delegate tasks to different people when you are not able to work on them.
As mentioned in the introduction a User can create their own tasks, which will not be associated with any Business Process. These tasks can be used to keep track of your personal list of TO DOs. You can also create tasks and assign them to different people in your team or group.
This chapter introduces the Deployment administration screen. Technical users will be able to check which deployment units are deployed into the platform and available to use. You can find the source code of these screens here: https://github.com/droolsjbpm/jbpm-console-ng/tree/master/jbpm-console-ng-business-domain
You can access to the Deployment Units List under the Runtime menu (TODO: fix image and menu name)
The Deployment Unit list shows all the Deployment Units deployed into the platform that are already enabled to be used. Each deployment unit can contain multiple business processes and business rules. By default the list is populated by Building and Deploying a KIE Module using the Project Editor Screen. When you Build and Deploy a
You also have the option to deploy custom Deployment Units with other options different from the defaults. When a KIE Project is deployed, by default the "DEFAULT" KIE Base and KIE Sessions are used and the SINGLETON Strategy is used. You can select a different KIE Base and KIE Session using the New Deployment Unit.
This section shows different examples that can be cloned directly inside the KIE Workbench from the JBPM-Playground repository (https://github.com/droolsjbpm/jbpm-playground). All these examples are high level and business oriented.
If you want to contribute with these examples please get in touch with any member of the jBPM/Drools Team.
Let’s imagine for a second that you work for a Software company that works with several projects and from time to time the company wants to hire new developers. So, which employees, Departments and Systems are required to Hire a new Developer in your company? Trying to answering these questions will help you to define your business process. The following figure, represents how does this process works for Acme Inc. We can clearly see that three Departments are involved: Human Resources, IT and Accounting teams are involved. Inside our company we have Katy from the Human Resources Team, Jack on the IT team and John from the Accounting team involved. Notice that there are other people inside each team, but we will be using Katy, Jack and John to demonstrate how to execute the business process.
Notice that there are 6 activities defined inside this business process, 4 of them are User Tasks, which means that will be handled by people. The other two are Service Tasks, which means an interaction with another system will be required.
The process diagram is self explanatory, but just in case and to avoid confusions this is what is supposed to happen for each instance of the process that is started a particular candidate:
- The Human Resources Team perform the initial interview to the candidate to see if he/she fits the profile that the company is looking for.
- The IT Department perform a technical interview to evaluate the candidate skills and experience.
- Based on output of the Human Resources and IT teams, the accounting team create a Job Proposal which includes the yearly salary for the candidate. The proposal is created based on the output of both of the interviews (Human Resources and Technical).
- As soon as the proposal has being created it is automatically sent to the candidate via email.
- If the candidate accept the proposal, a new meeting is created with someone from the Human Resource team to sign the contract.
- If everything goes well, as soon as the process is notified that the candidate was hired, the system will automatically post a tweet about the new Hire using the twitter service connector.
As you can see Jack, John and Katy will be performing the tasks for this example instance of the business process, but any person inside the company that have those Roles will be able to claim and interact with those tasks.
Let's take a look at the Project content in the Authoring Perspective:
As you can see it contains the hiring.bpmn2 process and a set of forms for each human task. You can explore these knowledge assets by clicking on them. You will notice that different editors will open for different types of assets. If you click on the Business Process file you will be able to edit the process definition using the Process Designer:
Feel free to inspect the forms as well. Notice that the Form Modeller will be opened and there you can edit the forms to fit your requirements.
In order to build the Project so it gets available in the Process Definitions List you need to go to the Authoring Perspective and open the Project Editor panel:
Once you open the Project Editor, you will see on the top right corner of the panel the button called Build & Deploy. This button will allow you to create a new Jar artifact that will be deployed to the Runtime environment as a new Deployment Unit.
Once you get the visual notification that the project was built and deployed successfully you can go to the Deployments screen to verify that your artifact is there. In order to do that go to the top level menu called Deploy -> Deployments
In the Deployments screen you will find all the deployed units. By default when you Build & Deploy a project from the Project Editor, it will be automatically deployed using the default configurations. That is Singleton Strategy, the default KIE Base and the default KIE Session will be used.
If you want a more advanced deployment, that is selecting a different strategy or using non defaults KIE Base or KIE Session you will be able to undeploy and re-deploy your artifacts using their GAV and selecting non default options.
Once your artifact that contains the process definition is deployed, the Process Definition will be available under Process Management -> Process Definitions.
In order to create new Process Instances you need to go to Process Management -> Process Definitions.
Here you will find all the available process definitions in the runtime environment. If you want to add new process definitions look at the previous sections where it is explained how to build and deploy KIE Projects.
You can start process instances using any of the two options highlated in the previous screen.
In order to create a new process instance most of the processes will require you to fill in some information and for that a form will be displayed. For this specific use case the name of the candidate that we are interviewing is required:
If we hit the big Start button, the new process instance will be created and the first task of the process will be create for the Human Resources Team. Depending on the assigned roles of the user that you are using to create the process instance you will be able to see the created task or not. In order to see the first task of the process we will need to logout tot he application and log in as someone from the Human Resources team.
After starting the process you can go to the Task -> Tasks section to interact with the created human tasks. Notice that in order to see the tasks in the task lists you will need to belong to some specific user Groups. For example the HR Interview task will be visitable for any member of the HR group, the Tech Interview will be visible by any member of the IT Group.
There are three points to consider when we configure the application for deployment:
Users/Groups/Roles
Domain Specific Tasks (Connectors)
JBoss AS 7 Profile
By default the KIE-Workbench uses the JBoss AS configured users to work. In order to create a new user we need to use the ./add-user.sh script located inside the /bin/ directory. Using this script we will be creating all the users required by our business processes, and for that reason we will be also assigning them groups and roles.
As you can see in the previous image, using the ./add-user.sh script you can create a new user for the Application User (first two options: option B, and empty realm). Note that you need to use different strings for the user name and for the password. For now you can create users with role admin, so it will have access to all the screens of the tool and then you can write the groups where the user belongs. In this case the user salaboy has Role: admin and he belongs to the IT group. There are some restricted words that cannot be used as group names. For now avoid using “analyst”, “admin”, “developer” for group names.
Domain Specific Tasks (Connectors) are the way to integrate your business processes with external services that can be inside or outside your company. These connectors are considered technical assets and because of that needs to be handled by technical users. Most of the time it is recommended to not change/modify the connectors when the application is running, and for that reason these connectors needs to be provided for the application to use in runtime. Three things are required to use a Custom Connector:
Provide an implementation of the WorkItemHandler interface, which is the one that will be executed in runtime.
Bind the implementation to a Service Task name.
Create the WorkItem Descriptor inside the tool.
In order to provide these three configuration points you can take a look at the Customer Relationship example in the jbpm-playground repository.
The main idea here is to have a separate project that contains the workItems implementations, for example: CreateCustomerWorkItemHandler , you will need to compile this project with maven and install the produced jar file inside the KIE-WB application. In order to do that you just copy the customer-services-workitems-1.0-SNAPSHOT.jar into the WEB-INF/lib directory of the kie-wb.war app. On this example the workItemHandler implementations interacts with a public web service that you can check here , so you will require internet connection in order to try this example.
Notice also that inside the customer-relationship project there are some high level mappings of the Domain Specific Tasks that can be used inside our Customer Relationship Project -> WorkItemDefinitions.wid.
This configuration will basically add you Service Tasks inside the Process Designer Palette:
The last step is to bind the High Level mapping to their implementation for this environment. You can do that by adding new entries into the WEB-INF/classes/META-INF/CustomWorkItemHandlers.conf file, for this example we just need to add the following entries:
…
“CreateCustomer”: new org.jbpm.customer.services.CreateCustomerWorkItemHandler(),
“AddCustomerComment”: new org.jbpm.customer.services.AddCustomerCommentsWorkItemHandler(),
“ManagersReport”: new org.jbpm.customer.services.ManagersReportWorkItemHandler(),
…
In order to run the KIE Workbench (or the jBPM Console NG) in JBoss AS 7 you need to run it with full JBoss AS7 profile, so if you are installing it using a fresh JBoss AS7 please don’t forget to start it using the full profile:
./standalone.sh –server-config=standalone-full.xml
the deployment time out. In some machines and some operating systems the deployment time could be greater than a minute and that will cause the application server to throw a timeout exception. In order to override the default configurations you need to edit the standalone.xml file and add the following attribute:
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.0">
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" deployment-timeout="1200" />
</subsystem>
So if your applications are not deploying add the extra attribute: deployment-timeout="1200" to the urn:jboss:domain:deployment-scanner:1.0 subsystem.