Business processes, particularly long-running processes that contain human interactions, often have to react to events. For example, let's imagine that a business process needs to provide a way to cancel the process while it is running. Or that we want to limit the maximum time in which a business process should finish. Or that a business process should start or stop on a specific date and time. All this can be achieved with events and Event Driven Architecture (EDA).
In this chapter, we will take a closer look at the events and event handlers in BPEL processes. We will do the following:
<pick>
activity<pick>
activity can be used with asynchronous callbacksSo let's get started...
So far we have talked about operation invocations. A BPEL process explicitly invokes an operation on a service or another BPEL process. Operation invocations are the most common interaction models used in software development. They require that the caller (service consumer) explicitly calls a service (also referred to as a service provider) by invoking a specific operation. This means that we need to know explicitly who we are calling. In cases where we would prefer a more loosely-coupled interaction, without explicitly stating who we are calling, operation invocations would be insufficient. This is where events come in.
An event represents an occurrence, something that happens or is regarded as happening, especially one of some importance. It enables a different interaction model, a model where it is not required to explicitly call a service. Rather, it is sufficient to trigger an event. Once the event is triggered, all services subscribed to this type of event will be invoked automatically.
An event-driven interaction model enables us to create a very loosely-coupled interaction. The one that triggers an event does not know which services are subscribed to that event. Therefore, it does not know which services will be invoked. Also, vice versa, the service subscribed to an event does not know who has triggered the event.
Events have become an important part of software architectures. EDA defines the concepts related to the production, detection, consumption, and reaction to events. EDA complements service-oriented architecture (SOA), as it enables SOA processes and services to react on events and to trigger events. Sometimes, SOA complemented with EDA is referred to as SOA 2.0. For more information on EDA, please refer to http://en.wikipedia.org/wiki/Event-driven_architecture. For more information on event processing, please refer to the book Getting Started with Oracle Event Processing 11g, Packt Publishing, or to the Oracle documentation at http://docs.oracle.com/middleware/1213/eventprocessing/index.html.
Business processes may be triggered by events. For example, let's imagine a process that takes care of book shelving. This process may be executed on different occasions, such as when the books arrive to the bookstore for the first time, after a customer has looked at the books, and during an inventory. Instead of explicitly invoking the process on each occasion, such a process could react on a corresponding event. A business process might also trigger an event. For example, the book warehousing process might trigger the event to bookshelf the books.
Business processes may have to react on events. Particularly long-running processes, which contain human interactions, often need to react on events. For example, in the previous chapter, we have added a human task to our book warehousing process where a user has to approve the selected bookstore. As it is usually not possible to foresee how long a user will need to complete a human task, we might want to add other measures to be sure that a certain BPEL process does not get stalled. For example, let's suppose that we would like to limit the total execution time of a specific BPEL process. We can achieve this using events and event handlers.
A second example would be a scenario where a business process has been initiated and is in progress; however, we would like to provide a possibility to cancel the process instance at any time. This is the case in many business processes, for example, in an ordering process, a client might place the order and change his or her mind after a certain time while the order is still being processed. In a bank, a client might apply for a loan and while the bank is deciding whether he is eligible for the loan, the client can change his mind.
Also, in our book warehousing process, where the processes select the appropriate bookstore to warehouse the books, we might have the need for handling events. In Chapter 9, Human Tasks, we have added a human interaction to the process. Therefore, we might handle both previously-described situations—limit the total execution time and handle cancelations (for example, if the books would be damaged during transport or similar situations).
Before we get to the example, let's just mention that events are also very useful with asynchronous invocations. In Chapter 5, Interaction Patterns in BPEL, we learned how to invoke services asynchronously. However, with events, we can wait for several incoming service calls simultaneously. Alternatively, we can limit the time waiting for an incoming call. We will talk more about this in the second half of this chapter.
In BPEL processes, we can react on the following types of events:
Business events represent occurrences with specific business meaning. For example, a business event could signal that the books have arrived and they require being sorted out to different bookstores. Or a business event could signal that the books have arrived to the bookstore and they need to be registered and shelved. We could find many more examples.
Business events contain a data payload, very similar to operations and their messages. For example, a business event signaling that a book has arrived to the bookstore would have an associated data payload containing the book data, such as title, ISSN, author name, and many others.
As we have already mentioned, business events need to be explicitly triggered by a process, service, or other software component. Once triggered, a business event will be delivered to all event-driven software components (processes, services, and others) that have subscribed to this type of event. In this sense, business events are one-way communications, which is asynchronous by its nature. Business events follow the fire-and-forget semantics, as the process or service that has triggered the event will not be notified about who has received the event.
Message events are related to operation invocations. In most cases, message events are triggered when the client or another service invokes an operation on the BPEL process. This makes sense in the following two scenarios:
Alarm events can be:
We usually specify a duration using a <for>
duration expression. We specify a deadline using an <until>
deadline expression.
To specify deadline and duration expressions, BPEL uses lexical representations of corresponding XML Schema data types. For deadlines, these data types are either
dateTime
or date
. For duration, we use the duration
data type. The lexical representation of expressions should conform to the XPath 1.0 (or the selected query language) expressions.
The evaluation of such expressions should result in values that are of corresponding XML Schema types: dateTime
and date
for deadline and duration
for duration expressions.
All three data types use lexical representation inspired by the ISO 8601 standard, which can be obtained from the ISO web page http://www.iso.org/iso/home/standards/iso8601.htm. The ISO 8601 lexical format uses characters within the date and time information. Characters are appended to the numbers and have the following meanings:
C
represents centuries.Y
represents years.M
represents months.D
represents days.h
represents hours.m
represents minutes.s
represents seconds. Seconds can be represented in the ss.sss
format to increase precision.Z
is used to designate Universal Time Coordinated (UTC). It should immediately follow the time of day element.For the dateTime
expressions, there is another designator:
T
is used as a time designator to indicate the start of the representation of the time.Examples of deadline expressions are shown in the following code excerpts:
<wait> <until>'2014-03-18T21:00:00+01:00'</until> </wait> <wait> <until>'18:05:30Z'</until> </wait>
For duration expressions, the following characters can also be used:
P
is used as the time duration designator. Duration expressions always start with P
.Y
follows the number of years.M
follows the number of months or minutes.D
follows the number of days.H
follows the number of hours.S
follows the number of seconds.To specify a duration of 4 hours and 10 minutes, we use the following expression:
<wait> <for>'PT4H10M'</for> </wait>
To specify the duration of 1 month, 3 days, 4 hours, and 10 minutes, we need to use the following expression:
<wait> <for>'P1M3DT4H10M'</for> </wait>
The following expression specifies the duration of 1 year, 11 months, 14 days, 4 hours, 10 minutes, and 30 seconds:
<wait> <for>'P1Y11M14DT4H10M30S'</for> </wait>