Developer Guide to the BPEL Designer: Troubleshooting

BPEL 2.0 Elements Not Present in This Release

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.

Using BPEL Schemas Different from the BPEL 2.0 Specification

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.

Service Endpoint Conflict

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"/>

Relationship of Service Endpoint to Test Cases

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.

Ports

GlassFish V2 Application Server HTTP Port

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

1. 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"/>
   
2. 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.

Travel Reservation Service Endpoint Conflict

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:

Change URLs

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:

1. In the IDE, open the ReservationPartnerServices project.
   (The IDE created the ReservationPartnerServices project in the location where you created the TravelReservationService project.)
2. 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.
3. In the Design view, under Enterprise Beans, click ReservationCallBackProviderMDB to expand the entry. Expand Bean Environment and then Environment Entries.
4. 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:

1. Right-click the test case node and choose Properties.
2. In the Properties window, update the value of the Destination property.
   Example:
   Change http://localhost:18181/TravelReservation/buildItinerary
   to
   http://localhost:19191/TravelReservation/buildItinerary

Test Run

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.

Test Run Failures

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
<...>

Disabling Firewalls when Using Servers

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.

Required Correlation Set Usage is Not Detected by the Validation System

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.0 Release Notes for other known issues for the SOA pack.