Embedded Java in a 11g BPEL process

2

In an earlier blog my colleague Peter Ebell (link) explained how you can create an extension of collaxa.cube.engine.ext.BPELXExecLet to do your coding in a regular Java environment so you have code completion and validation. In 11g no improvements have been implemented and the Java embedded activity is still a pretty dumb text editor. So the same approach is still valid. But there are some differences between the 1o en 11 version.

The class you need to extend has been moved to a different package: com.collaxa.cube.engine.ext.bpel.v1.nodes.BPELXExecLet. You need at least to include the SOA Workflow library in your project. If you want it to run you need additional packages.

Most of the methods of the 10 version still exist. Only the method getLocator is gone. You now need to get an instance of the locator bean through a factory.

Here is the sample code:

[sourcecode language=”java”] jndiProps.put(javax.naming.Context.PROVIDER_URL,”t3://localhost:8001/soa-infra/”);
jndiProps.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,”weblogic.jndi.WLInitialContextFactory”);
jndiProps.put(javax.naming.Context.SECURITY_PRINCIPAL, “weblogic”);
jndiProps.put(javax.naming.Context.SECURITY_CREDENTIALS, “welcome1″);
jndiProps.put(“dedicated.connection”, “true”);

oracle.soa.management.facade.Locator locator = null;
try {
locator = oracle.soa.management.facade.LocatorFactory.createLocator(jndiProps);
} catch (java.rmi.RemoteException re) {
addAuditTrailEntry(re.getMessage(), re);
} catch (Exception e) {
addAuditTrailEntry(e.getClass().toString());
addAuditTrailEntry(e);
} finally {
locator.close();
}
[/sourcecode]

You need to include the following package to be able to compile/validate the code:

$MW_HOME\oracle_common\soa\modules\oracle.soa.mgmt_11.1.1\soa-infra-mgmt.jar

If you want to execute the code outside SOA Suite you need to including the following packages (thanks to melvin)

$MW_HOME\oracle_common\modules\oracle.fabriccommon_11.1.1\fabric-common.jar
$MW_HOME\oracle_common\webservices\wsclient_extended.jar
$MW_HOME\wlserver_10.3\server\lib\weblogic.jar
$MW_HOME\Oracle_SOA1\soa\modules\oracle.soa.fabric_11.1.1\oracle-soa-client-api.jar

If you look at the code you might notice the jndi context is set explicitly. If this is not done you sometimes get an EJB Exception – caller permission to method denied. By each time setting the context the exception does not occur anymore. But now you have hard coded environment specific settings inside your code. This did not make me very happy. You do not want these kind of settings here. What you can do is move these settings to your composite.xml by using preferences.

In the composite.xml containing the BPEL process that contains your embedded Java Activity you can add preferences:

[sourcecode language=”xml”] <component name=”TerminateWorkflow”>
<implementation.bpel src=”TerminateWorkflow.bpel”/>
<property name=”bpel.preference.PROVIDER_URL”>t3://localhost:8001/soa-infra/</property>
<property name=”bpel.preference.SECURITY_PRINCIPAL”>weblogic</property>
<property name=”bpel.preference.SECURITY_CREDENTIALS”>welcome1</property>
</component>
[/sourcecode]

Inside the BPEL process itself you can assign these preferences to a process variable by using a BPEL extension function ora:getPreference(‘preference name without bpel.preference and surrounded by single quotes‘). After having assigned the value you can now use its value inside your embedded Java activity by calling the getVariableData function. Suppose you have assigned the first preference to the process variable PROVIDER_URL you can now get its value by calling:

[sourcecode language=”xml”] String PROVIDER_URL = (String)getVariableData(“PROVIDER_URL”);
[/sourcecode]

So no more hard coded settings anymore. These preferences can be changed inside a configuration plan. You can even change them runtime through a mbean in the enterprise manager. Although I cannot see any advantages of that in this case. See this blog if you are intested though.

Share.

About Author

Izaak de Hullu is an architect SOA and Integration. Experience in mostly Java integration projects with products like OSB, Weblogic but also BPM/BPEL products like Oracle BPM en Cordys.

2 Comments

  1. If you leave the value blank it will skip the replace. In your case it is better to leave it blank in the composite.xml en overwrite it using the config.xml.

  2. Hi
    In my config.xml i was leaving preference value to blank. Will it override the value of composite.xml or it will change the value of preference variable to blank….

    In my case it is not keeping the value blank….And if i am giving some value in config.xml it is overridding the value on composite.xml