business process execution language

BPA and BPM

BPEL (Business Process Execution Language)

Gavin Wright

What is BPEL (Business Process Execution Language)

BPEL (Business Process Execution Language) is an XML -based language that allows web services , APIs and human processes in a service-oriented architecture ( SOA ) to interconnect and share data in a business workflow.

Historically, many businesses used a single large monolithic program to create and execute business processes. One line-of-business program would be responsible for everything from inventory to payroll. These programs would often become fragile and difficult to maintain.

In response to these challenges, many businesses now use smaller web services or microservices to handle business functions. BPEL acts as the glue or the common language that each of these services speaks so they can work together toward a common goal.

microservices vs. monolithic application architecture

How is BPEL used in business?

Consider booking a business trip as an example where BPEL can be used. An employee starts the workflow for booking a flight. A list of available flights is pulled from a travel website. They select one. Their manager receives a notification and clicks a button to approve the expense. The system generates and sends a purchase order to accounting, and then books the flight on the airline website. It enters the expense and approval into the finance tracking software, and then sends the booking information and schedule to the employee and manager.

BPEL is an important tool in enterprise application integration . It defines how microservices interact. It can also act as the middleware layer that handles all communication between participating services.

transformation of enterprise application integration

In SOA, many small services are designed and built. Each service will operate independently and offer an API or way to interface with the other services. BPEL can be used as a common interface between the services to exchange data and control information.

BPEL code can be created manually or by a business process management program through a GUI . This allows workers with limited technical knowledge to read and create BPEL flows.

middleware architecture chart

BPEL choreography vs. orchestration

BPEL offers two paradigms of operation: choreography or orchestration . Orchestration is now the primary way to implement BPEL.

In choreography there is no central program that manages BPEL processes. Each service directly communicates with the other services it relies on without central authority. This can be thought of like a choreographed dance, each dancer knows their role and how they fit in their place, so they don't collide, but there is no director on the stage during the performance.

While choreographed systems can be simple to set up in small deployments, they can quickly grow unwieldy when many pieces are added and are more difficult to integrate new processes or to change the underlying services. Therefore, orchestrated BPEL implementations are now the standard.

In an orchestrated system, a central program manages the BPEL processes and communicates with the services. Each service does not need to be aware of the other services, only the central director. This can be thought of like an orchestra playing music.

Each instrument only has its own sheet music to read from. The conductor is on stage directing each section and ensuring that they work together as a whole. Orchestrated systems often require additional setup but are more agile and resilient.

History and subtypes of BPEL

The BPEL standard is maintained by OASIS , a nonprofit standards group. It has undergone several revisions and extensions during its history.

BPEL was first standardized by collaboration between IBM's Web Services Flow Language and Microsoft's XLang. This first version was named Business Process Execution Language for Web Services (BPEL4WS) when it was submitted in 2003. In 2004 it was formally renamed as Web Services Business Process Execution Language 2.0 (WS-BPEL). In 2007 an extension BPEF4People, or WS-HumanTask, was added to formally define steps that require human interaction. In general, the abbreviation BPEL is used to refer to the latest versions.

Programs that provide BPEL include the following:

BPEL and BPMN

Business Process Modeling Notation (BPMN) is a visual language to express business logic and information flows. It builds on Unified Modeling Language . There is no direct connection between BPEL and BPMN.

There are methods to map BPMN processes and flows into BPEL executable code, but they cannot be directly converted from one to the other. BPMN can be a helpful way to help model a BPEL before it is implemented or to help explain a BPEL flow.

business process categories

BPEL and WSDL

Web Services Description Language (WSDL) is a standard way for web services to describe the interfaces it uses when exchanging data. WSDL will include the variable and function the service uses. BPEL uses the WSDL descriptors of the web service to correctly interface with it.

BPEL code structure

BPEL uses XML notation. It therefore uses text with opening and closing tags.

The first element is the <process> tag. It defines the name of the process and namespaces used in the process. Next it will define <partnerLinks> for the participating services. Global variables are defined in the <variable> tag.

The process can call other services using <invoke> or can send to another process with <receive> .

The main body defines how the activity proceeds. Activities can be defined to be sequentially in a <sequence> or in parallel as part of a <flow> . Data flow can be controlled with loops using <while> and conditionals with <switch> and <pick> tags.

See how AI is helping to drive business process optimization , steps to implement automation in IT workflows and the difference between low-code development and business process management . Also, explore basic SOA principles that still apply to microservices , how application containers offer a new approach to SOA and the evolution of microservices governance from SOA .

Continue Reading About BPEL (Business Process Execution Language)

Related Terms

Dig deeper on bpa and bpm.

business process execution language

Business Process Modeling Notation (BPMN)

Bolstered BPMN standard is core of new BPM+ ecosystem

Business Process Modeling Language (BPML)

business process execution language

Business Process Management Initiative (BPMI)

KatieTerrell Hanna

The new API is faster and cheaper than the previous ChatGPT interface, and users can opt out of submitting their data to it, ...

Though the end of Heroku's free-tier services has left many developers and software teams in the cold, a flock of cloud platform ...

Teams that can write clear and detailed defect reports will increase software quality and reduce the time needed to fix bugs. ...

Azure management groups, subscriptions, resource groups and resources are not mutually exclusive. Businesses can -- and often do ...

Amazon CodeGuru reviews code and suggests improvements to users looking to make their code more efficient as well as optimize ...

Establishing sound multi-cloud governance practices can mitigate challenges and enforce security. Review best practices and tools...

Latency and lag time plague web applications that run JavaScript in the browser. Here are 11 reasons why WebAssembly has the ...

Has there ever been a better time to be a Java programmer? From new Spring releases to active JUGs, the Java platform is ...

Software developers can find good remote programming jobs, but some job offers are too good to be true. Follow these tips to spot...

We suggest you try the following to help find what you’re looking for:

A Hands-on Introduction to BPEL

Developer: J2EE & Web Services

by Matjaz B. Juric

Learn how to create an example business process that combines a set of fictional travel-related Web services and then deploy it to the Oracle BPEL Process Manager runtime environment.

Business Process Execution Language for Web Services (BPEL or BPEL4WS) is a language used for the definition and execution of business processes using Web services. BPEL enables the top-down realization of Service Oriented Architecture (SOA) through composition, orchestration, and coordination of Web services. BPEL provides a relatively easy and straightforward way to compose several Web services into new composite services called business processes .

In this article, you will learn how to create an example business process that combines a set of fictional travel-related Web services and then deploy it to the Oracle BPEL Process Manager runtime environment.

Downloads for this article

BPEL Background

First, some background. BPEL builds on the foundation of XML and Web services; it uses an XML-based language that supports the Web services technology stack, including SOAP, WSDL, UDDI, WS-Reliable Messaging, WS-Addressing, WS-Coordination, and WS-Transaction.

BPEL represents a convergence of two early workflow languages; Web Services Flow Language (WSFL) and XLANG. WSFL was designed by IBM and is based on the concept of directed graphs. XLANG, a block-structured language, was designed by Microsoft. BPEL combines both approaches and provides a rich vocabulary for description of business processes.

The first version of BPEL was developed in August 2002. Since then, many major vendors have joined (including Oracle), resulting in several modifications and improvements, and the adoption of version 1.1 in March 2003. In April 2003, BPEL was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) for standardization purposes, and the Web Services Business Process Execution Language Technical Committee ( WSBPEL TC ) was formed. This effort has led to even broader acceptance in industry.

Within the enterprise, BPEL is used to standardize enterprise application integration as well as to extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners. BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, reengineering, and the selection of the most appropriate processes, thus further optimizing the organization. Definitions of business processes described in BPEL do not affect existing systems, thereby stimulating upgrades. BPEL is the key technology in environments where functionalities are already or will be exposed via Web services. With increases in the use of Web services, the importance of BPEL will increase as well.

Orchestration versus Choreography

Web services usually expose operations of certain applications or information systems. Consequently, combining several Web services actually involves the integration of the underlying applications and their functionalities.

Web services can be combined in two ways:

In orchestration, which is usually used in private business processes, a central process (which can be another Web service) takes control of the involved Web services and coordinates the execution of different operations on the Web services involved in the operation. The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services. (See Figure 1)

Figure 1: Composition of Web services with orchestration

Choreography, in contrast, does not rely on a central coordinator. Rather, each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes. All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. (See Figure 2.)

Figure 2: Composition of Web services with choreography

From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography:

BPEL supports two different ways of describing business processes that support orchestration and choreography:

Now, let's walk through the creation of an executable BPEL business process; the code for it can be downloaded and deployed to the Oracle BPEL Process Manager . We will assume that Oracle BPEL Process Manager has been successfully installed according to the installation instructions and that it uses the default port 9700. If another port has been selected during installation, the examples have to be modified accordingly.

Building a Business Process

A BPEL process specifies the exact order in which participating Web services should be invoked, either sequentially or in parallel. With BPEL, you can express conditional behaviors. For example, an invocation of a Web service can depend on the value of a previous invocation. You can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By combining all these constructs, you can define complex business processes in an algorithmic manner. In fact, because business processes are essentially graphs of activities, it might be useful to express them using Unified Modeling Language (UML) activity diagrams.

In a typical scenario, the BPEL business process receives a request. To fulfill it, the process invokes the involved Web services and then responds to the original caller. Because the BPEL process communicates with other Web services, it relies heavily on the WSDL description of the Web services invoked by the composite Web service.

Let's take an example. A BPEL process consists of steps; each step is called an "activity." BPEL supports primitive as well as structure activities. Primitive activities represent basic constructs and are used for common tasks, such as the following:

Each BPEL process will also define partner links, using <partnerLink>, and declare variables, using <variable>.

To understand how business processes are described with BPEL, you will define an oversimplified business process for employee travel arrangements: The client invokes the business process, specifying the name of the employee, the destination, the departure date, and the return date. The BPEL business process first checks the employee travel status, assuming that a Web service exists through which such checks can be made. Then the BPEL process will check the price for the flight ticket with two airlines: American Airlines and Delta Airlines. Again assume that both airline companies provide a Web service through which such checks can be made. Finally, the BPEL process will select the lower price and return the travel plan to the client.

Then, we will build an asynchronous BPEL process. We will assume that the Web service for checking the employee travel status is synchronous. This is reasonable because such data can be obtained immediately and returned to the caller. To acquire the plane ticket prices we use asynchronous invocations. Again, this is a reasonable approach, because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a Web service and that both Web services are identical (i.e. provide equal port types and operations) to simplify our example.

In real-world scenarios, you will usually not have the choice about the Web services but will have to use whatever services are provided by your partners. If you have the luxury of designing the Web services and BPEL process at the same time, you will want to consider which interface is better. Usually you'll use asynchronous services for long-lasting operations and synchronous services for operations that return a result in a relatively short time. If you use asynchronous Web services, the BPEL process is usually asynchronous as well.

When you define a business process in BPEL, you essentially define a new Web service that is a composite of existing services. The interface of the new BPEL composite Web service uses a set of port types through which it provides operations like any other Web service. To invoke a business process described in BPEL, you have to invoke the resulting composite Web service. Figure 3 shows a schematic view of our process.

Figure 3: Example BPEL process for travel arrangements

In develop the sample BPEL process, you will go through the following steps:

Step 1: Inventory the Involved Web Services

Before you can start writing the BPEL process definition, you have to become familiar with the Web services invoked from our business process. These services are called partner Web services . This example has the Employee Travel Status Web service and the American and Delta Airlines Web service, which have identical WSDL descriptions. (Again, the Web services used in this example are fictional.)

Employee Travel Status Web Service. The Employee Travel Status Web service provides the EmployeeTravelStatusPT port type through which the employee travel status can be checked with the EmployeeTravelStatus operation . The operation will return the travel class that an employee can use, which can be economy, business, or first. (See Figure 4.)

Figure 4: The Employee Travel Status Web service

Airline Web Service. The Airline Web service is asynchronous; therefore, it specifies two port types: The first, FlightAvailabilityPT, is used to check the flight availability using the FlightAvailability operation. To return the result, the Web service specifies the second port type, FlightCallbackPT . This port type specifies the FlightTicketCallback operation.

Although the Airline Web service defines two port types, it implements only the FlightAvailabilityPT. FlightCallbackPT is implemented by the BPEL process, which is the client of the Web service. The architecture of the Web service is schematically shown in Figure 5:

Figure 5: The Airline Web service

Step 2: Define WSDL for the BPEL Process

Next, we have to expose the business travel BPEL as a Web service. The second step is therefore to define the WSDL for it. The process has to receive messages from its clients and return results. It has to expose the TravelApprovalPT port type, which will specify an input message. It also has to declare the ClientCallbackPT port type, used to return the result to the client (asynchronously, using a callback). This process is illustrated in Figure 6.

Figure 6: The WSDL for the BPEL process

Step 3: Define Partner Link Types

The third step is to define the partner link types. Partner link types represent the interaction between a BPEL process and the involved parties, which include the Web services the BPEL process invokes and the client that invokes the BPEL process.

In our example, there are three different partners: the client, the employee travel status Web service, and the airline Web service. Ideally, each Web service should define the corresponding partner link types (in the WSDL). (In real-world scenarios, this may not be the case.) Then we can wrap the partner Web service with a WSDL that imports the WSDL of the Web service and defines the partner link types. Alternatively, we can define all partner links in the WSDL of the BPEL process. However, this approach isn't recommended as it violates the principle of encapsulation.

For our example, we define three partner link types, each in the corresponding WSDL of the Web service:

Each partner link type can have one or two roles and for each role we must specify the portType it uses. For synchronous operations, there is a single role for each partner link type because the operation is only invoked in a single direction. For example, the BPEL process invokes the EmployeeTravelStatus operation on the employee travel status Web service. Because it is a synchronous operation, the BPEL process waits for completion and gets a response only after the operation is completed.

For asynchronous callback operations, you have to specify two roles. The first role describes the invocation of the operation by the client. The second role describes the invocation of a callback operation. In our example there is an asynchronous relation between the BPEL process and the airline Web service.

As you already know, three partner link types are required: two specify two roles because they are asynchronous, and one specifies a single role because it is synchronous.

Partner link types are defined in the WSDL within a special namespace: http://schemas.xmlsoap.org/ws/2003/05/partner-link/ . First let's define the travelLT link type in the BPEL process WSDL used by clients to invoke the BPEL process. The first role required is the role of the travel service (that is, our BPEL process). The client uses the TravelApprovalPT port type to communicate with the BPEL service. The second role, travelServiceCustomer, characterizes the client to which the BPEL process will perform a callback on the ClientCallbackPT port type:

The second link type is employeeLT . It is used to describe the communication between the BPEL process and the employee travel status Web service and is defined in the WSDL of the employee Web service. The interaction is synchronous, so we need a single role, called employeeTravelStatusService . The BPEL process uses the EmployeeTravelStatusPT on the employee Web service:

The last partner link type, flightLT , is used to describe the communication between the BPEL process and the airline Web service. This communication is asynchronous. The BPEL process invokes an asynchronous operation on the airline Web service. The Web service, after it has completed the request, invokes a callback on the BPEL process. Therefore we need two roles. The first role describes the participation of the airline Web service to the BPEL process, which is the airline service ( airlineService) . The BPEL process uses the FlightAvailabilityPT port type to make the asynchronous invocation. The second role describes the participation of the BPEL process to the airline Web services. For the airline Web service, the BPEL process is an airline customer, hence the role name airlineCustomer . The airline Web service uses the FlightCallbackPT port type to make the callback. This partner link type is defined in the WSDL of the airline Web service:

Understanding partner link types is crucial for developing a BPEL process specification. Sometimes it helps to make a diagram of all the interactions. Once the partner link types are defined, you have finished the preparation phase.

Step 4: Create the Business Process

Now you are ready to start writing the BPEL process definition. Typically, a BPEL process waits for an incoming message from the client, which starts the execution of the business process. In our example the client initiates the BPEL process through sending an input message: TravelRequest. Then the BPEL process invokes the Employee Travel Status Web service, sending the EmployeeTravelStatusRequest message. Because this invocation is synchronous, it waits for the EmployeeTravelStatusResponse message. Then the BPEL process makes a concurrent asynchronous invocation of both Airline Web services by sending them the FlightTicketRequest message. Each Airline Web service makes a callback, sending the TravelResponse message. The BPEL process then selects the more appropriate airline and makes a callback to the client with the TravelResponse message.

You start with an empty BPEL process outline that presents the basic structure of each BPEL process definition document:

Let's first add the required namespaces. Here you have to define the target namespace and the namespaces to access the Employee and Airline WSDLs and the BPEL process WSDL. You also have to declare the namespace for all the BPEL activity tags (here the default namespace, so you do not have to qualify each BPEL tag name). The BPEL activity namespace must be http://schemas.xmlsoap.org/ws/2003/03/business-process/:

Partner Links. Next you have to define the partner links , which define different parties that interact with the BPEL process. Each partner link is related to a specific partnerLinkType that characterizes it. Each partner link also specifies one or two attributes:

The partner link can specify a single role, which is usually the case with synchronous request/response operations. For asynchronous operations it specifies two roles. In our example, you'll define four roles. The first partner link is called client and is characterized by the travelLT tpartner link type. The client invokes the business process. You need to specify the myRole attribute to describe the role of the BPEL process ( travelService). You have to specify the second role: partnerRole . Here, this is travelServiceCustomer, which characterizes the BPEL process client.

The second partner link is called employeeTravelStatus and is characterized by the employeeLT partner link type. It is a synchronous request/response relation between the BPEL process and the Web service; you again specify only one role. This time it is the partnerRole, because you describe the role of the Web service, which is a partner to the BPEL process.

The last two partner links correspond to the airline Web services. Because they use the same type of Web service, we specify two partner links based on a single partner link type, flightLT. Here you have asynchronous callback communication, so you need two roles. The role of the BPEL process ( myRole) to the airline Web service is airlineCustomer, whereas the role of the airline ( partnerRole) is airlineService:

Variables. Variables in BPEL processes are used to store, reformat, and transform messages. You usually need a variable for every message sent to the partners and received from them. In this process you need seven variables. Let's call them TravelRequest, EmployeeTravelStatusRequest, EmployeeTravelStatusResponse, FlightDetails, FlightResponseAA, FlightResponseDA, and TravelResponse .

For each variable you have to specify the type. You can use a WSDL message type, an XML Schema simple type, or an XML Schema element. In this example use WSDL message types for all variables:

BPEL Process Main Body. The process main body specifies the order in which the partner Web services are invoked. Usually it starts with a <sequence> that allows you to define several activities that will be performed sequentially. Within the sequence, you first specify the input message that starts the business process. You do that with the <receive> construct, which waits for the matching messagein our case the TravelRequest message. Within the <receive> construct, you do not specify the message directly. Rather we specify the partner link, the port type, the operation name, and optionally the variable that holds the received message for consequent operations.

We link the message reception with the client partner, and wait for the TravelApproval operation to be invoked on port type TravelApprovalPT. We store the received message into the TravelRequest variable:

<receive> waits for the client to invoke the TravelApproval operation and stores the incoming message and parameters about the business trip into the TravelRequest variable. Here, the variable name is the same as the message name, but this is not necessary.

Next, you need to invoke the employee travel status Web service. Before that however we have to prepare the input for this Web service. Looking at the WSDL, you'll see that you have to send a message that consists of the employee part. You can construct such a message by copying the employee part of the message that is sent the client. You would write the corresponding assignment:

Now you can invoke the Employee Travel Status Web service. You make a synchronous invocation, for which we use the <invoke> activity. You use the employeeTravelStatus partner link and invoke the EmployeeTravelStatus operation on the EmployeeTravelStatusPT port type. You have prepared the input message in the EmployeeTravelStatusRequest variable. Because it is a synchronous invocation, the call waits for the reply and stores it in the EmployeeTravelStatusResponse variable:

The next step is to invoke both airline Web services. Again first prepare the required input message (which is identical for both Web services). The FlightTicketRequest message comprises two parts:

Therefore, write an assignment with two copy elements:

The input data includes the data that needs to be passed to the airline Web services. Because it is in the same format, you can pass it directly (using a simple copy). In the real world, you usually need to perform a transformation. You could do that using XPath expressions with <assign>, use a transformation service (such as XSLT engine), or use the transformation capabilities provided by specific BPEL servers.

Now you are ready to invoke both airline Web services. Make concurrent asynchronous invocations; to express concurrency, BPEL provides the <flow> activity. The invocation to each Web service will comprise two steps:

Use <sequence> to group both activities. The two invocations differ only in the partner link name: AmericanAirlines for one and DeltaAirlines for the other. Both invoke the FlightAvailability operation on the FlightAvailabilityPT port type, sending the message from the FlightDetails variable.

The callback is received using the <receive> activity. Again, you use both partner link names. <receive> waits for the FlightTicketCallback operation to be invoked on the FlightCallbackPT port type. Store the result message in the FlightResponseAA and the FlightResponseDA variables respectively:

In this stage of the process, you have two ticket offers. In the next step, you have to select one. To do that, use the <switch> activity.

In the <case> element, check whether the offer from American Airlines ( FlightResponseAA) is equal to or better than the offer from Delta ( FlightResponseDA) . Use the BPEL function getVariableData and specify the variable name for this purpose. The price is inside the confirmationData message part, which is the only message part, but you still have to specify it. You also have to specify the query expression to locate the price element. Here, this is a simple XPath 1.0 expression.

If the American Airlines offer is better Delta's, copy the FlightResponseAA variable to the TravelResponse variable (which you finally return to the client). Otherwise copy the FlightResponseDA variable.

You have come to the final step of the BPEL business processreturning a callback to the client using the <invoke< activity. For the callback, we use the client partner link and invoke the ClientCallback operation on the ClientCallbackPT port type. The variable that holds the reply message is TravelResponse:

With this, you have concluded our first business process specification in BPEL. You can see that BPEL is not very complicated and allows a relatively easy and natural specification of business processes.

Download a sample chapter from the book

Business Process Execution Language for Web Services

Each BPEL process you deploy to the Oracle BPEL Process Manager requires a process descriptor. This process descriptor is not covered by the BPEL standard and is specific to the BPEL server. The deployment process descriptor is the only part of the implementation of a process on a given platform that must be re-written to run the process on a different BPEL engine. The Oracle process descriptor is an XML file specifying the following details about the BPEL process: BPEL source file name, BPEL process name (ID), WSDL locations of all partner link Web services, and optional configuration properties. The default filename for the process descriptor is bpel.xml , but you can use any other name:

You are now ready to start the BPEL Process Manager. You can do this from the Start menu (if using Windows) or by executing the startOraBPEL script, which can be found in the c:\orabpel\bin directory (assuming Oracle BPEL Process Manager has been installed in c:\orabpel) . It is recommended that you include this directory in the path for easy access.

The Oracle BPEL Process Manager includes an Ant utility called obant, which you can use to configure complex compilation and deployment scenarios. obant is just a wrapper around standard Ant, which sets the environment and then invokes the standard Ant Java task. To use it you have to prepare the corresponding project file, usually called build.xml . The project file for our travel example process looks like this:

To compile and deploy our BPEL process you simply start obant from the command line.

Now that you have successfully deployed a BPEL process on the Oracle BPEL Server, it's time to execute it. Oracle BPEL Process Manager provides a BPEL Console through which you can execute, monitor, manage, and debug BPEL processes on a BPEL Server domain. The BPEL Console is accessible at http://localhost:9700/BPELConsole/. You have to click the process name, fill out the following form and click on the Post XML Message button:

Figure 7: BPEL Console

You now get a screen notifying you that the process instance is being processed asynchronously. You can select the visual flow of the execution, instance auditing, or instance debugging. The visual flow of the instance graphically shows the execution of a BPEL process instance. You can monitor the execution of the process and its state (running, completed, canceled, or stale):

Figure 8: Graphical view of the instance's flow

Oracle BPEL Process Manager provides several options for auditing, managing, debugging, and deploying of BPEL processes. For more information, see the product documentation .

Now that you are familiar with the basic concepts of Web services composition with BPEL, you can delve more deeply into more advanced concepts. In my next article , I'll explain advanced BPEL features such as fault handling, scopes, compensation, concurrent activities, and event handling.

Part 2: Advanced BPEL

Country/Region

business process execution language

What’s BPEL? Business Process Execution Language Explained

Double exposure business man with social media and digital technology

In any given business, there are processes which need to be repeated. Although there may be a small number of business processes that don’t use computer logic or web services, the reality is that most modern business practices take place virtually.

So how do business leaders ensure that processes are defined and followed? Enter stage: BPEL.

Developed and approved by OASIS (a technical committee containing business and technology giants such as Dell, IBM, and Microsoft), BPEL is designed to provide businesses with a way to automate and orchestrate business processes—sending emails, completing transactions, processing data, and many other different procedures, including the ability to correct errors found in other processes.

So, let’s take a look.

What is BPEL?

The name says it all: business process execution language.

BPEL is a language that makes these business processes programmable and easy to implement. Being able to define your processes, orchestrate and choreograph processes, and integrate web services into the average business workflow makes integrating BPEL a jump forward for teams aiming to improve the automated aspect of their organization.

The birth of BPEL

Developed in 2001 by IBM and Microsoft, Business Process Execution Language was designed to combine two now defunct XML languages: IBM’s WSFL and Microsoft’s Xlang . These languages were used for programming in the large and served similar purposes in the business context.

Although Microsoft initially intended to carry out this process on their own with the development of XLANG/s , the two companies joined forces to create an XML language which would take the market by storm.

Business Process Execution Language version 1.0/1.1

The two companies developed and named the resulting programming language “BPEL4WS”—short for Business Process Execution Language for Web Services. This name would be later abandoned, but the initial BPEL4WS was a big step in the direction of creating a programming in the large language that would dominate the market.

Business Process Execution Language 2.0

Throughout the years, additional teams have contributed to the Business Process Execution Language project, including SAP and Adobe Systems.

The most recent version of BPEL (WS-BPEL 2.0) was released in 2007. SAP would go on to create the Business Process Execution Language for People (BPEL4People) to explain the benefits BPEL and web services can be combined with human interactions.

Components of BPEL

The ease of integrating BPEL within your organization allows for enterprise-scale automation of services, including external process through Web services.

When originally designed, the team behind BPEL intend to fulfill 10 design goals:

BPEL workflow

BPEL example workflow ( Source )

Because of these 10 aims, BPEL (particularly the 2.0 version) was designed to be an orchestration language—not a choreography language like Xlang and the initial BPEL4WS creation.

The additional benefits that BPEL brings to a company through these 10 aims include:

(Compare automation & orchestration .)

BPEL and orchestration

BPEL orchestrates processes, resulting in three distinct benefits for businesses:

When your organization can access many internal and external services, BPEL can take all the data and make it readily available to you from a centralized location.

Using external web services actually adds to the overall automation process—web services handle both abstract business and executable business processes, allowing your staff to spend more human hours on what you need them to.

Similarly, new aspects of the infrastructure can be immediately integrated with BPEL and web services, allowing large scale improvements to business process.

Whenever new applications or infrastructure is added, they can be immediately integrated with new process descriptions. Large scale changes cause problems for many organizations, but the BPEL process management is there to make the process as painless as possible.

Orchestration in action

Orchestration in action ( Source )

BPEL use cases

Suggested use cases for WS-BPEL/Business Process Execution Language of other versions can be found on the OASIS Open website .

BPEL & Salesforce

When Salesforce needs to interact with the head CRM application, BPEL can be used to automatically communicate between the BPEL powered execution environment (or the engine and the platform) and allow for proper application integration.

BPEL & data manipulation

BPEL is perfect for data collection and manipulation . The use case provided by OASIS allows for a number of functions, including:

Integrating BPEL in your organization

Businesses live and die on their ability to repeat mission critical tasks. When these tasks can become more agile and performed without expensive integrations, a business can look forward to developing their process.

When you can take every business process in your organization and make it automatic, there are increases for business efficiency (even in the face of human behavior, thanks to SAP’s work with BPEL4People).

Integrating BPEL is perfect for businesses that have a wide range of process descriptions that can make the leap to the world of automation. With BPEL, business process management is straightforward.

Related reading

Application Workflow Orchestration: An Introduction

Application workflow orchestration makes sure data and application workflows are carried out in the correct sequence and at the correct time to ensure the successful delivery of a business service.

business process execution language

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing [email protected] .

BMC Brings the A-Game

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead. Learn more about BMC ›

You may also like

business process execution language

IT Management: Get Started with Help from Two Experienced Joes

business process execution language

What are Accidental Software Pirates and What Does It Mean to “True-Up”?

business process execution language

What it means to be Keeping The Lights On (KTLO)

business process execution language

Technical Support Engineer Role & Responsibilities

business process execution language

The Best IT/Tech Gifts of 2021

business process execution language

The Organizational Death Spiral: See It, Avoid It

About the author.

Austin Miller

Austin Miller is a tech writer living in Liverpool. With eight years’ experience teaching high schoolers, he now teaches people about the world of technology and how to get the most out of your computer systems.

Essential Business Process Modeling by Michael Havey

Get full access to Essential Business Process Modeling and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Chapter Five. Business Process Execution Language (BPEL)

The Business Process Execution Language for Web Services (BPEL4WS, usually shortened to BPEL, which rhymes with “people”) is, as its name suggests, a language for the definition and execution of business processes. Though it is not the only standard process language, BPEL is the most popular, and is beginning to saturate the process space.

There are two common ways to represent business processes: XML and notational. BPEL competes in the XML arena with BPML, XPDL, and other approaches. Notational languages include Business Process Modeling Notation (BPMN) and UML activity diagrams. Each type of representation has its merits and, as discussed in Chapter 2 , a good BPM architecture requires both of them.

IBM, Microsoft, and BEA wrote the BPEL specification and subsequently handed it over to the WSBPEL technical committee of the OASIS organization (of which they are members) for standardization. The conceptual roots of BPEL coincide exactly with earlier BPM initiatives of each of the three companies: IBM’s WSFL, Microsoft’s XLANG and BEA’s Process Definition for Java (PD4J) . As discussed in Chapter 3 , WSFL is based on Petri nets and XLANG uses concepts of the pi-calculus; BPEL, consequently, is a mixture of these two theories. PD4J, as discussed later in this chapter, is the basis for the Java extension to BPEL, known as BPELJ.

This chapter explores several aspects of BPEL:

Its authors and maintainers

How to develop a BPEL process ...

Get Essential Business Process Modeling now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Cover of Software Architecture Patterns

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

business process execution language

Don't miss an insight. Subscribe to Techopedia for free.

Business Process Execution Language (BPEL)

Table of contents, what does business process execution language (bpel) mean, techopedia explains business process execution language (bpel).

Business Process Execution Language (BPEL) is an Organization for the Advancement of Structured Information Standards (OASIS) executable language for exporting and importing business information using only the interfaces available through Web services. BPEL is concerned with the abstract process of "programming in the large", which involves the high-level state transition interactions of processes. The language includes such information as when to send messages, when to wait for messages and when to compensate for unsuccessful transactions. In contrast, "programming in the small" deals with short-lived programmable behavior such as a single transaction involving the logical manipulation of resources. BPEL was developed to address the differences between programming in the large and programming in the small. This term is also known as Web Services Business Process Execution Language (WS-BPEL), and is sometimes written as business process execution language for Web Services.

Microsoft and IBM both developed their own programming in the large languages, which are very similar and called XLANG and WSFL respectively. In view of the popularity of a third language, BPML, Microsoft and IBM decided to combine their two languages into another called BPEL4WS. After submitting the new language to OASIS for standardization, it emerged from a technical committee in 2004 as WS-BPEL 2.0. Web services interactions in BPEL are described in two ways:

Both models serve a descriptive role and have more than one possible use case. BPEL should be used both between businesses and within a given business. The BPEL4People language and WS-Human Task specifications were published in 2007 and describe how people can interact with BPEL processes. The 10 original design goals of BPEL are:

Related Question

Web Services Business Process Execution Language (WS-BPEL), Business Process Execution Language for Web Services

Share this Term

Related Terms

Related Reading

Trending Articles

Mastering the Foundations of AI: Top 8 Beginner-Level AI Courses to Try

Mastering the Foundations of AI: Top 8 Beginner-Level AI Courses to Try

7 Sneaky Ways Hackers Can Get Your Facebook Password

7 Sneaky Ways Hackers Can Get Your Facebook Password

Machine Learning from Home: Top 5 eBooks for Beginners

Machine Learning from Home: Top 5 eBooks for Beginners

7 Women Leaders in AI, Machine Learning and Robotics

7 Women Leaders in AI, Machine Learning and Robotics

Tech moves fast! Stay ahead of the curve with Techopedia!

Join nearly 200,000 subscribers who receive actionable tech insights from Techopedia.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Latest Articles

4 Principles of Responsible Artificial Intelligence Systems

By: Kaushik Pal | Contributor

How to Run API-Powered Apps: The Future of Enterprise

By: Rakshith Rao | CEO and Co-founder

By: Devin Partida | Editor-in-Chief for ReHack.com

We Interviewed ChatGPT, AI's Newest Superstar

By: Techopedia Staff

business process execution language

Business Processing Execution Language

BPEL (Business Process Execution Language) is based on XML and has been designed for the specification of executable and abstract business processes.

BPEL (Web Services Business Process Execution Language) is based on XML and defines the behavior of a Business Process in terms of the interactions between the Process and external entities. This interaction occurs through Web Services, with publicly exposed interfaces represented by the Web Services Description Language (WSDL).

BPEL provides a standardized method to expose and access applications as services. Using Enterprise Architect, you can easily integrate Service Orientated Architecture into other aspects of the enterprise.

BPEL in Enterprise Architect

Enterprise Architect supports generating BPEL from executable processes in the Business and Software Engineering and the Ultimate editions.

Although there is no standard graphical notation for WS-BPEL, Enterprise Architect uses the BPMN profile as a graphical front-end to capture BPEL Process descriptions.

Download the Trial

UML Tutorial

Enterprise Architect

Current Release Version 16.1, Build 1625 2-Mar-2023

Enterprise Architect Trial

IMAGES

Workflow Management Business Process Execution Language PNG, Clipart, Angle, Area, Budget
Business Process Execution Language (BPEL)
Business Process Execution Language (BPEL)
Introduction to business process execution language
Business Process Execution Language BPEL Assignment Help (Programming Language)
Business Process Execution Language

VIDEO

Demo BPEL Designer 1
New Way Of Linking Strategy to Execution and Impact-based Project Management
Shorts Hare Krishna Mahaname
Completely Blown Away !!! 🤯🔥
Production Planning and Execution
Learn C program Compilation and Execution complete process

COMMENTS

Business Process Execution Language
The Web Services Business Process Execution Language (WS-BPEL), commonly known as BPEL (Business Process Execution Language), is an OASIS standard
What is BPEL (Business Process Execution Language)?
BPEL (Business Process Execution Language) is an XML-based language that allows web services, APIs and human processes in a service-oriented architecture
A Hands-on Introduction to BPEL
Business Process Execution Language for Web Services (BPEL or BPEL4WS) is a language used for the definition and execution of business processes using Web
What's BPEL? Business Process Execution Language Explained
Developed in 2001 by IBM and Microsoft, Business Process Execution Language was designed to combine two now defunct XML languages: IBM's WSFL
OASIS Web Services Business Process Execution Language
The purpose of the Web Services Business Process Execution Language TC was to continue work on the business process language published in the Business
Business Process Execution Language for Web Services (BPEL)
BPEL – A Brief History. • BPELWS (Business Process Execution Language for Web Services) is a process modeling language. • Developed by IBM, Microsoft
Five. Business Process Execution Language (BPEL)
The Business Process Execution Language for Web Services (BPEL4WS, usually shortened to BPEL, which rhymes with “people”) is, as its name suggests
What is the Business Process Execution Language (BPEL)?
Business Process Execution Language (BPEL) is an Organization for the Advancement of Structured Information Standards (OASIS) executable
Business Processing Execution Language
BPEL (Business Process Execution Language) is based on XML and has been designed for the specification of executable and abstract business processes.
BPEL process
The Business Process Execution Language (BPEL) is a standard industry language. A BPEL process component implements a business process. A BPEL process