Using BPEL Schemas Different from the BPEL 2.0 Specification (Using the BPEL Designer and Service Engine)

Using the BPEL Designer and Service Engine

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

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