BPEL Activities & Components

Introduction to Activities and Components

When you expand SOA Components in the Component Palette of Oracle BPEL Designer, service components are displayed. Figure shows the components that display for a BPEL 1.1 process. A BPEL 2.0 process also shows the same components.

Figure A-1 SOA Components

Introduction to BPEL 1.1 and 2.0 Activities

This section provides a brief overview of BPEL activities and provides references to other documentation that describes how to use these activities.
Oracle BPEL Designer includes BPEL 1.1 and BPEL 2.0 activities that are available for adding in a BPEL process. These activities enable you to perform specific tasks within a process. Some activities are available in both BPEL 1.1 and BPEL 2.0. Others are available in only BPEL 1.1 or BPEL 2.0.
To access these activities, go to the Component Palette of Oracle BPEL Designer. The activities display under either of two categories:

·         BPEL Constructs: Displays core activities (also known as constructs) provided by standard BPEL 1.1 and 2.0 functionality. The activities in this category are displayed under additional subcategories of Web Service, Activities, and Structured Activities in BPEL 1.1 and Web Service, Basic Activities, and Structured Activities in BPEL 2.0.

·         Oracle Extensions: Displays extension activities that add value and ease of use to BPEL 1.1 and 2.0 functionality

1.Assign Activity

This activity provides a method for data manipulation, such as copying the contents of one variable to another. Copy operations enable you to transfer information between variables, expressions, endpoints, and other elements.

• Provides a way to copy data between variables in a BPEL Process
• One of the ways you can copy data from source to target in a BPEL Process.

<assign name=“Assign_1”>

• When you Double Click the Activity Icon. Assign popup window will appear you can perform following operation
• Copy , Append, insert  and Remove

• Copy operation

2.Compensate Activity

This activity invokes compensation on an inner scope activity that has successfully completed. This activity can be invoked only from within a fault handler or another compensation handler. Compensation occurs when a process cannot complete several operations after completing others. The process must return and undo the previously completed operations. For example, assume a process is designed to book a rental car, a hotel, and a flight. The process books the car and the hotel, but cannot book a flight for the correct day. In this case, the process performs compensation by unbooking the car and the hotel. The compensation handler is invoked with the compensate activity, which names the scope on which the compensation handler is to be invoked.

Below Figure shows the Compensate dialog in BPEL 1.1. You can perform the following tasks:

·         Click the General tab to provide the activity with a meaningful name.

·         Select the scope activity on which the compensation handler is to be invoked.

Figure Compensate Dialog

In BPEL 2.0, the Compensate dialog does not include a Skip Condition tab.

3. Email Activity

This activity enables you to send an email notification about an event.
For example, an online shopping business process of an online bookstore sends a courtesy email message to you after the items are shipped. The business process calls the notification service with your user ID and notification message. The notification service gets the email address from Oracle Internet Directory.
Figure A-11 shows the Email dialog in BPEL 1.1 and BPEL 2.0.

Figure A-11 Email Dialog

4. Empty Activity

This activity enables you to insert a no-operation instruction into a process. This activity is useful when you must use an activity that does nothing (for example, when a fault must be caught and suppressed).

Figure a-12 Empty Dialog

In BPEL 2.0, the Empty dialog includes a Documentation tab and does not include a Skip Condition tab.

5. Flow Activity

This activity enables you to specify one or more activities to be performed concurrently. A flow activity completes when all activities in the flow have finished processing. Completion of a flow activity includes the possibility that it can be skipped if its enabling condition is false.
For example, assume you use a flow activity to enable two loan offer providers (United Loan service and Star Loan service) to start in parallel. In this case, the flow activity contains two parallel activities – the sequence to invoke the United Loan service and the sequence to invoke the Star Loan service. Each service can take an arbitrary amount of time to complete their loan processes.
Figure A-14 shows an initial flow activity with its two panels for parallel processing. You drag activities into both panels to create parallel processing. When complete, a flow activity looks like that shown in Figure A-15.

Figure A-14 Flow Dialog (At Time of Creation)

Description of "Figure A-14 Flow Dialog (At Time of Creation)"

Figure A-15 Flow Dialog (After Design Completion)

You can also synchronize the execution of activities within a flow activity. This ensures that certain actives only execute after other activities have completed.

Note: Oracle’s BPEL implementation executes flows in the same, single execution thread of the BPEL process and not in separate threads.

6. FlowN Activity

This activity enables you to create multiple flows equal to the value of N, which is defined at runtime based on the data available and logic within the process. Index variable increments each time a new branch is created, until the index variable reaches the value of N.
Figure A-16 shows the FlowN dialog.

Figure A-16 FlowN Dialog

 

 

7. Invoke Activity

This activity enables you to specify an operation you want to invoke for the service (identified by its partner link). The operation can be one-way or request-response on a port provided by the service. You can also automatically create variables in an invoke activity. An invoke activity invokes a synchronous web service or initiates an asynchronous web service.
The invoke activity opens a port in the process to send and receive data. It uses this port to submit required data and receive a response. For synchronous callbacks, only one port is needed for both the send and the receive functions.
The invoke activity supports the bpelx: inputProperty and bpelx: outputProperty that facilitate the passing of properties through the SOAP header and the obtaining of SOA runtime system properties for useful information such as the tracking.compositeInstanceId and tracking.conversationId.
Figure A-20 shows the Invoke dialog in BPEL 1.1. You can perform the following tasks:

·         Provide the activity with a meaningful name.

·         Select the partner link for which to specify an operation.

·         Select the operation to be performed.

·         Automatically create a variable or select an existing variable in which to transport the data (payload).

Figure A-20 Invoke Dialog

 

 

8. Java Embedding Activity

This activity enables you to add custom Java code to a BPEL process using the Java BPEL exec extension bpelx: exec. This is useful when you have Java code that can perform a function, and want to use this existing code instead of starting over. In BPEL 2.0 projects, the bpelx: exec extension and Java code are wrapped in an <extension Activity> element.

• This activity enables you to add custom Java code to a BPEL process using the Java BPEL exec extension <bpelx:exec>.
• When user double clicks on the Java embedding icon, popup window will appear and user can enter the java code on it.

9. Notification Activities

• This activity enables you to send notification about an event to a user, group, or destination address.
• You can send a notification by e-mail, voice mail, fax, pager, or short message service (SMS).

 

10. Partner Link Activity

This service enables you to define the external services with which your process interacts. A partner link type characterizes the conversational relationship between two services by defining the roles played by each service in the conversation and specifying the port type provided by each service to receive messages within the conversation. For example, if you are creating a process to interact with a Credit Rating Service and two loan provider services (United Loan and Star Loan); you create partner links for all three services.
Figure A-22 shows the Partner Link dialog in BPEL 1.1. You provide the following details:

·         A meaningful name for the service.

·         The web services description language (WSDL) file of the external service.

·         The actual service type (defined as Partner Link Type).

·         The role of the service (defined as Partner Role).

·         The role of the process requesting the service (defined as My Role).

Figure A-22 Partner Link Activity

11. Pick Activity

This activity waits for the occurrence of one event in a set of events and performs the activity associated with that event. The occurrence of the events is often mutually exclusive (the process either receives an acceptance or rejection message, but not both). If multiple events occur, the selection of the activity to perform depends on which event occurred first. If the events occur nearly simultaneously, there is a race and the choice of activity to be performed is dependent on both timing and implementation.
The pick activity provides an OnMessage branch. When you double-click the OnMessage icon in BPEL 1.1, the dialog shown in Figure A-24 appears.

Figure A-24 OnMessage Dialog

The two branches of the pick activity are as follows:

·         onMessage (automatically displays below the Pick activity icon)

Contains the code for receiving a reply, for example, from a loan service.

·         onAlarm (does not automatically display; you must manually add this branch by selecting the Pick activity icon and clicking the Add OnAlarm icon)

Contains the code for a timeout, for example, after one minute.

Whichever branch completes first is executed; the other branch is not executed. The branch that has its condition satisfied first is executed.
Figure A-25 shows the OnAlarm dialog of the pick activity in BPEL 1.1.

Figure A-25 OnAlarm Branch Dialog of a Pick Activity

.

Note: You can also create onMessage branches in BPEL 1.1 scope activities and onAlarm branches in BPEL 1.1 and 2.0 scope activities. Expand the Scope activity in Oracle JDeveloper, and browse the icons on the left side to find the branch you want to add.

If you add correlations to an OnMessage branch, the correlations syntax is placed after the assign activity syntax. The correlation syntax must go before the assign activity.
As a work around, perform the following steps:

1.     Create a correlation set in Oracle JDeveloper.

2.     Assign this to the OnMessage branch.

3.     Complete the remaining design tasks.

4.     Before making or deploying the BPEL process, move the correlation syntax before the assign activity in the BPEL

12. Receive Activity

This activity specifies the partner link from which to receive information and the port type and operation for the partner link to invoke. This activity waits for an asynchronous callback response message from a service, such as a loan application approver service. While the BPEL process is waiting, it is dehydrated (compressed and stored) until the callback message arrives. The contents of this response are stored in a response variable in the process.The receive activity supports the bpelx:property extensions that facilitate the passing of properties through the SOAP header, and the obtaining of SOA runtime system properties for useful information such as tracking.compositeInstanceId and tracking.conversationId.
Figure A-26 shows the Receive dialog in BPEL 1.1. You can perform the following tasks:

·         Provide a meaningful name.

·         Select the partner link service for which to specify an operation.

·         Select the operation to be performed.

·         Automatically create a variable or select an existing variable in which to transport the callback response.

·         Figure A-26 Receive Dialog

13. Reply Activity

This activity allows the process to send a message in reply to a message that was received through a receive activity. The combination of a receive activity and a reply activity forms a request-response operation on the WSDL port type for the process.Figure A-31 Reply Dialog

14. Rethrow Activity

This activity enables you to rethrow a fault originally captured by the immediately enclosing fault handler.

Note: This activity is only supported in BPEL 2.0 projects.

Figure A-32 shows a rethrow activity within a fault handler (catch activity).

Figure A-32 Rethrow Activity

15. Scope Activity

This activity consists of a collection of nested activities that can have their own local variables, fault handlers, compensation handlers, and so on. A scope activity is analogous to a { } block in a programming language.Each scope has a primary activity that defines its behavior. The primary activity can be a complex structured activity, with many nested activities within it to arbitrary depth. The scope is shared by all the nested activities.

Figure A-33 Scope Dialog

Fault handling is associated with a scope activity. The goal is to undo the incomplete and unsuccessful work of a scope activity in which a fault has occurred. You define catch activities in a scope activity to create a set of custom fault-handling activities. Each catch activity is defined to intercept a specific type of fault.

Figure A-34 shows the Add Catch icon inside a scope activity. Figure A-35 shows the catch activity area that appears when you click the Add Catch icon. Within the area defined as Drop Activity Here, you drag additional activities to create fault handling logic to catch and manage exceptions. For example, a client provides a social security number to a Credit Rating service when applying for a loan. This number is used to perform a credit check. If a bad credit history is identified or the social security number is identified as invalid, an assign activity inside the catch activity notifies the client of the loan offer rejection. The entire loan application process is terminated with a terminate activity.

Figure A-34 Creating a Catch Branch

Figure A-35 Catch Activity Icon

16. Sequence Activity

This activity enables you to define a collection of activities to be performed in sequential order. For example, you may want the following activities performed in a specific order:

·         A customer request is received in a receive activity.

·         The request is processed inside a flow activity that enables concurrent behavior.

·         A reply message with the final approval status of the request is sent back to the customer in a reply activity.

A sequence activity makes the assumption that the request can be processed in a reasonable amount of time, justifying the requirement that the invoker wait for a synchronous response (because this service is offered as a request-response operation).
When this assumption cannot be made, it is better to define the customer interaction as a pair of asynchronous message exchanges.
When you double-click the Sequence icon, the activity area shown in Figure A-36 appears. Drag and define appropriate activities inside the sequence activity.

Figure A-36 Sequence Activity

17. Switch Activity

This activity consists of an ordered list of one or more conditional branches defined in a case branch, followed optionally by an otherwise branch. The branches are considered in the order in which they appear. The first branch whose condition is true is taken and provides the activity performed for the switch. If no branch with a condition is taken, then the otherwise branch is taken. If the otherwise branch is not explicitly specified, then an otherwise branch with an empty activity is assumed to be available. The switch activity is complete when the activity of the selected branch completes.
A switch activity differs in functionality from a flow activity. For example, a flow activity enables a process to gather two loan offers at the same time, but does not compare their values. To compare and make decisions on the values of the two offers, a switch activity is used. The first branch is executed if a defined condition (inside the case branch) is met. If it is not met, the otherwise branch is executed.

Figure A-39 Switch Activity

18. Terminate Activity

A terminate activity enables you to end the tasks of an activity (for example, the fault handling tasks in a catch branch). For example, if a client's bad credit history is identified or a social security number is identified as invalid, a loan application process is terminated, and the client's loan application document is never submitted to the service loan providers.

Note:

Figure A-40 shows several terminate activities in the otherwise branch of a switch activity.

Figure A-40 Terminate Activity

19. Throw Activity

This activity generates a fault from inside the business process.
Figure A-41 shows the Throw dialog.

Figure A-41 Throw Dialog

20. Transform Activity

This activity enables you to create a transformation that maps source elements to target elements (for example, incoming purchase order data into outgoing purchase order acknowledgment data).
Figure A-42 shows the Transform dialog in BPEL 1.1. This dialog enables you to perform the following tasks:

·         Define the source and target variables and parts to map.

·         Specify the transformation mapper file.

·         Click the second icon (the Add icon) to the right of the Mapper File field to access the XSLT Mapper for creating a new XSL file for graphically mapping source and target elements. Click the Edit icon (third icon) to edit an existing XSL file.

Figure A-42 Transform Dialog

.

21. Wait Activity

This activity allows a process to specify a delay for a certain period or until a certain deadline is reached. A typical use of this activity is to invoke an operation at a certain time. This activity enables you to wait for a given time period or until a certain time has passed. Exactly one of the expiration criteria must be specified.

Figure A-46 Wait Dialog

22. While Activity

This activity supports repeated performance of a specified iterative activity. The iterative activity is repeated until the given while condition is no longer true.

Figure A-47 While Dialog