bepl narration script

36
Oracle SOA Suite 11g: BPEL Component Overview Narration Script Oracle SOA Suite 11g: BPEL Component Overview Hello, and welcome to this Oracle eStudy course entitled Oracle SOA Suite 11g: BPEL Component Overview. My name is Bijoy Choudhury. I am a curriculum developer at Oracle and work with Server Technologies Curriculum, Fusion Middleware team. I will be your tour guide for approximately the next 3 hours of interactive lectures and review sessions. The aim of this course is to introduce you to Oracle BPEL in Oracle SOA Suite 11g. After completing this course, you are introduced to some of the new concepts of Oracle BPEL in Oracle SOA Suite 11g, and learn to create a composite application by using the BPEL Process service component by using Oracle JDeveloper 11g. Using the Player Before we begin, now might be a good time to take a look at some of the features of this Flash-based course player. Feel free to skip this slide and start the lecture if you’ve attended similar Oracle eStudy courses in the past. To your left, you will find a hierarchical course outline. This course enables and even encourages you to go at your own pace, which means you are free to skip over topics you already feel confident on, or jump right to a feature that really interests you, or go back and review topics that were already covered. Simply click on a course section to expand its contents and then select an individual slide. However, note that by default we will automatically walk you through the entire course without requiring you to use the outline. Standard Flash player controls are also found at the bottom of the player, including pause, previous, and next buttons. There is also an interactive progress bar to fast forward or rewind the current slide. Interactive slides may have additional controls and buttons along with instructions on how to use them. Also found at the bottom of the player is a panel containing any additional reference notes for the current slide. Feel free to read these reference notes at the conclusion of the course, in which case you can minimize this panel and restore it later. Or if you prefer you can pause and read them as we go along. Various handouts may be available from the Attachments button, including the audio narration scripts for this course. The course will now pause, so feel free to take some time and explore the interface. Then when you’re ready to continue, click the next button below or alternatively click the Module 1 slide in the course outline at left. Course Objectives So what can you expect to get out of this course? This course introduces you to Oracle BPEL Process service component in Oracle SOA Suite 11g. It does not attempt to provide every detail about a feature or cover aspects of a feature that were available

Upload: fazeelahmed

Post on 26-Dec-2014

276 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: BEPL narration script

Oracle SOA Suite 11g: BPEL Component Overview Narration Script Oracle SOA Suite 11g: BPEL Component Overview Hello, and welcome to this Oracle eStudy course entitled Oracle SOA Suite 11g: BPEL Component Overview. My name is Bijoy Choudhury. I am a curriculum developer at Oracle and work with Server Technologies Curriculum, Fusion Middleware team. I will be your tour guide for approximately the next 3 hours of interactive lectures and review sessions. The aim of this course is to introduce you to Oracle BPEL in Oracle SOA Suite 11g. After completing this course, you are introduced to some of the new concepts of Oracle BPEL in Oracle SOA Suite 11g, and learn to create a composite application by using the BPEL Process service component by using Oracle JDeveloper 11g. Using the Player Before we begin, now might be a good time to take a look at some of the features of this Flash-based course player. Feel free to skip this slide and start the lecture if you’ve attended similar Oracle eStudy courses in the past. To your left, you will find a hierarchical course outline. This course enables and even encourages you to go at your own pace, which means you are free to skip over topics you already feel confident on, or jump right to a feature that really interests you, or go back and review topics that were already covered. Simply click on a course section to expand its contents and then select an individual slide. However, note that by default we will automatically walk you through the entire course without requiring you to use the outline. Standard Flash player controls are also found at the bottom of the player, including pause, previous, and next buttons. There is also an interactive progress bar to fast forward or rewind the current slide. Interactive slides may have additional controls and buttons along with instructions on how to use them. Also found at the bottom of the player is a panel containing any additional reference notes for the current slide. Feel free to read these reference notes at the conclusion of the course, in which case you can minimize this panel and restore it later. Or if you prefer you can pause and read them as we go along. Various handouts may be available from the Attachments button, including the audio narration scripts for this course. The course will now pause, so feel free to take some time and explore the interface. Then when you’re ready to continue, click the next button below or alternatively click the Module 1 slide in the course outline at left. Course Objectives So what can you expect to get out of this course? This course introduces you to Oracle BPEL Process service component in Oracle SOA Suite 11g. It does not attempt to provide every detail about a feature or cover aspects of a feature that were available

Page 2: BEPL narration script

in previous releases. This course does not serve as a general introduction to the broad set of Oracle BPEL features and functionality. This course is most useful if you have prior hands on experience with a previous release. For broad or detailed information about the entire range of functionality refer to the documentation and Oracle University courses for Oracle SOA Suite 11g. After completing this course, you should be able to:

• Create a composite application in Oracle SOA Suite 11g by using the BPEL Process service component

• Orchestrate services in a composite application • Implement coordination of services • Manage transactions in a BPEL process

Course Road Map This course consists of five modules

• BPEL New Features in SOA Suite 11g • Creating a Simple BPEL Component • Orchestrating Services • Implementing Coordination • Managing Transactions

This module is specifically designed for that audience who have prior experience in working with Oracle SOA Suite 10g, and is only interested in knowing the new features of BPEL in Oracle SOA Suite 11g. If you are totally new to BPEL and have no prior experience of Oracle SOA Suite 10g, you are suggested to start with the next module that explain what are the different concepts in BPEL and how you go about creating a composite application by using the BPEL Process service component in Oracle SOA Suite 11g. This module highlights some of the new features and enhancement in BPEL in Oracle SOA Suite 11g. Module Topics This module covers the topics:

• Identify the new features in BPEL for Oracle SOA Suite 11g • Identify changes and enhancement to BPEL in Oracle SOA Suite 11g as compared to Oracle

SOA Suite 10g New Component Model In Oracle SOA Suite 11g, the BPEL Process service component conforms to the SCA component specifications and is implemented, assembled, and packaged as an SOA composite application. Oracle SOA Suite 11g enables a BPEL Process to access an SDO through an Entity Variable that is a special type of BPEL variable associated with a SDO as a service. Oracle ADF-BC components can be deployed simultaneously as Web Service and an SDO. In Oracle SOA Suite 11g, all the service components are managed and administered by using the Oracle Enterprise Manager Fusion Middleware Control console

Page 3: BEPL narration script

New Features and Enhancements Some of the additional new features and enhancement in BPEL in SOA Suite 11g are:

• New WSIL Connection to access WSDL for Partner Links • Fault Management Framework across BPEL and Mediator • Support Event Delivery Network and publishing and subscribing to Events • Oracle Application Development Framework (Oracle ADF), which is integrated with Oracle

JDeveloper, enables you design Task Display Forms that display task information and parameters received from a Human Task in a SOA composite application. The ADF-based Task Display Forms can be generated from the Human Task activity in a BPEL process.

• Enables support for User Messaging Service and related BPEL notification activities, such as Email, IM, Voice, and SMS activities. Oracle User Messaging Service enables two-way communication between users and deployed applications. Messages can be sent and received through Email, IM (XMPP), SMS (SMPP), and Voice.

• BPEL testing and debugging with Test Suites have been moved to composite level. New BPEL Activity Types and Attributes Some of the new BPEL activities in SOA Suite 11g are:

• The business rule activity that replaces the Decide activity in SOA Suite 10g to invoke the business rules

• Signal and Receive Signal activities that enables the master detail process co-ordination. The

signal activity is used in a master process to notify detail processes to perform processing at runtime and used in detail processes to notify a master process that processing has completed. The receive signal activity in detail processes to wait for the notification signal from the master process to begin processing and use in a master process to wait for the notification signal from all detail processes indicating that processing has completed.

• The phase activity creates Oracle Mediator and business rules service components for integration with a BPEL process

• The create entity, remove entity, and bind entity activities are used to work with entity variables BPEL Deployment Descriptor Properties Changes to BPEL deployment descriptor properties are now added to the composite.xml. There are two types of BPEL deployment descriptor properties:

• Configuration properties, which are specific properties used by the BPEL Engine, Enterprise Manager , or both. The server provides some predefined configuration properties.

• Partner link binding properties, which are used by BPEL process designers to externalize literal values from a process. For example, you may define a minimum credit rating that a customer must have before processing the order. You define partner link binding properties in the Properties tab of the Edit Partner Link window.

The illustration shows configuration properties called inMemoryOptimization being defined at design time by using JDeveloper BPEL Editor. Properties are saved as name–value pairs in <property> elements in the deployment descriptor, which is stored in the composite.xml file that is packaged in the SOA Archive Introduction to Oracle Enterprise Manager Fusion Middleware Control Oracle Enterprise Manager Fusion Middleware Control is the primary tool for managing, monitoring, and configuring the SOA run-time environment and components.

Page 4: BEPL narration script

By using the Fusion Middleware Control, you can perform tasks such as: • Deploying and undeploying composite applications • Managing the run-time state of composite applications • Shutting down and restarting composite applications • Initiating tests of SOA applications by using a Web-based service testing tool • Tracking and monitoring composite application instances and message flows through a

composite application • Examining and managing application fault conditions • Monitoring component engines

The slide shows a sample HelloBPEL process visual flow in the Oracle Enterprise Manager Fusion Middleware Control console. Click an activity icon to view the activity details. The following screen displays the payload data and the activity state. Overview of the Fault Management Framework Oracle SOA Suite 11g provides a generic fault management framework for handling faults in composite applications containing Mediator and BPEL components. If a fault occurs during run-time when a service is invoked, the fault management framework can be configured to catch the fault and performs a user-specified action. The fault management framework provides an alternative to designing Mediator fault routings or a BPEL process with Catch branches in Scope activities. User-defined fault policies are defined in a fault policy file that can be associated with the component or an activity. Using a policy binding file you can assign fault conditions with fault actions, such as specifying human intervention as a prescribed action. In such a case, you perform recovery of human intervention actions by using the Oracle Enterprise Manager Fusion Middleware Control. Module Review In this module, we covered the new features and enhancement in BPEL in Oracle SOA Suite 11g. Module Topics This module covers the topics:

• Create a BPEL component in the Composite Editor • Explain the BPEL process template types • Implement a simple BPEL process component • Structure a BPEL Process with Scope activities • Explain BPEL global and local variables • Copy XML data with Assign and Transform activities • Create copy operations in an Assign activity • Create and configure a Transform activity

Business Process Execution Language (BPEL) First let us understand what a BPEL Process is all about. Business Process Execution Language, called BPEL, is:

• A markup language for orchestrating services into an end-to-end process flow

Page 5: BEPL narration script

• A model of the behavior for both an executable and abstract process • Executed by a BPEL engine that can processes the BPEL XML source • Is an OASIS standard called “Web Services Business Process Execution Language” (WS-

BPEL) WS-BPEL is intended for as a language for modelling the behavior of both executable and abstract processes. The origins of BPEL can be traced to Web Services Flow Language (WSFL) and XLANG (a name of a language not an acronym), which is an XML-based extension of Web Services Description Language (WSDL). Oracle BPEL Process Manager supports all the WS-BPEL v1.1 features and most of the WS-BPEL v2.0 semantics. Parts of a BPEL Process The key elements of a BPEL process are:

• A service interface, that is the WSDL describing the BPEL process operation and associated request and optional response message structures. Therefore, a BPEL process can be exposed as a service for a composite application. The service interface provides the BPEL client with a way to interact with the BPEL process component.

• Activities, which are the actual XML elements that make up the BPEL process flow or sequence of instructions to be executed. This usually involves invoking other services to perform the function required for a business process implementation.

• Partner links, which represent a reference to external services that are invoked by BPEL process activities. In the JDeveloper Composite Editor, when you wire a BPEL process component an external (service) reference a partner link is created in the BPEL process component.

Activities and partner links are created as XML elements in source file for the BPEL process. Synchronous Process Concepts A synchronous BPEL process:

• Contains activities that should not take a long time, because the client waits for the response • Obtains the request with a Receive activity • Returns the response with a Reply activity

The graphic illustrates the simple design of the HelloBPEL synchronous BPEL process. Therefore, the process should be short-lived and send a response (a reply) to its invoker as soon as possible. When you create a synchronous BPEL process, Oracle BPEL Process Designer automatically creates a BPEL process template with a Receive activity as the first activity and ends with a Reply activity. You create additional processing tasks between the Receive and Reply activities. The sequence of activities in the HelloBPEL process design is the following:

• Receive request XML message, containing a name string, input from the client or invoker of the BPEL process.

• Assign the text "Hello " concatenated to the name string received as input to the result message. • Reply with the result XML message, which is the output data that is sent to the client in

response. The BPEL language is an XML structure and provides XML functions that can perform operations such as concatenation, by using the built-in concat string function

Page 6: BEPL narration script

Asynchronous Process Concepts An asynchronous BPEL process:

• Contains activities that may take some time, and optionally return a response to the client • Obtains the request with a Receive activity • Returns an optional response with callback implement with an Invoke activity

The basic structure of an asynchronous BPEL process flow, as created by Oracle JDeveloper Create BPEL Process wizard, comprises the following items:

1. A Receive activity at the start of the flow 2. An Invoke activity at the end of the flow

Oracle BPEL Process Manager automatically manages the correlation between the clients of the invoked process by using WS-Addressing techniques. This enables a long-running process to invoke the client when the process is complete. The final invoke operation is named a callback. The client should not have to wait for an asynchronous process to complete before it responds and must provide a way for the invoked process to call it back to obtain the result (response) from the process. Describing the BPEL Design Editor You see the Oracle JDeveloper 11g integrated development environment with its different sections:

• The application navigator displays the process files of a SOA project. Key files include the following:

o composite.xml that describes the entire SOA composite application. o HelloBPEL.bpel that depending upon the process type you selected, initially contains a

minimal set of BPEL activities. For example, if you selected to create an asynchronous process, then receive and invoke activities appear. You add syntax to this file when you drag activities, create variables, create partner links, and so on.

o HelloBPEL.componentType describes the services and references for the BPEL process service component.

o HelloBPEL.wsdl is the Web Services Description Language (WSDL) client interface, which defines the input and output messages for this BPEL process flow, the supported client interface and operations, and other features. This functionality enables the BPEL process flow to be called as a service.

• The Structure panel provides a structural view of the data in the BPEL process service component currently selected in the designer. You can perform a variety of tasks from this section, including:

o Importing schemas o Defining message types o Managing (creating, editing, and deleting) elements such as variables, aliases,

correlation sets, and partner links. o Editing activities in the BPEL process flow sequence that displays in the designer

• The BPEL editor toolbar contains icons that perform various actions, such as validating the BPEL process, navigating to the Composite Editor, and others.

• You see the JDeveloper BPEL Editor with a visual representation of the process diagram in the Design tab page. The BPEL editor window also has a Source tab to view and edit the BPEL XML source created visually in the Design view, and a History tab to view historical changes. The Source tab shows the raw XML source element hierarchy.

Page 7: BEPL narration script

• The Design tab page is divided into three main swim lanes: o The left-hand Partner Link swim lane contains the BPEL process service interface that

client's applications or components use to interact with the BPEL process component. o The right-hand Partner Link swim lane contains external services references. o The middle swim lane contains the BPEL process activities forming the process flow.

• The Component Palette contains Displays the available activities to add to the BPEL process service component. Activities are the building blocks. The BPEL Activities selection of the Component Palette displays a set of activities that you drag into the designer of the BPEL process service component. The Component Palette displays only those pages relevant to the state of the designer. BPEL Activities or BPEL Services are nearly always visible. However, if you are designing a transformation in a transform activity, the Component Palette only displays selections relevant to that activity, such as String Functions, Mathematical Functions, and Node-set Functions

• The Property Inspector shows properties for a subset of selected objects. • The Log windows display messages about the status of validation and compilation. To ensure

that a BPEL process service component validates correctly, you must ensure that the following information is correct:

o The BPEL process service component must have an input variable. o A partner link must be selected. o A partner role must be selected. o The operation must not be empty. o The input variable type must match the partner link operation type.

If deployment is unsuccessful, messages appear that describe the type and location of the error.

Creating a BPEL Component To create a SOA composite application in Oracle JDeveloper 11g with the BPEL Process service component:

1. In the JDeveloper Application Navigator, click New Application. 2. In the Create SOA Application - Step 1 of 3 screen, enter the application name and the

application directory and click Next. 3. In the Create SOA Application - Step 2 of 3 screen, enter the project name and select the project

technologies as SOA. Click Next.

There are two ways to create the BPLE component: 1. Select Empty Composite and double-click the composite.xml 2. On the Component Palette, drag a BPEL Process component into the Components column of

the Composite Editor for the application. 3. Its shows the Create BPEL Process dialog box, where you can select the BPEL process

Template type that defines how it interacts with its clients, its input and output message structures derived from an XML schema.

Similarly if you select "Composite With BPEL" option from the Composite Template, it directly takes you to the Create BPEL Process dialog box. Describing BPEL Process Templates You can create a BPEL process by selecting a specific BPEL Process template. The Template selected:

Page 8: BEPL narration script

• Defines the style of process interaction with its client • Determines the initial process skeleton structure

You can choose a template by selecting the appropriate template type: Asynchronous BPEL Process: Is the default, which populates the BPEL process with an initial Receive activity and a final Invoke (callback) activity forming the basic structure of an asynchronous process. Choose Asynchronous for a process that will take a relatively long time to process to completion. The client will eventually require and wait for a response, but not expect it straight away. The BPEL process returns a callback response with an Invoke activity Synchronous BPEL Process: Creates a BPEL process that includes an initial Receive activity and a final Reply activity to form the basic structure of a synchronous process. Choose Synchronous for a process that will be quick to respond with a result, or if it needs to participate in the client’s transaction. The client will wait for a response. The BPEL process returns response with a Reply activity One Way BPEL Process: Creates a BPEL process that includes only a Receive activity. Choose One Way for interactions that will not respond to the client. The client will not wait for any response (but will accept a response if one does happen to come back to it). Similarly the Based on a WSDL template type creates a BPEL process with an interface defined by a WSDL file The Define Service Later template creates an empty BPEL process with no interface definition. The interface definition can be defined at a later time. Designing the BPEL Process The BPEL process design involves considering the implementation requirements from the perspective of the client that will interact with the process, and the way the BPEL process orchestrates (interacts) with external services. When designing a BPEL process:

• Honor the interface definition (the service contract) and business requirements. This includes choosing:

o The interaction style: Synchronous, one-way or two-way asynchronous o A naming convention for the operations, input and output messages as well as associated

XML namespaces to ensure uniqueness across all services • Create XML Schema (XSD) for message structures first. It is easier to create a BPEL process

after having first created the XSD defining the message structures to be used • Consider using Scope activities to group related activities and manage BPEL variable life time • Drag and drop appropriate activities from the Component Palette into the diagram to create the

implementation for the desired process flow. • Provide access to the portfolio of services, and their related artifacts (XSD, WSDL), to be

orchestrated. Usually this is done through a Service (UDDI) Registry, Enterprise Repository, or other means such as WSIL browsers (if supported by WSIL files and servers

Constructing a BPEL Process Constructing your BPEL process is done graphically by dragging items from the BPEL Component Palette to their appropriate location and sequence in the middle swim lane of the process diagram. For

Page 9: BEPL narration script

example: 1. The Assign activity, which is used to copy XML data contained in one BPEL variable to

another, is dragged into the process flow. Process message data, held in BPEL variables, is communicated between the BPEL process and services it invokes. Data in variables can be shared among process activities whose scope allows them to see the variables.

2. A Partner Link Service component, which represents a link to a service, is dragged into one of the Services swim lanes from the Services list in the Component Palette (not shown).

If you click the Source tab, you can view and edit the BPEL XML source generated by the graphical design changes that you make in the Design view. In this way, you can edit the Design or Source and they are synchronized. Classification of BPEL Activity Types BPEL Activities are the building blocks of a BPEL process service component. Oracle BPEL Designer includes a set of activities that you drag into a BPEL process service component. You then double-click an activity to define its attributes (property values). Activities enable you to perform specific tasks within a BPEL process service component. Activities are defined as Basic, Structured, or Extension (see the next page) activities, which are subdivided into functional groups. For example, here are several key activities:

• Activities for Invoking and Providing Web Service Operations o Receive Activity: Waits for an initiating message or asynchronous call-back response

message from a service o Invoke Activity: Enables you to invoke a service (identified by its partner link) and

specify an operation for this service to perform o Reply Activity: Allows the process to send a message in reply to a message that was

received through a Receive activity • Activities for Updating Variables and Partner Links includes:

o Assign Activity: Manipulates XML data, to copy the contents of one variable to another o Transform Activity: Processes an XSL Transformation that maps source elements to

target elements that update variables. • Activities for Fault and Error Handing includes:

o Throw Activity: Generates a fault from inside the business process o Compensate Activity : Executes a compensation handler, containing a sequence of

activities executed, to reverse the results of a fault scenario o Catch Activity : enables you to trap a name (specific) fault or error condition o Catch All Activity: enables you to catch unnamed (non-specific) fault or error

conditions • Activities for Delayed Execution include the Wait activity that allows a process to specify a

delay for a certain period of time or until a certain deadline is reached • Activities for Termination include the Terminate activity that enables you to end the tasks of an

activity (for example, the fault handling tasks in a catch branch) • Activities for Doing Nothing include the Empty activity that provides a no-operation activity.

Useful for inserting sensor points for monitoring business activity or when a fault needs to be caught and suppressed.

Classification of BPEL Activity Types The Structured Activities provides a variety of flow control activities that includes:

• The Scope activity that 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

Page 10: BEPL narration script

“coding block” in a structured programming languages. • The Sequence activity that contains a collection of activities to be performed in sequential order • Specifying the Conditional Behavior by implementing the Switch activity. The switch activity

consists of an ordered list of one or more conditional branches each defined in their own • <case> branch, followed optionally by an <otherwise> branch. • Activities for Repetitive and Parallel Execution tasks include:

o The While Activity that supports repeated performance of a specified iterative activity. The iterative activity is repeated until the given while condition is no longer true.

o The Flow activity that executes two or more branches of activities in parallel (concurrently)

o The FlowN activity that executes N branches of the same set of activities in parallel. The number N is defined at run time based on the data available and logic within the process.

• Activities for selective event processing includes the Pick activity that provides a way to wait for the occurrence of a set of events, such as a message (onMessage branch) arriving or a timeout condition specified by an alarm (onAlarm branch). Only one of these events will be acted on by a sequence of activities to handle the event.

Oracle BPEL Extension Activity Types The BPEL specification allows vendors to create extended (or extension) activities. Extension will execute in any Oracle SOA environment and not in other vendor SOA implementations. Oracle Extension Activities can be classified as follows:

• The Human Workflow that includes the Human Task activity: The Human Task component is also a Scope activity which contains basic activities such as Assign, Invoke, an Receive activities for interaction with the task manager services built into the SOA run-time.

• There are also activities for Process Coordination that includes: o The Signal activity that notifies the other processes (master or detail) to continue

processing o The Receive Signal activity that waits until it receives the proper notification signal

from the other process (master or detail) before continuing its processing • Activities for notifying the concerned participants includes:

o The User Notification activity that enables the user to select notification channel used at run-time based on preferences defined by the end user in the User Messaging Preferences interface of the Oracle User Messaging Service. If the channel is not specified email is used by default.

o The Email activity that provides a way to send an email notification about an event o The IM activity that is use to produce instant message by using an IM service provider o The Voice activity that sends a telephone voice message as a notification to a user and o The SMS activity that sends a short message system (SMS) notification to a mobile

device • Activities for executing business rules include the Business Rule activity. The Business Rule is

a Scope activity that contains several basic activities such as Assign and Invoke activities required for interaction with the Business Rule engine to provide fact data for business rule execution and obtain the result facts.

• The Data Object Interactions activities include: o The Create Entity activity that is used to create a data row in a data source from data

Page 11: BEPL narration script

stored in an Entity Variable associated with a Service Data Object (SDO). o The Bind Entity activity that is used to query a data row by its unique ID from a data

source into an Entity Variable associated with an SDO o The Remove Entity activity that is used to delete a data row in a data source through an

Entity Variable associated with an SDO • Some of the other Miscellaneous activities include:

o The Java Embedded activity that enables you to add custom Java code to a BPEL process using the Java BPEL exec extension

o The Phase activity that is used to create a two-layer business process management (BPM) sequence that enables a dynamic business processes whose execution depends on elements of the context in which the process executes.

Structuring a Process with a Scope Activity A scope activity provides a container and a context for other activities. A scope provides handlers for faults, events, compensation, data variables, and correlation sets. Using a scope activity simplifies a BPEL flow by grouping functional structures. This grouping allows you to collapse them into what appears to be a single element in Oracle BPEL Designer. Therefore, a Scope activity:

• Groups related activities into a container • Manages BPEL process complexity • Determines BPEL variable life time (scope)

The graphic shows how to create the scope activity. A scope enables you to manage events within the scope by defining:

• Variables: By default, asynchronous and synchronous BPEL projects are created with two global variables called inputVariable and outputVariable, respectively.)

• Partner links • Fault handlers:

o The catch activity works within a scope to catch faults and exceptions before they can throw the entire process into a faulted state. You can use specific fault names in the catch activity to respond in a specific way to an individual fault.

o The catchAll activity catches any faults that are not handled by name-specific catch activities

• Message handlers • Alarm handlers • Compensation handlers

Adding Activities to a Scope Activities can be added to a scope from:

• The Component Palette • The BPEL Diagram

After dragging a Scope activity into the BPEL Design: 1. Click the Expand (+) icon to expand the Scope activity 2. Drag another activity, such as the Assign activity, from the Component Palette into the body of

the scope. 3. Alternatively, select and drag existing activities within the BPEL process diagram to the Scope

activity.

Page 12: BEPL narration script

Configuring a Scope Activity To configure a Scope activity, double-click the Scope activity, or right-click the Scope and select Edit, to edit the scope Name in the General tabbed page, add Correlation Sets, Sensors, Annotations, Partner Links, and Variables local to the scope. Configuration of scope components such as fault handlers (Catch or CatchAll branches, onMessage and onAlarm branches, and so on) can also be added using the shortcut menu displayed when you right-click the Scope activity. Alternatively, after expanding the Scope activity, you can add components to the scope by clicking the icons on the left of the expanded scope. BPEL Variables Now lets talk something about the BPEL variables. A BPEL variable:

• Maintain data for process activities and communication with other services. • Hold current process state and exist for the duration of the global (process) or local scope in

which they are declared • Type is derived from built-in data type, XML element, or WSDL message type.

A BPEL process provides a Scope activity, which may contain variables, activities, and other constructs. The main BPEL process is in a scope referred to as the main process scope. Variables added to:

• The process scope are called global variables, which are visible to all activities within the BPEL process and are present for the lifetime of the process

• Nested scopes are called local variables, which are visible to activities within their own scope, and are discarded when the scope ends

The BPEL variables are assigned data type that determines its structure and memory (size) requirements. Variable types can be derived from:

• A built-in data type, such as string, Boolean, among others • An XML element type, defined in XML Schema documents • A message type, defined in imported or inline XML Schemas of a WSDL document

It is best practice to keep common element type definitions in a centralized XML Schema document to enable sharing across cooperating services. Creating Variables and Importing Types Now lets try to create a variable and set the message type based on a message from a WSDL file imported into the project. To Create a BPEL variable:

1. On the JDeveloper Structure window, expand the Variables tree and select a Variables folder for the Process (scope) or a named Scope (if any exists), and click the “Create An Object of the Selected Node” (green plus) icon. The Create Variable window opens.

2. On the Create Variable dialog box, enter a Name and select a Type as a Simple Type, Message Type, or Element. For input and output messages used in an invoke activity operation you should select the Message Type and click the Browse (flashlight) icon.

3. On the Type Chooser window, expand the tree to locate the desired message type from Partner Link WSDLs or WSDL files in the Project. If the message type required is not present in the project, then click the Import WSDL icon, and in the Import WSDL File window enter the URL or browse for the WSDL file and click OK. Similarly, you can also click the Import Schema icon, and in the Import Schema File window enter the URL or browse for the schema

Page 13: BEPL narration script

file and click OK 4. On the Type Chooser window, select the message structure for the variable and click OK. The

Create Variable window field is populated with the selection, and you can click OK to close the Create Variable window.

5. The Type Chooser window, enables importing XML Schema (XSD) files for Element types. Assigning or Copying Data to Variables Now let us look into assigning or copying data to variables. In a BPEL process, data can be copied between variables with:

• The Assign activity, with one or more copy operations • The Transform activity, with a XSL Transformation applied to copy the data

The reason for copying data is to extract information to be examined or operated on, or copy the data to another structure that is used for a request to another service. BPEL variables, which are similar to variables in any programming language, are containers whose contents can change over time. It is important to note that the Transform activity is implemented as an Assign activity that executes a transformation function. In addition, changes to data in variable can arise from other sources, such as, receiving results from a decision service (Oracle Business Rules), changes to payload data supplied to a Human task (workflow), and receiving responses from invoked services. The table compares Transform with the Assign activity. In essence they are the same type of activity. You could easily create an Assign that uses the ora:processXSLT function. However, this is more manual work that does not provide a visual way to define the mappings, unless you have already created the XSL file using the XSLT Mapper. If you require a transformation, because the source and target data structures are complex and require complex mapping, it is much easier to use the Transform activity and the associated design-time visual mapping capabilities inherent in the XSLT Mapper. For simple copying of source to target data structures, an Assign activity, with a small subset of copy operations, provides a better alternative. An Assign with less than 10 copy operations is a guideline only. Ultimately it is a trade-off between the development and maintenance time, and the execution time. Creating an Assign Activity How to create an assign activity? The Assign activity is one of the ways you can copy data from a source to a target in a BPEL process. An Assign activity:

• Copies data from a source to a target • Data can be:

o A BPEL variable, which can supply an entire XML document, an XML fragment, or specific XML elements to be copied

o Expressions o An XML fragment, which provides a literal XML structure to be copied o A Partner Link, which supplies the XML data to be copied

Page 14: BEPL narration script

• An Assign activity can contain one or more copy operations • It Inserts the <assign> element in the BPEL source

You see the graphical representation to add an assign activity within the BPEL workflow in the BPEL editor. Targets can be variables that contain new or different data structures, using basic types or XML structures, and Partner Link. Therefore, an assign activity copies data between variables, and also can be used to copy expressions. An Assign activity may contain one or more copy operations. Additional copy operations can be used copy data from and to different locations in the same activity. Configuring an Assign Activity How to configure the assign activity? By right-clicking the Assign activity and selecting Edit, you can configure the activity and its operation. By default, double-clicking an activity performs an Edit action on that activity. Use the General tab to alter the name attribute value for the Assign activity element. The Copy operation tab enables you to perform different copy, append, remove, and rename operations. You use the:

• Copy Operation for a simple copy or assignment operation • Append Operation to append the source data to the target • Insert-After Operation to add data after the target • Insert-Before Operation to add data before the target • CopyList Operation to copy a list of elements from the source to the target • Remove Operation to remove elements from the target • Rename Operation to rename (restructure) elements in the target

Use the Edit and Delete icons to modify or delete an existing copy operation, respectively. By using the Up or Down icons, you can rearrange the execution order of each copy operation. The top-most copy operation is executed first. Creating Copy Operations How to create a copy operation? Double-click the assign activity to open the Assign dialog box and click the Copy operation tab. Click the Add icon and select Copy Operation. In the From section, you can select the source of data as:

• Variable • Expression • XML fragment • Partner Link

The To section defines the target of the copy operation. As shown in the slide, the target is likely to be another BPEL variable or a Partner Link. You see the new copy operation created. Similarly you can add a number of copy operations for a single assign activity. Creating Expressions with the XPath Expression Builder You can create expressions by using the XPath Expression Builder. In the From section of the create copy operation window, you select the source of data as Expression and click the XPath expression builder icon. In the XPath Expression Builder, to build the expression you can combine:

• Typing the text as shown in the Expression field • Selecting the BPEL Variables and Functions and clicking Insert Into Expression

Page 15: BEPL narration script

In the HelloWorld example, the XPath expression is passed as a parameter to a built-in function getVariableData that extracts the data from the input element contained in the message payload part of the inputVariable. The getVariableData function and its parameters are supplied as the second parameter to the concat function. The result is that the string value in the input is appended to the text "Hello ". In the example:

1. The concat function is added by double-clicking the entry in the String Functions list. 2. The area between the brackets is selected, and "Hello " and a comma are entered. 3. The cursor is placed after the comma, client:input is selected from the inputVariable tree, and

Insert Into Expression is clicked. Working with the XPath Expression Resolver Alternatively, in an expression field you can press Ctrl and Space key to display a list of choices for the context of the expression being constructed. Oracle BPEL Process Designer displays a list of choices suitable for the expression where the cursor is positioned. Select the best option and continue to build the expression using the XPath Expression Resolver, enter the expression text, or switch back to the XPath Expression Builder. Transforming Data in a BPEL Process Now lets talk about Transforming Data in a BPEL Process. Transformations in BPEL:

• Enables converting one document format to another • Simplifies copying large and complex data structures • Uses JDeveloper design-time XSLT Mapper

A BPEL process can use transformation services for: • Simplifying the task of copying a large and complex data between BPEL variables with

different XML constructs • Converting XML structures into request structures for invoked services, and responses returned

from invoked service The graphic shows the design-time components. A BPEL Transform is created from which the XSLT Mapper is opened to create an XSL file. The XSL file defines the mapping rules for converting elements from a Source-def.xsd to a Target-def.xsd . The BPEL run time shows the Transform.xsl file being used by the XLST processor to convert a source XML structure to a target XML structure, whatever the context in which it is used in the BPEL process. Creating and Configuring a Transform Activity Lets see how to create and configure a Transform Activity. To add transformation services to your BPEL process:

1. From the Component Palette, drag a Transform activity into your BPEL process. 2. Edit the Transform activity, by double-clicking it or right-click and select Edit. 3. Click the Create (green plus) icon for the Source , to select a variable and part in the Source

Variable window defining the input message structure . Select the Target Variable and its message part defining the output XML structure

4. Create, select, or edit a Mapper File containing the XSL Transformation rules. The example shows clicking the Create Mapper File (green plus) icon to created open the XSLT Mapper to create the transformations.

The source and target message structures are obtained from the BPEL variable message part type

Page 16: BEPL narration script

definitions. The XSLT Mapper is a visual design tool that provides a rich set of features to enable simple and complex mappings to be specified. Module Review In this module, we covered:

• Create a BPEL component in the Composite Editor • Explain the BPEL process template types • Implement a simple BPEL process component • Structure a BPEL Process with Scope activities • Explain BPEL global and local variables • Copy XML data with Assign and Transform activities • Create copy operations in an Assign activity • Create and configure a Transform activity

Next, answer a series of simple questions to make sure you are ready to move on. (Quiz) Module Topics Welcome to module two. This module covers the topics:

• Describe conditions for business process orchestration • Provide and access services from BPEL • Create and configure a Partner Link • Invoke a service synchronously and asynchronously • Perform conditional branching by using a Switch activity • Add and configure cases for conditional branching

Orchestrating Services from BPEL In the context of BPEL orchestrating services means:

• Coordinating communication of appropriate information with services identified by partner links by:

o Invoking one or more service operations with request data o Receiving responses from services, where applicable

• Managing the flow of process, request and response data In Oracle SOA Suite 11g, a BPEL process is a component of an SOA composite application, which receives and returns data through service entry points. The service entry points can be wired to a BPEL process component that processes the data and interacts with external references (external services) of the composite application. The external references used by the BPEL process component are seen as partner link elements in the BPEL process. A partner link can be thought of as a link or reference to exposed interface (WSDL) for an external service. When you create a Partner Link in a BPEL process component, an external reference that is wired to the BPEL process is added into the associated composite.xml file. When you wire a BPEL component to an external reference in the Composite Editor a corresponding Partner Link is added to the BPEL process design.

Page 17: BEPL narration script

Partner Links and Service Invocation A BPEL processes can be invoked by clients (composite components, client applications) through the WSDL interface exposed through the BPEL process client partner link. While the main purpose of a BPEL process is to invoke other services, the BPEL process requires a way to be initiated. The client partner link defines a reference to the WSDL document for the BPEL process to enable clients to invoke the BPEL process. A receive activity is used to specifies the partner link from which to receive information and the port type and operation for the partner link to invoke. To execute operations of another service, the BPEL process must have a reference to the target service. The reference to a service is added as a partner link (in a <partnerLink> element) in the BPEL source. A partner link maintains the reference to the location of the service endpoint, which is obtained from the service WSDL. A BPEL Invoke activity is used to initiate the external service from a BPEL process. The Invoke activity is configured with the operation to be executed, where the service operations are determined from the WSDL referenced by the partner link. When configuring a Partner Link in JDeveloper you can locate service resources, such as the service WSDL by using:

• The SOA Service Explorer, which provides access to services in a composite application • The SOA Resource Browser, which provides access to services inside and external from the

composite application, such as accessing resources located in the Resource Palette. Partner Links, Partner Link Types, and Roles A BPEL process describes a flow of interactions between the process and others services. Each interaction represents a relationship between the BPEL process and invoked service through a role that each play in the interaction. To identify roles and relationships applicable in an interaction, a BPEL process uses a partner link and a partner link type. A partner link, defined in the BPEL source , describes the roles that the BPEL process and the invoked service play. Each role is associated with a Port Type (operation defined in the WSDL), which determines the message data structures they can manipulate in their respective roles. A partner link is configured with a name, a partner link type, and one role for synchronous interactions or two roles for asynchronous interactions. A partner link type, defined in a WSDL document, describes the possible interactions a service can perform, thereby characterizing the conversational relationship between two services by specifying roles for each type of interaction offer by the service. A partner link type defines one or two roles.

• One role indicates that the service can complete the conversation without a callback. • Two roles indicate that there is a requirement to receive a callback from the service.

A role is associated to a Port Type, defined in the WSDL of a service, which determines operation performed by the role and the message structure received in a request or returned as a response within the context of the conversation. Creating a Partner Link A partner link can be created in two ways:

• Wire the BPEL process to another component or external reference in the Composite Editor. In this case, Partner Link properties are defined with information obtained from the external service (or component) WSDL interface to which the BPEL component is wired.

• You also drag a Partner Link from the Component Palette into a Partner Link column in the BPEL Editor. The Create Partner Link window is opened enabling you to configure the

Page 18: BEPL narration script

properties, such as the name and the WSDL URL, for the service to be referenced. The Composite Editor and BPEL Editor synchronize the .bpel and composite.xml source files so that partner links in a BPEL process are shown as external references in the composite application. Changes made in either location affects the other. After you drag a Partner Link into the Design window the Create Partner Link window is opened for you to configure the Partner Link, which is discussed on the next page. Configuring a Partner Link The Create Partner Link window enables you to defined a service name and enter or browse for the WSDL URL of the service to be referenced by the partner link. The Create Partner Link window provides enables you to create or locate the service WSDL by clicking:

• The SOA Resource Browser icon, which opens the SOA Resource Browser window in which you can locate a WSDL from the File System, in the Application folders, or (Application Server, WSIL) connections in the Resource Palette.

• The SOA Service Explorer icon, to browse for a service within the same composite application, possible an external service reference created in the composite.xml

• The Define Service icon, to create and configure a JCA Adapter as a service The example shows steps to create a Partner Link for an external Web (SOAP) Service:

1. After dragging a Partner Link into the Design window, on the Create Partner Link window enter a name for the partner link, then click the SOA Resource Browser icon.

2. In the SOA Resource Browser window, you can select File system, Resource palette, or Application. The example in the slide shows the Resource palette selection, locate and expand the service folder from the list, and select the endpoint, such as DemoApplications-ValidateCreditCreditService-context-root, and click OK.

3. On the Partner Link Type window, click Yes to create the Partner Link Type information. 4. On the Create Partner Link window, the WSDL URL and Partner Link Type are populated. For

a synchronous interaction select a value for the Partner Role. For an asynchronous service also set the My Role value, and clicks OK to create the Partner Link.

Similarly, you can also use the SOA Service Explorer option to select the endpoint for a partner link. Invoking a Synchronous Service Now let's see how to invoke a synchronous service by using the Invoke activity. A service operation is executed by using a BPEL Invoke activity. The slide the steps to create an Invoke activity and configure it to execute a service operation through a Partner Link:

1. Drag an Invoke activity from the Component Palette to the process flow. 2. Click and drag the right arrow icon of the Invoke_1 activity to the Partner Link, and the Edit

Invoke window is opened. 3. On the Edit Invoke window, the Partner Link and Operation fields are populated.

a. Enter a name for the activity, such as Invoke_CC. b. Select the desired operation or accept the initial one supplied. c. Create or select Input and Output Variables for exchanging messages with the service

4. On the Create Variable windows, for the Input and Output variables enter or accept the variable name and choose the Global Variable option to create the variable in the main process scope, or Local Variable to create the variable in the local scope (if any).

Page 19: BEPL narration script

The input and output variable in the example are created by clicking the green plus icons next to their respective fields to automatically create the variables. Alternatively, you can click the flashlight icon browse for existing BPEL process or scoped variables with the correct element or message format for the target service. The benefit of using automatically created variables is the variable type is automatically derived from the WSDL definition of the service referenced by the Partner Link. Invoking an Asynchronous Service Invoking an asynchronous service is the same as invoking a synchronous service. The main difference is that Invoke is configured with an input variable and not the output variable, because Invoke behaves like a one-way operation and does not wait for a response. The steps to configure an Invoke activity for an asynchronous service are:

1. Dragging an Invoke activity in to the BPEL process. 2. Dragging the right-arrow of the Invoke activity to the Partner Link referencing the

asynchronous service. 3. On the Edit Invoke window, create or locate an input variable to supply request data.

An output cannot be supplied when invoking an asynchronous service. JDeveloper knows an operation is asynchronous when the WSDL does not supply an output message for an operation. In this case, the Output field is disabled and cannot be populated. Receiving a Callback Response If the asynchronous service returns a response at some time later you need to add a Receive activity to obtain the response data. The slide shows the steps to create and configure a Receive activity involve:

1. Dragging a Receive activity in to the BPEL process, somewhere in the process activity sequence after the initiating Invoke activity.

2. Dragging the right-arrow of the Receive activity to the same Partner Link referenced by the correspond Invoke activity for the asynchronous service.

3. On the Edit Receive window, create or locate the variable to receive the callback data. The operation must be selected from a callback port, the only variable supplied is for receiving the response message from the service.

When configuring the BPEL process uses the Receive activity to implement the callback and it automatically makes use of the WS-Addressing mechanisms provided by the BPEL Engine. A Receive activity is also used at the beginning of a BPEL process to receive the input for an operation that initiates the process. In this case, the Create Instance option must be selected so that the BPEL Engine will create a new instance for each message received. This option should not be set for Receive activities used to obtain callback response messages in asynchronous interactions. A Pick activity can receive one of several messages and provide a Create Instance option. You can see a typical asynchronous pattern being created. Conditionally Branching with a Switch Activity A conditional branch is a structure used to take different processing paths based on some condition determined by the data values passed between activities in the process. BPEL implements conditional branching with the <switch> element, represented by the Switch activity in the Component Palette. A <switch> element can contain:

Page 20: BEPL narration script

• One or more ordered <case> branches, each with a condition to be evaluated. Only one branch is executed; that is, the first <case> branch returning a true result is processed, and no other branch is evaluated.

• An optional <otherwise> branch, which is processed if no <case> branch is processed. This is useful for a generic implicit condition handler.

In JDeveloper, when you drag a Switch activity from the Component Palette to the Diagram view, the following two conditional branches are created:

• A <case> branch • An <otherwise> branch

You may add additional <case> branches, as needed. Double-clicking the <case> branch enables you to specify a comment and a Boolean expression to be evaluated for the branch. All conditional branches contain a sequence of activities that can be processed when the branch is selected for execution. Adding a Switch Activity To add a Switch activity:

1. In the Component Palette, drag a Switch component into the process flow. 2. Right-click the Switch activity and select Edit to set the Name property. Alternatively, right-

click and select Rename. 3. Expand the Switch to reveal its initial structure, which contains one <case> branch and one

<otherwise> branch. 4. Configure additional case branches, delete branches, configure conditions, and drop an activity

into each branch as appropriate. Each branch can have only one activity. Therefore, if you require more than one process step to be executed in a branch, add a Scope or Sequence activity as the first one in the branch. You can have only one <otherwise> branch, which is optional. Configuring Branches of a Switch Activity The slide highlights the icons that can be used to:

• Add a <case> branch to the Switch • Add an <otherwise> branch to the Switch. If an <otherwise> branch already exists, another will

not be added and JDeveloper displays a warning message • Create a condition expression for a <case> branch to evaluate a condition. To configure a case

condition: 1. Click the View Condition Expression icon in the <case> branch. 2. Click the XPath Expression Builder in the Condition window. 3. Construct the conditional expression in the Expression Builder.

For XPath expressions and conditions created in the XPath Expression Builder it is recommended that you use explicit type conversion where appropriate to avoid subtle problems that can arise from implicit type conversion in an XML context. For example, XML data is usually treated as string data and comparing two numerical strings performs a string based comparison that may not yield the intended result for a numerical value comparison. Module Review In this module, we covered:

Page 21: BEPL narration script

• Describe conditions for business process orchestration • Provide and access services from BPEL • Create and configure a Partner Link • Invoke a service synchronously and asynchronously • Perform conditional branching by using a Switch activity • Add and configure cases for conditional branching

Next, answer a series of simple questions to make sure you are ready to move on. (Quiz) Module Topics Welcome to module three. This module covers the topics:

• Implement parallel processing by using a Flow activity • Add and configure Flow activity branches • Implement nonblocking invocation with a Flow • Create parallel branches dynamically with a FlowN activity • Implement Pick with an Alarm and Timeout • Execute activities repetitively with a While activity • Describe basic exception handling

Processing Activities in Parallel Parallel flows implement processing of concurrent sequences of activities. In BPEL, the <flow> element implements the flow structure. A <flow> may contain one or more branches each with their own activity sequences that are processed simultaneously, that is, in parallel. Nesting one or more activity sequences within each branch of a Flow activity enables concurrent processing. Each activity sequence within a flow branch must be contained in a BPEL Sequence activity (a <sequence> element). A Flow activity can be nested in a flow branch. Flow branch activity sequences are specified at design time. At run time, a flow terminates when all flow branch sequences have completed. Activities in a BPEL <sequence> construct are processed sequentially. A synchronous Invoke activity in a flow branch causes the remaining flow branches to wait until the synchronous exchange is completed. This has the effect of serializing execution of flow branches. However, by setting the nonBlockingInvoke partner link binding property to true the Invoke activities are executed in separate threads. Oracle BPEL Process Manager can also execute a FlowN activity, which appears in the BPEL source in the <bpelx:flowN> element. The FlowN activity is an Oracle BPEL extension and not part of the BPEL specifications, and can be used to dynamically control the number of flow branches created at run time. The FlowN contains a single activity branch that is executed a specified number of times. Adding a Flow Activity The sequences, in a Flow activity, are statically defined during design time. The Component Palette contains a Flow activity. To add and configure a parallel Flow in your process, perform the following steps:

1. Drag a Flow activity into the BPEL Diagram.

Page 22: BEPL narration script

2. Click the Expand icon to view the initial Flow branch sequences. 3. Click Add Sequence (blue down-arrow) icon to the left of the Flow icon to create new branches.

You can delete a branch by selecting the branch and pressing Delete, or by right-clicking the branch and selecting Delete. To configure branch sequences with activities, drag existing activities in the process flow or from the Component Palette into each flow sequence, as required. Blocking Invoke Problem with Flows There can be certain specific blocking problems with the Flow activity. A flow activity with two branches where:

• One branch invokes a synchronous process, which uses a blocking invoke • The other branch invokes an asynchronous process, which uses a nonblocking invoke

In this case, the second branch is not executed in parallel because it waits for the synchronous (blocking invoke) to complete Implementing Non-Blocking Invokes The solution to the blocking invoke problem is to implement a non-blocking invoke for synchronous invocations by:

• Editing the Partner Link for the synchronous service. • Adding the nonBlockingInvoke property on the Properties tab page with its value set to true

The nonBlockingInvoke property value has a default value of false, in which case the invocation is executed in the same thread as the BPEL process instance. When this property value is set to true, a separate thread is spawned to do the invocation so that the invoke activity does not block the instance. The steps to add the nonBlockingInvoke property to a Partner Link are:

1. On the BPEL Designer window, right-click a Partner Link and select Edit. 2. On the Edit Partner Link window, click the Property tab and then the Create Property icon. 3. On the Create Property window, select the nonBlockingInvoke value from the Name drop-down

list, and click OK. 4. On the Edit Partner Link window, replace the text Property Value with the value true, and click

OK. Executing a Branch Multiple Times with FlowN The FlowN executes the same branch multiple times, in parallel. Configuring a FlowN activity requires setting the following properties:

• Name: To specify the activity name • N: To specify the number of branch sequences to execute. This can be set dynamically. • Index Variable: To choose or create a read-only branch index variable in expressions

At design-time a FlowN activity is configured with a single branch sequence, which can be executed a number of times. The number of times the FlowN sequence is executed is determined at run-time by setting the number dynamically. The diagrams illustrate the concept, such that:

• At design-time a single flow branch is created. The N property is set to derive its value from a variable named nbr, that is, the number of flow branches created is dynamically determined at run-time.

Page 23: BEPL narration script

• At run-time the nbr variable is set to a value of 4 before executing the FlowN. When the FlowN is processed the FlowN property N is set to the value 4 and the BPEL Engine dynamically generates four flow branches of the same sequence. The index variable (i) is initialized to one and automatically incremented by the BPEL Engine and can be read or used by activities in the flow to index XML array structures as appropriate to the needs of the process. The index variable cannot be modified by any activity in the branch sequence.

Creating and Configuring a FlowN Activity The slide illustrates the steps to create a FlowN activity:

1. Drag a FlowN activity from the Component Palette into the process flow. 2. Right-click the FlowN_1 activity, and select Edit, or double-click the FlowN activity. 3. On the FlowN window you set:

- The Name field, to change the activity name. - The N field, to create an expression to dynamically determines the number of times the

branch executes in parallel. A literal value can be specified. - The Index Variable field, can be populated with a variable name by clicking the

Automatically Create Input Variable (green plus) icon or the Browse Variables (magnifying glass) icon to pick an existing variable. Automatic variables are created in the current Scope. If you change the generated name, it must be manually renamed.

To configure the branch activities:

1. Expand the FlowN activity. 2. Drag other activities into the branch.

The FlowN index variable is initialized to one and increments by one for each Flow branch. This index variable cannot be modify within the branch. The index variable is useful for indexing elements in XML array structures in different flow branch iterations. Comparing Flow and FlowN The slide provides a table of comparisons between the Flow and the FlowN activities

Flow FlowN

Can execute different activity sequences in each branch

Executes the same activity sequence for each branch

Number of branches known and created at design time

Number of branches unknown at design time and determined dynamically at run time

Can work with different or same data Can use the index variable to access a different set of data for each branch

More suited to invocation of services specified at design time

More suited for dynamic service invocation where services invoked are determined at run time

Page 24: BEPL narration script

Index variables must be manually incremented (if used)

Index variable automatically incremented

Implementing a Pick Activity Let's talk about implementing a Pick activity. The Pick activity is an excellent technique to use to implement a Receive activity (wait for a message) with a timeout. This is accomplished by using both of the following:

• An onMessage branch to receive a specific message from an operation exposed by a service through a Partner Link

• An onAlarm branch that implements a wait time The Pick activity terminates when a message or an alarm event occurs, whichever occurs first. A Pick activity can be configured with multiple onMessage and onAlarm branches as needed for the context it is used. The slide shows the steps to create a Pick activity with one onMessage branch and one onAlarm branch:

1. Drag a Pick activity from the Component Palette into the BPEL process flow. 2. Expand the Pick activity. By default, a Pick activity contains one onMessage and one onAlarm

branch. You can delete them or add additional branches using their respective icons. 3. Drag and configure activities into the onMessage branch to handle the case when the specified

message arrives. In addition, you configure the onMessage branch with an operation in a Partner Link for a service, and create a variable to receive the data.

4. Drag and configure activities in onAlarm, and configure the onAlarm branch times. Looping with a While Activity A While activity continues to repetitively execute a single activity (or set of activities in a sequence or scope) if the specified condition is true. When the condition becomes false, the loop terminates. To add and configure a While activity, perform the following steps:

1. Drag a While component from the Component Palette to the process Diagram. 2. Click the View Condition Expression icon, and construct the conditional expression in the

Expression Builder. 3. Expand the While activity and drag another activity, sequence, or scope into the body of the

While activity. When working with a While activity, treat it as a traditional programming loop construct, such that you:

• Perform an initialization before the loop • Evaluate the condition before entering the loop • Execute the body of the loop if the condition is true • Increment or modify the variables that affect the condition, such as the example for using a

counter, as shown in the slide Suspending a Process with a Wait Activity You can suspend a BPEL process by using the Wait activity. The Wait activity pauses for a specified amount of elapsed time or until a specified date-time. The slide shows the configuration window for a Wait activity. You can use an expression to calculate the time period for which the process will wait or the time it waits until.

Page 25: BEPL narration script

Fault Handling Concepts The two parts to designing and managing faults with service-oriented applications are:

• Identifying and creating the fault • Managing and handling the fault

For identifying the cause of faults, you can use the following two general categories: • Business faults, which arise from problems with data or business logic in a service; for

example, when a social security number is not found in the database • Run-time faults, which can include problems within the Web service or its execution

environment. For example, when data cannot be copied because the variable structure is incorrect, or the system runs out of resources such as memory, or an external service is unavailable.

For managing and handling faults the client needs to know of the specific fault that can occur or be able to handle unexpected error conditions. Returning faults to clients of a service is implemented differently depending on the type of service interaction style:

• For a synchronous service, a fault can be returned as the response, instead of expected data. • For an asynchronous service, because a fault response cannot be returned as an immediate

response, the options are to return a fault message through the same callback operation as the normal response, or to use a different callback operation.

Describing Faults in BPEL Processes Faults that occur during BPEL process execution because of errors generated by invoked services, internal or system failure conditions can be handled and gracefully managed to create robust applications. Faults detected by a BPEL process may need to be returned to the process client, by using a technique dependent on the type of interaction. The types of faults defined for a BPEL process include:

• Standard faults, which are defined by the WS-BPEL specification. Some standard fault name examples are: bindingFault, conflictingReceive, invalidReply, remoteFault.

• Business faults, which are user-defined application-specific names generated by the BPEL process as a result of errors in the business logic or data, such as CreditLimitExceeded

• Run-time faults, which are caused by the errors detected in the BPEL process execution environment, known as system faults. For example: an endless loop, and SOAP faults.

BPEL provides the following components that can be used for fault management: • The Scope activity provides Catch and CatchAll branches as fault handlers. • The Throw activity provides a way to generate a user-defined (business) or system fault. • The Reply activity provides a way to propagate (return) a fault as a response to a client

Creating BPEL Fault Handlers Let's see how to create BPEL fault handlers. A Scope activity is a container for sequences activities in a process flow, and supports the following fault handlers:

• One or more Catch branches, each of which handle a fault identified by its Qname • CatchAll branch, which can handle any fault without knowing its Qname

Fault handlers in a Scope enable you to control how exceptions are managed within a BPEL process. Using nested Scopes, you can localize or propagate faults through the logical process hierarchical structure. The example shows a main scope that contains:

• An Assign activity • An inner (nested) scope, which has an activity that invokes the CreditService

Page 26: BEPL narration script

The inner scope defines a single Catch branch to trap the InvalidCard exception, and does not provide a CatchAll branch. However, the main scope provides the CatchAll fault handler. If the CreditService returns an InvalidCard exception, the inner scope Catch fault handler manages the error. However, if the CreditService service returns a different exception, such as CardExpired, the inner scope does not handle the exception. The CardExpired exception is propagated to the main scope CatchAll fault handler, which manages the exception. Catch and CatchAll Handlers Each scope, implicitly or explicitly specified, in a BPEL process provides the option of adding exception handling to the process to manage or catch error conditions. These are known as fault handlers in BPEL terminology and are enclosed in a <faultHandlers> element in the BPEL source code. A scope may have zero or more Catch branches. Each Catch branch is defined in a <catch> element, whose faultName attribute identifies the specific fault condition as handled, and whose faultVariable attribute specifies a BPEL variable for storing the fault message data. It might also have zero or one CatchAll branch to handle any fault condition that may arise The BPEL fault-handling semantics are the same as those found in object-oriented languages such as Java. That is, the first Catch branch that matches the fault message type is processed. If a fault message type is generated for which there is no Catch branch, then the fault can be handled by a CatchAll branch, if present. If no fault handler is present for an error condition, then implicit or default fault-handling rules of the BPEL Process Manager server are invoked. Handling Faults with a Catch Branch A Catch branch is a fault handler for named exceptions, identified by their Qname. To add a Catch branch to a Scope for a named fault:

1. Click the Add Catch Branch icon in which you want to handle the error. 2. Double-click the Catch icon, (or right-click the icon and select Edit) to edit the activity. 3. On the Catch window, enter the Fault QName or click the Browse (magnifying glass) icon. 4. On the Fault Chooser window, locate and select a system fault, or a named fault defined in

some WSDL file, and click OK. Faults in WSDL file are for synchronous operations. 5. On the Catch window, create or browse for a Fault Variable. This variable is optional, and

required if you wish to it to be populated with fault message information supplied by the process that generates a fault. This is not required if faults (such as standard fault) are being trapped, because standard faults do not have associated messages.

Handling Faults with a CatchAll Branch

1. In an expanded Scope activity, click the Add CatchAll Branch icon to create a fault-handler branch.

2. Expand the fault-handler branch. 3. Add activities to process the exception condition.

Module Review In this module, we covered:

Page 27: BEPL narration script

• Implement parallel processing by using a Flow activity • Add and configure Flow activity branches • Implement nonblocking invocation with a Flow • Create parallel branches dynamically with a FlowN activity • Implement Pick with an Alarm and Timeout • Execute activities repetitively with a While activity

Next, answer a series of simple questions to make sure you are ready to move on. (Quiz) Module Topics Welcome to module four. This module covers the topics:

• Describe Transactions with Services • Explain Transactional implications of Services • Describe a Service Data Object (SDO) • Manage Transactions with SDOs • Explain compensation handling within a BPEL process

Transactional Services A transactional service can be defined as:

• Any service that stores data using a database transaction • Any endpoint implemented by:

o A Java Web service that executes database operations o A Database Adapter service that executes statements or procedures performing Data

Manipulation Language (DML) o A JMS Adapter or AQ Adapter that sends messages to transaction-based services o A Service Data Object that operates on a database

From a simplistic perspective, a transactional service can be defined as any Web Service or Adapter service implementation that performs DML operations in a relational database, where the operations are subject to Atomicity, Consistency, Isolated, Durable (ACID) principles. With the Oracle SOA Suite 11g platform, a transactional service can be implemented as a Java Web service, a Database Adapter, a JMS Adapter, and the AQ Adapter—all of which can be invoked from a Mediator and BPEL components. The Service Data Object is used by BPEL through entity variables (see the pages titled “Service Data Objects” and “BPEL Entity Variables”). In all cases, transactional boundaries depend on the context, configuration, and environment of the services that are implemented and invoked. Transaction semantics are different for services that are invoked synchronously compared with services invoked asynchronously. Transaction Boundaries with Services Transactions boundaries depend on the type of interaction. Transactions:

• Start when a service is invoked (operation begins) • End when a service ends (operation completes) • Propagate across synchronous services, which can:

o Join an existing transaction o End the existing transaction o Propagate the transaction to another synchronous services

• Terminate when invoking an asynchronous service, which:

Page 28: BEPL narration script

o Ends or suspends the existing transaction o Starts a new independent transaction

Since SOAP inherently has no support for transactions, using SOAP binding methods causes the invoked service to be performed as an atomic transactional, that is, all operations must be performed by the service in an all-or-none mode Implementing Transactional Services Transactional enabled services are those that execute some SQL statements, either:

• Explicitly, through a Web Service application or a Database Adapter that executes SQL statements, or

• Implicitly, through a Service Data Object. In all cases, the assumption is a transaction is started and completed when a service operation is invoked, and depending on context and how the operations are invoked they may possibly join an existing transaction. Introducing the Service Data Object (SDO) The Service Data Object (SDO) specification defines a data programming architecture and an API for programmatically accessing data across different data source types. The main purpose of the SDO specification is to simplify data programming, which implies how applications access data irrespective of the source of data. SDO simplifies data programming by:

• Unifying access across different data source types, such as relational databases (RDBMS), XML, Web services, and Enterprise Information Systems through JCA adapters.

• Providing support for common application patterns • Enabling applications, tools and frameworks to more easily query, view, bind, update, and

introspect data. Key components of the SDO specification are:

• The Data Graph, which is a collection of disconnected data objects that may form a tree (graph) structure.

• The Data Object, holds the actual primitive data or references to other Data Objects. Data Objects reference their Metadata describing their structure to support data introspection.

• The Data Mediator Service (also called a Data Access Service), connects client applications to data sources.

Client applications query a Data Mediator Service and get a data object (and possibly a data graph) in response. Client applications send an updated data graph to a Data Mediator Service to have the changes applied to the underlying data source. Implementing an SDO with ADF While you can write your own Java classes that implement the SDO interfaces defined by the SDO specifications, you may find that creating an ADF-BC Application Module containing ADF-BC components easier, because the ADF Java components created already implement the SDO interfaces. To quickly create an SDO for a composite application, use the JDeveloper ADF-BC wizards to generate an ADF-BC Application Module based on a database table. The ADF-BC components created can be configured with a service interface and deployed as a Web service that can also be used as an SDO. Before you deploy the ADF-BC application you must create a Business Components Service Interface archive type so that the application can be deployed and referenced as a Web Service or accessed as an SDO. Therefore to implement an SDO with ADF:

Page 29: BEPL narration script

• Create the ADF-BC Application Module by declaratively generating components based on database tables.

o Create a Generic Project that uses the ADF Business Components technologies. o In the project, create ADF Business Components with the Business Components From

Tables item. • Configure the ADF Application Service Interface properties and set the data source in the

Configurations properties. • Create a deployment profile with the Business Components Service Interface archive type. • Deploy the ADF-BC Application Module to the SOA server

Accessing an SDO in a Composite Application To interact with an SDO in a composite application create the following components:

• An External (service) Reference to an ADF Business Component (BC) application deployed as a business service. The external reference must be wired to the BPEL process component to create a partner link for the service. It is important to note that the ADF-BC component application is deployed to the run-time environment in a Enterprise Archive (EAR) file created as a Business Component Service Interface archive type.

• An Entity Variable in the BPEL process. When an Entity Variable is defined you require the partner link associated to the ADF-BC service to complete the Entity Variable definition.

• An activity that uses the Entity Variable. The activities that use an Entity Variable are the Bind Entity and Assign, Create Entity, and Remove Entity activities. The Assign activity cannot be used with an Entity Variable unless the Entity Variable is associated with an instance of data by using a Bind Entity activity.

Creating an SDO Partner Link Assuming you have an application deployed as and SDO, such as an ADF-BC application, then you can create a Partner Link to the service in the same way as you normally create Partner Links in a BPEL process component. An ADF-BC service interface is exposed through a WSDL and therefore it can be treated as a normal Web Service and an SDO. To create the Partner Link:

1. On a BPEL Diagram window, drag a Partner Link from the Component Palette onto the Partner Link column. When the Create Partner Link window is displayed enter the endpoint URL for the ADF-BC application service interface (WSDL). As normal, you are prompted to create the Partner Link Types, which is generated by JDeveloper. After this you can select the Partner Role and click OK to create the Partner Link.

2. On the Composite Editor window, there are two ways to create a Partner Link for an SDO to be used by a BPEL process component. These ways are:

a) Drag a Web Service from the Component Palette onto the External References column and configure the External Reference

b) Drag an ADF-BC Service from the Component Palette onto the External References column and provide required configuration details.

You must create a wire between the BPEL component and the SDO External Reference to create the Partner Link in the BPEL process.

Page 30: BEPL narration script

When you create an External Reference by using the Web Service component from the Component Palette, this generates a reference that uses SOAP Bindings. Services with SOAP Bindings can reside on the same machine or a machine remote from the Composite Application that uses the service. When you create an External reference based on the ADF-BC Service from the Component Palette it requires some additional configuration details, in particular it requires a Registry name for the ADF-BC service. The Registry name is generated when the ADF-BC component is deployed after creating addition XML elements in a Web application deployment descriptor. The process of performing this task is not covered in this course. The ADF-BC Service component implements a different binding type from the Web Service External Reference. The ADF-BC Service creates a component that uses an ADF Binding, which requires that the ADF-BC service is collocated with the Composite Application that uses it. The main benefit is that the ADF Binding uses native Java RMI interfaces and offers better run-time performance when invoking the service because you eliminate the overhead of the SOAP network layers. BPEL Entity Variables An Entity Variable is:

• Defined as a BPEL variable with the Entity Variable option selected and associated with the Partner Link of an SDO

• Used to query and manipulate data (bound by a key value) in a row of data source underlying the SDO

An Entity Variable is used to query and manipulate data in the underlying data source bound by a key value. An Entity Variable is created in a Scope in the same way as you create standard BPEL variables. However, in the Create Variable window you must select the Entity Variable option and associate the variable with a Partner Link for an SDO. Before you create the Entity Variable make sure the Partner Link for the SDO has been defined. The steps to create an Entity Variable are:

1. On a BPEL Scope, click the Variables icon. 2. On the Variables window, click the Create (+) icon. 3. On the Create Variable window, enter the variable Name field, such as customerEV. In the

Type section: - Select Element and click the Browse (magnifying glass) icon.

- On the Type Chooser window, expand the SDO server Partner Link to select the SDO structure. In the example the element structure is a View Object (or View Link) defined in the inline schema of the partner link for the ADF-BC application that is deployed as an SDO.

4. On the Create Variable window, select the Entity Variable option, and click the Browse icon to choose the Partner Link for the SDO.

5. Close the Create Variable dialog box. The Entity Variable is ready to be used in BPEL activities.

Executing SDO Operations with an Entity Variable An Entity variable is used with the following BPEL activities, causing associated operations in the ADF-BC SDO service to be executed:

• A bindEntity activity invokes the most generic form of getNameVO method, where NameVO is typically derived from your View Object (or View Link) name of underlying ADF-

Page 31: BEPL narration script

BC service. The bindEntity activity gets a data row of values that match unique key values supplied in bindEntity activity.

• A createEntity activity inserts a new row, by calling createNameVO. A bindEntity activity is not required

• A removeEntity activity deletes the row, by executing deleteNameVO. • Assign or Transform activities, modifies elements in the Entity Variable causing the

changes to be cached in BPEL process memory. The Entity Variable must first be used in a bindEntity activity. The actual data is stored (updated) in the database through the ADF-BC service at BPEL dehydration points, which causes the processCSNameVO method of the ADF-BC service to be invoked (where CS means ChangeSummary).

The ADF-BC component methods are registered in the extra metadata of the corresponding WSDL portType for the ADF-BC application service. The table on the slide specifies the SDO operations that map to the ADF-BC application's Create, Read, Update, Delete (CRUD) methods. The Entity Variables in BPEL activities execute' s these methods to perform the specific task. The ProcessChangeSummary method must be selected to enable BPEL entity variables to execute bind and update operations on the SDO Service. Querying Data with an Entity Variable The steps to query a data row by the primary key value by using an Entity Variable in a Bind Entity activity are:

1. Add a Bind Entity activity into the BPEL process. 2. Configure the bind activity. Right-click the Bind Entity activity and select Edit. 3. On the Bind Entity properties window, set properties such as the Name, Entity Variable, and

Unique Keys, and click OK. The Bind Entity activity executes the getNameVO method in the ADF-BC service, where NameVO represents the View Object name whose methods are exposed through the ADF-BC service. Configuring the BindEntity Activity The graphics show the steps to configure the settings in the Bind Entity window. Apart from setting meaning name, the main steps are:

1. Next to the Entity Variable field, click the Browse icon to locate the Entity Variable to be bound to the data. The Browse Variables window displays the Entity Variables in scope and the name selected populates the Entity Variable field.

2. Next to the Unique Keys section, click the Create (green plus) icon to specify a key field to be used when binding the Entity Variable to data. This opens the Specify Key window

3. On the Specify Key window, click the Variable (x) icon to display the Browse Entity Variable window. On the Browse Entity Variable window, expand the Entity Variable tree and locate the element representing the primary key. There is a colored entry that is an annotation that identifies the key element. Do not select the annotation element. Click OK to return to the Specify Key window, which now has the Key Local Part and Key Namespace URI populated by your selection.

Page 32: BEPL narration script

4. On the Specify Key window next to the Key Value field, click the Expression Builder icon to open the Expression Builder in which you can create an expression or select a variable to provide the value for the key to look up a target row in the database . Click OK

The bindEntity activity represents a query by unique ID and retrieves a single row. However, if the Entity Variable is based on a master-detail structure the detail rows are retrieved the same time as the master row. Updating Data with an Entity Variable To update a row using an Entity Variable, use an Assign activity (with copy operations or transform functions) where the target of the changes is one or more elements in the Entity Variable. Before performing any update operations you must have executed a Bind Entity activity to associate the database row with the process context. Entity Variable elements that are not set are not updated. Elements that are assigned an empty value are treated as NULL values. Note: A Transform activity can be used to obtain or modify values in an Entity Variable. In addition, for update operations to be possible the ADF-BC service must expose the ProcessChangeSummary method of the view objects associated with the Entity Variable. Inserting Data with an Entity Variable To create data with an Entity Variable:

• Prepare the new data values in a BPEL variable. • Add and configure a Create Entity activity with:

o The Entity Variable o An expression that gets data values from a BPEL variable

The Create Entity activity copies the data from the location specified in the “From” expression into the Entity Variable, which is used to perform an insert operation through its associated Service Data Object. The BPEL source code is shown for the element after configuring the From field. XML elements in the Entity Variable map to columns of the table into which their values are inserted. Therefore, exceptions can occur if values required by the database column are not included with the insert operation. However, with an Oracle Database, columns can be populated by the database by using the default value options eliminating the need for the XML elements to provide an initial value. XML elements, which map to columns that allow NULL values, can be excluded or set as an “empty” element to insert a NULL value. The Create Entity activity does not require the Entity Variable to be bound to a data row. Deleting Data with an Entity Variable The graphic shows how to create and configure a removeEntity activity, which is used to delete a row from the underlying database. In this case, the Entity Variable should be populated with a key value of the row to be deleted, or previously bound to an existing row by using the bindEntity activity. The DML operations performed by the use of the createEntity, removeEntity, and Assign operations on an Entity Variable that has been used in a bindEntity activity, are performed with an

Page 33: BEPL narration script

optimistic locking strategy. Therefore, some exceptions can occur due to concurrency issues. The concurrency mechanism is managed by the SDO maintaining the current revision number of a row. The ADF-BC service will throw an exception if the row’s revision number is determined to be out of date. Transaction Concepts in BPEL To help understand transaction handling and management in a BPEL process, we define the following types of BPEL process:

• A Transient process executes from start to end without dehydration. A transient process executes within a single transaction. Unhandled faults or a machine crash during the execution of a transient process do not leave a trace in the system.

• A Durable process has one or more dehydration points during the course of process execution. Dehydration occurs when BPEL activities, such as a <receive>, a Pick <onMessage>, and a <wait>, are encountered, to save process state while waiting for the event to be completed. A durable process is executed in multiple transactions because of the database commits to save the process state in the dehydration store.

For a BPEL process, a transaction:

• Begins at the start of the process. The first Receive activity marks the start of a BPEL process. • Ends at the end of a transient (synchronous) process, when it sends the reply to its client, or

when a dehydration point occurs in a durable (asynchronous) process. If a fault occurs before these end conditions, the transaction is rolled back to the start and unhandled faults are returned to the caller.

BPEL Process Dehydration Certain business processes can be long running, because the involved partners might not be able to react instantly to the requests. This happens in asynchronous scenarios where a business process invokes a partner Web service (using the <invoke> activity) and then waits for the response (using the <receive> or <pick> activities). While waiting for the response, the BPEL engine can store the process (and its state, such as variables in scope) in the database (dehydration store), thus freeing up server resources. This is called dehydration. When the BPEL engine receives the response it first restores the process with its state from the database (hydration) and then continues with the execution of the process. In real-world scenarios where many business processes might be running side by side, the dehydration capability is important as it reduces the demands on hardware performance. The process of dehydration causes data being written to the SOA database in the same transaction context as the changes that are made to application database data through Entity Variables and SDOs. Therefore, implicit dehydration points (at the start of a Receive, Wait, or Pick activity) cause a commit to occur ending any application transactions. You can explicitly request dehydration by calling the built-in checkpoint() method, in a Java Embedding activity. However, the built-in checkpoint() method is being deprecated in the future. The alternative option is to set the Partner Link idempotent property to true for a synchronous operation. Default Transactional Behavior in BPEL Oracle BPEL Server always executes requests within a JTA transaction, such that if a JTA transaction exists the server’s local transaction is enlisted into the global transaction. If the JTA transaction does

Page 34: BEPL narration script

not exist, a local transaction is created. Oracle BPEL Engine completes its local transaction either when a breakpoint activity (dehydration) occurs or at the end of the flow. The graphic illustrates the following behavior:

1. The client initiates the JTA transaction and invokes a synchronous BPEL process. 2. The synchronous BPEL process does not specify the transaction property (by default), and

creates a new local transaction , which is committed when the synchronous BPEL process successfully ends and returns a response to the client.

3. When the client invokes the asynchronous BPEL process, the message invocation is executed within the client JTA transaction, and not the asynchronous BPEL process, which executes in its own transaction. When the client JTA transaction commits, the BPEL synchronous instance and asynchronous invocation message are committed to the database.

4. If the JTA transaction is rolled back, the synchronous BPEL process transaction remains committed.

Transaction Boundaries with Entity Variables A transaction with Entity Variables within a BPEL process:

• Starts when an Entity Variable is updated • Ends with a commit being performed when

o A BPEL process dehydration or wait point occurs o A Scope containing the Entity Variable completes without fault

• Ends with a rollback being performed when a Scope containing the Entity Variable terminates with an unhandled fault condition

When making changes to an Entity Variable through an assign operation the changes are made to a copy of the data local to the BPEL process. Typically, the local copy is fetched from database through ADF-BC service. The data changes are pushed back to the ADF-BC service, which commits the data, when:

• The BPEL process is dehydrated • The Scope in which the Entity Variable is declared completes without propagating a fault

Dehydration of a BPEL process happens when the BPEL process cannot proceed, that is, the process (including all the parallel branches, if exists) are waiting for some incoming message (a <receive> activity) or some time-based event (a <wait> activity) All the work performed in the BPEL process will be grouped under one atomic transaction. Essentially, the dehydration point dictates the atomic transaction shape and boundary of the BPEL process. When the changes are performed by another remote service invoked by a BPEL process through SOAP, the changes are executed in a different transaction context. Compensation and Transactions The problem with transactional-based processes is that a global XA transaction is not possible with an asynchronous service invocation. Asynchronous services perform transactions in their own local context. So, how do you get transactional behavior with long-running processes? By using compensation techniques, implemented with compensation handlers in BPEL, you can manage transactional-style operations and error recovery across asynchronous operations. However, the

Page 35: BEPL narration script

service that provides the transactional operation must also provide the undo operation, which reverses the effects of the transactional operation. This allows a BPEL process to manage what has been done and enables it to undo the work done in the event of an error. The example mentioned is of a travel agency that orchestrates external services to manage a travel booking for a customer. The complete transaction requires an airline reservation, car hire, and accommodation to be done. If the airline and car reservations have been successfully made, and the accommodation booking cannot be made due to room unavailability, then the process must be managed such that the airline and car reservations are undone. Compensating Transaction: Example The travel flow example is used to explain the key concept of compensating transactions. The Travel flow process scope contains a nested scope called Travel_Booking. The Travel_Booking scope is key to the implementation because it contains:

• The nested scopes, containing activity sequences, to perform their “do” operation. Each scope has a compensation handler with activities to perform their “undo” operation.

• The fault handlers to catch exceptions raised by “do” operations so that the appropriate compensation can be performed

The example illustrates how compensation occurs when the last transactional operation, in the Do_Hotel scope fails. The flow shown includes the following:

1. The Do_Airline successfully invokes the bookAirline operation. 2. The Do_Car successfully invokes the bookCar operation. 3. The Do_Hotel fails and throws RoomUnavailableException, indicating an error. 4. The Travel_Booking Scope’s Catch branch handles the exception and executes the

Compensate activities. 5. The Do_Car Compensation handler is processed to perform the cancelCar operation. 6. The Do_Airline Compensation handler is executed to invoke the cancelAirline

operation. Implementing Compensation in BPEL The key steps required to implement compensation in BPEL are:

1. Create an outer scope containing all transaction operations. 2. Add an inner scope for each operation, containing the “do” operation activities. 3. Add a compensation handler containing the “undo” operation activities to the inner scope. 4. Add a fault handler (Catch branch) configured to listen for the specific error condition requiring

compensation to the outer scope. 5. In the fault handler, add the Compensate activity configured with the name of the scope whose

compensation handler should be processed. The fault handler can include as many Compensate activities needed to perform all the required undo operations for the error condition.

Module Review In this module, we covered:

• Describe Transactions with Services • Explain Transactional implications of Services • Describe a Service Data Object (SDO)

Page 36: BEPL narration script

• Manage Transactions with SDOs • Explain compensation handling within a BPEL process

Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)

Course Summary In this course, we learned about:

• Create a composite application in Oracle SOA Suite 11g by using the BPEL Process service component

• Orchestrate services in a composite application • Implement coordination of services • Manage transactions in a BPEL process

How can I learn more ? So where can you find more information of these or other Oracle SOA Suite 11g topics? Many online resources are available including he sites shown here. From these locations, you can download the product installers, access the online product documentation, find additional instructor-led and self paced training course on this product and browse and participate in product-specific customer discussion forums. This concludes our self – paced estudy course. We at Oracle know that your time and attention is valuable and limited, so we sincerely hope this training has met your expectations and learning objectives.