Developer Guide to BPEL Designer
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.
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
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:
Update the Destination Property
When executing a test case:
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 <...>
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.
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.
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.
The BPEL service engine requires strict usage of correlation sets. Currently the validation system does not detect violations of the following requirements:
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.
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.
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 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.
Adding breakpoints while debugging
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:
Debugger confuses BPEL sources from different projects
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.
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.