Contributed by Bob May, maintained by Irina Filippova
December 2007
Developer Guide to the BPEL Designer
![]() |
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:
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
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:
Update the Destination Property
In the TravelReservationServiceApplication Composite project expand the Test node. For each test case node under it:
When executing a test case:
If you receive a failed test run, you can do one 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 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:
See the NetBeans IDE 6.0 Release Notes for other known issues for the SOA pack.