A BPEL process definition is written as an XML document using the <process> root element. Within the <process> element, a BPEL process will usually have the top-level <sequence> or <flow> element. Within the sequence, the process will first wait for the incoming message to start the process. This wait is modeled with the <receive> construct. Then, the process will perform some activities and return a response. This is shown in the following code excerpt:
<process ...>
...
<sequence>
<!-- Wait for the incoming request to start the process -->
<receive ... />
<!-- Perform some activities -->
...
<!-- Return the response -->
<reply ... />
</sequence>
</process>To provide an idea of a BPEL process structure, let's look more closely at the BookstoreABPEL process. We can see the <process> activity, which represents the root element. Within the <process> activity, several XML namespaces are defined. The process will also import WSDL. We have already mentioned that each BPEL process requires the interface definition, which is specified in WSDL:
Next, <partnerLinks> are declared. Partner links define which services our process is communicating with. The client, which calls the BPEL process, is one of the partners. In our process, it is the only partner, as our BookstoreA process does not call any other services or processes.
Next, variables are declared. BPEL uses variables much like any other programming language, except that these variables hold the XML elements or primitive types. Two variables are declared by default. The inputVariable holds the input payload (input parameters). In our case, these are the four parameters, including ISSN, title, edition, and publishing year. The outputVariable activity holds the output, which is returned to the client (the one who has invoked the BPEL process), as shown in the following screenshot:
Next, we specify the process steps. These are gathered within the top-level <sequence> activity, which contains all the process flow. Each BPEL process first waits for the initial request message from the client (<receive>). Usually, a BPEL process also returns some response to the client. This is true for the synchronous BPEL processes. In this case, the BPEL process will end with a <reply> activity through which it will return the response to the client.
In between <receive> and <reply>, we specify all the required activities for the actual process flow. In our case, this is only an <assign> activity, which has been used to manipulate variables and to assign the quantity of 5 to the one of the elements of the outputVariable. With more complex processes, we would have several activities listed here. The BPEL source code of our first process looks like the following screenshot:
This corresponds to the following graphical presentation in the design view:
In this section, we will have a more detailed look at different BPEL activities. This gives us more information on the syntax of the activities and helps us to understand the BPEL language better.
Let's focus more closely on the <process> tag. This delimits the root element of the BPEL document. The <process> tag requires that we specify certain attributes. We have to specify at least the following attributes:
name: This attribute specifies the name of the BPEL business processtargetNamespace: This attribute specifies the target namespace for the business process definitionxmlns: This namespace used by BPEL is available at http://docs.oasis-open.org/wsbpel/2.0/process/executable.
Usually, we also specify one or more additional namespaces to reference other involved namespaces (for example, those used by services). If you look at the preceding screenshot, you will see that there are quite a few namespace declarations, such as xmlns:client, which has the namespace of the imported WSDL and any reference to elements within WSDL will go through this namespace.
We can also specify additional attributes for the <process> tag as follows:
queryLanguage: This attribute specifies which query language is used for node selection in assignments, properties, and other uses. The default (and part of the BPEL standard) is XPath 1.0 (urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0). However, another language can be specified, such as XPath 2.0 or XQuery. The available options are determined by what is supported by a given BPEL engine.expressionLanguage: This attribute specifies which expression language is used in the process. The default is again XPath 1.0 (urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0).suppressJoinFailure: This attribute determines whether to suppress join failures (yesorno). Default isno. This is used in flow activities with links, which is an advanced scenario of using BPEL.exitOnStandardFault: This attribute defines how the process should behave when a standard fault occurs. We can specifyyesif we want the process to exit on a standard fault (other thanbpel:joinFailure), ornoif we want to handle the fault using a fault handler. Default isno.
With <receive>, the process waits for incoming messages (that is, operation invocations). Usually, it waits for the initial message to start the process. Another typical use of <receive> is to wait for callbacks (we'll discuss this in Chapter 5, Interaction Patterns in BPEL).
With <reply>, a BPEL process can send a response. Usually, it is used in the synchronous BPEL processes. However, in general, it can be used with any open request or response operation. Both activities use the same basic attributes as follows:
partnerLink: This attribute specifies which partner link will be usedoperation: This attribute specifies the name of the operation to wait for being invoked (<receive>), or the name of the operation that has been invoked but is synchronous and requires a reply (<reply>)variable: This attribute specifies the name of the BPEL variable used to store the incoming message (<receive>) or send the outgoing message (<reply>)
Note
For each BPEL activity, we can also specify a name attribute. We use the name attribute to provide names for activities. In most BPEL activities, the name attribute is optional, but we can add it to improve the readability of the code.
Let's now take a closer look at the <receive> activity. We said that <receive> waits for the incoming message (operation invocation), either for the initial to start the BPEL process, or for a callback function. Usually, the business process needs to store the incoming message and it can use the variable attribute to specify a suitable variable.
Another attribute for the <receive> activity is the createInstance attribute, which is related to the business process life cycle and instructs the BPEL engine to create a new instance of the process. Usually, we specify the createInstance="yes" attribute with the initial <receive> activity of the process to create a new process instance for each client. We will discuss this attribute in more detail in the next chapter.
The following example shows a <receive> activity that waits for the getBookData operation on the port type client:BookstoreBBPEL using the bookstoreBbpel_client partner link. As this is the initial <receive> activity, the createInstance attribute is used. The client request is stored in the inputVariable variable:
The <reply> activity is used to return the response for the synchronous BPEL operation. It is always related to the initial <receive> through which the BPEL process started. Using <reply>, we can return the response, which is the normal usage, or we can return a fault message. Returning a fault message using <reply> is discussed in Chapter 6, Fault Handling and Signaling.
When we use <reply> to return a response for a synchronous operation, we have to define only one additional attribute—the name of the variable where the response is stored. The following example shows a reply on an initial receive operation. It uses the bookstoreBbpel_client partner link and provides a response for the getBookData operation on client:BookstoreBBPEL port type. The return result is stored in the outputVariable variable. Please note that the same partnerLink, portType, and operation name have been used in the initial <receive>:
With this, we have concluded our discussion on the fundamental BPEL syntax. We will look more closely into the syntax on other activities in subsequent chapters of this book.