One of the primary means of orchestrating web services is the use of Business Process Execution Language (BPEL). This guide explores ways in which the IDE enables you to edit, compile, and deploy BPEL processes compliant with the WS-BPEL 2.0 specification. Using the BPEL Designer feature of the IDE, you can easily create and edit BPEL processes, deploy them to the BPEL Service Engine, and run these processes in test or debug modes.
The topics listed here provide information about how to use the BPEL Designer.
The section covers the following topics:
Overview of the JBI Runtime Environment
The Composite Application Project
The Java Business Integration (JBI) runtime environment provides the runtime capability for SOA tools in the IDE. The JBI runtime environment includes several components that interact using a services model. This model is based on Web Services Description Language (WSDL) 2.0. Components that supply or consume services within the JBI environment are referred to as Service Engines. One of these components is the The BPEL Service Engine that provides services for executing business processes. Components that provide access to services that are external to the JBI environment are called Binding Components.
The JBI components are installed as part of the GlassFish application server, which is packaged with the NetBeansTM IDE.
In the IDE, open the Services window, expand the GlassFish V2 node, and expand the JBI node.
If you do not see the JBI node, you need to start the Application Server by choosing Start from the pop-up menu of the GlassFish V2 node.
For a detailed overview of the Java Business Integration concept and a description of JBI nodes, see the JBI Component Technical Overview.
The BPEL Service Engine is a JSR 208-compliant JBI runtime component that provides services for executing WS-BPEL 2.0 compliant business processes. The BPEL Service Engine provides runtime services for deploying BPEL processes. To deploy a BPEL process, you need to add it as a JBI module to a Composite Application project.
The BPEL Service Engine starts together with the Application Server. Thus, before deploying and performing test runs of a Composite Application project, make sure that the Application Server is started.
If the Services window is not visible, choose Window > Services.
In the Services window, expand the Servers node.
The Servers node should contain a GlassFish V2 subnode. If the GlassFish V2 node does not appear, go to To configure the GlassFish V2 Application Server:.
If a green arrow badge appears on the GlassFish V2 node, the server is running. If a green arrow badge does not appear, go to To start the GlassFish V2 Application Server:.
If the Services window is not visible, choose Window > Services.
In the Services window, right-click the Servers node and choose Add Server from the pop-up menu.
The Add Server Instance dialog box opens.
In the Choose Server page, from the Server drop-down list, select GlassFish V2 Application Server/GlassFish.
(Optional) In the Name field, change the default name for the server.
The IDE uses this name to identify the server.
Click Next.
The Platform Location Folder page opens.
In the Platform Location field, use the Browse button to navigate to and select the installation location of the application server.
Select the Register Local Default Domain radio button and click Next.
Enter the user name and password for the domain's administrator.
If you accepted the default values during the installation, the user name is admin and the password is adminadmin.
Click Finish.
In the Services window, right-click the GlassFish V2 node and choose Start.
Wait until the following message appears in the Output window:
Application server startup complete.
When the server is running, the IDE displays a green arrow badge on theGlassFish V2 node.
The BPEL Service Engine is represented as sun-bpel-engine in the Services window of the IDE, under the GlassFish V2 > JBI nodes.
See the BPEL Service Engine User's Guide for details about the BPEL Service Engine and supported BPEL 2.0 language constructs.
The Composite Application project is used to create a Service Assembly that can be deployed to the Java Business Integration (JBI) runtime environment. Within the Composite Application project, you can:
Assemble an application that uses multiple project types (for example, BPEL Module or XSLT Module projects).
Configure external/edge access protocols (SOAP, JMS, SMTP, and others).
Build JBI deployment packages.
Deploy the application image to the target JBI component.
Monitor the status of JBI components and applications.
To deploy a Composite Application to the BPEL Service Engine, it must include a JBI module created from a BPEL Module project. Within a Composite Application Project that includes a JBI module, you can also create and execute test cases that can then be run against the deployed BPEL processes.
For more information about working with Composite Application projects, see The BPEL Module Project and Testing and Debugging BPEL Processes sections of this guide.
The BPEL Module project is a group of source files which includes BPEL files, WSDL files, and XML schema files. Within a BPEL Module project, you can author a business process compliant with the WS-BPEL 2.0 language specification.
The BPEL Module project provides point-and-click support for the following:
Using the New Project wizard to create a BPEL Module project and a Composite Application project.
Importing WSDL Resources to act as partner services in the business process.
Creating new WSDL resources, as needed.
Importing XML Schema resources.
Adding BPEL activities to the business process diagram; further defining the elements by using Property Editor dialog boxes, Properties window, and pop-up menu actions.
Creating and changing the source code of the BPEL, WSDL and XSD files.
Checking and validating XML source code.
Building and adding the project as a JBI module to a Composite Application project.
Test running BPEL processes by sending sample messages to the deployed process or processes.
Debugging deployed business processes
Accordingly, the typical procedure to follow when building a BPEL process is:
Creating a new BPEL Module Project using the New Project wizard.
Creating a Composite Application Project.
For sample processes, Composite Application projects are created automatically for you. For the processes created from scratch, you should create the Composite Application project manually.
Adding JBI Modules to Composite Application Projects to the Composite Application project.
(Optional) Build the Composite Application project and make sure that the Application Server is started.
Deploying a Composite Application Project the Composite Application project to the BPEL Service Engine.
For sample processes, test cases are automatically created; for new projects, you need to create at least one test case.
Run one or all test cases.
(Optional) Debug the BPEL process.
In the IDE, choose File > New Project from the main menu and then perform the following steps:
In the Name and Location page, enter the project name and specify the project location or accept the defaults.
Click Finish.
The Projects window now contains a project node for the BPEL Module project.
To create a BPEL file for your project, right-click the Process Files node and choose New > BPEL Process from the pop-up menu.
In the New BPEL Process dialog box, specify the file name and folder. Click Finish.
To create a WSDL file for your project, right-click the Process Files node and choose New > WSDL Document from the pop-up menu.
In the New WSDL Document dialog box, specify the file name and folder. Optionally, select the Import XML Schema File(s) checkbox and browse for a Schema file to import. Click Finish.
A typical BPEL Module project contains a BPEL source file, WSDL and XSD files.
Take a look at the artifacts you have created:
In the Projects window, expand the created BPELModule1 node and the Process Files node.
The Process Files node contains these items:
newProcess.bpel, the BPEL process
newWSDL.wsdl, the process web service interface.
Double-click the newProcess.bpel node.
Notice the following:
The newProcess.bpel diagram opens in the Design view.
The Design view is the area where you can visually model business processes. The BPEL Designer automatically generates BPEL code that corresponds to the visual design.
The Source view for newProcess.bpel can be invoked by clicking the Source button.
The Palette of BPEL elements opens in the Design view to the right of the design area.
The Properties window opens for a selected element below the Palette.
The Navigator window shows the BPEL Logical View of the BPEL process.
The BPEL Mapper window appears in the bottom (if it does not appear automatically, choose Window > Other > BPEL Mapper from the main menu).
Double-clicking the newWSDL.wsdl node opens the WSDL Editor where you can view and modify your newWSDL.wsdl file. For more information see Working with WSDL Files
You open the Properties dialog box for a BPEL Module project by right-clicking the BPEL Module project's node and choosing Properties. The tree in the left pane shows that you have access to three pages:
General
Project References
XML Catalog
The General page allows you to view the path to the folder containing the project's files and view or modify the prefix for the project service engine (such as com.sun.bpelse).
The Project References page displays other BPEL Module projects that are referenced by your BPEL Module project. In this page, you can add and remove projects referenced by the BPEL Module project.
The XML Catalog page displays XML catalog entries used within your BPEL Module project. XML catalogs provide mapping information that maps an external entity in an XML document to the actual location of the document being referenced. In this page, you can remove XML catalog entries from the list of XML catalogs for your BPEL Module project.
A BPEL Module project is not directly deployable. You must first add a BPEL Module project, as a JBI module, to a Composite Application project. You can then deploy the Composite Application project. Deploying the project makes the service assembly available to the application server, thus allowing its service units to run.
The New Project wizard guides you through the steps needed to create a Composite Application project.
Choose File > New Project (Ctrl-Shift-N).
In the Categories list, select SOA and in the Projects list, select Composite Application and click Next.
In the Name and Location page, name the project and specify the location of project files.
To set the new Composite Application project as main, leave the Set as Main Project checkbox selected.
Click Finish.
The new Composite Application project appears in the Projects window. In order to deploy and perform test runs of your business process, add the BPEL Module as a JBI module to the Composite Application project.
When you build a project, the IDE compiles the BPEL source file and packages the BPEL file and web service artifacts, including WSDL and XSD files, into a JAR archive. You should add this project JAR file to a Composite Application project and then deploy it to the JBI server.
Follow this procedure to build a BPEL Module project:
In the Projects window, right-click the BPEL Module project's node and choose Build Project.
You can also perform a clean build by right-clicking the BPEL Module project's node in the Projects window and choosing Clean and Build Project.
Watch for the BUILD SUCCESSFUL message in the Output window.
In the Projects window, right-click the Composite Application project's node and choose Add JBI Module.
In the Select Project dialog box, select the BPEL Module project folder, make sure that the project's JAR file has appeared in the Project JAR Files list, and click Add Project JAR Files.
To verify that the BPEL Module has been added as a JBI Module, in the Projects window, expand Composite Application project > JBI Modules. You should see the JAR file of the BPEL Module project.
The Deploy action compiles the files in the Composite Application project, packages the compiled BPEL and related web service artifacts (including WSDL and XSD files) into an archive, and deploys them to the Application Server.
Right-click the Composite Application project's node, and choose Deploy Project.
In the Warning dialog box, make sure the GlassFish V2 is selected and click OK.
Deployment has succeeded if you see the Build successful message in the Output window.
If the Output window is not visible, choose Window > Output > Output.
Open the Services window and expand Servers > GlassFish V2> JBI > Service Assemblies to see the deployed Service Assembly.
If you do not see the deployed project, right-click the Service Assemblies node and choose Refresh.
The best way to get acquainted with constructing BPEL diagrams is to create sample processes. You can design your BPEL process by modifying existing sample processes.
For samples, the New Project sample wizard automatically generates both types of projects, BPEL Module and Composite Application, so you do not need to separately create each of these projects. The IDE automatically adds the sample BPEL Module project as a JBI module to the Composite Application project.
In the BPEL Designer, you can create the following sample processes:
A Synchronous Sample Process
An Asynchronous Sample Process
Travel Reservation Service sample
A synchronous process refers to a conversation style in which the client sends a message to the process, waits for a reply, and continues work only when the reply comes back. When you create a synchronous sample process, the IDE generates a skeletal process with a single synchronous operation and the required WSDL and XML schema files.
An asynchronous process applies to long-running conversations in which the client does not wait for a reply from the process before continuing its work. Instead of returning the result synchronously to the client, this process accepts the client's request, performs work that might be long-running, and then asynchronously calls back to the client when the work is done. When you create an asynchronous process, the IDE generates a skeletal process with one incoming and one outgoing asynchronous operation and the required WSDL and XML schema files.
Note that any particular process can consist of an arbitrary collection of synchronous and asynchronous interactions with one or more conversational partners.
This sample is a real-world BPEL process sample constructed using the majority of BPEL elements and several partner web services.
Together with the Travel Reservation Service sample, the wizard creates another project, Reservation Partner Services, a basic EJB and JMS based implementation of the three partner services.
Choose File > New Project (Ctrl-Shift-N).
In the Categories list, expand the Samples node and select SOA.
In the Projects list, select the sample project you want to create and click Next.
In the Name and Location page, name the project and specify the location of project files.
Click Finish.
The wizard creates two types of projects for the selected sample: a sample BPEL Module project and a sample Composite Application project. You are free to modify the sample business process and or add additional BPEL processes to the BPEL Module. To deploy, test-run, and debug the BPEL process, use the Composite Application project.
This section explores the navigation capabilities of the BPEL Designer.
Printing BPEL Diagrams and Source Files
In the BPEL Editor you can switch between Source View, Design View, Mapper View and Logging View. All the views are always kept in sync.
Design View
The Design view is a business processes designer where you can author a diagram of your business process. In the Design view, you add, edit, and delete diagram elements. The diagram constructed in the Design view is automatically generated into BPEL source code compliant with the WS-BPEL 2.0 specification with the exceptions listed in the BPEL 2.0 Language Constructs section of the BPEL Service Engine User's Guide.
The Design view opens by default when you double-click a BPEL source file from a BPEL Module project in the Projects window. To switch to the corresponding place in the Source view, right-click an element in the Design view and select Go to Source (Alt-O).
Source View
The Source view shows the underlying code for a business process diagram. The Source view is based on the IDE's XML Source view and provides access to conveniences such as code folding, XML syntax highlighting, and code completion.
You can perform source level editing as well as visual designing. The BPEL Designer will perform round-trip two-way engineering to ensure that the Design view and Source view remain synchronized with each other. The IDE will automatically re-parse the BPEL source file and rebuild the diagram every time you perform manual edits of the source file.
To switch to the corresponding place in the Design view, place a cursor at the line in the Source view, right-click and choose Go to Design (Alt-D).
Mapper View
The BPEL Mapper provides a framework for processing and directing BPEL process data. The BPEL Mapper can be used to assign values or to set conditions. To switch to the the Mapper view press Ctrl-Shift-F9 or click the Mapper tab on the editor toolbar. For more information refer to The BPEL Mapper section.
Logging View
The Logging view provides you with the capability to set logging or alerting rules for the process. To switch to the the Logging view press Alt-L or click the Logging tab on the editor toolbar. For more information seeLogging and Alerting section.
The Clone Document feature is a customization option which enables you to clone documents views. For example, if you want to see both the source and the design view of a BPEL process at the same time (or the Design and Mapper view) follow the instructions below.
Several views of one document are always kept in sync.
Open the BPEL file
Right click the tab with the file name and choose Clone document. Another tab with the same document will be created.
Drag and drop one of the tabs to the location you choose: left, right or to the bottom of the screen. An orange frame will show you where the window you are dragging will be placed.
The Navigator window is a companion of the BPEL Designer. If the Navigator window is not visible, you can manually invoke it by selecting Window > Navigating > Navigator from the main menu or pressing the Ctrl-7 key combination.
The Navigator window provides two distinct views of the BPEL process: BPEL Logical View and XML View. You can switch between the XML View and BPEL Logical View using the drop-down menu in the upper part of the Navigator window.
The XML View is identical to the Navigator view that is available for all XML documents opened in the IDE. The XML View is a companion to the BPEL Source view. Double-click any Navigator node and the Source view adjusts the current line of code to show the selected element.
The Navigator also provides the BPEL Logical View of BPEL processes. When you select BPEL constructs in the Design view, the BPEL Logical View shows the same element selected. Alternatively, when you select a node in the BPEL Logical View's tree, the corresponding element is selected on the diagram.
Right-clicking the nodes in the BPEL Logical View invokes pop-up menus with actions relevant to the particular node. For example, for the Assign element, the actions are Go to Source, Go to Design, Wrap With, Move Up and Move Down, Toggle Breakpoint, Delete, Show BPEL Mapper, and Properties. The Go to Source and Go to Design actions, available for most of the nodes, have associated keyboard shortcuts: Alt-O for Go to Source and Alt-D for Go to Design.
In general, the nodes in the Navigator window correspond to the elements on the diagram. In addition, there are nodes, such as Variables and Correlation Sets, that are related to functionality not directly accessible from the diagram. To view the variables used in the business process, expand the Variables node in the BPEL Logical View of the Navigator window. For variables, the following commands are available in the pop-up menu:
Go To Source. Opens the source of the BPEL file and places the cursor at the place where the variable is mentioned for the first time.
Go To Type Source. Opens the source file that contains a definition of the variable type. This can be, for example, a WSDL file.
Find Usages. Shows usages of variables in the BPEL file. This command is also available from the pop-up menu for correlation sets and Partner Link elements.
Of particular relevance is the Imports node, which lists XSD and WSDL files referenced with the help of the Import element in your BPEL file. Using the pop-up menu for the Imports node, you can add reference to an XSD or WSDL file. Note that only files located in the project folder may be referenced.
In the BPEL Logical View of the Navigator window, right-click the Imports node and choose one of the following, depending on the format of the imported file: Add WSDL Import or Add Schema Import.
In the Create New Import dialog box, select the file in your project structure to add it as import.
You first need to add the files stored in your project directory to the project structure. Then you can add them as imports. The files that are already referenced are displayed in the strikethrough style.
View the values in the read-only Namespace and Type fields and click OK.
The resource file you have just added appears under the Imports node in the Navigator window.
From the Navigator window you can add properties and property aliases to the WSDL files referenced in the BPEL document.
In the BPEL Logical View of the Navigator window, right-click a WSDL file under the Imports node and choose Add Property from the pop-up menu.
In the Create New Correlation Property dialog box, specify the property name.
Select the property type and click OK.
In the BPEL Logical View of the Navigator window, right-click a WSDL file under the Imports node and select Add Property Alias from the pop-up menu.
In the Create New Property Alias dialog box, click Browse next to the Property field to specify the property.
In the Property Chooser dialog box, select the property for which you are creating the alias and click OK. The Property Type field in the Create New Property Alias dialog box is populated with the type.
In the Map Property To tree, expand the WSDL file node and select the message or message part.
To add a query, enter the query string in the Query text field.
If the Synchronous with Tree checkbox is selected, the Query field is updated each time you change the selection in the Map Property To tree.
Click OK.
For more information on defining properties and property aliases with the WSDL Editor, refer to the Developer Guide to the WSDL Editor.
The Properties window contains the properties information for the currently selected element of the process. You can also use the IDE's Properties window to configure all BPEL element properties. The contents of the Properties window differs depending on the active element of the process. There are only two permanent fields of the Properties window available for every element:
Name. Shows the name of the element.
Documentation. Contains comments associated with the element. For more information see Documentation section.
To open the Properties window, choose Window > Properties or press Ctrl-Shift-7.
When you open a BPEL file from the Projects window, the diagram opens in the Editing Mode of the Design view by default. In this mode, you can edit the diagram and scroll through it. The Editing Mode is enabled when the Navigation mode is selected on the Editor toolbar.
In the Editing Mode, you can scroll through the diagram by using the following methods:
Turning the mouse wheel
Using the horizontal and vertical scroll bars
Pressing the Tab key to move through elements
Zooming in and out of the diagram. The zoom feature allows you to reduce or enlarge the size of your diagram to get a closer view or to see more of the diagram at a reduced size. You can change the zoom value using the Zoom Value drop-down list on the Editor toolbar. To scale the diagram to fit the window, click Fit Diagram. To scale the diagram width to fit the window width, click the Fit Width button.
Note that the minimum scale size is 33% and some large diagrams might not fit entirely the window.
To change the scale do one of the following:
Click Zoom In or Zoom Out button on the toolbar.
Click Fit Diagram button on the toolbar to scale the diagram to fit the window.
Click Fit Width button on the toolbar to scale the diagram width to fit the window.
Turn on the Navigation Mode on the toolbar, then you can zoom in and out using the mouse wheel.
You can print BPEL diagrams and source files and customize printing settings, including border, headers, footers, colors, line numbers, and zooming, to suit your preferences.
Open a BPEL file in the Design view.
Choose File from the main menu and select one of the following commands:
Print Preview. Preview the print layout or configure print settings.
Print to HTML. Print the .bpel file as an HTML file.
In the IDE, select an object you want to print.
In the Print Preview window, click Print Options. The Print Options dialog box opens.
Change the print settings to suit your preferences:
Print Border. Adds a border to the printed page. Click the Color icon to change the border color.
Print Header and Print Footer. Specifies the text, alignment, color, and font of the header and footer. To hide the header or footer, clear the Print Header or Print Footer checkboxes, respectively. To specify the header or footer pattern text, click in the field corresponding to the alignment (Left, Center, or Right) and select one of the buttons below. For example, to add the time of printing at the bottom left corner, select the Print Footer checkbox, click into the Left field, and click the "Time of printing " icon. Click the Choose Footer Color and Choose Footer Font icons to modify the color and the font for the page header and footer.
Line Numbers. Specifies whether to print line numbers for source files.
Wrap Lines. Wraps the lines to fit them on the page.
Print as in Editor . The printed page will look like you see it in the editor.
Text Font and Color. Specifies the color and font of the text when you are printing, for example, source files.
Background Color. Specifies the background color.
Line spacing. Specifies the value for line spacing.
Zoom. Specifies the scale for the printed text or diagram on the page. You can select to fit width or height or choose a specific zoom scale.
Click OK.
In the IDE, select an object you want to print.
Choose File > Print Preview.
In the Print Preview window, click Page Setup. The Page Setup dialog box opens.
You can also invoke the Page Setup dialog box by choosing File > Page Setup.
On the Page Setup page specify the following parameters:
Paper size
Source of the paper
Paper orientation
Margin sizes
Click Printer button and specify the printer.
Click Ok.
Getting started with the diagram.
The BPEL Diagram. Operations with Elements on the Diagram
Configuring Element Properties in the Design View
Finding Usages of BPEL Components
The BPEL diagram (BPEL Design View) is the visual representation of the BPEL Process. On the diagram you can author business process by adding and configuring activities. You can also edit existing .bpel files. To open a .bpel file double-click it's name in the Projects window. By default, the process diagram will be open.
In the Design view, you can perform the following operations on elements:
Create elements by dragging elements from the Palette to the diagram. The Design view supports the notion of "drop points", which means that you must align elements with these drop points when you drag them. Not all elements are created via drag-and-drop from the Palette. These other elements are created using pop-up menus which are invoked when you right-click an existing diagram element.
Select elements on a diagram. A single click on an element selects it. Selection is a necessary step in performing several other operations, such as deleting, moving, or editing an element.
Invoke pop-up menu actions for diagram elements. Each BPEL element has a pop-up menu. This pop-up menu can be invoked by right-clicking the element. The pop-up menu will offer a set of actions which are relevant to the selected element.
Move diagram elements. You can move diagram elements by selecting the element and then dragging it to a new location. If you move a container element, all its children move along with the container.
Edit element names in the Design view directly. Double-click the element name on the diagram to edit it.
Invoke XML Validation. You can invoke XML validation by clicking the Validate XML button on the Design view editor toolbar. For more information, see the Validation section.
Apply filters to diagram elements. The Editor toolbar contains the Show Partner Links and Show Sequences toggle buttons. Both Partner Link elements and Sequence elements are shown by default. Clicking the Show Partner Links button hides the Partner Link elements on the diagram. Clicking the Show Sequences button hides the Sequence containers on the diagram. Clicking either button a second time will again reveal the Partner Link elements, or the Sequence elements on the diagram, respectively.
You cannot add new Partner Link or Sequence elements to the diagram if you chose not to show them.
Finding elements on the diagram. You can find BPEL elements in the Design view by their names or types. You can use either the Find bar (Edit > Find or Ctrl-F) or the Advanced Search feature (Edit > Advanced Search or Alt-Shift-F). In the Find bar, select the type of search you want to perform, type in the search query and click Find. In the Advanced Search dialog box, you can refine your search query and search BPEL elements by their name and/or type.
Collapsing or expanding elements on
the diagram. When a large diagram is open in the Design view, you
can collapse or expand container elements, such as Sequence or Scope, using
the quick action buttons that appear near the selected elements. By default,
when you open a diagram in the Design view, you can see all container elements
expanded. To expand all elements on the diagram, click the Expand All icon on
the Editor toolbar. You can use the following combinations of keys: Enter
to expand the selected element, Shift-Enter to collapse the selected element,
and Alt-Enter to expand all elements on the diagram.
Wrapping activities with container elements. You can wrap elements with container activities in a single click. The wrap feature is useful, for example when you want to quickly place an activity inside another activity. In the Design view, right-click the activity you want to wrap, point to the Wrap With option, and select the wrapper BPEL activity.
After you add BPEL activities to a diagram, you need to configure them. You can do this using either the Property Editor dialog boxes or the IDE's Properties window. Note that Property Editor dialog boxes are available only for some elements.
To open the Property Editor for an element, do one of the following:
Right-click the element and choose Edit.
Double-click the element.
To open the Properties window for an element, right-click the element and choose Properties. The properties for this element are displayed in the standard IDE's Properties window. If the IDE's Properties window is not open, choose Window > Properties from the main menu (Ctrl-Shift-7).
For BPEL files, the Find Usages command determines where the following elements are used in the associated .bpel files:
Variable
Partner Link
Correlation set
In the IDE, open the BPEL file (.bpel) you want to work with.
By default, the IDE opens the Design view for the BPEL file.
In the Design view, select the element for which you want to see usages.
You can also select the element in the BPEL Logical View of the Navigator window.
Right-click the element either in the Design view or in the Navigator window and choose Find Usages (Alt-F7) from the pop-up menu.
The IDE opens the XML Usages window in the lower part of the IDE. The first time you invoke the Find Usages function, the window has no tabs. For each consequent query, the IDE adds a Find XML Usages tab that shows the usages of the component you selected.
(Optional) To go to the source for an element and double-click that element in the tree. The right part of the XML Usages windows is a visual representation of element usages throughout the project.
The BPEL Designer synchronizes the Design and Source views as follows:
Changes you make in a diagram are reflected immediately in the corresponding source code.
Changes you make in the source code are reflected on the diagram when you switch to the Design view.
To save changes in the Design or Source view, choose File > Save or press Ctrl-S.
This section is the palette elements reference.
Using the Partner Link Element
Using the CompensateScope Element
Using the Repeat Until Element
The Process element is already present in your diagram. The New Project wizards always create a skeletal BPEL file that contains at least a process element. Therefore, the Process element is not part of the Palette. The Process element is assumed to be present, as it is the minimum requirement for a BPEL file.
The following screenshot shows the representation of a process in the Understanding the Travel Reservation Service sample.
Right-click the Process element and choose Add from the pop-up menu to add the following:
Specify the name and the target namespace of the Process element in the Properties window, invoked by right-clicking the element and choosing Properties.
A BPEL process can be synchronous or asynchronous. A synchronous BPEL process blocks the client (the one which is using the process) until the process finishes and returns a result to the client. An asynchronous process does not block the client. Rather it uses a callback to return the result (if any). Usually we use asynchronous processes for longer-lasting processes and synchronous for processes that return a result in a relatively short time. If a BPEL process uses asynchronous web services, the process itself is usually also asynchronous.
The Invoke element enables the business process to invoke a one-way or request-response operation on a portType offered by a partner. It enables the business process to send messages to partners. The operation is defined in the partner's WSDL file.
In the Design view, drag the Invoke element from the Palette to the diagram.
Perform one of the following procedures to associate the Invoke element with a Partner Link element:
Directly draw a message flow from the Invoke element to the target Partner Link.
Double-click the Invoke element. A dialog opens where you can examine or change the following:
The name of the Invoke element.
The partner link that is invoked.
The operation associated with the Invoke element.
The input variable associated with the Invoke element.
The output variable.
Both input and output variables can be created or browsed through this dialog.
In the Property Editor dialog box, you can either create a variable or use an existing variable to hold input and output data. Click the Create button to create a variable for the Invoke element, and click Browse to choose an existing variable.
Note that when you click the Browse button, the Input Variable Chooser or the Output Variable Chooser dialog boxes opens. In these dialog boxes, a checkbox with the option to show variables with appropriate types appears. This checkbox restricts the list of available variables to those which are of the proper type for the activity you are configuring. In this way the Design view helps you develop valid BPEL code.
Correlation sets on invoke activities, which deal with outbound operations, are used to validate that outgoing messages contain data which is consistent with the data contained within specified correlation set instances.
The Correlations tab in the Invoke Property Editor dialog box enables you to examine or specify a correlation set.
The tab shows:
Names of correlation sets
The initiation of a correlator
The pattern associated with the correlation
For more information see Understanding Correlation. Using the Correlation Wizard.
The Receive element allows the business process to do a blocking wait for a particular message to arrive.
In the Design view, drag the Receive element from the Palette to the diagram.
Double-click the Receive element (or right-click it and choose Edit) to configure its properties. Here the example is provided for the Travel Reservation Service sample:
The name of the Receive element (ReceiveItinerary ).
The partner link (Travel).
The operation associated with the Receive element (buildItinerary).
The input variable to the Receive element (ItineraryIn ).
Select Browse for the Input Variable to open the Input Variable chooser, where you can choose other variables associated with this process. Select Create to create a new variable.
Create Instance. If selected, an instance of the BPEL process starts when an associated message arrives. Note that if the Receive activity is the first activity in your business process, the Create Instance checkbox must be selected.
You can also edit some of the element's properties in the Properties window. To open the window, right-click the Receive element and choose Properties or choose Window > Properties (Ctrl-Shift-7) from the main menu. You can edit the information by clicking on the ellipsis button. You cant edit the shadowed information from this window, to change it open the property editor as described above.
The Correlations tab in the Receive Property Editor dialog box enables you to examine or specify a correlation set.
The tab shows:
Names of correlation sets
The initiation of a correlator
For more information see Understanding Correlation. Using the Correlation Wizard.
Use this activity to return a message from the process to the same partner that initiated the operation. The combination of Receive and Reply activities creates a request-response operation.
This activity is used in a synchronous (request/response) operation, and specifies the same partner, port type and operation as the Receive activity that invoked the process.
In the Design view, drag the Reply element from the Palette to the diagram.
Double-click the Reply element (or right-click and choose Edit) to open a Property Editor dialog box for the Reply element. In this dialog box, you can specify the following:
The name of the element.
The Partner Link.
The operation.
Type of response: Normal Response or Fault Response.
Select Normal Response if the Reply element is to be used for the normal response message type. Optionally, specify the output variable: either create a new output variable or browse for an existing variable.
Select Fault Response if the Reply element is to be used to send a fault message. Choose a fault name and, optionally, specify the fault variable: either create a new fault variable or browse for an existing variable.
You can also edit some of the element's properties in the Properties window. To open the window, right-click the Receive element and choose Properties or choose Window > Properties (Ctrl-Shift-7) from the main menu. You can edit the information by clicking on the ellipsis button. You cant edit the shadowed information from this window, to change it open the property editor as described above.
The Correlations tab in the Reply Property Editor dialog box enables you to examine or specify a correlation set.
The tab shows:
Names of correlation sets
The initiation of a correlator
For more information see Understanding Correlation. Using the Correlation Wizard.
Partner Link elements identify the parties that interact with your business process. Each link is defined by a partner link type and a role name.
The type determines the relationship between a process and its partners by defining the roles played by each service in a conversation. The relationship is further determined by specifying the port type provided by each service to receive messages. Each role specifies one port type in the WSDL file.
Roles determine the conversational aspect of this process or its partner. You use a single role for a synchronous operation as the results are returned using the same operation. You use two roles in an asynchronous operation as the partner role switches during a callback.
It is easy to confuse partner links and partner link types, however:
Partner link types and roles are special WSDL extensions defined by the BPEL specification. As such, they are defined in WSDL files, not in the process BPEL file.
Partner Link is a BPEL 2.0 element. It is defined in the process BPEL file.
Partner link types are prerequisites to the Partner Link element definition. A Partner Link element can only be defined by referring to a particular partner link type and role which, as mentioned, must be defined in a WSDL file.
To add the Partner Link element to the BPEL process, do one of the following:
Drag the Partner Link element from the Palette to the diagram.
Drag a WSDL file node from the same project in the Projects window to the diagram.
Drag a WSDL file node from a different project in the Projects window to the diagram.
Drag a web service node from an EJB project or a Web Application project in the Projects window to the diagram.
Note: When you drag the web service node, the BPEL Designer retrieves the WSDL file from the Application Server. To successfully retrieve the WSDL file, the Application Server has to be running and the web service project must be deployed.
When you drag the Partner Link element, a WSDL file node, or a web service node to the diagram, the Partner Link Property Editor appears.
The Partner Link Property Editor dialog box enables you to establish partner links for your BPEL processes.
The Partner Link Property Editor is invoked by double-clicking a Partner Link element on the diagram, or right-clicking the Partner Link element and choosing Edit. The Partner Link Property Editor also appears when you drag the Partner Link element, a WSDL file node, or a web service node to the diagram.
With the Partner Link Property Editor, you can specify:
The Partner Link name
The WSDL file associated with the Partner Link
Further on you can choose whether to use the existing partner link type or create a new partner link type.
If the WSDL file you selected contains partner link types, the Use Existing Partner Link Type option is selected and the Partner Link Type drop-down list is populated with the partner link types found in the WSDL file. You can use one of the existing partner link types or select the Use a Newly Created Partner Link Type option to create a new partner link type.
If the WSDL file does not contain partner link types, the Use a Newly Created Partner Link Type option is selected.
Use Existing Partner Link Type
Choose the partner link type from the drop-down list. The My Role and/or Partner Role fields are filled in automatically.
To swap the roles of the business process itself (My Role) and the partner (Partner Role), click the Swap Roles button.
Use a Newly Created Partner Link Type
Specify the WSDL file in which to add a partner link type. You can do one of the following:
Add the partner link type to the wrapper WSDL file, as suggested by the IDE in the Create in File field by default. If you choose this option, the IDE will automatically create the wrapper WSDL file in your project structure. You can use wrapper WSDL files when the original WSDL file is read-only or when you do not want to modify the original WSDL file. The original WSDL file will be imported to the newly created wrapper WSDL file.
Add the partner link type to a WSDL file within your project. Click Browse and locate the WSDL file in which to add the partner link type.
Specify the partner link type name.
Specify the role of the business process itself (My Role) and/or the role of the partner (Partner Role) as follows:
Select the appropriate checkbox.
Specify the role name.
Choose the port type from the drop-down list.
You can also review and modify the Partner Link's properties in the Properties window invoked by right-clicking the element and choosing Properties.
The partnerlinks are put to the left and to the right margin of the process diagram. Service requestors are placed on the left side, service providers are placed on the right side. To define the role and to choose the appropriate side for each partnerlink the IDE uses the order of roles defined for the partnerLinkType in the WSDL file. The role defined first in the partnerLinkType in the WSDL file is considered to be a service role, the second defined role is considered to be the role for the requestor and callback receiver. If the roles are defined in the reverse order in the wsdl file (the callback receiver role is defined on the first place, and the service role on the second place) then you get the improper partnerlink layout in the BPEL process diagram, though the operation is not damaged. If a partnerlink appears on the wrong side you probably have to go to the WSDL file and swap places for the role definitions in the partnerLinkType.
Sometimes you need to communicate with partner services whose endpoints are not known beforehand or you need to change an endpoint reference (EPR) during the process execution. The Dynamic Partner Links feature allows you to dynamically assign an endpoint reference to the partner link. This means you can use one partner link for communication with several web–services as long as these services have the same interface.
Each partner link has abstract information and concrete information defined. While the abstract information describing web-service interface should be static, the concrete access information such as address and port can be discovered and used dynamically.
For successful deployment of the process a partner link should be completely defined. It means that when you deploy the project, the WSDL file for the partner link should contain both the abstract and the concrete information for the partner link defined, including address and port, though later the concrete information can be changed independently from the WSDL file.
The BPEL specification mandates that only the partner EPR can be changed dynamically. In BPEL terms, only the partnerRole of a partnerLink element can have a new value assigned. The myRole value doesn't change after the BPEL has been deployed.
To assign a new EPR to a partner link you can use the standard Assign activity and the BPEL Mapper.
The EPR information can be provided in different ways:
you can provide it as a literal (type endpoint reference information manually into a literal) and map it to the partner link
use an incoming message to extract the endpoint address
use a variable of the Service Reference type
copy EPR from one partner link to another
If you use an incoming message, an EPR schema should be defined as a part of the message in WSDL. To assign the EPR to a partner link, use the message variable.
Create a new Assign activity in the process.
Open the BPEL Mapper
In the target tree on the right, find the partner link to which you want deliver a new concrete part.
In the source tree, find a variable containing the new endpoint address
The address of the web-service can be defined in terms of different schemas, and the JBI container requires a special data type called ServiceRefType which is a simple wrapper for any endpoint-describing data type.
To wrap your data:
In the mapper toolbar, choose BPEL > Wrap with Service Reference.
This function is a doXslTranform function that uses a predefined XSL-style sheet.
This function is a doXslTranform function that uses a predefined XSL-style sheet. A new concrete part is assigned to the partner link.
The runtime supports only schemas included into WS-BPEL 2.0 specification. The WS-Addressing schema is not included in the BPEL specification and as a result it is not supported by the BPEL runtime. When the WS-Addressing schema is used for the first time it is copied from NetBeans global catalog to the BPEL Module project source root and further the project refers to the local copy of the schema. The adressing.xsd schema also appears among the Module's procees files in the Projects window.
The Assign activity assigns values to variables. You use the Assign element to copy data from one variable to another, construct and calculate the values of expressions, and store new data in variables. Expressions are required to perform simple computation or operate message selections, properties, and literal constants to produce a new value for variables. The Assign activity can contain one or more elementary assignments.
Use the BPEL Mapper to define the copy rules for the Assign activity or add expressions. For more information, refer to the Assign Activity Scenario section of the guide.
The BPEL Mapper windows opens when you select the Assign activity on the diagram. If this window is not visible, you can invoke it manually, by choosing Window > Other > BPEL Mapper from the main menu.
The Properties window of the Assign element, invoked by right-clicking the element and choosing Properties, contains two properties:
Name. This is the name of the element
Assignments Count. This is the number of assignment rules specified for the element.
The Empty element has no operation associated with it. It is usually used as a placeholder within a process, to catch and suppress faults, or to help synchronize actions within a flow activity that are executed concurrently.
The Empty element can be used when someone else will be implementing a business process, or when the activities within a flow activity need to be synchronized.
Drag the Empty element from the Palette to the diagram.
Use a Wait element to specify a wait condition based on a unit of time or a duration.
Drag the Wait element from the Palette to the diagram. Like other elements, it must be placed in the correct position in the process flow; otherwise you will not see the element in the diagram.
Right-click the element in the diagram and choose Properties to invoke a Properties window. Using the Properties window, you can specify:
The name of the element.
The alarm type. The available options are:
For – specifies a duration for the process to wait
Until – specifies the time until which the process is delayed.
For/Until. Clicking the ellipsis button (...) invokes a dialog box where you specify the time in accordance with the selected expiration type.
Use this activity to signal an internal fault.
In defining the properties of this element, you can specify a fault name and a fault variable. These details can then be passed onto a fault handler that is configured to deal with this kind of exception.
The properties of the Throw element can be configured via the Properties window invoked by right-clicking the element and choosing Properties. The options are:
Name
Fault Name. Clicking the ellipsis button (...) invokes the Fault Name dialog box where you can choose the fault from the list that includes faults defined in WSDL files.
You can use the WSDL Editor to add fault definitions to the WSDL file. For more information, see the Configuring Port Types Using the WSDL View section of the Developer Guide to the WSDL Editor.
Fault Variable. Click the ellipsis button (...) to specify the name of the variable, already declared in the BPEL file, that will contain the fault message.
The Rethrow activity can only be used within a fault handler. The Rethrow activity is used to rethrow the fault caught by the fault handler. Before adding the Rethrow element to the BPEL process, you should add a Fault Handler element to the Process or Scope element and add a Catch or Catch All element to the Fault Handler container.
If you have not added a Fault Handler container to the diagram, in the Design view right-click the Scope or Process element and choose Add > Add Fault Handlers.
Right-click the Fault Handler container and choose Add > Add Catch or Add > Catch All.
Drag the Rethrow element from the Palette to the diagram and place it inside the Catch or Catch all element of the Fault Handler container.
There are no properties to be defined for the Rethrow element as it rethrows the fault caught by the fault handler.
Use this activity to halt the execution of an activity or a process: either within the process, within a structured activity, or within a handler.
In the Design view, drag the Exit element from the Palette to the diagram.
Note: The BPEL runtime does not support Exit within the Flow and On Alarm elements, or within the On Event child of the Event Handler element.
The Compensate activity can only be used within Catch, CatchAll, Compensation Handler or Termination Handler elements.
The Compensate activity causes compensation of all scopes immediately enclosed into the scope containing the fault handler, compensation handler or termination handler with the Compensate activity.
From the Palette, drag the Compensate activity and place it inside the Catch, CatchAll, Compensation Handler or Termination Handler element on the diagram. The Compensate activity requires no property configuration, its behavior is pre-defined.
The Compensate activity can only be used within Catch, CatchAll, Compensation Handler or Termination Handler elements.
The Compensate Scope activity enables compensation for one specified Scope or Invoke element enclosed into the scope that contains the handler with the Compensate Scope activity by invoking the compensation handler of the Scope or Invoke element.
From the Palette, drag the Compensate Scope activity and place it inside the Catch, CatchAll, Compensation Handler or Termination Handler element on the diagram.
Right-click the Compensate Scope element and choose Properties.
In the Properties dialog box, configure the following:
Name. Enter an arbitrary name.
Target. From the drop-down list, select a scope or an invoke activity to be compensated.
Documentation. Optionally, write a comment on the activity.
The If activity supports conditional behavior of a business process instance. The If activity consists of conditional branches defined by the If and Else If elements, followed by an optional Else branch. The conditions on If and Else If branches are evaluated in the order they appear. During execution, the first branch whose condition holds true is taken and provides the activity specified for the If activity. In other words, if there are several Else If branches whose conditions hold true, only the first of them will be executed.
If none of the branches evaluates to true, then the Else path is chosen. If the Else branch is not explicitly specified, this branch is considered to contain an Empty activity. The If activity is complete when the activity of the selected branch completes.
In the Design view, drag the If element from the Palette to the diagram.
Double-click the If element on the diagram or select the Mapper tab on the toolbar, the BPEL Mapper opens.
Specify the condition for the If element using the BPEL Mapper. For more information, refer to the If Activity Scenario section of the guide. You can also specify the condition manually in the Properties window, invoked by right-clicking the element and choosing Properties.
(Optional) In the Properties window, enter the name for the If element.
Add the element that will be executed if the condition is true into the If element. Configure the nested element. If you add another element into the If element, the nested elements are automatically wrapped in the Sequence element.
Add other branches (Else If and Else) as described below.
Right-click the If element and choose Add Else If.
Add an activity to the Else If that will be executed if the condition defined for this Else If element is true. To define a condition, use the BPEL Mapper.
(Optional) Add more Else If activities by choosing Add Else If and add activities to them.
Drag the activity you want to be executed on the Else branch onto the connector path marked with a slash mark. Configure the nested activity.
In the Design view, drag the Else If branch that you want reordered and drop it onto the placeholder that appears next to another Else If branch.
Use the While element to repeatedly execute one or more activities as long as specific conditions are in place at the beginning of each iteration. This element contains other elements that are repeated while success criteria you specify are met. If the condition you specify leads to false, none of the activities listed will be executed.
Note: the While element first checks the validity of the condition and then executes the iterative activity. Conversely, the Using the Repeat Until Element element first executes the activity and then checks the validity of the condition.
In the Design view, drag the While element from the Palette to the diagram.
Drag an activity that will be repeatedly executed and place it inside the While element. If needed, configure the activity's properties.
Use the Properties window to specify the name and condition of the While element. You can enter the condition manually or use the The BPEL Mapper to generate the condition for you. To open the BPEL Mapper window, choose Window > BPEL Mapper or right-click the While element on the diagram and choose Show BPEL Mapper.
Use the Repeat Until element to repeatedly execute one or more activities as long as specific conditions are in place after the execution of each iteration. This element contains other elements that are repeated until the success criteria you specify are met. If the condition you specify leads to true, the activities listed will be executed once.
Note: the Repeat Until element first executes the iterative activity and then checks the validity of the condition. Conversely, the While element first checks the validity of the condition and then executes the activity.
In the Design view, drag the Repeat Until element from the Palette to the diagram.
Drag activities that will be repeatedly executed and place them inside the Repeat Until element. If needed, configure the activity's properties.
Use the Properties window to specify the name and condition of the Repeat Until element. You can enter the condition manually or use the The BPEL Mapper to generate the condition for you. To open the BPEL Mapper window, choose Window > Other > BPEL Mapper or right-click the Repeat Until element on the diagram and choose Show BPEL Mapper.
Use the For Each element to repeatedly execute its contained scope activity exactly N+1 times where N equals the Final Counter Value minus the Start Counter Value.
In the Design view, drag the For Each element from the Palette to the diagram.
Add elements that will be repeatedly executed from the Palette into the For Each element. The elements that you add are automatically wrapped into the Scope element.
Right-click the For Each element and choose Properties to open its Properties window.
The Properties window for the For Each element includes the properties listed below.
Name. Specifies the name of the For Each element.
Counter Variable Name. Declares the counter variable name.
Start Counter Value. Sets the start counter value. Use The BPEL Mapper to generate an integer value expression.
Final Counter Value. Sets the final counter value. Use The BPEL Mapper to generate an integer value expression.
When the For Each activity is started, the expressions in Start Counter Value and Final Counter Value are evaluated for the first and only time. That is, once the two values are returned they remain constant for the lifespan of the activity. If the Start Counter Value is greater than the Final Counter Value, then no iteration will be performed.
Completion Condition (Optional). Specifies an integer value expression. After execution of each directly enclosed activity, the number of completed activities is checked against this value. When the number of completed activities equals the value of the specified expression, no further activities are started. When the expression value is greater than the available number of iterations, then no iteration will be started.
Count Completed Branches Only (Optional). If this checkbox is selected, it tells the runtime to only count the branches that have completed successfully. If this checkbox is cleared, all branches, completed successfully or unsuccessfully, will be counted.
The Pick element blocks the process and waits until one of the specified events occurs. After the specific event occurs, the activity associated with this event is performed. The possible events are the arrival of a message or a timer-based alarm. The occurrence of the events is mutually exclusive. If more than one of the events occurs, then the selection of the activity to perform depends on which event occurred first.
The Pick activity provides two branches, On Message and On Alarm. The branch whose condition is satisfied first (i.e. a message is received or the specified timer expires) is executed. When you add a Pick element to your diagram, it automatically includes one On Message statement in which you specify the properties of the message that the process awaits from a partner service. Each Pick element must include at least one On Message statement. The On Alarm branch contains a timer you can use to specify how long the process is to wait.
In the Design view, drag the Pick element from the Palette to the diagram.
For the On Message branch, configure the properties of the message for which the process is waiting. The configuration is similar to that of the Usage element.
From the Palette, drag the activity that will be executed and place it inside the On Message branch. Configure the activity's properties.
(Optional) Add more On Message branches by choosing Add > On Message from the pop-up menu and configure them as described above.
(Optional) Add one or more On Alarm branches following the procedure below.
Right-click the Pick element and choose Add > On Alarm from the pop-up menu.
Configure the timer via the Properties window, invoked by right-clicking the element and choosing Properties. The available options are:
Alarm Type — used to choose the type of alarm. The type can be one of the following:
For — specifies a duration for the process to wait.
Until — specifies a deadline for the process.
For/Until — used to configure the deadline or the duration for the chosen alarm type. Click the ellipsis button (...) to specify the time. You can also use the The BPEL Mapper.
Find the activity you want executed after the time expires, and drag it from the Palette to the placeholder inside the On Alarm element.
(Optional) Add one or more On Alarm branches as described above.
The Properties window for the Pick element, invoked by right-clicking the element and choosing Properties, includes the following fields:
Create Instance. If set to yes, a new process instance will be created when the specified event occurs. If you do not plan to start a new process instance, keep the default N/A value.
Name. This is used to specify the name for the element.
Use the Flow element to define a set of activities that will execute concurrently (in parallel).
The Flow activity is a structured activity, containing other activities separated into individual control paths or branches. You can embed as many paths in the activity as you want, and they will all be executed simultaneously.
During execution, each path is executed concurrently, and the activities on each are executed in the order in which they appear, unless they are the source of a link. When the activities are the source of a link, the condition of the link and the join condition of the activity must be evaluated. If the link conditions that lead to an activity conflict with those of its join condition, then a fault is thrown on that activity.
In the Design view, drag the Flow Element from the Palette to the diagram.
Drag an element to the placeholder inside the Flow element. If you add another element into the same branch of the Flow element, the elements within a branch are automatically wrapped in the Sequence element.
You can add one or more branches to the Flow element. The Flow element has a special user interaction style. It always shows a placeholder for the next branch that you might wish to add. To add a new branch, drag an element from the Palette to the immediately available "next branch" placeholder.
To change the order of activities inside the Flow element:
In the Design view, right-click the Flow element and select Change Order.
Select an element and use the Move up or Move down buttons to change the position of the element inside the container.
Use the Sequence element to nest a series of activities into your process. The activities within a sequence will execute in strict sequential order. Process execution returns to the business process when the last activity within the nest has completed.
Drag the Sequence element from the Palette to the diagram.
You can add one or more child activities to the Sequence. The Sequence element has a special user interaction style. It always shows one or more valid placeholders for the next activity that you might wish to add. To add a new child activity, drag and drop an element from the Palette onto the immediately available next or previous activity placeholder.
To change the order of activities inside the Sequence element:
In the Design view, right-click the Sequence element and select Change Order.
Select an element and use the Move up or Move down buttons to change the position of the element inside the container.
The Scope activity is essentially a collection of child activities that can have their own Variables, Fault and Event Handlers, and correlation sets. The Scope activity provides the behavior context for the child elements. The attributes defined for a parent Scope have local visibility inside this Scope. For example, the variables declared for a Scope are visible only inside that Scope and all nested Scopes. These variables can then be used for the child activities of this Scope.
In the Design view, drag the Scope element from the Palette to the diagram.
Right-click the element and choose Add from the pop-up menu to add the following:
In the Design view, drag elements from the Palette and place them inside the Scope element.
Configure the elements.
(Optional) Specify the name of the Scope element in the Properties window, invoked by right-clicking the element and choosing Properties.
Variables in BPEL programming function just as they do in other programming languages: they hold temporary values, form parts of expressions, or are passed as parameters to external partners. Normally, you need a variable for every message sent to or received from a partner service. The BPEL Designer supports the following types of variables:
WSDL Message type. These variables correspond to web service message types that are defined in WSDL files imported by the process. In a BPEL file ( .bpel), these variables must specify a value for the messageType attribute. Message type variables are used to hold data in interactions between the process and its partner services.
XML Schema type. These variables correspond to simple or complex XML Schema data types. The XML schema types themselves are defined in XML Schema files (.xsd) or in WSDL files that are imported into the process. In a BPEL file, variables of this type must specify a value for the type attribute.
XML Schema element. These variables correspond to XML Schema elements.The XML schema elements themselves are defined in XML Schema files (.xsd) or in WSDL files that are imported into the process. In a BPEL file, variables of this type must specify a value for the element attribute.
Built-in type. Variables of this type are standard simple types defined in the XML Schema specification.
Global and Local Variables
The variables defined at the Process root are global variables, which have a global visibility throughout the entire process. The variables defined within a particular Scope are visible only inside that Scope and all nested Scopes. These variables are called local variables. A variable defined for an inner Scope element can hide an upper defined variable of the same name.
The name of a variable must be unique among the names of all variables defined within the same Scope.
Right-click the Process or Scope element and select Add > Variable.
In the Create New Variable dialog box, name the variable. The name should be unique within this Scope element.
Expand the node corresponding to the type of the new variable and select its type. You have the following options:
Built-in Types. Expand the Built-in Types node, select the type's name, and click OK.
Message Type. Expand a .wsdl file node, select a message type and click OK.
XML Schema. Expand an .xsd file node or a .wsdl file that contains an embedded schema. Expand the Global Complex Type, Global Simple Type, or Global Elements Simple nodes, select the appropriate type, and click OK.
For your convenience, global types of variables are displayed in bold.
(Optional) Clear the Show Imported Files Only checkbox to view the contents of non-imported WSDL and XML schema files.
Click OK.
By default, the Create New Variable dialog box only shows those files that have already been referenced in the process. However, the project may contain other WSDL and XSD files which have not yet been imported into the process. If you select a type for the new variable that is defined in a non-imported file, the IDE will automatically add the required import to the BPEL process.
You can also add variables from the The Navigator Window window. To add a variable, select BPEL Logical View in the Navigator, expand your BPEL Module project's node, right-click the Variables node and choose Add Variable.
In the Navigator window, select BPEL Logical View.
Expand BPEL Module project's node > Variables and double-click the variable you want to edit.
In the Property Editor dialog box for the variable, change the variable type and name.
Click OK.
The section describes how to use the BPEL Mapper.
The BPEL Mapper provides a framework for processing and directing BPEL process data. This framework consists of the following components:
Menu Bar. The menu bar provides operators, necessary elements, and XPath functions you use to create BPEL mappings. You can also enhance or extend BPEL mappings by incorporating predicates that consist of XPath functions.
On the right side of the menu bar, you can use the following buttons to work with function boxes, or functoids:
Expand Mapped Nodes. Expands all mapped nodes.
Collapse All. Collapses all function boxes. This command is useful when you work with numerous function boxes in the mapping pane.
All. All nodes are displayed.
Output. Only connected nodes wil be dispayed.
Source tree pane. The source tree pane is placed on the left and contains a tree component that provides access to a business process's data variables and partnerlinks.
Mapping pane. The mapping pane contains a canvas for creating BPEL mappings. When you select a function from the menu bar, a function box appears in the mapping pane. If the function accepts any arguments, then the left side of the function box has one connector for each argument. If an argument is optional, then a question mark appears after the argument name. The right side of the function box has one connector for the result. You can use the BPEL Mapper with the following business process elements:
Assign activity. You can define one or more copy assignments.
If activity. You can define the condition.
Else If element within an If activity. You can define the condition.
For Each activity. You can define the condition.
Repeat Until activity. You can define the condition.
While activity. You can define the condition.
Wait activity. You can specify the deadline or duration.
onAlarm event.You can specify the deadline or duration..
Destination tree pane. This pane is placed on the right. Tree component of the destination pane depends on the business process element that you are mapping. The pane contains the following components:
For an Assign activity, the right pane contains the same tree component as the left pane.
For an If activity, Else If element, For Each activity, Repeat Until activity, and While activity, the right pane contains a Result node.
For the Wait activity, the right pane contains a Deadline or Duration node.
Open the BPEL diagram and do one of the following:
Double-click the element that requires BPEL Mapper. The Mapper tab opens.
Select an element that requires the mapper and on the diagram toolbar click the Mapper tab.
If you want to see the mapper and the diagram of the process at the same time, you can place the mapper to a separate window. For more information see Cloning Document Views.
You can create a mapping from the source tree pane directly to the destination tree pane, without using any of the functions. This type of mapping can be any of the following:
Variable to variable
Part to part
XSD element to XSD element
XSD attribute to XSD attribute
Partner link to partner link
You can also create a mapping that uses one or more XPath functions from the BPEL Mapper's menu bar. For example, if the BPEL process includes a Wait activity that waits for a period of time, then you can use the Duration Literal function to specify the duration.
In the source tree pane, expand the tree component until the node that you want to map from appears.
If the destination tree pane contains a tree component, then expand the tree component until the node that you want to map to appears.
Select the node in the source tree pane and drag the pointer to the node in the destination tree pane.
A link connects the nodes.
In the destination tree pane, expand the tree and select the node you want to map to. A blue area appears on the mapping pane. The functions you choose will appear here.
Click the drop-down menu that contains the function.
Click the function.
A function box appears in the mapping pane.
Map any arguments into the appropriate connector on the left side of the function box. The source can be a node in the source tree pane or the output from another function box. If an argument is optional, then a question mark appears after the argument name.
Map the result from the right side of the function box. The destination can be a node in the destination tree pane or the input into another function box.
The BPEL Mapper enables you to create a predicate that consists of XPath functions.
A predicate applies a condition to a node that can have multiple values. The result is the subset of nodes that satisfy the condition.
For example, assume that a node represents the number of products. If you want to select all products whose number is greater than 50, then you can use the greater than and number literal functions to define the condition.
Only certain types of nodes allow you to create predicates. The pop-up menu of these nodes contains the New Predicate option. When you expand the tree component in the source tree pane, the nodes that can have predicates are marked with an asterisk (*).
Once you create a predicate, you can use the predicate in an assignment. For example, you can copy data from a predicate in the source tree pane to a node in the destination tree pane.
You can edit or delete an existing predicate.
In the source tree pane, right-click a node that is marked with an asterisk (*) and choose New Predicate.
The Predicate Editor appears.
Use XPath functions to create the condition for the predicate. Map the result to the predicate node in the destination tree pane.
Click OK.
The editor adds the predicate node immediately below the original node. The condition appears in brackets.
In the source tree pane, right-click the predicate node and choose Edit Predicate.
Modify the condition.
Click OK.
A collection of XPath functions are available in the BPEL Mapper's menu bar. These functions are based on the XPath 1.0 specification.
Each function has zero or more arguments. Each function returns a single result.
The menu bar contains the following drop-down menus: Datetime, Operator, Boolean, String , Nodes, and Number.
The Datetime menu contains the following functions:
Duration Literal enables you to enter a duration literal. Use the format specified in the XML Schema specification.
Current Time provides the current time.
Current Date provides the current date.
Current Date and Time provides the current date and time.
The Operator menu contains the following functions:
Greater Than
Greater or Equal
Less Than
Less or Equal
Addition
Subtraction
Multiplication
Div or division operator returns the quotient for a given dividend and divisor.
Mod or modulus operator returns the remainder for a given dividend and divisor.
Negative
Not Equal
EQUAL
The Boolean menu contains the following functions:
True returns true.
False returns false.
AND uses the following logic: If both arguments are true, then the function returns true. If either argument is false, then the function returns false.
OR uses the following logic: If either argument is true, then the function returns true. If both arguments are false, then the function returns false.
Not uses the following logic: If the argument is false, then the function returns true. If the argument is true, then the function returns false.
Lang returns true or false depending on whether the language of the context node is the same as or is a sublanguage of the language specified in the argument.
Boolean converts the argument to a boolean. For detailed information about the logic, see the XPath 1.0 specification.
The String menu contains the following functions:
Contains uses the following logic: If the first argument string contains the second argument string, then the function returns true. Otherwise, the function returns false.
Normalize Space returns the argument string with whitespace normalized by stripping leading and trailing whitespace and by replacing sequences of whitespace characters with a single space.
String converts an object to a string.
Starts With uses the following logic: If the first argument string starts with the second argument string, then the function returns true. Otherwise, the function returns false.
String Length returns the number of characters in the string.
Substring returns the substring of the first argument starting at the position specified in the second argument with the length specified in the third argument. The position of the first character is 1, the position of the second character is 2, and so on. The third argument is optional. If the third argument is not specified, then the function returns the substring starting at the position specified in the second argument and continuing to the end of the string.
Substring Before returns the substring of the first argument string that precedes the first occurrence of the second argument string in the first argument string. If the first argument string does not contain the second argument string, then the function returns an empty string.
Substring After returns the substring of the first argument string that follows the first occurrence of the second argument string in the first argument string. If the first argument string does not contain the second argument string, then the function returns an empty string.
Translate returns the first argument string with occurrences of characters in the second argument string replaced by the character at the corresponding position in the third argument string.
Concat returns the concatenation of the arguments.
String Literal enables you to enter a string literal.
The Nodes menu contains the following functions:
Local Name returns the local part of the expanded name of the node in the argument node-set that is first in document order. (An expanded name consists of a local part and a namespace URI.)
Name returns the qualified name that represents the expanded name of the node in the argument node-set that is first in document order. (An expanded name consists of a local part and a namespace URI.)
Namespace URI returns the namespace URI of the expanded name of the node in the argument node-set that is first in document order. (An expanded name consists of a local part and a namespace URI.)
Position returns the context position.
Last returns the context size.
Count returns the number of nodes in the argument node-set.
The Number menu contains the following functions:
Number converts the argument to a number. For detailed information about the logic, see the XPath 1.0 specification.
Number Literal enables you to enter a number literal.
Round returns the number that is closest to the argument and that is an integer.
Sum returns the sum, for each node in the argument node-set, of the result of converting the string values of the node to a number.
Floor returns the largest number that is not greater than the argument and that is an integer.
Ceiling returns the smallest number that is not less than the argument and that is an integer.
These examples illustrate several mapping scenarios:
Assume that you want a BPEL process to copy data received from a partner. Do the following tasks:
Add an Assign activity after the Receive activity.
Use the BPEL Mapper to define one or more copy assignments. To open the BPEL Mapper, double-click the Assign activity on the diagram or select the Mapper tab on the toolbar.
The following example shows a copy assignment that does not use any XPath functions. The itinerary part of the ItineraryIn variable is copied to the itinerary part of the ItineraryOut variable. Notice that the left pane and the right pane contain the same tree component.
The following example shows a copy assignment that uses the concat XPath function. The input variable paramA is concatenated to the end of the string literal Parameter A: and copied to the output variable paramA.
Assume that you want to execute a series of steps only if a certain condition is true. Do the following tasks:
Add an If activity to the BPEL process.
Use the BPEL Mapper to define the Boolean condition. To open the BPEL Mapper, double-click the If activity on the diagram or select the Mapper tab on the toolbar.
Add the steps inside the If activity.
The following example shows a mapping for the condition. The mapping uses the Not XPath function, which is available from the Boolean node on the menu bar. If the itinerary has an airline reservation, then the Not XPath function returns true. The result is mapped to the Result node in the right pane.
Assume that you want a BPEL process to copy itinerary data from itineraries of customers with no more than two in their party. The input records include a variable that specifies the number of passengers in the customer's party. Do the following tasks:
In the left pane of the BPEL Mapper window, right-click the repeating node that is marked with an asterisk (*) and choose New Predicate.
The Predicate Editor window appears.
Add the Less Than XPath function to the middle pane.
Add the number literal XPath function to the middle pane. Set the value to 3.
Map the variable node to the first argument of the Less Than XPath function.
Map the result of the number literal XPath function to the second argument of the Less Than XPath function.
Map the result of the Less Than XPath function to the Result node in the right pane.
Click OK.
The following example shows how the mapping appears in the Predicate window. Once you click OK, you can use the predicate node in a copy assignment.
If the BPEL process received the following XML, then the predicate would select the first Air tag.
<Air> <NumberInParty>2</NumberInParty> </Air> <Air> <NumberInParty>4</NumberInParty> </Air> <Air> <NumberInParty>6</NumberInParty> </Air> |
The following sections describe, in order of their appearance:
The circumstances under which you would use a specific handler.
The use of those elements within the context of the BPEL Designer.
The BPEL language provides the capability to catch and manage exceptions using fault handlers. For example, exceptions occur when web services return different data than was expected. If faults are not handled, the entire BPEL process can be thrown into a faulted state. Therefore, to prevent the entire process from fault, you can add fault handlers to catch and manage exceptions within particular Scopes.
Each fault handler contains an activity that runs in case of an error. For example, a partner service is notified if an error has occurred. Fault handlers can be added to the entire process or to individual Scope elements.
You can attach one Fault Handler container to either the Process or the Scope elements. Inside the Fault Handlers container, you can create several Catch activities configured to catch specific kinds of faults, or one Catch All handler element to catch all the exceptions not caught by specific handlers.
Right-click the Scope or Process element and choose Add > Fault Handlers.
An empty container element appears.
Right-click the Fault Handler container and choose Add > Catch or Add > Catch All.
You may add as many specific Catch elements as you wish to the Fault Handlers group. You can add only one Catch All element per Fault Handlers container.
Add an activity to the Catch or Catch All element that will be executed in case of a fault.
Use this element to intercept and deal with a specific kind of fault.
This element is used within an appropriate Fault Handlers container element.
The properties of the Catch element are defined in the Properties window. You can also right-click the element on the diagram and choose Properties. The available properties are:
Fault Name. Select the qname of the fault from the list of faults, which contains faults defined in the WSDL files.
Fault Variable Name. Specify the name of an existing BPEL variable that will contain the fault message.
Fault Variable Type. Specify the type of the variable.
Use the Catch All element to intercept and deal with all faults that are not caught by an associated catch element.
The Catch All element is used within a fault handler window along with one or more Catch elements. It is defined within a Fault Handlers container element along with one or more Catch elements.
There are no properties for the Catch All element. Its behavior is pre-defined and requires no property configuration.
The entire BPEL process as well as each individual Scope can be associated with a set of Event Handlers that are invoked concurrently if the corresponding event occurs. The actions taken within an Event Handler can be any type of activity, such as Sequence or Flow. The only immediate child of an Event Handler is Scope, so when you drag an element from the Palette into an Event Handler, it is automatically wrapped in Scope.
There are two types of events:
Incoming messages, which correspond to a request/response or one-way operation in WSDL. These messages are specified using the On Event elements.
Alarms, or timers, which invoke activities after the specified periods or when a deadline is reached. The times are specified using the On Alarm elements.
Right-click the Process element or any Scope and invoke the Add Event Handlers action. This does not add any particular Event Handler, it adds a container element to which you can then add specific Event Handlers.
Once you have added an Event Handlers container, you can right-click on the Event Handlers element to add an On Event or On Alarm branch. You may add as many specific On Event or On Alarm elements as you wish to the Event Handlers group.
The On Event element indicates that the specified event waits for a message to arrive. The interpretation of this tag and its attributes is very similar to a Receive activity.
Right-click the Event Handlers container and choose Add > On Event.
Double-clicking the On Event element opens a Property Editor where you can specify/change the following:
The partner link
The operation associated with the On Event element
The event variable
Right-clicking the On Event element and choosing Properties opens a Properties window where you can review and modify the properties of the element. In addition to the properties present in the Property Editor dialog box, the Properties window contains the Port Type field, which are filled in when you specify the partner link and operation, and the Type field, which is filled with the type of the specified even variable.
The Correlations tab in the On Event Property Editor dialog box enables you to examine or specify a correlation set.
The tab shows:
A correlation sets' name
The initiation of a correlator
For more information see Understanding Correlation. Using the Correlation Wizard.
The On Alarm element specifies the deadline for or the duration of the nested Scope.
The properties of the On Alarm element are defined in the Properties window, invoked by right-clicking the element on the diagram and choosing Properties. The available properties are:
Alarm Type is used to choose the type of alarm. The available options are:
For. Sets the duration for the process to wait.
Until. Specifies the deadline for the process.
Repeat Every. Specifies the frequency of process initiation. It initiates the process each time the specified duration period expires. The clock for the very first duration starts when the associated scope starts.
For + Repeat Every. Specifies the frequency of process initiation after the duration of a specified wait time. The process is initiated each time the duration period specified in the Repeat Every field expires. The first alarm is fired when the period of time specified in the For field expires.
Until + Repeat Every. Specifies the frequency of process initiation based on the specified deadline. The process will be initiated each time the duration period specified in the Repeat Every field expires. The first alarm is fired when the deadline specified in the Until field is reached.
The second (and third, where available) property is used to specify the duration or deadline for the selected alarm type.
A business process often contains several nested transactions. The overall business transaction can fail or be cancelled after many enclosed transactions have already been processed. Then it is necessary to reverse the effect obtained during process execution. For example, a travel planning process can include several nested transactions to book a ticket, to reserve a hotel and a car. If the trip is cancelled, the reservation transactions must be compensated for by cancellation transactions in the appropriate order. For such cases, WS-BPEL provides you with the capability to define compensation actions. A Compensation Handler is a container for the activities that perform compensation actions. You can add one Compensation Handler to either the Scope or the Invoke elements. The compensation handler can be invoked by Using the CompensateScope ElementUsing the Compensate Element activity.
Right-click the Scope or Invoke element and choose Add > Compensation Handler. An empty container element appears.
From the Palette, drag one or several activities that will be executed and place them inside the Compensation Handler container. Configure the properties of each activity.
You do not have to configure any properties for the compensation handler.
The termination handler is used to control the termination of a running scope. The termination of a running scope happens if a scope or process enclosing it has faulted.
When a fault is thrown inside a scope or process, a fault handler associated with the scope or process should be run, but before that all the running activities inside the faulted scope or process should be terminated. If a faulted scope or process has any enclosed scopes which are still running, they also should be terminated. Terminating a scope means terminating activities inside it and executing the termination handler associated with the scope.
Note that a scope can be terminated only if, it is either running normally, is running its compensation handler or termination handler. A completed scope as well as a scope that is faulted or is running its fault handlers cannot be terminated.
The termination handler is a container for the activities that will be performed in case a scope is terminated. You can add one termination handler for a scope.
If a fault occurs inside the termination handler of a scope, the fault is not propagated to the enclosing scope.
In the Design view right-click the Scope element and choose Add > Termination Handler. An empty container element appears.
From the Palette, drag one or several activities that will be executed and place them inside the Termination Handler container. Configure the properties of each activity.
You do not have to configure any properties for the termination handler.
Correlation mechanism is used to route messages to the right processes. The section describes how to define correlation.
Understanding Correlation. Using the Correlation Wizard
The BPEL Service Engine runtime uses a mechanism called correlation to track the multiple, long-running exchanges of messages that typically take place between a BPEL process and its partner services. The correlation mechanism helps to route messages to appropriate process instances.
A message in a conversation is connected with a composite value made up of one or more properties defined in a WSDL file. A property is a field within a message identified by a query. Queries are specified by special constructs called property aliases.
Thus, correlation sets are used to support stateful collaboration between web services in a standardized, implementation independent way. Correlation sets rely on the correlation data tokens stored in the message envelopes, headers, or business documents themselves. The declaration of correlation relies on the declarative properties of messages.
The following terms apply to correlation:
property is an abitrarily named token. It must be a simple type. It is defined in a WSDL file.
property alias is a rule that tells the BPEL runtime how to map data from a message into a property value. You can define several property aliases for a property that will be used as a correlation value. You would do this if the same property value needs to be mapped from more than one message, which is typical in correlation. For instance, if two different messages have the same part that you want to extract. Then you need one property and two property aliases - one for each message). Property aliases are defined in a WSDL file.
correlation set is defined in a BPEL file. A correlation set is a compound key made up of one or more property values, actually it is a property set. The BPEL runtime uses this key to ensure that messages are routed to the right process instance for a particular conversation.
correlations mark the activities, they identify the correlation sets by name and indicate which correlation sets occur in the messages being sent or received.
Correlation sets can be defined for the Process element. The defined correlation sets are then used by message activities (Invoke, Reply, and Receive), which describe a conversation between a process and a partner service.
Correlation sets on Invoke activities are used to verify that outbound messages contain data that is consistent with the data found within specified correlation set instances.
Correlation set names are also used in the onMessage branches of Pick elements and in the onEvent variant of event handlers.
There are two ways to define correlation:
Use the Correlation wizard which will automatically perform all the main steps. This is the most easy and convenient way to define correlation. Usually you do not have to know in details how does correlation work. The Wizard will make it for you.
Define correlation manually
The Correlation Wizard is used to define correlations for two messaging activities, such as Invoke, Reply, Receive, OnEvent or onMessage branch of Pick element.
The wizard only enables you to create correlation. You can't edit correlation in the wizard.
In the Design view, right click the activity that requires correlation and choose Define Correlation. The Correlation Wizard opens.
Step 1. Select the messaging activity. From the drop-down list choose an initiating messaging activity. The activity chosen here will initiate the correlation set. Click Next.
Step 2. Define the correlation. On the left you see a tree structure of the message that initiating activity sends or receives. On the right you see the structure of the message passed by the correlating activity. Connect the messages parts that should be used to define correlation by selecting the node in the source tree pane and dragging the pointer to the node in the destination tree pane.
The correlation is set. The Wizard will create properties and property aliases in a WSDL file, define a correlation set in BPEL, and associate the correlation set with the activities you chose.
Note that properties and property aliases are written to a new WSDL file that you can see among the process files of the BPEL Module. The original WSDL file for the partner service is imported to the new WSDL. For all correlation created using the Wizard, both properties and property aliases are written to this file. Partner WSDL files are imported. The correlation set defined in the BPEL file refers to the new WSDL.
Define one or more properties in the WSDL file using the WSDL Editor or To add a property to a WSDL file:.
Define property aliases in the WSDL file using the WSDL Editor orTo add a property to a WSDL file:.
Define a correlation set for the Process in the BPEL file, using one or more of the previously defined properties.
To define a correlation set:
In the Design view, right-click the Process element and choose Add > Correlation Set.
Alternatively, in the BPEL Logical View of the Navigator window, right-click the Correlation Sets node and choose Add Correlation Set.
In the Add Correlation Set dialog box, specify the name for the correlation set and click Add to add properties.
In the Property Chooser dialog box, expand the WSDL file node, and select a property to add to the set.
(Optional) Clear the Show Imported Files Only checkbox to view the contents of non-imported WSDL and XML schema files.
By default, the Property Chooser dialog box only shows those files that have already been referenced in the process. However, the project may contain other .wsdl and .xsd files which have not yet been imported into the process. If you select a type for the new property that is defined in a non-imported file, the IDE will automatically add the required import to the BPEL process.
The correlation sets defined for the Process have global visibility. The name of a correlation set must be unique among the names of other correlation sets.
Click OK.
Associate one or more correlation sets with a message that is sent or received in an Invoke, Receive, Reply, or Pick activity.
In the Design view, double-click an element (Invoke, Receive, Reply, the On Message branch of Pick, or the On Event branch of an Event Handlers container element).
In the Property Editor, select the Correlations tab and click Add.
In the Choose a Correlation Set dialog box, expand the Correlation Sets node, select the correlation set and click OK.
Choose the initiate attribute for this correlation set from the Initiate drop-down list. You can select one of the following options:
Yes. The activity must attempt to initiate the correlation set.
Join. The activity must attempt to initiate the correlation set if the correlation set is not yet initiated.
No. The activity must not attempt to initiate the correlation set. This is the default option.
For an Invoke activity, specify the message pattern.
From the Pattern drop-down list, select a pattern attribute to indicate whether the correlation applies to the outbound message (request), inbound message (response), or both (request-response).
(Optional) Add more correlation sets as needed and click OK.
The Sun BPEL Service Engine provides you with the ability to trace the message or expression values during the process execution. The Logging and Alerting feature make use of standart WS-BPEL extension mechanism. Logging and alerting are supported for almost all BPEL activities
The IDE provides you with the ability to define logging and alerting for the process activities. Logging is used to write specified expression values or partner links endpoint reference information to the server log. Alerting allows you to receive an alert with this information. After you set the logging or alerting conditions and the BPEL process is executed, specified expression values are written to the server log file or an alert is sent to the user, depending on the log level.
Both logging and alerting are defined in the Logging mapper. The Logging mapper is available as a tab from the Design or Source view of the BPEL Process.
When defining logging for an activity you can trace the value of the following components :
Variable
Part
Expression
In the mappings you can use one or more XPath functions from the menu bar.
On the diagram, select an activity. The logging will be performed in connection with the activity execution.
Go to the Logging tab of the BPEL Editor. The Logging mapper opens. You can also open the Logging mapper by right clicking the activity and choosing Go To > Logging (Alt-L).
In the source tree pane, expand the variables tree until the variable to be traced is visible.
In the destination tree pane expand the activity node. The nodes designating the moment of logging become visible.
Choose when the logging entry should be made and expand the appropriate node:
LOG_onStart. The variable value is written to the log when the activity starts.
LOG_onComplete. The variable value is written to the log when the activity execution is complete.
Define the level of logging. Drag the connection from the variable to be traced to the appropriate node in the destination tree pane. The following levels of logging are available:
Severe
Warning
Info
Config
Fine
Finer
In the Design view a small icon appears next to the activity with logging defined on it. By clicking the icon you can switch to the Logging mapper.
The entry to the log will be made only if the log level defined for the variable corresponds to the log level specified for the BPEL SE on the application server.
To specify the log level for the BPEL SE, the application server Admin Console is used.
In the Services window, expand the Servers node. Ensure that the GlassFish application server is running. It has to have a green arrow badge next to it. If the server is not running, right click the server name and choose Start from the context menu.
Open the Admin Console in your browser. To do this, follow the steps:
Right click GlassFish V2 application server node, and choose Properties from the context menu. The Servers window opens. On the Servers pane, GlassFish V2 should be selected.
On the Connection tab, copy the contents of the Location field (by default it is localhost:4848).
Paste the string to the browser and press Enter. The Sun Java System Application Server Admin Console opens in the browser window.
Log in to the Admin Console using your username and password. By default, the username is admin and the password is adminadmin.
On the left pane under the JBI node choose Components > sun-bpel-engine. The BPEL service engine properties page opens.
On the BPEL service engine properties page, select the Loggers tab. On the Loggers tab you can specify log levels for the individual loggers.
Choose the appropriate log level for the sun-bpel-engine from the drop down list.
If logging is defined for a process activity, and the log level specified for it corresponds to the log level set for the BPEL SE, after you perform a test run of the process, the selected variable value will be written to the server log file.
The project should be deployed to the application server.
In the Services window, under the Servers node, right click GlassFish V2 application server node and choose View Server log from the context menu. TheGlassFish server log opens in the Output window. The activity message value will be included in the log, you can use Search to find it. Note, that some overhead information is hidden.
You can also open the log in a text editor and see the full information. Navigate to <application server installation directory>/domains/domain1/log/ and open the server.log file with the text editor. The information provided in the log includes the following points, divided with the vertical bar:
Date and time of the entry
Log level
Manager type (for logging this is Trace Manager)
Thread
The message value
Here is the sample of the log entry :
[#|2008-03-25T09:26:18.796+0300|INFO|sun-appserver9.1|com.sun.jbi.engine.bpel.core.bpel.trace.BPELTraceManager|_ThreadID=26;_ThreadName=BPELSEInOutThread8;|<?xml version="1.0" encoding="UTF-8"?><jbi:message xmlns:msgns="http://localhost/SynchronousSample/SynchronousSample" name="input1" type="msgns:requestMessage" version="1.0" xmlns:jbi="http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper"><jbi:part><syn:typeA xmlns:syn="http://xml.netbeans.org/schema/SynchronousSample"> <syn:paramA>Hello World</syn:paramA> </syn:typeA></jbi:part></jbi:message>|#]
Alerting feature enables user to get notification in case specified events happen. Alerting events are connected with the execution of the process activities.
The general workflow for defining alerting is as follows:
Set alerting level for an activity of the process.
Ensure the application server is running and deploy the project.
Choose or Create MBean client and subscribe to getting event notifications.
The client will extract alerting messages and perforn specified actions (write to log/send e-mail/do nothing).Run the process and get notified.
The BPEL Designer has a built-in BPEL code validation functionality that helps developers create well-formed, valid and standard-compliant code. The code is checked for errors and the user is notified if validation fails.
The Validator checks the BPEL process in accordance with the following criteria:
For conformance with the BPEL 2.0 schema.
See the Troubleshooting section of this guide for more information about using BPEL schemas different from the BPEL 2.0 specification.
For compliance with static analysis rules defined in the WS-BPEL 2.0 specification.
For broken references.
For constructs that are valid per the BPEL 2.0 specification but are not yet supported by the Sun BPEL Service Engine.
The BPEL Designer provides two types of validation:
Real-time validation
This type of validation is invoked automatically and does not require any explicit actions from the user. Only the current file is checked. The validation is performed in accordance with all the criteria mentioned above, except for validation for conformance with the BPEL 2.0 schema.
Explicit validation
This type of validation requires that the user explicitly invoke the validation process. All imported XSD and WSDL files are also checked. The validation is performed in accordance with all the criteria mentioned above.
To invoke explicit validation, do one of the following:
In the Source view, right-click the source to invoke the pop-up menu and choose Validate XML (Alt-Shift-F9)
In the Design view, click the Validate XML button (Alt-Shift-F9) on the Editor toolbar.
The user is notified about validation errors or success in the Outpur window, in the Design view, and in the Navigator.
The results of validation appear in the Output window if validation has been invoked explicitly. If validation fails, the Output window contains errors and/or warnings:
If validation is successful, there are no warnings or errors in the Output window.
The Design view shows the results of both real-time and explicit validation in callout windows on the diagram and the error stripe.
In the diagram, a red cross next to an element on the diagram means that the element has not passed validation and the output contains errors. A yellow triangle with an exclamation mark means that the element has not passed validation and the output contains warnings. If there are both errors and warnings, the Design view shows a red cross. If you click the cross or the triangle, a callout window appears with a list of errors and/or warnings:
The callout window includes messages related to validation in accordance with all the criteria listed above. Messages related to the real-time validation are constantly updated.
In the Design view, validation results are also shown by the error stripe, which is a strip to the right of the scroll bar that contains red marks if some elements have not passed validation. The error stripe represents the entire diagram, not just the portion that is currently displayed. You can immediately see if your BPEL process contains errors without having to scroll through the entire diagram. You can click a red mark to jump to the element that causes problems. If no errors are detected, the small square in the error stripe is green.
The Navigator window shows the results of both real-time and explicit validation by adding a red cross or a yellow triangle to the element's icon if validation has failed. For example, in the screenshot below, the AirlineReserved receive activity has not passed validation and the output contains errors.
The section describes how to test and debug BPEL processes.
Testing a deployed business process application involves using test cases that act as remote partner services which send SOAP messages to the BPEL Service Engine runtime.
In simple words, the interaction process is the following: The BPEL Service Engine runtime receives the SOAP message and creates an instance of the BPEL process and starts executing the instance. A BPEL process can have many running instances. The BPEL Service Engine runtime receives a message and, using correlation, routes it to the appropriate instance of the process. If an instance does not yet exist, a new instance is created.
To test-run a deployed business process application, you need to configure test cases to act as remote partner services sending SOAP messages to the BPEL Service Engine runtime.
In order to obtain test results you must do the following:
All steps in this section assume the following:
You have already Creating a new BPEL Module Project containing a WSDL file that defines an operation you want to test.
You have successfully Building a BPEL Module Project.
You have added your BPEL Module project to a Composite Application project as a JBI Module.
To add a test case and bind it to a BPEL operation:
In the IDE Projects window, open the Composite Application project to expose its Test folder.
Right-click Test, and choose pop-up menu item New Test Case.
This launches the New Test Case wizard.
In the Enter the Test Case Name step, enter a name for the test case and click Next.
In the Select the WSDL Document step, open the BPEL Module project, select the .wsdl file containing the operation you want to test, and then click Next.
In the next step, select the operation you want to test, and then click Finish.
In the project tree, under Test, a new folder is created, containing two files: Input.xml and Output.xml.
If you view the test case in the Files window, you see Concurrent.properties as a third file.
To set the test properties:
In the Projects window, under the Composite Application > Test node, right-click the node for the test case and choose Properties from the pop-up menu.
Set the properties of the test case as follows:
Description : string
Destination : URL (from the .wsdl file's <soap:address location="THIS"> tag)
Identifies the location of the web service to be tested.
SoapAction (default: blank)
Input File (read-only; generated by system)
Name of the input file. This file contains the input data for the test case.
Output File (read-only; generated by system)
Name of the output file. This file contains the output data for the test case.
Concurrent Threads : integer; default = 1
Each thread can invoke the test case multiple times (see the following property). Thus, if conc=2 and inv=3, the test case will be run 6 times (two threads, each run thrice).
Invokes Per Thread : integer; default = 1
Number of times each thread invokes the test case.
Test Timeout (sec) : integer; default = 30
How long each thread has to finish. If it does not finish in the allotted time, then an exception is thrown.
Calculate Throughput : boolean
Comparison Type : drop-down list with the following options:
identical: Considers the output and actual output as a stream of characters.
binary: Considers the output and actual output as a stream of bytes.
equals: Considers the output and actual output as a XML documents.
Feature Status : drop-down list with the following options:
progress: Marks test completion as "success", regardless of actual outcome.
done: Records actual outcome of test.
To customize test input:
In the Projects window, expand the Test node and the node for a specific test case.
Right-click Input.xml and click Edit.
Modify the contents as needed. For example, wherever you see <value>?string?</value> click within ?string? and replace it with a string of any length. However, within such strings, do not include the characters < (less-than sign) or & (ampersand) unless you use them with XML semantics.
When you are satisfied, click Save.
Right-click Output.xml and click Edit to examine the contents:
It is empty. This is a special state that triggers a special operation when the test is run.
Each time the test is run, the current output is compared to the contents of Output.xml. If any differences are detected, they will be stored in the Actual_yymmddhhmmss .xml file under the test case folder. However, in the special case where Output.xml starts null, then the output is written to Output.xml.
In each run after the first, assuming Output.xml is no longer null, its contents are preserved. In other words, a previous output is never overwritten by new results.
In the Projects window, expand the Composite Application project > Test, right-click the node for the specific test case and choose Run.
The first run correctly reports that it failed. This happens because the output produced does not match the (empty) Output.xml file, and the file’s null content is replaced with the output of the first run.
Test results are shown in the JUnit test results window, which opens automatically when you run a test case.
If you run the test again without changing the input, second and subsequent runs report success, since the output matches the contents of Output.xml.
If you change the value in the Input.xml and re-run the test, then:
If the feature-status property is set to progress, then the test indicates success even though a mismatch occurred.
If the feature-status property is set to done, then the test indicates failure.
If you right-click the test case node and click Diff in the pop-up menu, the window displays the difference between the latest output and the contents of Output.xml.
Debugging BPEL processes follows the same general principles as debugging Java applications. Debugging BPEL processes involves setting breakpoints in the source code and executing the process step-by-step within a debugging session. The BPEL Debugger visually represents the execution of a BPEL process and allows you to view and change variables, monitor the results of executing expressions, and use fault breakpoints tomonitor the state of variables before a fault is thrown.
The main steps in debugging BPEL processes are:
Confirm that the GlassFish application server has started.
Create test cases.
For sample processes, test cases are automatically created; for new projects, you need to create at least one test case.
Open the BPEL process file either in the Source view or Design view.
Set breakpoints in the code or on the diagram. Optionally, add watches for XPath expressions in your process or add fault breakpoints.
Start a debugging session. Watch the BPEL Debugger Console window for confirmation that the debugging session has started.
Within the debugging session, run one or several test cases.
View execution of BPEL processes on the diagram in the Design view or in the BPEL Process Execution window and view running instances of BPEL processes in the BPEL Process Instances window.
When an instance stops at a breakpoint, step through the code or the diagram, examine the values of variables in the BPEL Variables window, or observe the values of XPath expressions in the Watches window.
Finish the debugging session.
A debugging session begins when you connect the BPEL Debugger to the BPEL Service Engine. Only one debugging session can be running with the BPEL Service Engine at a given time.
After a BPEL debugging session starts, you can execute process instances step-by-step, inspecting the values of BPEL variables and XPath expressions in the Local Variables and Watches windows. You can monitor the execution of a BPEL process within a debugger session on the diagram in the Design view: the activities that are being executed are highlighted on the diagram as the current execution position advances. The BPEL Process Execution window also shows the execution of the BPEL process.
In the Services window, make sure that the GlassFish V2 Application Server is running. The Application Server is running if it has subnodes and is marked with a green triangle.
If the server is not started, right-click it and choose Start from the pop-up menu. For details about how to start the Application Server, see the The BPEL Service Engine section.
In the IDE, open the BPEL process in either the Source or Design view.
Set breakpoints in the BPEL process.
To set breakpoints in the Source view, click next to the line where you want to set the breakpoint.
To set breakpoints on the diagram, switch to the Design view, right-click the element and choose Toggle Breakpoint from the pop-up menu. A red square appears at the top of the element with a breakpoint.
The Toggle Breakpoint pop-up menu command is also available for the elements in the Navigator BPEL Logical View. For the elements with breakpoints, the Navigator shows a small red box (ReceiveItinerary):
Optionally, you can add watches to monitor XPath expressions. To add a watch, copy the XPath expression you want to monitor, choose Run > Add Watch from the main menu, and paste the expression into the Watch Expression field. Click OK.
Note: You can also add XPath expressions that are not present in the code, but that would be valuable from the debugging point of view.
In the Projects window, right-click the Composite Applications project you want to debug and choose Debug (BPEL) from the pop-up menu.
A debug session is established on the BPEL Service Engine. Watch the BPEL Debugger Console window for confirmation. The connection might take some time to complete. When it is successfully completed, you can see the new session in the Sessions window and the following messages in the BPEL Debugger Console:
11:35:17 Connecting to localhost:3343
11:36:19 Debug session started
Note that the Debug (BPEL) command performs the following actions:
Enables debugging with the BPEL Service Engine (sets the DebugEnabled property of the BPEL Service Engine to true)
Builds the Composite Application project and all JBI Modules added to this project
Deploys the Composite Application project to the BPEL Service Engine
Starts the debugging session by connecting the BPEL Debugger to the BPEL Service Engine
Therefore, whenever you start a debugging session you can be sure that the latest version of the BPEL process is deployed on the BPEL Service Engine.
Now you can run a test case and monitor the execution of the BPEL process until it stops or reaches a breakpoint. As the process advances, the current context is displayed on the diagram and in the BPEL Process Execution window.
If you have several debugging sessions (you may have a Java debugging session running at the same time) and want to change the current session, double-click the name of this session in the Sessions window. Alternatively, right-click the session you want to make current and select Make Current. This session becomes current and the BPEL Process Instances, Watches and Local Variables Windows are updated to show the data related to the new current session.
When you want to finish a debugging session, open the pop-up menu for the session you want to stop and choose Finish in the Sessions window or select Finish Debugger Session on the toolbar. A message that the debugging session is finished is displayed in the BPEL Debugger Console.
To finish all debugging sessions, in the Sessions window, right-click any session and choose Finish All.
Breakpoints are used to instruct the BPEL Debugger to stop execution at the specified place of a BPEL process. When a BPEL process instance reaches a breakpoint, it becomes suspended and you can step into the code, change the current process instance in the BPEL Process Instances window, track the execution of the process instance in the BPEL Process Execution window and in the Design view, examine the values of variables in the Local Variables window, view the process partner links in the Partner Links window and view the values of XPath expressions in the Watches window.
You can also use fault breakpoints to check the values of variables before a fault is thrown.
To view and organize the breakpoints currently set in the IDE, open the Breakpoints window by choosing Windows > Debugging > Breakpoints (Alt-Shift-5). For each breakpoint, you can see the name of the file and the line where this breakpoint is located. In the Breakpoints window you can enable and disable breakpoints by checking or removing the checkbox in the Enabled column.
In the IDE, open the BPEL file in either the Source or Design view.
Do one of the following:
In the Source view, click the left margin of the row where you want to place a breakpoint.
In the Design view, right-click an element where you want to place a breakpoint and choose Toggle Breakpoint (Ctrl-F8).
In the Design view, breakpoints are displayed as small red squares on top of specific elements. In the Source view, breakpoints are shown as red squares on the left margins of code lines.
Alternatively, you can set and remove breakpoints in the BPEL Logical view of the Navigator window by choosing Toggle Breakpoint from the pop-up menu. In the Navigator window breakpoints are shown as small red squares attached to elements.
Once the project has reached the breakpoint it is suspended. You can manage the subsequent execution using the commands available in the Run menu or as buttons on the toolbar.
Within the debugging session the following commands are available:
To be able to use these commands you have to start the debugging session and to run a test case.
Pause. Once the user activates this action, the process will continue till it reaches the first element on which it can stop. If there is no current process instance, the debugger will wait for the first execution event from any process instance.
Continue (F5). Once the process has reached the breakpoint or is paused you can choose Continue. This action causes the current process instance to run until it encounters the next breakpoint or until the instance completes. The state of the instance changes to Running.
Step Into (F7). Steps to the next BPEL activity. As you step, the current line indicator advances, the current position is highlighted on the diagram, and the contents of the BPEL Debugger windows change accordingly. If the current activity has any enclosed elements, the process will step to the first enclosed element. Sometimes it is not visible on the diagram but is reflected in the BPEL Process Execution window. For example, if an Assign activity has <copy> element inside it, from the Assign the process will step to Copy.
Step Over (F8). Steps to the next BPEL activity of the same level as the current activity. If the current activity has any enclosed elements, they all are executed without suspension.
Step Out (Ctrl-F7). Steps to the next higher level activity of the process. For example, an Assign activity has several Copy elements inside. If one of the Copy elements is the current activity, performing Step Out will move you to the next activity of the Assign level and you will not have to step through all the Copy elements.
Run to Cursor (F4). Runs the BPEL process to the position selected in the Navigator window (BPEL Logical View), on the diagram (in the Design view) or to the cursor location in the Source view. When the location of the cursor is reached, the process instance becomes suspended.
On the diagram, click on the small red square indicating the breakpoint. This disables the breakpoint but does not remove it completely.
OR: In the Breakpoints window, clear the Enabled checkbox for the breakpoint you want to disable.
The toolbar contains three buttons for group operations over the process breakpoints.
Enable Breakpoints for Selected Element. Enables all the breakpoints for the selected element and it's enclosed elements.
Disable Breakpoints for Selected Element. Disables all the breakpoints for the selected element and it's enclosed elements.
Delete Breakpoints for Selected Element. Deletes all the breakpoints for the selected element and it's enclosed elements. If no element is selected on the diagram, the Process element is considered selected for the operations.
When a running process reaches a breakpoint, the Design view highlights the current position of the debugger and uses colors to differentiate between the states of BPEL activities. As the process advances, the colors and icons for the activities on the diagram are updated to reflect the execution progress.
On the diagram, the following notation is used:
Green color (glowing). The breakpoint set for the activity is reached.
Gray color (grayed-out effect). The activity has not been executed yet.
Green triangle. The activity is now being executed.
Blue triangle. The activity has been successfully completed.
You can also monitor the execution of current BPEL process instances in the BPEL Process Execution window (see below).
When a debugging session starts, debugger windows are displayed below the editing area. The Sessions, BPEL Process Instances, BPEL Variables, and BPEL Process Execution windows contain information related to BPEL processes running within the current debugging section.
If a debugger window is not displayed, choose Window > Debugging > window-name (for example, Window > Debugging > BPEL Process Instances).
The Breakpoints and Watches are standard IDE debugger windows. They display all breakpoints and watches set in the IDE.
The Sessions window lists all open debugging sessions, including Java and BPEL debugging sessions. For the BPEL Service Engine, only one session can be started. However, the Sessions window also displays other open debugging sessions, such as Java sessions. Only one of the open debugging sessions can be current, and it is shown in bold. Other debugger windows, such as BPEL Process Instances, BPEL Process Execution, and BPEL Variables, display data related only to the current debugging session.
The information provided for each session includes:
Name. The name of the session.
State. The current state of the session. Sessions can be starting or running.
Language. The language of the application debugged in this session.
You can perform the following actions on sessions available in the pop-up menu:
Make current. Makes the selected session current.
Finish. Finishes the selected session.
Finish all. Finishes all debugging sessions.
The BPEL Process Instances window lists all BPEL process instances deployed to the BPEL Service Engine and their currently running instances. For each process instance correlation sets and Faults are listed as subnodes.
If the current session is not a BPEL Debugger session, this window is empty. The BPEL Process Instances window is populated when a debugging session starts on the BPEL Service Engine, or when the current session is a BPEL Debugger session.
The information displayed for each process instance includes the instance name, unique instance ID, and its state. Process instances can exist in one of the following states:
Running. The instance is currently being executed on the BPEL Service Engine.
Suspended. The instance has been suspended for some reason. For example, the process instance has reached a breakpoint.
Unknown. The status of the instance is unknown.
A process instance that is current is shown in bold. A process instance becomes current when it reaches a breakpoint or when you manually make it current.
To make a process instance current, do one of the following:
Double-click the process instance.
Right-click the process instance and choose Make Current from the pop-up menu.
To terminate a process instance:
Right-click the process instance and select Terminate from the pop-up menu. The process instance is terminated and removed from the list.
For the Correlation Sets node the information comes out during the process execution.
For each process instance correlation set, a list of properties it includes is shown. For the properties, type and value information is displayed. Find more information on Correlation sets, properties, and property aliases here: Using Correlation.
The Local Variables window shows the structure of local variables and their values for the current process instance and current position. The current position is the place where the current process instance became suspended. When you change the current process instance, the records in the Local Variables window are updated to reflect the variables for the new current process instance and the new current position.
The structure of local variables is shown as a tree. The information provided for each variable includes the variable name and value.
In the Local Variables window you can do the following:
View the variable structure. To do this, expand the variable node in the tree.
View and edit the values of variables. To edit the value of a variable, click the ellipsis (...) button and enter the new value in the editor window.
The structure of local variables is shown as a tree. The information provided for each variable includes the variable name and value.
The Watches window shows the list of XPath expressions that you want to monitor. You add watches explicitly before or during the debugging session. The Watches window shows the expression and its value. The value of the expression may change as the process advances depending on the logic of your process.
(Optional) Be sure that the Watches window is visible or choose Window > Debugging > Watches (Alt-Shift-2) to view it.
If you want to enter an XPath expression from your BPEL process, copy it using one of the following methods:
In the Source view, copy the XPath expression you want to watch. The XPath expressions can be found inside the <condition> tag.
In the Design view, select an element that has an expression and copy the expression from the Condition row in the Properties window.
Right-click inside the Watches window and choose New Watch.
In the Watch Expression field of the New Watch dialog box, do one of the following:
Paste the XPath expression you have copied.
Enter any valid expression that is compliant with XPath 1.1.
(Optional) If needed, add more watches.
Ensure that a debugging session is running and perform a test run.
As the process instance reaches a breakpoint and becomes suspended, examine the values of the expressions being watched in the Value column of the Watches window.
The BPEL Process Execution window graphically represents the progress of executing the current BPEL process instance in the BPEL Debugger. When you change the current process instance, the process tree in the BPEL Process Execution window is updated to reflect the state of the new current process instance and the new current position.
In the BPEL Process Execution window, the following colors are used to display the state of BPEL activities:
Green. The activity is being executed at the moment.
Gray. The activity has not been executed yet.
Black. The activity has been executed.
BPEL Process Execution Window displays the following information:
Name. The name of the activity.
Thread. The thread in which the activity is/was executed. For the nodes that have not yet been executed no thread information is provided.
Line. Contains the path to the file and the line number for the activity in the file.
XPath. Shows XPath expression pointing to the activity.
In the BPEL Process Execution window, you can only view the progress of executing BPEL processes. You cannot perform any actions in this window.
The Partner Links window lists the all the partner links defined in the BPEL Process.
The information provided for the partner links includes:
My Role
Partner Role (for two-way operations only)
Endpoint. The endpoint information is available for dynamically defined partner links only. For more information see Dynamic Addressing.
You can see the following messages in the BPEL Debugger Console:
The Debugger is attempting to connect to the BPEL service engine.
The Debugger has successfully connected to the BPEL service engine and the debug session has started.
If you see this message, verify the following:
The GlassFish V2 Application Server is running.
The BPEL service engine is started.
The DebugEnabled property of the BPEL service engine is set to true.
The host name is the host name of the machine that runs the GlassFish V2 Application Server you are connecting to ( localhost by default).
The port value is the same as the DebugPort property of the BPEL service engine you are connecting to (3343 by default).
You already have a running debug session attached to this particular service engine.
The Debugger lost connection to the server. Check that the server is running and the network is up.
You explicitly terminated the debug session when it was connecting.
You explicitly terminated the debug session when it was running.
Troubleshooting.
Using BPEL Schemas Different from the BPEL 2.0 Specification
Disabling Firewalls when Using Servers
There are certain limitations to the elements supported in this release of the BPEL Designer. See the BPEL Service Engine User's Guide for details about the supported BPEL 2.0 language constructs and related limitations.
This release of the BPEL Designer supports the BPEL 2.0 final specification and does not support previous specifications. This means that when you open the BPEL files that comply with the previous versions of the specification, the BPEL Designer shows the Unable to Show the Diagram message.
If you see this message, do the following:
Check the specification version that the BPEL file complies with. BPEL files that comply with the BPEL 2.0 specification have the following string:
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
WSDL files that contain PartnerLinkType definitions should have the following string:
xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
Replace the namespaces in your files with those above and try to open the BPEL file in the BPEL Designer.
Make sure that the BPEL constructs used in your process are compatible with the BPEL 2.0 specification.
When deploying two or more Composite Application projects, a service endpoint conflict might occur and the deployment fails. In case of the service endpoint conflict, the following message is displayed:
Deploy service assembly failed. (partial success) MESSAGE: (SOAPBC_DEPLOY_2) Failed to deploy: java.lang.Exception: An activated endpoint already has the same SOAP Address location: http://localhost:18181/SynchronousSample C:\<...>\SynchronousSample1Application\nbproject\build-impl.xml:209: Service assembly deployment failed. BUILD FAILED (total time: 31 seconds) |
This could typically arise from trying to deploy nearly identical processes that are packaged in different Composite Application projects. The workaround for this issue is to use different endpoints during the deployment of different Composite Application projects.
Explanation: Even though you are deploying distinct Composite Applications and distinct BPEL processes, by default they will have the same endpoint addresses defined in their SynchronousSample.wsdl files. They will both contain the following endpoint address:
<service name="service1"> <port name="port1" binding="tns:binding1"> <documentation/> <soap:address location="http://localhost:18181/SynchronousSample"/> </port> </service> |
If you attempt to deploy two Composite Applications (for example, SynchronousSampleApplication and SynchronousSample1Application ) with identical service endpoints, the deployment of the second one will fail due to the endpoint conflict.
You may wish to deploy more than one version of a Composite Application because you want to modify one or both of these processes and deploy both of them at the same time. Or you may want to compare their behavior. To do this you must first make their endpoint addresses distinct. This means editing the process WSDL file and adjusting the soap:address location attribute so that there is no conflict. You can adjust either the port number or the service name. For example, either of these would be sufficiently distinct from the original:
<soap:address location="http://localhost:18182/SynchronousSample"/> |
or
<soap:address location="http://localhost:18181/SynchronousSampleNew"/> |
Each Test Case in the Composite Application project will attempt to send the input message to the target process when you invoke the Test action. In order to know where to send the message, each test case has a property called destination. You can modify this property in the Properties window. To invoke the Properties window, right-click the test case node and choose Properties from the pop-up window.
destination=http://localhost:18181/SynchronousSample |
The value of the destination property is set at the time the test case is created. So if you subsequently change the service endpoint you will need to manually adjust the destination attribute for any previously generated test cases. Newly generated test cases, of course, will be OK.
By default, the installer attempts to configure the Application Server's HTTP port to be 8080. Some of the sample processes assume the 8080 value. If for any reason, the Application Server's HTTP port is not 8080, you will have to make adjustments to the samples.
In particular, the Travel Reservation Service sample will require several adjustments.
Assume, for instance, that the Application Server is listening on HTTP port 8090 (not on the default 8080). In this case, you will have to do the following:
Adjust Reservation Partner Services WSDL files
In the TravelReservationService BPEL Module project, change the soap address value in the AirlineReservationService.wsdl from
<soap:address location="http://localhost:8080/webservice/AirlineReservationService"/> |
to
<soap:address location="http://localhost:8090/webservice/AirlineReservationService"/> |
Similarly, update the soap address values in VehicleReservationService.wsdl and
HotelReservationService.wsdl.
Note: To find out which HTTP port the Application Server is listening on, open the Services window, right-click the GlassFish V2 Application Server's node and choose View Admin Console. This opens the GlassFish V2 Application Server Administration Console in your browser. Type username and password (default values are admin/adminadmin) and log in. Click Application Server in the left pane and choose the General tab in the right pane. The HTTP port value you need is the first in the HTTP Port(s): line.
Alternatively, find the following lines in the Application Server log:
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080 WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8181 WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 4848 |
The value you need is in the first line.
Refer to the Service Endpoint Conflict section above for a general description of the problem. In case of the Travel Reservation Service sample, however, you have to take these additional steps:
If port 18181 is not available, and if you want to run TRS on another port, such as port 19191, perform the following steps:
Open TravelReservationService.wsdl.
In the service tag change,
soap:address location="http://localhost:18181/TravelReservation/buildItinerary"/
to
soap:address location="http://localhost:19191/TravelReservation/buildItinerary"/
Similarly, update URL's for airlineReserved, hotelReserved and vehicleReserved.
Adjust the Partner EJB project, ReservationPartnerServices
Perform the following steps:
In the IDE, open the ReservationPartnerServices project.
(The IDE created the ReservationPartnerServices project in the location where you created the TravelReservationService project.)
In the Projects window, expand the ReservationPartnerServices project node, expand the Configuration Files node, and then double-click the ejb-jar.xml node to open the file in the visual editor.
In the Design view, under Enterprise Beans, click ReservationCallBackProviderMDB to expand the entry. Expand Bean Environment and then Environment Entries.
Under Environment Entries, select each entry and click Edit to change the 18181 port number in the Entry Value field.
For example, for AirlineCallbackURL, change
http://localhost:18181/TravelReservation/airlineReserved
to
http://localhost:19191/TravelReservation/airlineReserved
Update the Destination Property
In the TravelReservationServiceApplication Composite project expand the Test node. For each test case node under it:
Right-click the test case node and choose Properties.
In the Properties window, update the value of the Destination property.
Example:
Change http://localhost:18181/TravelReservation/buildItinerary
to
http://localhost:19191/TravelReservation/buildItinerary
When executing a test case:
If the Output.xml file is empty (it is empty after a new test case is created), then you are asked whether the Output.xml should be populated with the response from the first test run. This first test run output will indicate that the test run failed.
If the Output.xml file is not empty, then the results obtained are compared with the content of the file; if they match, the test execution is marked as passed.
If you receive a failed test run, you can do one of the following:
Check the response message after a failed test run. The response message is available under the test case node in the Projects window. The response message is time stamped.
You can verify that the response does not match the expected response (that is, Output.xml) and this might help you understand the problem.
Check the Server log file after a failed test run.
To do so, go to the IDE's Runtime tab. Select the View Server Log action on the GlassFish V2 Application Server node.
This shows the contents of the server log and might contain information about why a test run failed.
One particular case of test run failures is related to tests that use content-based correlation embedded in Input.xml (for example, the Input.xml files in the Travel Reservation Service test cases have <UniqueID>...</UniqueID> as the basis for correlation). In this situation, if you run the test case when there is already a running process instance initiated by the same test case, the second process instance will not be initiated and the test will fail. The following message will appear in the GlassFish V2 Application Server log:
Exception occurred while executing a business process instance. com.sun.jbi.engine.bpel.core.bpel.exception.CorrelationAlreadyExists: An instance is associated with the correlation <...> |
You might have to disable any firewall in order to successfully deploy run, debug, or test applications on the Application Server or business processes on the BPEL Server.
The BPEL service engine requires strict usage of correlation sets. Currently the validation system does not detect violations of the following requirements:
On Message: The On Message element must have a valid <correlations> child if the On Message is used in a Pick activity that does not have the createInstance="yes" attribute.
Receive: The Receive element must have a valid <correlations> child if it does not have the createInstance="yes" attribute.
On Event: The On Event element must have a valid <correlations> child.
See the NetBeans IDE 6.1 Release Notes for other known issues for the SOA pack.
To better understand the BPEL Designer features provided by the NetBeans IDE see the following tutorials on NetBeans web-site: