Developer Guide to BPEL Designer: Troubleshooting

Last Updated: 15 November 2006
Contributed by Bob May, maintained by Dmitry Markovski

Contents

Developer Guide to BPEL Designer

Service Endpoint Conflict

At the time of Composite Application deployment, the system will attempt to define one or more service endpoints for the deployed process(es). Every service endpoint must be unique. Therefore, if you attempt to deploy two processes with the same service endpoint definition, the system will flag this as an error and the deployment will not succeed. A message like the following will be shown:

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)

If you see this type of message it means that there is a service endpoint conflict. This could typically arise from trying to deploy nearly identical processes that are packaged in different Composite Application projects. This would arise, for instance, if you invoke the New Project > Samples > Synchronous BPEL Process (or any other sample) more than one time. You will get more than one BPEL Module and more than one Composite Application project. For example if you take the default path, twice. You will get four projects:

These will be distinct Composite Applications and distinct BPEL processes, but 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 (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 wish to make modifications to one or both of these processes and deploy both of them at the same time. Perhaps you wish to compare the behavior side by side. You can do this but you must 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"/>

Endpoint Deactivation

When the BPEL engine encounters the endpoint conflict, it may proactively deactivate the conflicted endpoint. Once this happens, this message will appear in the server log.

java.lang.RuntimeException: javax.jbi.messaging.MessagingException: Endpoint has been deactivated.
at com.sun.jbi.engine.bpel.EngineChannel.reply(EngineChannel.java:227)

You may not initially notice this message, but a symptom of this problem is that subsequent test runs fail. When you see this, make sure that you then resolve the conflict and redeploy the Composite Application. Then everything should be fine.

Relationship of Service Endpoint to Test Cases

Each Test Case in the Composite Application 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, invoked by right-clicking the test case node and choosing 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

Sun Java System Application Server HTTP Port

By default, the Enterprise Pack 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 TravelReservationService BPEL module, 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 what HTTP port the Application Server is listening on, open the Rintime window, right-click the Sun Java System Application Server 9 node and choose View Admin Console. This opens the Sun Java System 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, follow the following set of 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 ejb-jar.xml Visual Editor.
  3. In the Editor, 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

  1. In the TravelReservationServiceApplication Composite project:
  2. Expand the Test node and 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:

Test Run Failures

If you receive a failed test run, you can do either or both of the following:

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 Sun Java System Application Server log:

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

Modifications to XSD and WSDL files

Issue 81190

When you modify XSD and WSDL files, BPEL validation is not started automatically. BPEL validation is only invoked when you introduce changes to the BPEL file or perform a build or deploy action on the BPEL project. You can also manually invoke BPEL validation by clicking the Validate XML button (Alt+Shift+F9) on the Design view or Source view toolbar. For more information, see the Validation section.

Issue 86274

If XSD or WSDL files are not well-formed, correct the problem. However, note, that the BPEL file will not reflect the changes made to the XSD and WSDL files until you reopen the BPEL file.

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:

Changes in the Partner Service

Issue 86499

If the interface of your partner service changes, for example, when the signature of a web service operation changes, and you have not imported the modified WSDL file, then the BPEL process hangs. You have to import the new WSDL file and redeploy the application. You may have to restart the BPEL service engine.

Deleting Property from Correlation Set in Navigator Incorrectly Deletes Property from WSDL

Issue 87221

If you delete the Property from a correlation set using pop-up menu commands in the Navigator, the Property is incorrectly deleted from the WSDL file. The workaround is to use the correlation set editor and not the Delete pop-up menu action on the Property node itself.

Canceling the PartnerLink Dialog

Dragging a WSDL file or a Web Service node from a NetBeans project onto a BPEL Module diagram causes several effects to take place. These effects include the automated "retrieval" of the dragged source object's WSDL file(s). If you cancel the PartnerLink dialog that appears when you drag a WSDL file or a Web Service node onto a diagram, the IDE does not roll back the retrieval of the WSDL files(s). If these files are not needed by the project, simply delete them manually from the Projects window, as you would delete any other project resource.

The Undo and Redo Commands

Issue 84793

The Undo and Redo commands are not available when the Navigator window has focus. To access the Undo and Redo commands, put focus on the diagram. You will be able to undo and redo the changes initiated in the Navigator window.

Debugging

Adding breakpoints while debugging

Issue 82497

If you have an active debugging session, you can only add breakpoints to the language of the active debugging session. For example, if you have an active BPEL debugging session, you will not be able to add breakpoints to java code and vice versa. The workaround is to make active the debugging session related to the language that you want to add breakpoints to. Alternatively, to add breakpoints, close all debugging sessions.

BPEL Debugger Console Messages

You can see the following messages in the BPEL Debugger Console:

Connecting to <host>:<port>
The Debugger is attempting to connect to the BPEL service engine.
Debug session started
The Debugger has successfully connected to the BPEL service engine and the debug session has started.
Unable to start a debug session : Unable to connect to <host>:<port> : Connection timed out: connect
If you see this message, verify the following:
  • The Sun Java System 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 Sun Java System 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).
Unable to start a debug session : Already connected to <host>:<port>
You already have a running debug session attached to this particular service engine.
Debug session terminated : Target disconnected
The Debugger lost connection to the server. Check that the server is running and the network is up.
Stop connecting
You explicitely terminated the debug session when it was connecting.
Debug session finished
You explicitely terminated the debug session when it was running.

Debugger confuses BPEL sources from different projects

Issue 79288

If you have two processes in the IDE with the same qname and you have breakpoints set in both processes but at different elements, the BPEL Debugger stops at breakpoints specified in both processes when you deploy and debug only one of them. This happens because the BPEL Debugger is attached to the BPEL engine itself and not to a separate process.

Assume you have two projects with different names (for example, SynchronousSample and SynchronousSample1) but both of these projects include identically named processes (SynchronousSample). Assume further, that both of these processes have breakpoints set, one of these processes, SynchronousSample, is deployed and SynchronousSample1 is closed, not even open in the IDE. When you begin to debug, the debugger stops at ALL breakpoints (i.e. the union of breakpoints in both files). This can create a surprising effect because the IDE automatically opens a source file when it reaches a breakpoint; in this example, it opens the SynchronousSample1.SynchronousSample process file, and stops at one of its breakpoints. The workaround for this problem is to clear breakpoints from the conflicting process file.

For more information on debugging, see the Debugging BPEL Processes section.

Unable to Show Diagram

Issue 87719

Normally, the Design view will only show the message "Unable to Show Diagram" when the BPEL source is malformed. In such case, the recommended procedure is to go to the Source view and run the "Check XML" action and/or the "Validate XML" action. They will tell you what needs to be corrected in the BPEL source. Make the corrections. Save the file. At this point the Design view should be able to render the diagram properly. However, there are some cases where the Design view reports "Unable to Show Diagram" even when the BPEL file is well-formed. One such case is noted in Issue 87719. In this case, the BPEL file is actually well-formed, but the Design view continues to report "Unable to Show Diagram". The only workaround for this case is to restart the IDE. After the restart, the diagram should render properly.

top


Copyright and Trademark Notice