Skip Navigation Links | |
Exit Print View | |
Oracle Java CAPS BPEL Designer and Service Engine User's Guide Java CAPS Documentation |
BPEL Designer and Service Engine User's Guide
To View the Installed or Deployed JBI Components
The Composite Application Project
BPEL Designer and Service Engine Features
Supported WS-BPEL 2.0 Constructs
BPEL Service Engine and Oracle SOA Suite
Understanding the BPEL Module Project
Creating Sample Processes in the BPEL Designer
An Asynchronous Sample Process
Travel Reservation Service Sample
Creating a Sample BPEL Module Project
Navigating in the BPEL Designer
Element Documentation and Report Generation
Creating Documentation for an Element
Collapsing and Expanding Process Blocks in the Diagram
To Collapse and Expand a Process Block
Zooming In and Out of the Diagram
Printing BPEL Diagrams and Source Files
To Preview and Print a BPEL Diagram or Source File
Creating a BPEL Module Project
To Check the Status of the GlassFish V2 Application Server in the NetBeans IDE
To Register the GlassFish V2 Application Server with the NetBeans IDE
To Start the GlassFish V2 Application Server in the NetBeans IDE
Creating a new BPEL Module Project
To Create a BPEL Module Project
Creating the XML Schema and the WSDL Document
Creating a BPEL Process Using the BPEL Designer
Creating a Composite Application Project
To Create a New Composite Application Project
Building and Deploying the Composite Application Project
To Build and Deploy the Composite Application Project
Testing the Composite Application
Test the HelloWorldApplication Composite Application Project
Developing a BPEL Process Using the Diagram
Configuring Element Properties in the Design View
Finding Usages of BPEL Components
To Find Usages of a BPEL Component
The BPEL Designer Palette Elements
Adding BPEL Components to the Process
Using the Partner Link Element
Dynamic Partner Links and Dynamic Addressing
Using the CompensateScope Element
CompensateScope Element Properties
Adding an Else If Branch to the If Element
Adding an Else Branch to the If Element
Using the Repeat Until Element
Repeat Until Element Properties
Adding Branches to the Flow Element
Changing the Order of Elements inside Flow
Adding Child Activities to the Sequence
Changing the Order of Elements inside Sequence
To Open the BPEL Mapper Window
To Create a Mapping Without Using any Functions
To Use a Function in a Mapping
To Delete a Link or Function in a Mapping
Using Type Cast and Pseudo-Components
Type Cast and Pseudo Component Limitations
Using Normalized Message Properties
Using Normalized Message Properties in a BPEL Process
Using Predefined Normalized Message Properties in a BPEL Process
To Use Predefined Normalized Message Properties in a BPEL Process
Adding Additional Normalized Message Properties to a BPEL Process
To Add a Normalized Message Property Shortcut to a BPEL Process
To Edit an NM Property Shortcut
To Delete an NM Property Shortcut
To Add a Normalized Message Property to a BPEL Process
BPEL Code Generation Using NM Properties
General Normalized Message Properties
Binding Component Specific Normalized Message Properties
To Add a Compensation Handler to Scope or Invoke Elements
To Add a Termination Handler to Scope or Process Elements
Understanding Correlation. Using the Correlation Wizard
Elements That Use and Express Correlation
Defining Correlation Using the Correlation Wizard
BPEL Process Logging and Alerting
To Set the Log Level for the BPEL Service Engine
Configuring the BPEL Service Engine Runtime Properties
Accessing the BPEL Service Engine Runtime Properties
BPEL Service Engine Deployment Artifacts
Testing and Debugging BPEL Processes
To Add a Test Case and Bind it to a BPEL Operation
Steps in Debugging BPEL Processes
Starting and Finishing a BPEL Debugging Session
Using Breakpoints to Debug BPEL Processes
Group operations over breakpoints
Monitoring Execution of BPEL Processes
Correlation Sets and Faults information
BPEL Debugger Console Messages
Monitoring the BPEL Service Engine
Installing the BPEL Monitor API and Command Line Monitoring Tool
To Install the Monitoring Tool
Using the BPEL Monitor Command Line Tool
To Use the BPEL Monitor Command Line Tool
Configuring Quality of Service (QOS) Properties, Throttling, and Redelivery
Configuring the Quality of Service Properties
To Access the Config QOS Properties Editor
Configuring Message Throttling
Configuring an Endpoint for Throttling
Using Dynamic Partner Links and Dynamic Addressing
Using a Literal to Construct an Endpoint
Using an Existing Partner Link's Endpoint
Using an Incoming Message to Extract the Endpoint
Using a Database Query to Provide an Endpoint
Sending Service Endpoint References
Configuring Persistence for the BPEL Service Engine
Setting the JVM Classpath to the Database JDBC Drivers
To Set the GlassFish JVM Classpath Settings
Configuring the User and Database for Persistence
Creating an XA Connection Pool and a JDBC Resource
To Create an XA Connection Pool
Creating a Non-XA Connection Pool and JDBC Resource
Enabling Persistence for the BPEL Service Engine
To Enable Persistence for the BPEL Service Engine
Truncating and Dropping Tables
Configuring Failover for the BPEL Service Engine
Using BPEL Schemas Different from the BPEL 2.0 Specification
Relationship of Service Endpoint to Test Cases
GlassFish V2 Application Server HTTP Port
Travel Reservation Service Endpoint Conflict
Disabling Firewalls when Using Servers
Required Correlation Set Usage is Not Detected by the Validation System
The following topics provide information to help you troubleshoot common business process issues:
Using BPEL Schemas Different from the BPEL 2.0 Specification
Disabling Firewalls when Using Servers
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 then select Properties.
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, the port numbers are defined in the domain.xml file, located in appserver_home/domains/domain_name/config. Look for the http-listener elements. The ports are defined for http-listener-1, http-listener-2, and admin-listener. By default, these values are 8080, 8181, and 4848 respectively. http-listener-1 is the port the Application Server is listening on.
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.