Describing how the job position is requested

In the first part, we find all the answers to our questions; however, a few remain unanswered:

• How is the first part of the process represented? How can we track when the new job position is discovered, the request for that job position is created, and when this job position is fulfilled?
• Why can’t we add more activities to the current defined process? What happens when we add the create request, find a candidate, and job position fulfilled activities inside the interview process?

The answers for these questions are simple. We cannot add these proposed nodes to the same process definition, because the interview process needs to be carried out (needs to be instantiated) once for each candidate that the recruiting team finds. Basically, we need to decouple all these activities into two processes. As the MyIT Inc. manager said, the relationship between these activities is that a job request will be associated with the N-interviews’ process.

The other important thing to understand here, is that both the processes can be decoupled without using a parent/child relationship. In this case, we need to create a new interview’s process instance when a new candidate is found. In other words, we don’t know how many interviews’ process instances are created when the request is created. Therefore, we need to be able to make these creations dynamically.

We will introduce a new process that will define these new activities. We need to have a separate concept that will create an on-demand new candidate interviews’ process, based on the number of candidates found by the human resources team. This new process will be called “Request Job Position” and will include the following activities:

• Create job request: Different project leaders can create different job requests based on their needs. Each time that a project leader needs to hire a new employee, a new instance of this process will be created where the first activity of this process is the creation of the request.
• Finding a candidate: This activity will cover the phase when the research starts. Each time the human resources team finds a new candidate inside this activity, they will create a new instance of the candidate interviews’ process. When an instance of the candidate interviews’ process finds a candidate who fulfills all the requirements for that job position, all the remaining interviews need to be aborted.

We can see the two process relationships in the following figure:

If we express the Request Job Position process in jPDL, we will obtain something like this:

In the following section, we will see two different environments in which we can run our process. We need to understand the differences between them in order to be able to know how the process will behave in the runtime stage.

Environment possibilities

Based on the way we choose to embed the framework in our application, it’s the configuration that we need. We have three main possibilities:

• Standalone applications
• Web applications
• Enterprise application

Standalone application with jBPM embedded

In Java Standard Edition (J2SE) applications, we can embed jBPM and connect it directly to a database in order to store our processes. This scenario will look like the following image:

In this case, we need to include the jBPMJARs in our application classpath in order to work. This is because our application will use the jBPM directly in our classes.

In this scenario, the end users will interact with a desktop application that includes the jbpm-jpdl.jar file. This will also mean that in the development process, the developers will need to know the jBPM APIs in order to interact with different business processes.

It’s important for you to know that the configuration files, such as hibernate.cfg.xml and jbpm.cfg.xml will be configured to access the database with a direct JDBC connection.

Web application with jBPM dependency

This option varies, depending on whether your application will run on an application server or just inside a servlet container. This scenario will look like:

In this case, we can choose whether our application will include the jBPMJARs inside it, or whether the container will have these libraries. But once again, our application will use the jBPM APIs directly.

In this scenario, the end user will interact with the process using a web page that will be configured to access a database by using a JDBC driver directly or between a DataSource configuration.