ReplyTo header in Unified Endpoint configuration of WSO2 BPS

In a BPEL process, when there is an invoke to an external synchronus web service, and if you want to send the response of this service to a different endpoint (rather than sending back to the BPEL process), you can use Unified Endpoint configuration of WSO2 BPS 3.0.0 to set the WS:Addressing ReplyTo header as follows:

	<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
	<wsa:Address>http://localhost:9763/services/DebugService/</wsa:Address>
	<wsa:Metadata>
	<id>SInvokeEPR</id>
	<qos>
	<enableAddressing>
	<ReplyTo>http://localhost:8281/services/OtherServiceProxy</ReplyTo>
	</enableAddressing>
	</qos>
	</wsa:Metadata>
	</wsa:EndpointReference>

view raw gistfile1.xml hosted with ❤ by GitHub

You can refer to this config file (locatd in registry or in the file system) as follows, inside the deploy.xml file:

	<invoke partnerLink="DebugPL">
	<service name="DebugService:DebugService" port="DebugServiceSOAP">
	<endpoint xmlns="http://wso2.org/bps/bpel/endpoint/config" endpointReference="debug.epr"/>
	</service>
	</invoke>

view raw gistfile1.xml hosted with ❤ by GitHub

There are other use cases of UEP like adding QOS, Security etc. You can read more on that here.

Use of 'DynamicImport-Package: *' in OSGi

In OSGi, 'DynamicImport-Package' attribute is used in the MANIFEST.MF file to specify the patterns of packages that are not found in the normal bundle contents or Import-Package field. If the package is not available in the initial resolution process, it will not fail, but will be attempted to resolve every time a class from the package is required.

 'DynamicImport-Package: *' is a trick used by bundles to allow importing client packages which are not known during bundle build time, in addition to its own dependencies, to prevent ClassNotFoundException issues. [i.e. If there are classes which have Class.forName (or other dynamic look up)] This turns OSGi Framework into a very expensive class path for the packages involved and breaks the concept of versions in OSGi. Use of this attribute is said to be a sign of a non-modular design and it might be a good time to revisit the architecture.

To learn more:

• DynamicImport-Package - OSGi Community Wiki http://wiki.osgi.org/wiki/DynamicImport-Package
• What is the difference between bootdelegation and DynamicImport-Package in osgi http://stackoverflow.com/questions/14729568/what-is-the-difference-between-bootdelegation-and-dynamicimport-package-in-osgi
• If code uses Class.forName (e.g. hibernate) consider DynamicImport-Package https://github.com/bndtools/bnd/issues/80

How to make use of WS-Addressing ReplyTo header in an Asynchronus BPEL Process

In Apache ODE or WSO2 BPS, if you are looking for a way to asynchronously call back from a BPEL process, after the process is finished, to an reply address dynamically provided in the Request Message with WS-Addressing headers, you can copy the wsa:Address from the ReplyTo header, to the partnerLink related to the final invoke as follows:

	<bpel:assign>
	<bpel:copy>
	<bpel:from header="ReplyTo" variable="initialRequest">
	<bpel:query querylanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">wsa:Address/text()</bpel:query>
	</bpel:from>
	<bpel:to partnerlink="resultPartnerLink" />
	</bpel:copy>
	</bpel:assign>

view raw gistfile1.xml hosted with ❤ by GitHub

If you're testing this with SOAP UI, make sure you include wsa:Action, wsa:To, wsa:ReplyTo and MessageID in the request. Otherwise you will get an error similar to 'org.apache.axis2.AxisFault: A required header representing a Message Addressing Property is not present'
You can read more here about Using WS-Addressing in SOAP UI
Hat-tip: From Apache ODE mail archives, Related question from StackOverflow

How to clean up Instance data for a given BPEL Process Instance ID from Apache ODE/WSO2 BPS

This is a stored procedure that can be used to delete all the instance related data from the DB for a particular BPEL instance.

	create or replace
	PROCEDURE cleanInstance(instanceID NUMBER) AS
	BEGIN
	DELETE FROM ODE_EVENT WHERE INSTANCE_ID=instanceID;
	DELETE FROM ODE_CORSET_PROP WHERE CORRSET_ID IN (SELECT cs.CORRELATION_SET_ID FROM ODE_CORRELATION_SET cs WHERE cs.SCOPE_ID IN (SELECT os.SCOPE_ID FROM ODE_SCOPE os WHERE os.PROCESS_INSTANCE_ID=instanceID));
	DELETE FROM ODE_CORRELATION_SET WHERE SCOPE_ID IN (SELECT os.SCOPE_ID FROM ODE_SCOPE os WHERE os.PROCESS_INSTANCE_ID=instanceID);
	DELETE FROM ODE_PARTNER_LINK WHERE SCOPE_ID IN (SELECT os.SCOPE_ID FROM ODE_SCOPE os WHERE os.PROCESS_INSTANCE_ID=instanceID);
	DELETE FROM ODE_XML_DATA_PROP WHERE XML_DATA_ID IN (SELECT xd.XML_DATA_ID FROM ODE_XML_DATA xd WHERE xd.SCOPE_ID IN (SELECT os.SCOPE_ID FROM ODE_SCOPE os WHERE os.PROCESS_INSTANCE_ID=instanceID));
	DELETE FROM ODE_XML_DATA WHERE SCOPE_ID IN (SELECT os.SCOPE_ID FROM ODE_SCOPE os WHERE os.PROCESS_INSTANCE_ID=instanceID);
	DELETE FROM ODE_SCOPE WHERE PROCESS_INSTANCE_ID=instanceID;
	DELETE FROM ODE_MEX_PROP WHERE MEX_ID IN (SELECT mex.MESSAGE_EXCHANGE_ID FROM ODE_MESSAGE_EXCHANGE mex WHERE mex.PROCESS_INSTANCE_ID=instanceID);
	DELETE FROM ODE_MESSAGE WHERE MESSAGE_EXCHANGE_ID IN (SELECT mex.MESSAGE_EXCHANGE_ID FROM ODE_MESSAGE_EXCHANGE mex WHERE mex.PROCESS_INSTANCE_ID=instanceID);
	DELETE FROM ODE_MESSAGE_EXCHANGE WHERE PROCESS_INSTANCE_ID=instanceID;
	DELETE FROM ODE_MESSAGE_ROUTE where PROCESS_INSTANCE_ID=instanceID;
	DELETE from ODE_PROCESS_INSTANCE where ID=instanceID;
	end;
	/

view raw gistfile1.sql hosted with ❤ by GitHub

How to find BPEL Process Instance ID from Correlation Property Value in Apache ODE/WSO2 BPS

This is a small SQL query to retrieve Process Instance ID from the DB, when we know a Correlation Property Value, for a simple case where the correlation set consists of only one property.

SELECT PROCESS_INSTANCE_ID FROM ODE_SCOPE WHERE SCOPE_ID IN (SELECT cs.SCOPE_ID FROM ODE_CORRELATION_SET cs WHERE cs.CORRELATION_SET_ID IN (SELECT os.CORRSET_ID FROM ODE_CORSET_PROP os WHERE os.PROP_VALUE='$CORR_PROP'));

Here, use the respective correlation property value instead of $CORR_PROP