Idea Transcript
t
Process Orchestration can simply be defined as the coordination of events and activities in a process at technical levels, to help achieve objectives laid down by the business. From an SOA perspective, orchestration involves direction and management of multiple component services to create a composite application or an end-to-end process. While orchestration tends to imply a single central engine performing the coordination act, another overlapping concept of choreography applies to sharing this coordination activity across multiple autonomous systems.
While we are covering orchestration for SOA, it is worthwhile to also discuss reference architecture for BPM, to understand how all components of technology fit together for modeling, executing, monitoring, and optimizing a business process. Following an architecture-lead approach, as always, is a good way to initially guide BPM projects. It is not necessary to implement all aspects of this architecture from day one, but as we mature with our BPM implementation, its coverage can be increased to gain maximum value. From the perspective of this article, this reference architecture provides an understanding of how process execution and orchestration is a core activity in bridging the abstract business models and underlying SOA infrastructure. If you look at the following architecture for BPM, you will realize that it is divided into layers and groups. The vertical right side covers the aspects of modeling the processes, business rules, and services. Free Stuff
Offers & Alerts
The horizontal stack starts with the presentation layer, which allows multiple channels through which a company's customers, employees, and partners can interact. It could be a web portal, a hand-held device, and so on. These channels are supported by the process orchestration layer, which assists in orchestrating different aspects of a business process to provide information to respective users in a channel. In this layer, we will have a process engine that will take inputs from the presentation layer and interface with underlying technologies and services to complete an end-to-end process. This layer will be responsible for ensuring that information is gathered from all sources at the right time, to enable a smooth process flow. The requirements for process orchestration will be fed by the activities performed by the business modeling team and the development teams, working on the process models using standards such as BPMN and BPEL. The orchestration layer will then interface with what we call 'Enterprise Services', which could be business services, technical services, or utility services, available either as basic services, or a composition of multiple services required to support the process orchestration. To enable access to these enterprise-level services, we will have an integration layer or an Enterprise Service Bus, which will provide a standards-based interface to multiple systems within or outside the organization, and also human service providers. We also have a layer of data management services that will be different high-level data sources that the BPM landscape will use. An example is a service registry to manage multiple services or metadata, which will manage information about all of the available data sources in the landscape to which this process has access. On the vertical left side, we have the monitoring services, which will capture all the events generated by the process to help in analyzing the process performance against key performance indicators laid down by the business. As we move ahead in this article, we will use this reference architecture to understand how various technology components fit together. Let us now go ahead with an example to see how we can orchestrate a process using Oracle BPEL Process Manager.
One of the fundamental benefits of using a BPM system for modeling a business process – in this case the Oracle suite of products – is to allow models created using BPMN at the business level to be executed, and to automate manual processes. It also allows a business to evaluate gaps in current processes and identify the remedial actions that can be implemented quickly using the execution engine. When working on the example for the 'Portfolio Account Opening' process, we created the business process model using BPMN, analyzed the process, converted the BPMN model into a process blueprint to be shared by the development teams, filled the technical gaps, and enriched and finally deployed the process to the BPEL Process Manager. Let us take the next step in understanding how our deployed process will work, and the functionality it offers to the users working on this process. Our aim is to make you aware of how process-driven SOA works for an end-to-end process. This explanation assumes that you have some working knowledge of BPEL constructs such as activities, partnerlinks and so on. XSD and WSDL are used with in the JDeveloper environment to create and deploy BPEL processes. For a detailed understanding of BPEL and its complex constructs, you may want to refer to these resources. For our case, we will use a simplistic representation of information, tasks and moving from one task to another. Let us go through a series of steps to trigger an instance of the account opening process:
First, let us initiate the services related to SOA Suite. You can open them by selecting Start SOA suite from the Program menu.
After the SOA suite services have started, we will open the SOA Launch Console, which provides a dashboard for all tools under the SOA suite that can be accessed from this location. To open the console, you can either enter the URL, which is typically http://localhost:8888; unless you have specified something specific during your installation. You can also access the console from the Program menu and select SOA Launch Console. The following screenshot shows what the SOA Suite console looks like. And As you can see, it provides, in addition to from all the product literature and technical guides, links to the main components of the SOA suite including BPEL Control, which is highlighted in the image.
Open the Oracle BPEL Process Manager administration interface by clicking the BPEL Control link to access the details of the account opening process we deployed earlier.
The first screen we see is the Process Dashboard, which provides us with the information on the currently-deployed processes in the database. As we can see, we have our 'Portfolio Account Opening Process'. There are currently some instances of the processes already running, and some instances have completed recently. To test the flow of the process and its behavior, trigger a new process instance for the deployed process through this console. To do this, click on the 'Portfolio_Account_Opening_Process' link on the dashboard to access details of our deployed process, and initiate a new instance. In a production environment, this step could be automated through a customized graphical interface. We will use the BPEL Process Manager to initiate this test process.
As you can see, the BPEL process Portfolio_Account_Opening_Process has been deployed from the development environment inside the BPEL Process Manager. To initiate the process instance, we have used a simple string as the input. In this case, we will just start the process by providing Open Account as the payload string, and posting the XML message to initiate the process instance. To check whether the process instance has started, we can view the visual flow for the instance by clicking the visual flow link.
The following visual flow shows that we have triggered the instance of the process, and it has reached a stage where the bank has received the application.
From our BPEL process, let us analyze the Receive Application activity, which is a human task involving the user to check whether or not the bank has received an application form from the customer. In this case, during development, the process developers will create a human task form to define how this task will work, and what data elements will be involved in the process.
In the task form, we will add all details relevant for this task. For example, we want this task to be assigned to a bank employee who will analyze whether the application has been received or not from the customer. It does not need multiple steps of approval. Hence, we have selected SingleApprover workflow pattern from the many task allocation patterns available. You can access the details by double-clicking the assignment section.
We have also chosen a particular user, who will perform this task, from the available user list in our application server. In this case, the task will be assigned to user jcooper Let us get back to our process instance, which has been initiated from Oracle BPEL Process Manager. At this moment, the process is waiting for the bank employee, jcooper, to verify whether the bank has received the application for the new portfolio account from the customer. For your reference, we have set up this user in our Oracle Application Server administration environment, which available from the SOA console, and you can have your own set of users defined.
Our user, jcooper, can access this task form by using 'Oracle Worklist Application' which is a web interface that enables users to act on their assigned human workflow tasks. Using this application, a manager can approve employee leave requests, or a bank clerk can review a new account opening application that has been initiated as part of the BPEL process. The application can also be used by supervisors to analyze the allocation of tasks to his team or group, and to route and assign them appropriately. Worklist Application users can also update the payload for a task, attach documents or comments, route the task to other users, and conclude tasks through approvals and rejections. This Worklist Application works on top of the workflow service provided.
To access the Worklist Application, we can open the web browser and access the URL http://hostname:portnumber/integration/worklistapp/Login, or use the start menu as follows:
This will open up the login screen for the Worklist Application, which we will access using Username, jcooper, and Password, welcome1. This can be different for your setup.
After we have logged in, the Worklist Application will appear as follows:
As we can see, the Worklist provides the user with a comprehensive view of the tasks and information meant for him, based on his role in the organization. The various tabs and menu items are meant to aid the user in managing his or her set of tasks and take relevant action. Also, the left-hand menu provides a view of a user (in this case jcooper) with an option to select tasks based on priority or deadline, and so on. There is also a chart option, which provides a snapshot of the user's activity in terms of their completed tasks. This is an important tool for managers as well, to ascertain the status of various tasks in the process that are active and are being worked on by his reportees. To further elaborate the concept, we will focus on the tasks that are being initiated by the account opening process.
As soon as we trigger the process instance from the BPEL console, a task will be created for jcooper as seen in the following screenshot.
We will notice that a new task has appeared in the task list or Inbox with the titleReceive Application. This is because this is the next activity in the BPEL process, and the human task is now behaving as we wanted it to, and is displaying the task information for the user, jcooper. You will also notice that the chart below shows that one task is currently assigned to this user. As we can see, the process is currently in a wait state, because it has initiated the task to check whether the user has received application or not, and is awaiting a response from the user. In the Worklist Application, user jcooper is now able to see the Receive Application task in their task list. The user can see the details of the task by clicking on the task, or he or she can choose from the various options that are available to them. In this case, the user has a choice to decide whether he or she has received the application or not. We will continue the process by selecting the Application Received option and clicking the Go button.
Once the task has been submitted, it will be moved out of the user's task box or work queue, suggesting that the user has completed this task. We can also validate this by checking that the number of completed tasks increases by one, and the currently assigned tasks count goes back to zero in the chart section.
In BPEL Process Manager, we will see that the status of the process has progressed, and now the process has initiated another task to check whether there are any documents missing in the customer's application.
This will result another task item for the user in the Worklist Application, as seen in the following screenshot:
In this case, the user checks for the documents and decides that all are in order, and there are no issues. If the documentation was not complete, the user could have suggested an available alternative, which would have resulted in a loop to check at regular time intervals for document availability before progressing. In a real-life scenario, the logic could be more complex, where we can provide a checklist of documents received and follow-up on each of these with the customer. The control now passes back to the Process Manager, where we have made a dummy activity that checks the bank's systems to determine whether the customer is an existing customer or not. In this case, we are taking the default value that the customer is an existing user of the bank's services. In real life SOA architecture, we would have made a service call to the banking system to perform this check, typically over the ESB.
In our case, the process will quickly move to the next human task, to check eligibility, as we can see from the BPEL flow. Again in a real life scenario, the job of checking eligibility can be automated using a service call to a rules engine that is based on business policies of the bank, or it could be the job of specialized personnel in the bank to decide on eligibility. In this case however, we are sending the task to the default user jcooper for them to make a decision on the applicant's eligibility.
The control again goes back to the Process Manager, now that the customer has been found to be eligible to open a portfolio account. Based on this decision, the control passes on to the system to create a portfolio account, which we have created as a straight-through activity, considering that the backend systems will create the portfolio account, and will attach it to the details of the customer's existing details. When the account is created (we are assuming that the customer is a high-priority customer), we will allocate a portfolio manager to the customer.
This, in real life, can be done by selecting from a list of portfolio managers automatically, based on criteria such as how busy the person is, or it could be sent as a task, for a manager to allocate a portfolio manager. In this example, we are taking a happy path of just asking the user to allocate a portfolio manager, although this could be developed as a straight-through process in most cases. This also demonstrates the fact that the implementation of a BPM project, and the way a process activity is automated, is driven by the business requirements' appetite for automation, and the capability of a system to implement such automation in the most appropriate manner. Another benefit of a BPM-based system is that the activities can be deployed iteratively and more frequently than the typical application life cycle, allowing the business to improve their processes as they find bottlenecks and areas of potential improvement. So, we can have this example as a base, which could be iterated in real life to handle much more complicated, real world scenarios, with the fundamental concepts remaining similar.
To take the execution example further, the control for the process now moves back to the process manager, where the next step is to prepare a welcome kit for the customer, to be sent to him or her by mail. Again, one way to do this is through a human task, where someone initiates the process of sending a welcome kit. However, nowadays these tasks are automated and the welcome kit is sent automatically or with minimal human intervention, based on the customer's data and choice of product request.
This initiates a task for the user to prepare a welcome kit.
The control passes back to the process manager where the customer is notified via mail or any other channel that his or her request has been approved, and they should await the arrival of the welcome kit or any other communication message from the bank through an automated notification activity. Moreover, the bank, as part of their compliance and record keeping exercise, would like to store the physical documents in a warehouse for further reference. This will be the final activity in the process.
The assigned user will store the documents, or have someone store the documents, update the status, and send back the control to the Process Manager for the process to end.
The following figure shows what the visual flow looks like at the end of the process execution of the 'Portfolio account opening process':
In this example, we can see how a process defined using BPMN by the business teams is communicated using a process blueprint from Oracle BPA to JDeveloper. This process blueprint then acts as the requirement specifications on which the process developers will work, and add technical details linking the process model to actual human tasks and technical services before executing the process in the process engine. After covering the core flow of information from process models to process engine, we will shift our focus to other valuable complementary technologies that are part of BPM architecture, such as Business Rules Management and BAM, in the subsequent sections.
In this article,we saw BPM architecture and role of business process orchestration in an organisation. We also covered the core flow of information from process models to process engine.
If you have read this article you may be interested to view :
if you have any queries or issues.