Top 43 Oracle Bpel Interview Questions You Must Prepare 19.May.2024

.NET is probably fourth or fifth on the list of systems customers want to integrate with, so it is fairly important. The BPEL Process Manager ships with examples showcasing how a BPEL process can invoke a .NET service as well as how a .NET client can initiate a BPEL process. We are looking at extending those samples to demonstrate security and reliable messaging.

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.

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.

Web services can be combined in two ways:

  • Orchestration
  • Choreography

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.

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.

BPEL PM 10.1.2 and 10.1.3 supports BPEL4WS 1.@However, some features from WSBPEL 2.0 working draft have already been implemented in the BPEL PM 10.1.2 and 10.1.3 releases. We plan for full support for BPEL 2.0 shortly after it is released and expect a smooth migration path.

Managing message events is particularly important when the business process is waiting for callbacks from partner Web services. activity, lets you wait for only a single (exactly specified) message on a port type. 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. If no callback is received, the process flow continues as designed. This approach is particularly useful in loosely coupled service-oriented architectures, where you cannot rely on Web services being available all the time. This way, the process flow can proceed even if one of the bookstores does not return an offer.

Oracle is a very active member of the OASIS BPEL committee. With more than 6,500 developers using the BPEL Process Manager, we are at the forefront of the adoption of BPEL and can circle back the feedback we are collecting to the committee. Oracle is also actively involved of peripheral specifications: WS-reliability, WS-message delivery, WS-context, WS-security, JSR-208/Java business integration. All these standards are coming together to trform the internet into a messaging/integration backbone. They will therefore play a very important role in the adoption of BPEL.

BPEL provides the activity, through which you can specify that the business process should await the occurrence of one event in a set of events. Events can be message events handled with the activity or alarm events handled with the activity. For each event, you specify an activity or a set of activities that should be performed.

Because they are good for Oracle in that they allow us to leverage the hundreds of man-years invested in building a scalable and reliable container. And they are good for our customers in that they prevent them from being locked in.

You can assign the current value of a date or time field by using the Oracle BPEL XPath function getCurrentDate, getCurrentTime, or getCurrentDateTime, respectively. In addition, if you have a date-time value in the standard XSD format, you can convert it to characters more suitable for output by calling the Oracle BPEL XPath function formatDate.

In the next example, the formatDate function converts the date-time value provided in XSD format to the string 'Jun 10, 2005' (and assigns it to the string field formattedDate).

The J2EE platform is maturing towards better support for clustering, Virtualization and monitoring. By architecture the BPEL Process Manager as a set of J2EE components, we will trparently leverage those capabilities. Virtualization, automatic deployment, on-demand scalability, and self-healing are notions that marry very well with business processes so it will be very interesting to see those developments come together.

Orchestrating a set of services into an end-to-end process flow entails a new set of technical requirements (binding to heterogeneous system, synchronous and asynchronous message exchange patterns, data manipulation, flow coordination, exception management, undeterministic events, compensating tractions, side-by-side versioning, in-flight instance management and auditing). The goal of BPEL is provide a richer and yet simpler abstraction/standard for addressing those requirements. Although it is a fairly new standard, it leverages from 10+ years of research and development Microsoft and IBM invested in XLANG and WSFL.

Scopes are hierarchically organized parts into which a complex business process can be divided. They provide behavioral contexts for activities. In other words, scopes enable you to define different fault handlers for different activities (or sets of activities gathered under a common structured activity such as or ). In addition to defining fault handlers, you can declare variables that are visible only within a scope. Scopes also let you define local correlation sets, compensation handlers, and event handlers.

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.

There are 2 audit trail tables used in BPEL: audit_trail and audit_details.

All audit trail events are inserted into audit_trail. audit_details is used for the details section of an event (ie. payload); if a payload exceeds a certain size, it is inserted into audit_details instead of being inlined in the audit_trail event.

The from-spec query within bpelx:insertBefore yields zero or more nodes. The node list is appended as child nodes to the target node specified by the to-spec query.

The to-spec query of the insertBefore operation points to one or more single L-Value nodes. If more than one node is returned, the first node is used as the reference node. The reference node must be an element node. The parent of the reference node must also be an element node. Otherwise, a bpel:selectionFailure fault is generated. The node list generated by the from-spec query selection is inserted before the reference node. The to-spec query cannot refer to a partner link.

The following example shows the syntax before the execution of . The value of addrVar is:

After the execution of the following syntax in the BPEL process file:
Redwood Shore> 
The value of addrVar now becomes:
Redwood Shore

We can increase the performance by writing indexes and sequences. (Or) Go to application server - Configurations - Change Xml file


  • off - absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.
  • minimal - all events are logged; however, no audit details are logged.
  • production - all events are logged. The audit details for assign activities are not logged; the details for all other nodes are logged.
  • development - all events are logged; all audit details for all activities are logged.


The maximum size (in bytes) an audit trail details string can be before it is stored separately from the audit trail. If a details string is larger than the threshold it will not be immediately loaded when the audit trail is initially retrieved; a link will be displayed with the size of the details string. Typically, the details string will contain the contents of a BPEL variable. In cases where the variable is very large performance may be severely impacted by logging it to the audit trail. The default value is 50 kilobytes.

There are in total 5 tables which are used by mediator instance tracking:

  • Mediator_instance - One row for each mediator message flow.
  • Mediator_case_instance - One row for each mediator case (~ routing rule).
  • If a mediator component has two routing rules then this should have 2 records for that mediator instance.
  • Mediator_case_detail - Captures mediator audit trail for each mediator routing rule. Number of records may vary based on the nature of mediator component.
  • Eg: if mediator component is having a async req-resp routing rule then this would contain 2 rows for the corresponding mediator routing rule.
  • Mediator_document - Stores the payload for routing rules which are configured as deferred (~ parallel in jdev). So if all the routing rules are "sequential" then this will not contain any records.
  • Mediator_audit_document - Stores the payload for audit trail and only when "instanceTrackingLevel" for mediator is "Complete".

In a BPEL process, every piece of data is in XML forms. This includes the messages passed to and from the BPEL process, the messages exchanged with external services, and local variables used by the process. You define the types for these messages and variables with the XML schema, usually in the WSDL file for the flow, the WSDL files for the services it invokes, or the XSD file referenced by those WSDL files. Therefore, all variables in BPEL are XML data, and any BPEL process uses much of its code to manipulate these XML variables. This typically includes performing data trformation between representations required for different services, and local manipulation of data (for example, to combine the results from several service invocations).

You can use the activity instead of the initial activity. You can specify several operations, and receiving one of these messages will result in the creation of a business process instance. Then you have to use a special form of the activity. You specify the createInstance attribute for the activity, but you can specify only events; events are not permitted in this specific form.

To understand the use of this special form of the activity, consider the bookstore Web service, implemented as a simple BPEL process.

(Business Process Execution Language) BPEL Process is a language used for the composition, orchestration and coordination of webservics. In this post we will explain BPEL, define the BPEL role with regard to Service Oriented Architecture and explain the process-oriented approach to SOA and the role of BPEL.

In BPEL the Enterprise application and information systems have become more more fundamental assets to companies. The Companies are trust on them to be able to perform business operations.

Enterprise Information system can improve the efficiency of businesses through the automation of business processes. The objective of almost every company is that the application it uses should provide comprehensive support for business processes. It me that applications should align with business processes closely.

BPEL Role of business processes and their challenges,BPEL Business and IT alignment,What are BPEL features,what are BPEL features, BPEL Orchestration and Choreography, Examine the relation of BPEL to other Languages, The future of BPEL.

Already existing applications have often been developed using older technologies, languages and architectures, which are by definition less flexible to change. Such C,C++, and Mainframe. These applications are tightly coupled applications, constructed of interrelated modules, these are can not be differentiated, upgraded, or refactored with reasonable amount of effort, place important limitations on the flexibility of such applications.

Already existing applications are also difficult to modify and adapt because they have not been developed in a flexible way that would allow modifying application parts quickly and efficiently. Modifying existing applications are require more time Complexity of existing applications and the overall IT Architecture, Modifying them is a complex, difficult and time-consuming task.

SOA, BPEL, and composite applications bring us one step closer to "real-time enterprise." We believe that rich business activity monitoring is the next step as it provides details visibility into the execution of cross-functional processes and a platform of business process optimization. You should expect to see a lot more from Oracle on that aspect of the solution going forward.

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

  •  Executable processes allow you to specify the exact details of business processes. They follow the orchestration paradigm and can be executed by an orchestration engine.
  • Abstract business protocols allow specification of the public message exchange between parties only. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.

Historically every time a standard has been adopted (SQL, J2EE, LDAP, SMTP/POP/IMAP, HTML, etc.), native solutions have won. It is because native solutions are less complex, faster and offer richer functionality. It is also because re-architecting an engine around a new abstraction is very difficult, especially if you have an existing install base that you need to maintain and evolve in parallel.

The bpelx:rename extension in an assign activity enables a BPEL process to rename an element through use of XSD type casting.

The syntax of bpelx:target is similar to and a subset of to-spec for the copy operation. The target must return a list of one more element nodes. Otherwise, a bpel:selectionFailure fault is generated. The element nodes specified in the from-spec are renamed the QName specified by the elementTo attribute. The xsi:type attribute is added to those element nodes to cast those elements to the QName type specified by the typeCastTo attribute.

Assume you have the following employee list:


Promotion changes are now applied to Peter Smith in the employee list:

After executing the above casting (renaming), the data looks as follows with xsi:type info added to Peter Smith:


The employee data of Peter Smith is now invalid, because and are missing. Therefore, is used to add that information.


There is a constant pressure for businesses to interconnect their applications. This is what is driving the adoption of web services and SOA as an enterprise blue print for reducing the cost and complexity of integration initiatives. Making web services work is a two-step process: first you publish and then you orchestrate. Publish me taking a part of a existing system and exposing it as a service. Orchestrate me composing multiple discrete services into an end-to-end process flow. BPEL is the industry standard for orchestration.

Although fault handlers and scopes improve the robustness of BPEL processes considerably, you can also manage events.

BPEL supports two types of events:

  1. Message events are triggered by incoming messages through operation invocation on port types.
  2. Alarm events are time-related and are triggered either after a certain duration or at a specific time.

You use the assign activity to copy data from one XML variable to another, or to calculate the value of an expression and store it in a variable. A copy element within the activity specifies the source and target of the assignment (what to copy from and to), which must be of compatible types. 

The formal syntax as shown in the Business Process Execution Language for Web Services Specification is as follows:


This syntax is described in detail in that specification. The from-spec and to-spec typically specify a variable or variable part, as in:

Example of assigning a numeric value to a variable in XPath expressions.

You can assign numeric values in XPath expressions. The following example shows how to assign an XPath expression with the integer value 100.

A business process sometimes needs to signal a fault explicitly. Therefore, BPEL provides the activity, which has the following syntax:

BPEL does not require definition of fault names prior to their use in the activity. This flexible approach can be error-prone, because there is no compile-time checking of fault names. In the case of typos, misspelled faults will not be handled by the designated fault handler.

Faults can also have an associated variable that contains fault data. If such a variable is required, you have to specify it when throwing a fault, by using the optional faultVariable

Business processes specified in BPEL will interact with partner processes through operation invocations on Web services. The communication between Web services is usually over internet connections that are not highly reliable. Web services can also raise faults due to logical and execution errors. Therefore, BPEL business processes need to handle faults appropriately and may also need to signal faults themselves.

Faults in BPEL can be from various sources:

  • A BPEL process can explicitly signal (throw) a fault.
  • A fault can occur when the BPEL process invokes a Web service operation. The operation might return a WSDL fault message, which results in a BPEL fault.
  • A fault can be thrown automatically by the BPEL runtime environment, either due to a certain condition in the BPEL process itself (such as a join failure), as a consequence of error conditions in the runtime environment, or related to network communication or other reasons. For such situations, BPEL defines several standard faults.

In BPEL processes, invocation of operations on Web services can be particularly error-prone. There are numerous situations—such as broken connections, unavailability of Web services, or changes in the Web services WSDL—that can prevent a BPEL process from successfully invoking a partner Web service operation.

Such faults can be handled in the section of the corresponding scope.

When a fault occurs within a business process, the process may not complete successfully. (But it can complete successfully if the fault is handled within a scope, which enables you to divide a complex process into several parts; more on scopes later.) The business process can handle the fault through one or more fault handlers. Within a fault handler, the business process defines custom activities that should recover from the fault and possibly reverse the partial (unsuccessful) work of the activity where the fault has occurred.

The fault handlers are specified before the first activity of the BPEL process, after partner links and variables.

The overall structure is shown in the following code excerpt:

Within the fault handlers, you specify several activities where you indicate which fault you want to catch and handle. Within a fault handler, you must specify at least one or . The activity can be specified only once within a fault handler.

Usually you specify several activities where you will handle specific faults and use to handle all other faults. To specify which fault you would like to handle, you must specify at least one of the following:

  • faultName, which specifies the name of the fault to handle
  • faultVariable, which specifies the variable type used for fault data

The flexibility of activities is high, and all the following variations are permissible:

Fault handlers in BPEL are similar to try/catch clauses in modern programming languages such as Java.

Existing systems are not going away. Yet enterprises need to build new applications that can leverage the functionality encapsulated in those existing systems. The notion of a composite application is based around the idea of building new applications by wiring together existing building blocks. Orchestration plays an important role in this picture because it is the glue that coordinates the execution of each discrete service. A good orchestration server needs to be reliable, scalable and render the BPEL process logic with very high fidelity.

The bpelx: remove extension in an assign activity enables a BPEL process to remove a variable.

Node removal specified by the XPath expression is supported. Nodes specified by the XPath expression can be multiple, but must be L-Values. Nodes being removed from this parent can be text nodes, attribute nodes, and element nodes.

The XPath expression can return one or more nodes. If the XPath expression returns zero nodes, then a bpel:selectionFailure fault is generated.

The syntax of bpelx: target is similar to and a subset of to-spec for the copy operation.

The following example shows addrVar with the following value:

500 Oracle Parkway 
Mailstop 1op6

After executing the following syntax in the BPEL process file, the second address line of Mailstop is removed.

The Oracle BPEL Process Manager is a new addition to the Oracle product portfolio. It enables enterprises to model, deploy and manage BPEL processes. It comprises an easy-to-use BPEL modeler, a scalable BPEL engine, an extensible WSDL binding framework, a monitoring console and a set of built-in integration services (trformation, user task, java embedding). It makes BPEL/Web service orchestration a first class citizen of the Java platform.

In this example of assigning Boolean values, the XPath expression in the from clause is a call to XPath's Boolean function true, and the specified approved field is set to true. The function false is also available.

The XPath specification recommends that you use the "true()" and "false()" functions as a method for returning Boolean constant values.

If you instead use "boolean(true)" or "boolean(false)", the true or false inside the Boolean function is interpreted as a relative element step, and not as any true or false constant. This me it attempts to select a child node named true under the current XPath context node. In most cases, the true node does not exist. Therefore, an empty result node set is returned and the boolean() function in XPath 1.0 converts an empty node set into a false result. This result can be potentially confusing.

Oracle BPEL Process Manager provides support for using Oracle JDeveloper to graphically design BPEL processes. 

Oracle JDeveloper is an integrated development environment (IDE) for building applications and Web services using Java, XML, and SQL standards. Oracle JDeveloper supports the entire development life cycle with integrated features for designing, coding, debugging, testing, profiling, tuning, and deploying applications. A visual and declarative development approach and the Oracle Application Development Framework (ADF) work together to simplify application development and reduce coding tasks.

Oracle JDeveloper uses BPEL as its native format. This me that processes built with Oracle JDeveloper are 100% portable. Oracle JDeveloper also enables you to view and modify the BPEL source without decreasing the usefulness of the tool.

You design BPEL processes by dragging and dropping elements (known as activities) into the process and editing their property pages. This eliminates the need to write BPEL code. You integrate BPEL processes with external services (known as partner links). You also integrate adapters and services such as workflows, trformations, notifications, sensors, worklist task management, and business rules with the process. Oracle JDeveloper can deploy the developed processes directly to Oracle BPEL Server. This facilitates the development and maintenance of BPEL processes.

Oracle BPEL Process Manager provides support for the following services and adapters in Oracle JDeveloper:

  • Trformations, workflows, worklists, notifications, sensors, and business rules
  • Technology adapters (file, FTP, database, AQ, JMS, MQ, and Oracle Applications)

  • Custom errors
  • Timed out errors
  • BPM errors
  • Validation Errors

BPEL Console supports two modes of invocation: an HTML Form view and an XML Source mode.

The XML Source mode, shown below, allows you to enter XML source data directly into a text form and that source is passed, as is, to initiate the BPEL process. To simplify the use of this mode, you can configure default XML data in the deployment descriptor of the process, which will be pre-loaded into the XML data field .

Alternatively, the HTML Form view in the BPEL Console's Initiate tab will automatically generate an HTML input form (when possible), which can be used to provide the input values to initiate a BPEL process for testing purposes.

You may want to perform various operations on XML data in assign activities.

The following bpelx extension types provide this functionality:

  • bpelx:append 
  • bpelx:insertBefore
  • bpelx:insertAfter
  • bpelx:remove
  • bpelx:rename and XSD Type Casting
  • bpelx:copyList

Primitive activities represent basic constructs and are used for common tasks, such as the following:

  • Invoking other Web services.
  • Waiting for the client to invoke the business process by sending a message.
  • Generating a response for synchronous operations.
  • Manipulating data variables.
  • Indicating faults and exceptions.
  • Waiting for some time.
  • Terminating the entire process.

An alert is displayed when there are stuck messages for asynchronous BPEL processes. A global time threshold is used identify stuck messages.

Alerts are displayed at multiple levels:

  • soa-infra
  • Composite
  • Flow Trace (PS4)