The KIE Workbench provides a series of utilities that allow us to create a detached communication between the process definition and the process execution. In order to do so, it provides a very specific structure that will look quite familiar to developers. Let's first explore how the process definitions (and other types of knowledge assets) are grouped in the KIE Workbench.

The Workbench groups process in Maven-based projects. Each Maven project is an individual, self-sufficient unit containing information about the know-how to compile, deploy, run, and test itself and can declare dependencies to other modules in their pom.xml file. Each project is part of a repository, and each repository belongs to an organizational unit. The end picture for this structure looks something like what is shown in the following diagram:

The configurations we will be most interested in tweaking when using the KIE Workbench to define our projects are the ones directly associated with our project. To edit those properties, we must go to the perspective available by clicking on the navigation bar option Authoring | Project Authoring. There, we can create a new project (clicking on Project) in a particular repository by selecting the option from the second menu bar, the one under the black menu bar, called New Item. A project creation wizard will guide us in configuring a Maven release ID for the project. Have a look at the following screenshot:

Once the Finish button is clicked on, we're directed to the project editor, where we can configure dependencies, KIE Bases, KIE Sessions, and all the project-relevant components. The project editor groups all responsibilities to define dependencies, for project runtime configurations, and to allow the user to build and deploy the project in a Maven repository.

The same options are available when selecting an already existing project by clicking on the Tools | Project Editor option that appears under the navigation bar in the Project Authoring perspective, as shown in the following screenshot:

In the preceding screenshot, we can see that we have different types of settings for our project. We are mostly interested in the Knowledge bases and sessions item of the settings list box, because it will allow us to configure where and how the business processes that we will define will end up exposed to the runtime.

Each Maven project that we define in the KIE Workbench encloses a particular configuration for one or more types of runtime. Each runtime definition will have its own KIE Bases, KIE Sessions, and special configurations for each one to work in the way we expect them.

Keep track of how to get to the knowledge settings of our project for now, because we will use it later. But first, before we configure how to expose our process definitions, we need first to learn how to define them. To do so, let's take a look at the jBPM6 Process Designer.

The process designer is started whenever we choose to create a business process (by selecting the New Item | Business Process option in the project authoring perspective), or open one that we previously created from the Project Explorer view (the one on the left-hand side of the Project Authoring perspective). It should be a tool flexible enough to allow users to create their own specific types of extensions to the BPMN2 standard, but strict enough to allow the generated process definition to still comply with the standard. That way, the generated process will be able to run the process runtime with jBPM6 the way the user wants, and at the same time, it will be able to run in any other type of process runtime that is compliant with BPMN2.

To achieve this level of flexibility, enough configurations should be allowed so that every implementation parameterization can be added to the business processes being defined. In order to keep the structure of the process in a tidy but efficient way, the process designer provides an attribute panel to define specific parameters for all the components in the diagram, from a specific sequence flow to the process itself.

In the following screenshot, we see a brief glimpse of the process designer UI present in the Workbench:

In the preceding screenshot, we can see a few of the characteristics available for the designer. We can see the diagram definition, the properties of a selected node (the terminate event) in the panel to the right-hand side corner of the editor, and we can see that we can change the type of the selected node as well. At the top of the editor, we can see a series of icons with many different functions: save, cut, copy, paste, delete, undo, redo, and a few others that we will cover in more detail in the next few chapters. This section is called the action bar of the process designer. We can also see other sections, such as the Metadata tab, at the bottom, where we can put specific information about our knowledge asset, such as version history and item description. Also, the canvas has tabulation at the top, dividing the Process Modelling view from another called Simulation Results, which will be explained in detail in Chapter 5, Creating a Process Project in the KIE Workbench.

There are more attributes to the process designer that, at this moment, are going to distract us from getting a full perspective of the Workbench, which is why we will leave the full induction to the designer for Chapter 5, Creating a Process Project in the KIE Workbench.

In order to be able to create executable processes, we will end up needing more than just the process definitions. Process definitions will be dependent, at least in runtime, of a specific data model, handlers for specific tasks, and even rules to make complex decisions at particular points. In order to be able to run such complex processes we will need a way to define all these components along with the business processes. The KIE Workbench provides us with many different editors that cover all these necessities.

All types of knowledge definitions that we will need to create will be accessible later on from the Project Explorer view on the right-hand side of the project authoring perspective, and can be created from the display view after clicking on the New Item option. Each type of knowledge asset has a different structure, and due to size restrictions in the book, we won't be able to explain every single one. However, we will cover the ones most related to process definitions and runtimes.

The first things that a growing process definition will need are work item definitions. Work item definitions are specific mappings added to abstract tasks in BPMN2 in order to determine some form of special behavior that a given task should have. They have predefined inputs and outputs that suggest a way of communicating with the task, a given name to map it to a specific implementation, and (for the purpose of diagramming) they have a display name and an (optional) icon. In the KIE Workbench, work item definitions are written in a special scripting language called MVEL (http://mvel.codehaus.org), and the given editor provides a few helper buttons to create the needed script faster, as shown in the following screenshot:

But work item definitions are just the beginning of the needed components. Also, depending on the type of tasks we use from the BPMN2 standard, we might need to create rules for Business Rule tasks, or classes to be used for data objects. The KIE Workbench provides a way to define both types of assets, through the different rule editors and the data modeler, as shown in the following screenshot:

In the preceding screenshot, we see a business rule opened from the Guided Rule Editor window, which allows us to define a rule in natural language. It will be based on a Java-based model, created with the data modeler shown in the following screenshot:

Finally, we need a way to define all configurations to the runtime that will be specific for a particular process definition or group of process definitions. Now that we have seen how to define processes, we can go back to the project editor and see the configuration behind the Knowledge bases and sessions option, as shown in the following screenshot:

In the view shown in the preceding screenshot, we can define different KIE bases for our project. We can make one of them the default one and decide which packages to include inside them. The packages will represent the different folders that we create in our project and where we might add processes, work item definitions, rules, or anything else. In this way, we can have multiple KIE bases in one project with different process definitions working inside each one.

Each KIE base will have a series of KIE sessions associated, and we will be able to configure them to work in multiple ways. We will see the different configurations for KIE sessions when we see the interaction of processes and other knowledge definition types in Chapter 9, Integration with Other Knowledge Definitions.

This is the point where the process definition environment ends and the process runtime begins. The next step is to click on the Build & Deploy button in the project editor to make the project and all its configurations available for the runtime. I understand that you would have preferred to start defining your own processes, but don't despair. We will start doing so as soon as we start with Chapter 5, Creating a Process Project in the KIE Workbench. For now, we need to concentrate on understanding how all components are interconnected.

Process defining components only need to worry about the process until it is deployed in a Maven repository. Later on, each process runtime should be concerned with having the corresponding version of a Maven dependency running inside.

The process runtime is the internal configuration that the workbench must provide to create and execute process instances. In order to do so, it must provide external system connectors to connect to other systems and human tasks. This configuration should be something that can be easily extended over time.

The KIE Workbench provides this extension capacity through the project authoring perspective, which allows us to manage all our knowledge through KIE modules. Once we have all the business processes and other knowledge assets we need in our project, we can open the Tools | Project Editor option from the second navigation bar in the project authoring perspective. This would open the editor shown in the following screenshot:

In the preceding screenshot, we selected the Evaluation project in the Project Explorer view, by clicking first on the jbpm-playground repository and then in the Evaluation project. Once in the project editor (which will open once you select the Evaluation project), we click on the Build & Deploy button to actually compile the project content and publish it on an internal Maven repository.

Once a project is deployed, it becomes a component in the engine that feeds process definitions that can be executed to our environment. We call this engine configuration the process runtime. In a sense, the process runtime is just a preconfigured environment for jBPM6 to execute processes already connected to all external systems and humans.

A process runtime should be configurable, that is, we should be able to include all the different configurations to make sure the environment is going to run the process definitions in the way we want. To do so, we can edit the kmodule.xml file of the projects we are creating. To do so, we need to select the Project Settings: Project General Settings to see a drop-down menu and select Knowledge Base Settings inside the Project Editor tool. The following screenshot shows the Knowledge Base Settings editor:

The process runtime can be configured in this editor to have special external connectors and can be later on exposed to many other servers using the runtime engine and runtime manager interfaces, which are discussed in detail in Chapter 7, Defining Your Environment with the Runtime Manager.

Having the process runtime allows our processes to be able to execute in the backend of our workbench. In order to interact with said workbench directly, we need a special UI to access all the methods involved in process execution. For that, the KIE Workbench provides a few entries in the Process Management navigation bar option. We'll discuss each one of them.

Only when we have successfully deployed a KIE module, can we see its process definitions in the Process Definitions List perspective (found inside the Process Management navigation bar option). In the following case, we see the process definitions available in the demo/jbpm-playground-Evaluation project. The following screenshot shows the Process Definitions perspective in the KIE Workbench:

In the list shown in the preceding screenshot, we can see an icon (the magnifying glass icon) to see the process details (its human tasks, the users and the roles assigned to them, the process ID, and so on) and another icon (the play button icon) to start the process (which will provide a previously defined form to fill the data necessary to begin the process). When we press the play icon, it will show us the following form to start a process instance of the Evaluation process. After completing the form and pressing the large play button, we will have created a new process instance as shown in the following screenshot:

This interface allows us to see the different process definitions available to start them, but we still need an interface to see the currently running process instances and its internal state. For that, there is another option in the Process Management navigation bar option, called Process Instances. In the following screenshot, we can see the task initiated by completing the form in the preceding screenshot:

The UI allows us to filter process instances by their state, see their details, send signals to them, or abort them. But this is mostly an administrative topic to handle process systems. End users would mostly interact with the tasks assigned to them, or their roles. To do so, the workbench needs a way to show:

For that purpose, the workbench provides us with task lists and task form interfaces.

It is important that all asynchronous tasks (that the process runtime is waiting to be completed) have a way to be managed from external tools. The case of human tasks is special, because they won't be handled by an automatic external system, but by people who need a UI to interact with said tasks. For that purpose, the workbench provides a way to see tasks that are either owned by the current user or could be assigned to the current user in the form of lists. On this view, we can perform a series of different actions on each task: claim them, release them, and start them, which are all explained in detail in Chapter 6, Human Interactions. Task lists can be generic, but for some special cases, we might want to make them more specific to show special data of certain types of tasks.

In the following screenshot, which can be accessed using the main toolbar option Tasks | Tasks List, we will find several views for task lists dedicated to personal tasks:

And when we click on the play button in one of those tasks, we go ahead to the next important UI point for human tasks, the Task Forms option.

Task forms can be generic, based on task input and output information (elements described in Chapter 3, Using BPMN 2.0 to Model Business Scenarios), but should be dependent on each specific task to provide the most interaction help to the end user, because sometimes input/output information is not enough to infer the expected user interaction. Once a task is started, we can click on it to see its details, and we can have access in the workbench to the specific task form by clicking on the Work button. Have a look at the following screenshot:

From the view shown in the preceding screenshot, we can save the progress of the task, release it to the group, and complete it. Some generic abilities enabled for all tasks involve attaching documents and adding comments. Both are provided in the task details as well at a click on the Attachments or Comments buttons. At this point, if you go back to the Process Instances view, you will see that the process instance is in another stage because you completed the specific task.

Using these components, we will have enough user interfaces to work with any process we might encounter. We will use this chapter as a guide to start creating the managing processes in Chapter 5, Creating a Process Project in the KIE Workbench.

All these components are bonded together in the KIE Workbench thanks to a particular framework called UberFire that allows us to have a configurable and extensible workbench environment. We will dedicate Appendix, The UberFire Framework, to discussing its structure and use, which will become useful if you wish to extend the jBPM6 provided tooling for your own personal customization. This is an advanced topic, but will give you a full control over how to use the KIE Workbench to fit it best to your company.