All developers and process analysts who are beginning to use JBoss jBPM All JBoss Developer Studio/JBoss Tools release documentation you can find at. A Java developer's guide to the JBoss Business Process Management framework Thoroughly understand how the jBPM framework works Build custom Java. pdf. jBPM6 Developer Guide Learn about the components, tooling, and . He is now a Drools and jBPM Senior Software Developer at Red Hat/JBoss, fully.
|Language:||English, Spanish, Arabic|
|ePub File Size:||18.58 MB|
|PDF File Size:||10.63 MB|
|Distribution:||Free* [*Regsitration Required]|
jBPM Developer Guide. You are reading this because you are starting to get interested in the open source world. This book is especially for Java architects and. jBPM Developer GuideA Java developer's guide to the JBoss Business Process Management frameworkMauricio "Salaboy" Sa. The JBoss jBPM team [soundofheaven.info] Eclipse- based developer tools to support the modeling, testing and debugging of Share process PDF - generates a stand-alone HTML object tag which.
And when we try to represent processes with this language, we will have some kind of sentence or paragraph expressed in our business process language. But somehow, business analysts are not supposed to design and execute business process on their own. This means that if we have a transition that has node A as the source node, and node B as the destination node, that transition will not be the same as the one that has node B as the source node, and node A as the destination node. In real world a task or an activity if you prefer could be: We will see code in this section and I will ask you to try it at home, debug it, and play with this code until you feel confident about what is the internal behavior of this example. We also haven't specified where our sources are located and where our compiled project will be placed after it is built.
The book starts by explaining the key concepts in a Business Process Management framework. It will help you to learn and practice all of the conceptual and theoretical terms used in the Business Process Management field.
Then you will master jPDL, the preferred process language for jBMP, which will let you specify exactly how your processes must be defined and implemented. From here on, the book takes a closer look at the engine, discussing a broad range of topics from building real business processes inside real applications to learning and implementing advanced capabilities of the jPDL and jBPM framework.
It will also help you to handle vital information and tasks related to persistence, integrating jBPM with other enterprise systems, and deploying jBPM to existing J2EE application servers.
By the end of this book, you will gain all the experience required to implement solutions that use the framework as well as to make decisions about how the framework needs to be used in particular situations.
Stay ahead with the world's most comprehensive technology and business learning platform. With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.
Start Free Trial No credit card required. View table of contents. Start reading. Business Process, why should I know about that? This means that in most of the cases our applications will be used across the company business units.
This requires one application to interact with services of each unit. So, SOA advises us about how to build our application to have flexibility and fluid communications between each business unit services. Orchestration This term refers to the possibility to coordinate the interaction between systems calls.
This coordination is always achieved by a director that will know which is the next system call in the chain. This term is used to represent a logical sequence, which is used to obtain a business result using different calls to different systems in a specific order. This term is used very frequently in conjunction with BPEL.
We'll discuss that in the next section. Technological terms These technological terms, in contrast with all the theory that we see behind them, give us the knowledge that we need to use tools in the way that is intended. Try to link all this technical information with the theory that we have seen before. If you feel that something is missing, please read more bibliographies until you feel confident with it.
But don't worry, I will do my best to help you. Workflow When developers talk about workflows, probably they are referring to some framework, tool, or product, which lets them define a sequence of steps that one application will take. That is, they mean some kind of state machine that will be embedded in the application.
As we mention this in most of the cases, workflows are specific to one domain and probably to one application. Enterprise Service Bus ESB Enterprise service buses emerge as very flexible products that implement a lot of connectors, which let us plug our heterogeneous applications to them and then interact with each other.
With ESB, we achieve the abstraction about which protocol we need to use to talk with another application and we only need to know how to talk with the bus. Then the bus is in charge of the translation between different protocols and languages. This language lets us define how and when web services for different applications need to be called and how the data should be passed through these calls.
One final thing to notice here is that BPM is a discipline. This means that BPM is technology agnostic, you can implement this discipline in your company just with a pen and paper, but if you are a developer I would think that you wouldn't want to do that. That is why BPMS comes to save us. That's because jBPM is a framework that lets us implement the main stages of BPM unless you want to implement it in pen and paper! BPMS makes up for a piece of software that lets us implement all the main stages that the discipline describes.
These tools are frameworks that provide us with the designing tools to describe our Business Processes. They also offer configurable executional environments to execute our designed processes, and tools to analyze and audit the history of our process executions in order to improve our processes and make more accurate business decisions.
That is exactly what jBPM gives us—an open source development framework integrated with nice tools to describe our processes in a formal language called jPDL, jBPM Process Definition Language , an executional environment to see how the processes live and guide our company through their activities, and a set of best practices to analyze our processes and improve the company performance and incomings.
If you have not heard about any of these terms you are lucky, because these too are overused terms. In the case of jBPM, that is a BPM system; we are going to see that it is also designed to have a graph-oriented language that can be useful to have a fluid communication with business analysts. But somehow, business analysts are not supposed to design and execute business process on their own.
On the other hand, BPM suites are products oriented to help business analysts to design and implement a fully-functional process on their own. These products have a "developer free" policy. These kind of products are commonly closed sources and also come integrated with an application server. As you can imagine BPM suites are good tools. But the main problem is that most of the time they do not have enough flexibility and expressiveness to adapt to everyone's business needs.
To tackle the flexibility issues, BPM system's developers can adapt and modify the entire framework to fulfill the business requirements. Also, BPM systems are like any other framework—environment agnostic, so depending on the kind of business requisites, developers can choose to create a standalone application, web application, or a full enterprise application. This comes with another huge advantage; we can choose any vendor of web or application server!
We are not tied to JBoss, not to any other license fees. Because these tools will change the way we think about our applications and in my experience I never want to go back. This is because a new approach of development arrives.
This will give our applications flexibility and an easy way to adapt to everyday changes that our company requires. New approach Here we are going to see how our component-oriented paradigm is modified a bit to make use of the advantages proposed by the BPM discipline. To achieve that, we must have formal description of our processes, know on which environment our processes should run and then combine these two areas in one implementation that the business analysts understand and have all the technical details that allow the process to run in a production environment.
To make this implementation flexible and adaptable, we need to have a loosely-coupled design and relationship between our formal representation of the processes and all the technical details. Remember that these two "artifacts" process formal description and all that involves technical details: This is because our process definition must always be understood by business analysts, and technical details will always be implemented for developers who know about environments and executional configurations.
To have a clear vision about what I'm talking about, we will analyze the following image: And our work will just be to modify some process definition adoptions for new requirements for example, change one activity before another or put a new activity and our process will be synchronized with our company changes.
I do not want to lie here, but if you apply some basic principles to technical details, minor changes will be needed when our process requires modifications. Now it is time to get to know jBPM implementation in depth, so in the next chapter we are going to focus on a deep analysis of the framework's internal component distribution and the basic principles that cause the real implementation.
But wait a moment, before the next chapter I have some homework for you to do. Homework This is a special homework, and you can use the outcome to see your knowledge improvements throughout the rest of the book. For this homework you will need to find one or two simple processes in your company and describe them, like the example that we saw in this chapter. Try to describe your processes using the following guidelines: Try to find something that is important to your company, not only for developers.
You probably will find something that is not even close to systems or computers like the recycling example. When you find a business goal, it's easy to name your process related to the goal, as follows: As we mentioned earlier, business processes are about team, business unit, and also business partners' integration. So, don't limit your processes to your area. Ask managers about tasks and if these tasks are part of a bigger business scenario. You will need to find out who does which tasks that you find inside your process.
This is a very important point, try to also identify the nature of these roles, for example if some role in your process is irreplaceable, or if there are a lot of people who can do the job. Try to identify different systems that are used throughout different business units, and try not to imagine systems' improvement.
Just write down what you see. Try to focus on processes that have concrete tasks, which people do every day. If you find that you are describing a really huge process, and that every activity you find is another complete process, this is not within the scope of this homework.
On the other hand, you can describe very detailed tasks that in reality is just one task; for example, if you have a form that demarcates three sections, and these three sections are filled in all together for the same business role at the same time, you do not need to describe three separate tasks, one for each section, because with one task you are representing them all in the filled form. Sometimes companies have these business processes documented probably if the company was trying to achieve some Quality Assurance certification , but most of the time these documented processes are not reflected in the company's everyday work.
So, try to look at a process that happens right near you. Do not add extra activities to your processes, there will be time to improve your current processes. So, if you are not sure that the task is being performed, throw it away.
If you can graph your process as boxes and arrows, you are heading in the right direction. Also a graph could be helpful to draw quick validations from your partners and managers.
As I mentioned before, this discovering process task is for business analysts. But for learning reasons, this can help us to understand and gain expertise in recognizing real-life processes and then have more fluid talks with business analysts. Take your time to do this homework, later you will find that you are learning how to improve your newly-found processes.
Sequence of activities that are done by humans and systems interactions in order to achieve some business goal. This is a key concept, keep it in mind. BPM is discipline oriented to analyze, improve, and maintain business processes in an iterative way over time.
We also see all the advantages and some history about this. It's a software that lets us implement the main stages of BPM. A set of tools for designing, managing, and improving our business processes.
It is designed for teams composed by developers and business analysts. We also tried to understand why developers need to know all these concepts, and we reached the conclusion that a new paradigm of software development can be implemented using the BPM theory. In the next chapter, we will learn about the jBPM framework.
We will see how it is composed and the set of tools that this framework provides us. The focus of this book is to show how the framework is internally built using a developer's perspective that will help you to: We will be fully focused on the approach used to implement jBPM. This approach is called Graph Oriented Programming, and we will discuss and implement a basic solution with it.
This will guide us to knowing about the framework internals with a simplistic vision. That will give us the power to understand the main guidelines used to build the entire framework. During this chapter, the following key points will be covered: This chapter will give us the way to represent our business processes using the Java language and all the points that you need to cover in order to be able to represent real situations.
The Graph Oriented Programming GOP approach is used to gain some features that we will want when we need to represent business processes inside our applications. Basically, graph oriented programming gives us the following features: We are going to take a quick look at that and formulate some code in order to try to implement our minimal solution with these features in mind.
Starting with GOP as a bigger concept, you will see that the official documentation of jBPM mentions this topic as one of the most important concepts behind the framework. Here, we will reveal all of the advantages that this approach implementation will give us.
Basically, by knowing GOP, we will gain complete knowledge about how processes are represented and how they are executed. Therefore, a common question here is, why do we need a new approach GOP for programming our processes when we have already learnt about the object-oriented programming paradigm?
Common development process In order to answer the previous question, we will quickly analyze the situation here. To achieve this, we need to understand the nature of our processes. We will also analyze what kind of advantages developers gain when the business process information is decoupled from the rest of the application code. Let's clarify this point with a simple example. Imagine that we have to build an entire application that represents the stages in the "Recycling Things Co.
The most common approach for a three-tier application and development process will be the following: One thing that we can notice here, and which happens in real software projects, is that the business analyst's description will be lost in the design phase, because the business analyst doesn't fully understand the design class diagrams as these diagrams are focused on implementation patterns and details. If we are lucky and have a very good team of business analysts, they will understand the diagrams.
However, there is no way that they could understand the code. So, in the best case, the business analyst description is lost in the code—this means that we cannot show our clients how the stages of their processes are implemented in real working code.
That is why business analysts and clients stakeholders are blind.
They need to trust that we the developers know what we are doing and that we understand percent of the requirements that the business analysts collect. Maybe they are not functional changes, but there are sometimes changes that affect the behavior of the software or the way users will interact with it. This allows them the stakeholders to ask for changes that will be easily introduced to reflect everyday business requirements.
Let's be practical and recognize that, in most situations, if we have the application implemented in a three-tier architecture, we will have the following artifacts developed: Business logic If we are careful developers, here we are going to have all of the code related to a logical business processes method. In the case of the example, here we will have all the stages represented in some kind of state machine in the best cases. If we don't have a kind of state machine, we will have a lot of if and switch statements distributed in our code that will represent each stage in the process.
For example, if we have the same application for all the branches of a company, this application will need to behave differently for the main office's employee than for the 'just finished' warehouse employee. This is because the tasks that they are doing are very different in nature. Imagine what would happen if we want to add some activity in the middle, probably the world would collapse! I don't want to be one of these developers. User interfaces Once again, if we are lucky developers, the process stages will not be represented here, but probably many if and switch statements will be dispersed in our UI code that will decide what screen is shown to each of the users in each activity inside the process.
So, for each button and each form, we need to ask if we are in a specific stage in the process with a specific user. Implementation Where do Business Processes fit here? This is mainly achieved through the use of a common language that both sides understand. It lets us represent the current process that the business analysts see in the everyday work inside the company, and all of the technical details that these processes need, in order to run in a production environment.
As we can see in the next image, both roles interact in the creation of these new artifacts. Also, they can ask for changes to improve the performance and the current way used to achieve the business goal of the process. One of the main advantages of this approach is that we can get visibility about how the processes are executed and which activity they are in at any given moment of time.
This requirement will force us to have a simple way to represent our business processes—in a graphicable way. We need to be able to see, all the time, how our production processes are running. With this analysis, we will implement some basic approach to understand how we use this paradigm on top of the Java language in the next section. To let the business analysts and developers communicate smoothly and to fully understand what is happening in the real process.
In order to know how our processes are going on to make more accurate business decisions. No more huge development projects for small changes and no more migrations. With these requisites, presented in the previous section, in mind, we are able to implement a simple solution on top of the Java language that implements this new approach called the Graph Oriented Programming paradigm. As the name of the paradigm says, we are going to work with graphs—directed graphs to be more precise.
A graph can be defined as a set of nodes linked to each other as the following image shows us: These transitions will be directed, because they will define a source node and a destination node. This means that if we have a transition that has node A as the source node, and node B as the destination node, that transition will not be the same as the one that has node B as the source node, and node A as the destination node.
Take a look at the following image: Like in the object-oriented programming paradigm, we need to have a language with specific set of words for example, object here. We will need words to represent our graphs, as we can represent objects in the object-oriented paradigm.
Here we will try to expand the official documentation proposed by the jBPM team and guide the learning process of this important topic. We will see code in this section and I will ask you to try it at home, debug it, and play with this code until you feel confident about what is the internal behavior of this example.
Let's get started first with the graph definition and with some of the rules that the graph needs to implement, in order to represent our business processes correctly. Up until now, we have had two concepts that will appear in our graph oriented programming language—Node and Transition. These two concepts need to be implemented in two separate classes, but with a close relationship. Let's see a class diagram about these two classes and make a short analysis about the attributes and methods proposed in this example.
Node Long id String name leavingTransitions Transition String label destination [ 36 ] Chapter 2 Modeling nodes in the object-oriented world This concept will be in charge of containing all of the information that we want to know about the activities in our process. Node Note that we are using Generics here. A feature available from the Java Language Specification 1.
Long id String name List leavingTransitions As you can see in the class diagram, this class will contain the following attributes that store information about each activity of our process: This represents all the transitions that leave the node This concept will need to implement some basic methods about executional behavior, but it will be discussed when we jump to the executional stage.
For now, we are only going to see how we can represent a static graph. Modeling a transition in the object-oriented world This concept is very simple, we want to know how the nodes will be linked to each other. This information will define the direction of our graph. For that, we need to know the following information: This is the destination node where the transition arrives [ 37 ] jBPM for Developers With these two classes, we will be able to represent our processes.
But wait a minute; if our processes only have nodes, we are hiding what is happening inside them, we only see nodes and not what is happening in the process.
So, we need more expressiveness, to describe our processes in a more shocking way. Those who see the process, can understand the process "direction" and the nature of each activity inside it.
Of course, the behavior of each activity will also be clarified with a more specific language that provides us with other words, and not just nodes and transitions to describe activities and the flow. Expanding our language The only thing that we need to do in order to have more expressive power in our graphs is to increase the number of words in our language. Now we only have Node and Transition, these two words are not enough to create clear graphs that can be understood by our stakeholders.
To solve that, we can have some kind of hierarchy from the most abstract concepts that represent a generic activity to more concrete concepts related to specific activities such as Human Tasks, Automatic Activities, Decision Activities, and so on. In order to do this, you only need to extend the Node concept and add the information that you want to store for a specific activity behavior. Basically, what I am saying here is that the Node concept has the basic and generic information that every activity will have, and all subclasses will add the specific information related to that specific activity behavior in our specific domain.
In an Object Oriented Paradigm, we achieve that by implementing the graphicable interface, because we want all the subclasses of Node to be graphicable as well this is not shown in the diagrams, but you can see it in the code. This interface provides the signature and makes us implement the methods to graph each node easily, giving us the flexibility to graph our process in different formats.
It is also important to note that each subclass can override the graphic functionality in order to represent, graphically, the difference of each behavior. The only thing that we need now is some container that represents the graph as a whole.
As we have a collection of nodes and transitions now, we need a place to have all of them together. Process Definition: We can say that this class will represent the formal definition or our real situation. This will only contain a list of nodes that represent our process.
For this interface, we need to implement the functionality of the methods addNode Node n , getNode long id , getNodes , and so on. The main goal of this section is to be able to understand from the source how the jBPM framework is built internally. Understanding this simple implementation will help you to understand how the framework represents, internally, our processes definitions. That knowledge will allow you to choose the best and more accurate way to represent your business activities in a technical way.
We are ready to see how this is translated to Java classes. Please feel free to implement your own solution to represent process definitions.
If you don't feel confident about the requirements or if you are shy to implement your own solution, in this section we are going to see all the extra details needed to represent our definitions correctly.
I also provide the Java classes to download, play, and test. As in the previous section, we start with the Node class definition. In this class, we are going to see details of how to implement the proposed concept in the Java language. Here we are just implementing our own solution in order to be able to represent simple business processes.
This is just for the learning process. The Node concept in Java This class could be found in the code bundle for the book at http: We can find the Node class placed inside the package called org. It is a simple class that contains properties—here, you need to notice: The idea here is to use the transitions based on names and not objects. In other words, we can choose which transition to take using just a String. The Transition concept in Java In the same package of the Node class, we can find the definition of the Transition class: As you can see, here we have two Node class properties that allow us to define the direction of the transition.
Also, we have the label property that allows us to identify the transition by name. This property the label property is a kind of ID and must be unique inside all the leaving transitions of a particular node, but it could be repeated in any other node. The Definition concept in Java In the same package, we can find the Definition class.
The idea of this class is to store all the nodes that compose a process definition. This will be important when we want to store these definitions in a persistent way. This forces us to define the graph method from the Graphicable interface, and the addNode Node and getNode Long methods from the NodeContainer interface. Testing our brand new classes At this point, we can create a new instance of the Definition class and start adding nodes with the right transitions.
Now we are going to be able to have some graphical representation about our process. All of these classes could be seen in the chapter02 code in the simpleGOPDefinition maven project. You will see two different packages, one that show a simple definition implementation about these concepts, and the other shows a more expressive set of nodes overriding the basic node implementation, to have a more realistic process representation.
If you don't know how to use maven, there is a quick start guide at the end of this chapter. You will need to read it in order to compile and run these tests. In the test sources, you will find a test class called TestDefinition, it contains two tests—one for the simple approach and the other with the more expressive approach.
Each of these test methods inside the TestDefinition class uses the JUnit framework to run the defined tests. Feel free to modify and play with this implementation. Always remember that here we are just defining our processes, not running them. This can be achieved by creating a class where each instance represents one execution of our process definition—bringing our processes to life and guiding the company with their daily activities; letting us see how our processes are moving from one node to the next one.
With this concept of execution, we will gain the power of interaction and influence the process execution by using the methods proposed by this class. We are going to add all of the methods that we need to represent the executional stage of the process, adding all the data and behavior needed to execute our process definitions. This will let us query the process status when we want. Definition Execution Node currentNode Definition definition An important question about this comes to our minds: Why doesn't the process flow until the end when we start it?
And the answer to these important questions is: The important thing here is to notice that there will be two main types of nodes: These type of nodes will represent automatic procedures that will run without external interactions. The activity that they represent needs to wait for a human or a system interaction to complete it. Wait states versus automatic nodes The difference between them is basically the activity nature.
We need to recognize this nature in order to model our processes in the right way. As we have seen before, a "wait state" or an "event wait" situation could occur when we need to wait for some event to take place from the point of view of the process. These events are classified into two wide groups—Asynchronous System Interactions and Human tasks. For non-advanced developers, the word "asynchronous" could sound ambiguous or without meaning.
In this context, we can say that an asynchronous execution will take place when two systems communicate with each other without blocking calls. This is not the common way of execution in our Java applications.
When we call a method in Java, the current thread of execution will be blocked while the method code is executed inside the same thread. See the following example: When this happens, the call stack will continue with the next line in the main class. This blocking call is commonly named as a synchronous call. On the other hand, we got the non-blocking calls, where the method is called but we the application are not going to wait for the execution to finish, the execution will continue to the next line in the main class without waiting.
In order to achieve this behavior, we need to use another mechanism. One of the most common mechanisms used for this are messages.
Let's see this concept in the following image: Message [ 46 ] Execute Backup MSG Chapter 2 In this case, by using messages for asynchronous executions, the doBackup method will be transformed into a message that will be taken by another thread probably an external system in charge of the real execution of the doBackup code.
The main class here will continue with the next line in the code. It's important for you to notice that the main thread can end before the external system finishes doing the backup. That's the expected behavior, because we are delegating the responsibility to execute the backup code in the external system. But wait a minute, how do we know if the doBackup method execution finished successfully?
In such cases, the main thread or any other thread should query the status of the backup to know whether it is ready or not. Human tasks Human tasks are also asynchronous, we can see exactly the same behavior that we saw before.
However, in this case, the executing thread will be a human being and the message will be represented as a task in the person's task list. Task Do Task Actor As we can see in this image, a task is created when the Main thread's execution reaches the doBackup method.
This task goes directly to the corresponding user in the task list. In this case, the "Do Backup" activity is a manual task that needs to be performed by a human being. In both the situations, we have the same asynchronous behavior, but the parties that interact change and this causes the need for different solutions.
For system-to-system interaction, probably, we need to focus on the protocols that the systems use for communication. In human tasks, on the other hand, the main concern will probably be the user interface that handles the human interaction.
First of all, by the name.
If the node represents an activity that is done by humans, it will always wait. In system interactions, it is a little more difficult to deduce this by the name but, if we see an automatic activity that we know takes a lot of time, that will probably be an asynchronous activity which will behave as a wait state.
A common example could be a backup to tape, where the backup action is scheduled in an external system. If we are not sure about the activity nature we need to ask about the activity nature to our stakeholder. We need to understand these two behaviors in order to know how to implement each node's executional behavior, which will be related with the specific node functionality. Creating the execution concept in Java With this class, we will represent each execution of our process, which means that we could have a lot of instances at the same time running with the same definition.
This class can be found inside another project called chapter We have to separate the projects, because in this one, all the classes we have for representing the processes include all the code related to the execution of the process. Inside the package called org. We can say that the currentNode is a pointer to the current node inside a specific definition. The real magic occurs inside each node. Now each node has the responsibility of deciding whether it must continue the execution to the next node or not.
In order to achieve this, we need to add some methods enter , execute , leave that will define the internal executional behavior for each node.
We do this in the Node class to be sure that all the subclasses of the Node class will inherit the generic way of execution. Of course, we can change this behavior by overwriting the enter , execute and leave methods. We can define the Node. If you carefully look at these three methods, you will notice that they are chained, meaning that the enter method will be the first to be called. And at the end, it will call the execute method, which will call the leave method depending on the situation.
The idea behind these chained methods is to demarcate different phases inside the execution of the node. All of the subclasses of the Node class will inherit these methods, and with that the executional behavior.
Also, all the subclasses could add other phases to demarcate a more complex lifecycle inside each node's execution. The next image shows how these phases are executed inside each node. Also, it is important to note that transitions also have the Take phase, which will be executed to jump from one node to the next.
All these phases inside the nodes and in the transition will let us hook custom blocks of code to be executed. One example for what we could use these hooks for is auditing processes. We could add in the enter method, that is the first method called in each node, a call to an audit system that takes the current timestamp and measures the time that the node uses until it finishes the execution when the leave method is called. A new concept appears.
The Action interface that we see in that loop, represents a pluggable way to include custom specific logic inside a node without changing the node class. This allows us to extend the node functionality without modifying the business process graph. This means that we can add a huge amount of technical details without increasing the complexity of the graph.
For example, imagine that in our business process each time we change node, we need to store the data collected from each node in a database. In most of the cases, this requirement is purely technical, and the business users don't need to know about that. With these actions, we achieve exactly the above. We only need to create a class with the custom logic that implements the Action interface and then adds it to the node in which we want to execute the custom logic. In the chapter This test is called TestExecution and contains two basic tests to show how the execution works.
CustomAction implements Action secondNode. This execution lets us interact with the process. As this is a simple implementation, we only have the start method that starts the execution of our process, executing the logic inside each node.
In this case, each node is responsible for continuing the execution to the next node. This means that there are no wait state nodes inside the example process. In case we have a wait state, our process will stop the execution in the first wait state. So, we need to interact with the process again in order to continue the execution. Feel free to debug this test to see how this works.
Analyze the code and follow the execution step by step. Try to add new actions to the nodes and analyze how all of the classes in the project behave. When you get the idea, the framework internals will be easy to digest. Homework We are ready to create our first simple GOP language, the idea here is to get hands-on code and try to implement your own solution. Following and using the guidelines proposed in this chapter with minimal functionality, but with the full paradigm implemented, will represent and execute our first process.
We could try to implement our example about "Recycling Thing Co. So, you can debug it and play with it until you get the main points [ 52 ] Chapter 2 of functionality. In the following sections, I will give you all the information that you need in order to implement the new words of our language and the behavior that the process will have. This is quite a lot of homework, but trust me, this is really worth it.
The idea of finishing this homework is to feel comfortable with the code and the behavior of our defined processes. You will also see how the methods are chained together in order to move the process from one node to the next. Creating a simple language Our language will be composed with subclasses from our previous node class.
Each of these subclasses will be a word in our new language. Take a look at the ActivityNode proposed in the chapter And when we try to represent processes with this language, we will have some kind of sentence or paragraph expressed in our business process language. As in all languages, these sentences and each word will have restrictions and correct ways of use.
We will see these restrictions in the Nodes description section of the chapter. So, here we must implement four basic words to our simple language. These words will be start, action, human decision, and end to model processes like this one: These restrictions are always related to the words' meanings.
For example, if we have the word "start" that will be a subclass of node represented with the node: StartNode, this node implementation could not have arriving transitions. This is because the node will start the process and none of the rest of the nodes could be connected to the start node.
Also, we could see a similar restriction with the end node, represented in the implementation with the EndNode class, because it is the last node in our processes and it could not have any leaving transitions. With each kind of node, we are going to see that they have different functionality and a set of restrictions that we need to respect when we are using these words in sentences defining our business processes. These restrictions could be implemented as 'not supported operation' and expressed with: Take a look at the EndNode class, you will see that the addTransition method was being overridden to achieve that.
Nodes description In this section, we will see the functionality of each node. You can take this functionality and follow it in order to implement each node.
Also, you could think of some other restrictions that you could apply to each node. Analyze the behavior of each method and decide, for each specific node type, whether the method behavior needs to be maintained as it is in the super class or whether it needs to be overwritten. This will be our first node in all our processes. When we create a new instance of process execution, this node is selected from the process description and set as the current node in the current execution.
The start method in the execution class will represent the event that moves the process from the first node to the second, starting the flow of the process. It will be our last node in all our processes. This node will end the life of our process execution instance. As you can imagine, this node will restrict the possibility of adding leaving transitions to this node.
This node will contain a reference to some technical code that executes custom actions that we need for fulfilling the process goal. This is a very generic node where we can add any kind of procedure. This node will behave as an automatic activity, execute all of these actions, and then leave the node. This is a very simple node that gives a human being some information in order to decide which path of the process the execution will continue through.
This node, which needs human interaction, will behave as a wait state node waiting for a human to decide which transition the node must take this means that the node behaves as an OR decision, because with this node, we cannot take two or more paths at the same time. One last thing before you start with the real implementation of these nodes. We will need to understand what the expected results are in the execution stage of our processes. The following images will show you how the resultant process must behave in the execution stage.
The whole execution of the process from the start node to the end node will be presented in these three stages. Stage one The following image represents the first stage of execution of the process. In this image, you will see the common concepts that appear in the execution stage. Every time we create a new process execution, we will start with the first node, waiting for an external signal that will move the process to the next node.
An execution is created using our process definition instance in order to know which activities the process will have. The start node is selected from the process definition and placed inside the current node reference in the execution instance.
This is represented by the black arrow pointing to the Start node. As the StartNode behaves as a wait state, it will wait and externally trigger to start the process execution.
We need to know this, because may, we can think that if we create an instance of execution, it will automatically begin the execution. Stage two The second stage of the execution of the process is represented by the following image: We can start the execution by calling the start method inside the execution class.
This will generate an event that will tell the process to start flowing through the nodes. The process starts taking the first transition that the start node has, to the first action node.
This node will only have an action hooked, so it will execute this action and then take the transition to the next node. This is represented with the dashed line pointing to the Action node.
This node will continue the execution and will not behave as a wait state—updating the current node pointer, which has the execution, to this node. The Human Decision node is reached, this means that some user must decide which path the process will continue through. Also, this means that the process must wait for a human being to be ready to decide.
Obviously, the node will behave as a wait state, updating the current node pointer to this node. What exactly does this mean? Until here, the execution goes from one wait state the start node to another wait state the human decision node inside the method called start, enclosing all the automatic nodes' functionality and leaving the process in a wait state. Let's analyze the method call stack trace: It returns to the main method and continues with the next line after the Execution.
Stage three The following image represents the third stage of execution of the process: Now we are waiting for a human to make a decision, but wait a second, if the thread that calls the start method on the instance of the execution dies, we lose all the information about the current execution, and we cannot get it back later. This means that we cannot restore this execution to continue from the human decision node. On the other hand, we can just sleep the thread waiting for the human to be ready to make the decision with something like Thread.
Where X is expressed in milliseconds. But we really don't know how much time we must wait until the decision is taken. So, sleeping the thread is not a good option. We will need some kind of mechanism that lets us persist the execution information and allows us to restore this status when the user makes the decision.
For this simple example, we just suppose that the decision occurs just after the start method returns. So, we get the execution object, the current node this will be the human decision node , and execute the decide method with the name of the transition that we want to take as argument. Let's run HumanDecisionNode execution. This is an ugly way to make the decision, because we are accessing the current node from the execution. We could create a method in the execution class that wraps this ugly call.
However, for this example, it is okay. You only need to understand that the call to the decide method is how the user interacts with the process. When we make this decision, the next action node is an automatic node like the action one, and the process will flow until the EndNode, which is ending the execution instance, because this is the last wait state, but any action could be made to continue.
As you can see, the wait states will need some kind of persistent solution in order to actually be able to wait for human or asynchronous system interactions. That is why you need to continue your testing of the execution with HumanDecisionN ode execution. In the following chapters, you will see how this is implemented inside the jBPM framework. Once you try it, you will feel that you really understand what is going on here; giving you a lot of fundamental concepts ready to use.
You could download the solutions pack from http: Quick start guide to building Maven projects A quick start guide for building Maven projects is follows: Then you can just import the project into your workspace Summary In this chapter, we learnt the following main points that you will need in order to understand how the framework works internally.
We have analyzed why we need the Graph Oriented Programming approach to represent and execute our business processes. In the next chapter, we will be focused on setting up our environment to get started with jBPM. However, not for a simple "hello world", but for real application development. We will also talk about the project source structure and how we can create projects that use the framework in an embedded way. In order to achieve this, we need to download, install, and understand a common set of tools that will help us in the development process.
This chapter will begin with a short introduction about the jBPM project so that we can be "ordered" and understand what we are doing. We will discuss the project's position inside all the JBoss projects. We will also talk about the project's main modules and the features proposed by this framework. All these tools are widely used in the software development market, but for those who don't know about them, this chapter will briefly introduce these tools one by one.
This chapter will also include two important steps. Firstly, a revision of the framework source code structure. Secondly, how to set up this code in our favorite IDE in order to have it handy when we are developing applications. Once we have set up the whole environment, we will be able to create two simple, real applications that will be our project templates for bigger applications. At the end of this chapter, you will be able to create applications that use the framework and also gain knowledge about how all of these tools interact in our development environment.
Setting Up Our Tools The following topics will be covered throughout this chapter: JBoss is in charge of developing middleware "enterprise" software in Java. It is middleware because it is a type of software to make or run software, and "enterprise", as it is focused on big scenarios. This enterprise does not necessarily mean Java EE. It is also interesting to know that JBoss was bought from a company called Red Hat famous for the Linux distribution with the same name, and also in charge of the Fedora community distribution.
In order to get the right first impression about the framework, you will need to know a little about other products that JBoss has developed and where this framework is located and focused inside the company projects. At this moment, the only entry point that we have is the JBoss community page, http: This page contains the information about all the middleware projects that JBoss is developing all open source.
If we click on the Projects link in the top menu, we are going to be redirected to a page that shows us the following image: The most representative modules are: And then, on top of it all, we can see three important blocks—Portal, Integration, and Telecom. As you can imagine, we are focused on the Integration block that contains three projects inside it. Therefore, we might suppose that these three products will run without any dependency from JBoss or any other application server.
Now we are going to talk about these three frameworks, which have different focuses inside the integration field. JBoss Drools Drools is, of late, focused on business knowledge, and because it was born as an inference engine, it will be in charge of using all that business knowledge in order to take business actions based on this knowledge for a specific situation.
You can find out more information about this framework now redefined as Business Logic integration Platform at http: JBoss ESB It is a product focused on supplying an Enterprise Service Bus ESB , which allows us to use different connectors to communicate with heterogeneous systems that were created in different languages. These use different protocols for communication.
You can find out more information about this project at http: This involves all the APIs and tools that are related to the processes and how to manage them.
As we are going to see in all the chapters of this book, the framework perspective is always centered on the business process that we describe. Also, the services available inside the framework are only for manipulating the processes. All the other things that we want or need for integration with our processes will be delegated to third-party frameworks or tools.
It is important to notice the home page, which shows us the following image: This image shows us the component distribution inside the jBPM framework project.
Understanding these building blocks components will help us to understand the code of the framework and each part's functionality.
Most of the time, this image is not clearly understood, so let's analyze it! Supported languages One of the important things that the image shows is the multi-language support for modeling processes in different scenarios. These supported languages are selected according to our business scenario and the technology that this scenario requires. This language can be used in situations where we are defining the project architecture and the technology that the project will use.
In most of the cases, jPDL will be the correct choice, because it brings the flexibility to model any kind of situation, the extensibility to expand our process language with new words to add extra functionality to the base implementation, and no technology pluggability limitation, thereby allowing us to interact with any kind of external services and systems.