SOA Overview Part-2

 

What Is BPEL?

 BPEL stands for Business Process Execution Language. It is a XML based declarative language that can be used implement end to end business processes. Basic building block of these processes is a service, which could be a web service. BPEL utilizes various adapters to service enable legacy and custom applications before consuming them in processes. BPEL also provides human workflow that has variety of uses.

Ø  BPEL stands for Business Process Execution Language.

Ø  it is one of the component of SOA Suite tool.

Ø  BPEL is a XML based language used to design business process/flows.

Ø  We perform service orchestration in BPEL.

Ø  We design a business process that integrates a series of discrete services into an end-to-end process flow.

Ø  BPEL is a sub-set of the Business Process Management discipline.

Ø  BPEL bridges the gap between BPM and SOA.

Ø  BPEL does what BPM cannot do on its own

i.e. execute/orchestrate processes across department/functional systems in a standard way while at the same time providing

Visibility & Control to the Business Process Owner 

Business Process Execution Language (BPEL) is:

Ø   A mark-up language for orchestrating services into an end-to end process flow

Ø   Built on top of XML-related specifications

Ø   Executed by a BPEL engine that can process the BPEL XML source

Main Usage Patterns for BPEL Components

• BPEL is good for creating components that:

– Call upon multiple services, especially asynchronous and longrunning ones

– Provide complex, externalized decision logic 

• The BPEL component works closely with:

– Mediator

– Business Rule service components

 – Human Task components

– Notification service

BPEL Provide end to end business process by using BPEL activities Like 

1)Assign activity   2)Switch activity   3)Receive activity   4 )Reply activity

5)Flow activity      6) FlowN activity   7) Invoke activity     8) Pick activity

9)Transform        10) Scope activity  11) Email activity     12) Throw activity

13)Wait activity     14)  While activity   

What Are Different Parts Of BPEL?

Below are different parts of BPEL

1.  Service Interface: A WSDL describing the functionality of the BPEL process.

 The service interface provides the end user a way to interact with the BPEL process component using Service Interface / Service Binding.

2.    Activities: units of work. The actual elements that make up the BPEL process flow or sequence of instructions to be executed.

3.    Partner links: also called Reference bindings.

 A partner link describes the roles played for the interaction between the BPEL process and the service it invokes.

When one component interact with other different component or binding component, relationship btn them is called as Partner link.

2 types of partner link

Client partner link and

Invoke partner link

When we hit something or we r interacting with someone is called invoke partner link

But when something is interacting with us is called as client partner link

Wire

Connection between service & binding component and within service & binding components know as wire.

I.e. this enable us to graphically connect the components in a SOA composite application. 

Assign Activity:

An assign activity enables you to manipulate data, such as copying the contents of one variable to another.

Can copies data from variables, expressions or xml fragments of one variable to any another variable of a BPEL process.

it is used to copy the content of one element to other element using copyrules operation. (btn source and target )

Mapping should be always btn simple element (i.e where actual value r their).

from-spec: A variable can optionally be initialized by using an inline from-spec.

to-spec : The to-spec points to the variable being created.

bpelx:append : The bpelx:append extension in an assign activity enables a BPEL process service component to append the contents of one variable, expression, or XML fragment to another variable's contents.

bpelx:insertBefore : The bpelx:insertBefore extension in an assign activity enables a BPEL process service component to insert the contents of one variable, expression, or XML fragment before another variable's contents.

bpelx:insertAfter : The bpelx:insertAfter extension in an assign activity enables a BPEL process service component to insert the contents of one variable, expression, or XML fragment after another variable's contents.

ignoreMissingFromData

insertMissingToData

keepSrcElementName 

Can perform any of the following task:

Copy

Copylist

Append

insertAfter

insertBefore

Invoke Activity:

This activity enables you to specify an operation you want to invoke for the service (identified by its partner link). The operation can be one-way or request-response on a port provided by the service. You can also automatically create variables in an invoke activity. An invoke activity invokes a synchronous web service or initiates an asynchronous web service.

The invoke activity opens a port in the process to send and receive data. It uses this port to submit required data and receive a response. For synchronous callbacks, only one port is needed for both the send and the receive functions.

The invoke activity supports the bpelx:inputProperty and bpelx:outputProperty that facilitate the passing of properties through the SOAP header and the obtaining of SOA runtime system properties for useful information such as the tracking.compositeInstanceId and tracking.conversationId.

An invoke activity enables you to invoke a service (identified by its partner link) and specify an operation for this service to perform.

Opens a port in the BPEL process service component to send and receive data.

Scope

The scope activity partitions a BPEL business process into logically organized sections. It provides context for variables, fault handling, Compensation, event handling, and Correlation sets. It is a structured activity that contains one other activity, which may itself contain other activities.

It is a container and a context for other activities of a BPEL process.

Scope activity is used to group functional steps within a BPEL process.

We can collapse scope activity into a single element in Oracle BPEL Designer.

The scope activity consists of collection of nested activities that can have their own local variables, fault handlers, compensation handlers, and so on.

 A scope enables you to manage events within the scope by defining.

-> Variable(By default, asynchronous and synchronous BPEL Projects are created with two

global variables called input and output variables, respectively)

->Partner links

-> Fault handlers, specific catch handlers and catch all handlers

-> Compensation handlers

-> Message handlers

-> Alarm handlers

Sequence

Sequence is make sure whatever activity following under this will execute sequence.

The sequence activity enables you to define a collection of activities to be performed in a sequential order.

Signal

It notifies the other processes to continue processing.

Receive Activity:

This activity specifies the partner link from which to receive information and the port type and operation for the partner link to invoke.

This activity waits for an asynchronous callback response message from a service, such as a loan application approver service.

 While the BPEL process is waiting, it is dehydrated (compressed and stored) until the callback message arrives. The contents of this response are stored in a response variable in the process.

The receive activity supports the bpelx:property extensions that facilitate the passing of properties through the SOAP header, and the obtaining of SOA runtime system properties for useful information such as tracking.compositeInstanceId and tracking.conversationId.   

Receive activity is used to except the payload or the request coming from outer world inside the BPEL.

A receive activity is also used when a process is started asynchronously through a partner link.

A receive activity waits for an asynchronous call-back response message from a service.

Reply

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

It allows the process to send a message in reply to a message that was received through a receive activity.

Note: The receive and reply activities are used to form the standard request – response pattern.

Receive Signal

receive signal activity waits until it receives the proper notification signal from the other process(master or detail) before continuing its processing. 

Pick Activity:

This activity waits for the occurrence of one event in a set of events and performs the activity associated with that event. The occurrence of the events is often mutually exclusive (the process either receives an acceptance or rejection message, but not both). If multiple events occur, the selection of the activity to perform depends on which event occurred first. If the events occur nearly simultaneously, there is a race and the choice of activity to be performed is dependent on both timing and implementation.

The pick activity provides two branches, each one with a condition. The branch that has its condition satisfied first is executed.

The pick activity provides a wait for the occurrence of a set of events, such as a message arriving or a timeout condition specified by an alarm. Only one of these events will be acted on by a sequence of activities to handle the events.

The pick activity has 2 branches −

·        onMessage − the code on this branch is equal to the code for receiving a response before a timeout was added.

·        onAlarm − this condition has code for a timeout of one minute.

Events

an onEvent branch in a scope activity that causes a specified event to wait for a message to arrive

BPEL supports two types of events

Message Events

Alarm Events

onMessage :

These events are triggered by incoming messages through operation invocation on port types.

This condition has code for receiving a reply.

An onMessage branch is similar to a receive activity in that it receives messages. 

It have different operations. Therefore, separate threads and parallel processes can be invoked for each operation.

onAlarm :

These events are time-related and are triggered either after a certain duration or at a specific time.

·        Often, however, it is more useful to wait for more than one message, of which only one will occur.

·        Alarm events are useful when you want the process to wait for a callback for a certain period of time, such as 15 minutes.

o   If no callback is received, the process flow continues as designed.

o   Useful in loosely coupled service-oriented architectures, where you cannot rely on Web services being available all the time.

This condition has code for a timeout.

·         S is for seconds

·         M for one minute

·         H is for hour

·         D is for day

·         Y is for year

 

This time is defined as PT1M, which means to wait one minute before timing outS is for seconds.

you want a time limit of 1 year, 3 days, and 15 seconds, you enter it as PT1Y3D15S.

.

Wait activity:

The wait activity allows a process to wait for a given time period or until a time limit has been reached.

It allows a process to specify a delay for a certain period of time or until a certain deadline is reached.

<wait <for>'duration-expr'</for> | <until>'duration-expr'</until>

    standard-elements

  </wait>

 

Bind-Entity

The bind-Entity is used to create a key point to the data in an application development framework bussiness componenet or ADF BC data provider service(via an entity variable).

Compensate

"This activity invokes compensation on an inner scope activity that has successfully completed.

This activity can be invoked only from within a fault handler or another compensation handler. "

"Compensation occurs when a process cannot complete several operations after completing others.

The process must return and undo the previously completed operations. "

For example, assume a process is designed to book a rental car, a hotel, and a flight. The process books the car and the hotel, but cannot book a flight for the correct day. In this case, the process performs compensation by unbooking the car and the hotel.

The compensation handler is invoked with the compensate activity, which names the scope on which the compensation handler is to be invoked.

It is used to invoke a compensating sequence of activities as a result of a fault or execution of a compansate handler.

The BPEL process can be made use of for notification service. The process can be designed to send the following

email

voice message

instant messaging (IM), or

short message service (SMS) notifications

For the services mentioned above, you can configure the channel for the incoming and outgoing message.

Email

It provides a way to send an email notification about an event.

SMS

It provides a way to send a short message system, also known as SMS Notification.

Voice

It provides a way to send a telephone voice notification about an event. 

Terminate

the terminate activity enables you to end the tasks of an activity (Ex:,the fault handling tasks in a catch branchs).

Throw

throw activity generates a fault from within the business process.

What is a throw activity? What it is ?

Throw activity will explicitly throw the fault and this fault will get caught by the catch block and the corresponding actions will get executed.

Predefined errors in BPEL?

·                         Custom errors

·                            Timed out errors

·                         BPM errors

·                           Validation Errors 

Explain error handling in BPEL and what is a error handling framework? How does a error handling  framework better than simple error handling in BPEL?

EHF –Whenever any error thrown by the BPEL process/Mediator then EHF will check whether exist in  Fault-Bindings.xml files and if  so  then the  action in the Fault-Policy.xml file will be taken and if the action is not found then the fault will the thrown and it will be handled in the catch block.

How do we resubmit a faulted process?

Scenario A: The BPEL code uses a fault-policy and a fault is handled using the “ora-human-intervention” activity, then the fault is marked as Recoverable and the instance state is set to “Running”.

Scenario B: The BPEL code uses a fault-policy and a fault is caught and re-thrown using the “ora-rethrow-fault” action, then the fault is marked as Recoverable and the instance state is set to “Faulted”; provided the fault is a recoverable one (like URL was not available). 

Transform

This activity enables you to create a transformation that maps source elements to target elements (for example, incoming purchase order data into outgoing purchase order acknowledgment data).

Transform activity enables you to create a transformation that maps source elements to target elements. 

Empty

An empty activity provides a no-operation activity. This is useful when u need to insert specific sensor points for monitoring business activity or when a fault need to be caught and supressed.

Java Embedding

Enables you to add custom java code to a BPEL process using the java BPEL exec extension.

BPEL variables

It used to exchange data btn activities within a BPEL Processes or with other service in a composite.

A variable can be defined in a main scope of a BPEL process or within a scope as a data variable.

3 types of BPEL variable

1.       Xml Schema Type (Built-in datatype – string,int, boolean etc)

2.       Message Type of partner links or any project WSDL Files. (defined in wsdl.)

3.       Element Types of any project schema files, imported schema files or project wsdl  files or

Imported schema of project partner links. (either direct on BPEL Process, WSDL or an xml schema document.)

Parallel Flow in a BPEL Process

Parallel flows are especially useful when you must perform several time-consuming and independent tasks.

A BPEL process service component must sometimes gather information from multiple asynchronous sources. Because each callback can take an undefined amount of time (hours or days), it may take too long to call each service one at a time. By breaking the calls into a parallel flow, a BPEL process service component can invoke multiple web services at the same time, and receive the responses as they come in. This method is much more time efficient.

 Execution of Parallel Flow Branches in a Single Thread

Branches in flow, flowN, and forEach activities are executed serially in a single thread.

To achieve pseudo-parallelism, you can configure invoke activities to be nonblocking with the nonBlockingInvoke deployment descriptor property. When this property is set to true, th

e process manager creates a new thread to perform each branch's invoke activity in parallel.

Creating a Parallel Flow

You can create a parallel flow in a BPEL process service component with the flow activity.

The flow activity enables you to specify one or more activities to be performed concurrently. 

The flow activity also provides synchronization. 

The flow activity completes when all activities in the flow have finished processing.

Note: Branches in a flow activity are executed serially in a single thread.

A flow activity typically contains many sequence activities.

Each sequence is performed in parallel.

FLOW

This activity enables you to specify one or more activities to be performed concurrently. A flow activity completes when all activities in the flow have finished processing. Completion of a flow activity includes the possibility that it can be skipped if its enabling condition is false.

For example, assume you use a flow activity to enable two loan offer providers (United Loan service and Star Loan service) to start in parallel. In this case, the flow activity contains two parallel activities – the sequence to invoke the United Loan service and the sequence to invoke the Star Loan service. Each service can take an arbitrary amount of time to complete their loan processes.

A flow activity typically contains many sequence activities, and each sequence is performed in parallel.

For example, two asynchronous callbacks execute in parallel, so that one callback does not have to wait for the other to complete first. Each response is stored in a different global variable.

The BPEL Code determines the number of parallel branches.

The flow activity provides a mechanism to specify one or more sequence of activities to be performed concurrently.

The BPEL Code determines the number of parallel branches. However the number of required branches could vary depending on the available information.

flowN

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

Create multiple flows equal to the value of N. which defined at run time based on data available and logic within within the process.

An index variable increments each time a new branch is created, until the index variable reaches the value of N.

The flowN activity performs activities on an arbitrary number of data elements.

As the number of elements changes, the BPEL process adjusts accordingly.

 

The branches created by flowN perform the same activities, but use different data.

Each branch uses the index variable to look up input variables.

The index variable can be used in the XPath expression to acquire the data specific for that branch.

forEach Activity

 You can use a forEach activity to process multiple sets of activities sequentially or in parallel.

The forEach activity executes a contained (child) scope activity exactly N+1 times, where N equals a final counter value minus a starting counter value that you specify in the Counter Values tab of the For Each dialog. 

If activity

Enables you to use an if activity when conditional behaviour is required for specific activities to decide between two or more branches.

<if>-<elseif>-<else>

This activity replaces the switch activity in BPEL 2.0. The activity enables you to define conditional behaviour for specific activities to decide between two or more branches. Only one activity is selected for execution from a set of branches.

BPEL - Using Conditional Branching

Switch activity 

This activity consists of an ordered list of one or more conditional branches defined in a case branch, followed optionally by an otherwise branch. The branches are considered in the order in which they appear. The first branch whose condition is true is taken and provides the activity performed for the switch. If no branch with a condition is taken, then the otherwise branch is taken. If the otherwise branch is not explicitly specified, then an otherwise branch with an empty activity is assumed to be available. The switch activity is complete when the activity of the selected branch completes.

A switch activity differs in functionality from a flow activity. For example, a flow activity enables a process to gather two loan offers at the same time, but does not compare their values. To compare and make decisions on the values of the two offers, a switch activity is used. The first branch is executed if a defined condition (inside the case branch) is met. If it is not met, the otherwise branch is executed.

In a BPEL process, we implement a conditional branch using a switch activity.

Switch Activity adds a <switch> element in the BPEL source.

It consists of one or more ordered <case> branches for specifying a condition to be evaluated that are processed in their order of appearance  and whichever branch encountered with a true condition, it is processed Switch activity may may not  have an <otherwise> branch .

Otherwise branch is processed if all <case> conditions are false.

Switch activity contains activities for implicit exception handling.

Enables you to set up two or more branches, with each branch in the form of an XPath expression. If the expression is true, then the branch is executed. If the expression is false, then the BPEL process service component moves to the next branch condition, until it either finds a valid branch condition, encounters an otherwise branch, or runs out of branches.

If multiple branch conditions are true, then BPEL executes the first true branch. 

While activity

Enables you to create a while loop to select between two actions. 

The while loop repeats an activity until a specified success criteria is met.

repeatUntil Activity

If the body of an activity must be performed at least once, use a repeatUntil activity instead of a while activity. 

The XPath expression condition in the repeatUntil activity is evaluated after the body of the activity completes.

<compensateScope>

This activity helps compensate the specified child scope.

<rethrow>

This activity has been added to fault handlers. It enables you to rethrow a fault originally captured by the immediately enclosing fault handler. 

What Happens When You Create a SOA Application and Project?

A BPEL directory is created for BPEL processes.

A Mediators directory is created for Oracle Mediators.

A HumanTasks directory is created for human tasks.

An oracle/rules directory is created for business rules.

·         Events

Displays the business event files (.edn).

·         Schemas

Displays the BPEL process schema files (.xsd).

·         testsuites

Displays the test suite files.

·         Transformations

Displays the transformation XSLT (.xsl) and XQuery (.xqy) mapper files.

·         WSDLs

Displays all WSDL files (.wsdl).

·         composite_name

A composite_name file is automatically created when you create a SOA project. This file describes the entire composite assembly of services, service components, references, and wires.

Files in the BPEL Composite

The BPEL composite contains the following files −

·        composite.xml − This file describes the entire composite assembly of services, service components, references, and wires.

·        .bpel − This file contains the set of activities added to the process.

·        .componentType − This file describes the services and references for the BPEL process service component.

·        .wsdl − This file defines the input and output messages for this BPEL process flow, the supported client interface and operations, and other features.

Binding Components:

Binding components establish a connection between a SOA composite and the external world. There are two types of binding components: 

Services

Services provide the outside world with an entry point to the SOA composite application.

By using WSDL.

The binding connectivity of the service describes the protocols that can communicate with the service, for example, SOAP/HTTP or a JCA adapter. 

References

References enable messages to be sent from the SOA composite application to external services in the outside world.

·         Service (default)

Creates a web service to provide an entry point to the SOA composite application

·         Reference

Creates a web service to provide access to an external service in the outside world. 

JCA adapters:

This includes the AQ adapter, database adapter, file adapter, FTP adapter, JMS adapter, MQ adapter, socket adapter, Oracle User Messaging Service adapter, LDAP adapter, Oracle Coherence adapter, and third-party adapter.

MDS:

Share Data with the SOA Design-Time MDS Repository

Export the Selected Contents of the /apps Folder to a JAR File

 Import the Contents of the JAR File into the /apps Folder

Transfer the Selected Contents of the /apps Folder to another MDS Repository

Export an existing Release 11g MDS Repository to a JAR file:

Human Task

->The business process requires an element of human intervention.

->There are cases where fully automated business processes also require human intervention while managing error /exception.

->Integrate with people for manual intervention.

->Assign right users or group with the tasks.     

Human Workflow Components:  

Human Task: Task or work assign to user, role or group.               

Participant: Users or set of users identified for a task based on some business policy and to which task is routed.               

Notification:  A message sent to a user or a group assigned to a task.               

Work list: An web based application for the users to log-in and act on tasks.               

Human task Editor:A tool used to define/modify  the task settings  and parameters.

                Human task configuration is stored in a .task metadata file that is deployed with the project.

Task Parameter

            Add Task parameter in the parameter section of the .task

            Define the type of parameter as simple type or xsd element type.

            Map the parameter value with a corresponding BPEL variable.

            Generate a task form.     

Access the worklist Application.

            http://<hostname>:<port>/integration/worklistapp

            After login into worklist application user can view

              Task assignment

              Task parameter information.

Idempotent Activity

Idempotent Activity are those that can be retired. Ex: Assign activity.

Nonidempotent Activity

It happen only once such as invoke activity, after that bpel engine saves the instance.

"Breakpoint Activities - Receive, pick, wait, onMessage, onAlarm are nonidempotent activities.

Others are idempotent activity.)"

There are two kinds of processes in BPEL.

Durable and Transient

Durable Process:

Durable processes have one or more midprocess breakpoint or idempotent activities. Causing it to stop and wait for some event in the middle of the process.

Durable process tend to be long-lived.

Transient Process:

Transient process do not have any midprocess breakpoint and idempotent activities. They do not stop and wait for any event in the middle of the process.

Transient process tend to be short-lived.

Note:

If there are any breakpoint activities, the process is durable otherwise, the process is transient.

Dehydration

Saves current state of long running information. (Such as when a process is waiting for asynchronous call back) in a dehydration database.

It saves last state of the BPEL Process instance.

When dehydration does occurs?

Dehydration occurs when the BPEL process encounters a breakpoint activities.

These are the three case when dehydration occurs.

è When the BPEL instance encounters a midprocess breakpoint activity,(excluding the initial receive).

This only occurs to durable and nontransient process." 

-> When the BPEL instance encounters a nonidempotent activity(such as invoke). On recovery from a

Crash, The BPEL engine retires only the idempotent activities. Therefore, dehydration occurs when the  engine encounters a nonidempotent activity."

->When the BPEL instance finishes, The BPEL engine saves the process instance to the dehydration

 Store, unless t is configured not to do so. This occurs to durable and transient processes." 

By default, all the BPEL process are dehydrated weather they are synchronous or asynchronous.

"However, if a synchronous process does not need to be durable, you can turn off dehydration mechanism by setting the properties (in the BPEL Process deployment descriptor):"

inMemoryOptimization = true

copletionPersistPolicy = faulted/off