January 11, 2010

SOA Suite 11g - api tricks part 3 - composite mode / state

Yesterday one of my colleagues called in to ask how to retrieve the state of a composite.

The first important piece to understand is that there are two parts to the state
a) active | retired (this setting decides whether new instances can be created [active], or old ones are allowed to finish w/o new ones being allowed to be created [retired] - this is referred to as composite mode
b) on | off (this is the composite state) and overrides (a) in either allowing call access [invoke / callback] to the composite revision [on] or not at all [off]. This is referred to as composite state.

This entry explained how to find a specific instance back via composite sensor values, instance id, or conversation id, yet the starting point is the same.

From oracle.soa.management.facade.Locator one can use getComposite(CompositeDN), which gets you to the composite (an impl of oracle.soa.management.facade.Composite)

In order to retrieve the mode (a) and the state (b) - use the api (and unfortunately the implementation).


System.out.println("Mode: " + composite.getMode() + " state: " +
((oracle.soa.management.internal.facade.CompositeImpl)composite).getState());

This will get you something along the below line

Mode: active state: on.

A few comments in general on the api

January 10, 2010

SOA Suite 11g: weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds

We are back, happy 2010 :0)

and the first question comes from Tsanio in Bulgaria.

He reports:
We have a BPEL process that has a couple of DB Adapter invocations in it. The first one calls a stored procedure and takes a long time to execute (over 5 minutes). In the BPEL process are invoked consecutively the respective procedure and then are made a few more invokes to the database for selecting of records in tables (they are passing quickly). When starting this process, after getting the result from the first invoke of DB Adapter (the slow procedure) and make the second Invoke (the quick select) we get error "JTA transaction is not present or the transaction is not in active state."

As I wrote in earlier posts - everything, whatever you so in SOA suite runs inside a JTA transactions at runtime (read everything that goes through BPEL, Mediator or is initiated by an adapter)

In SOA Suite 10.1.3 on OC4J - there were two knobs that people could tweak to prolong the time of a jta-transaction. The global jta transaction timeout could be set in transaction-manager.xml.
Now BPEL PM overwrote this setting in its own EJBs - e.g. Dispatcher Bean, Cube Engine and Delivery Bean. So the change could be done in $SOA_SUITE_HOME/j2ee\\application-deployments\orabpel\ejb_ob_engine\orion-ejb-jar.xml
As OESB used User Managed Transactions, the setting there was in $SOA_SUITE_HOME\integration\esb\config esb_config.ini - namely through xa_timeout

On weblogic in SOA Suite 11g - the same idea applies, except that the place to set those is little different.
Globally, the transaction timeout can be set via the weblogic console / JTA and for BPEL specific beans, go to deployments / scroll to soa-infra and expand it. Now scroll down to EJBs and find "BPELEngineBean" - in the configuration section, all the way down you find the transaction timeout - set to 300 seconds by default.

With changing those two entries Tsanio and his team could move on.


December 13, 2009

SOA Suite 11g - faulthandling

I have updated my sample on faulthandling to show fault-policy usage and how to work with the standard runtime fault - all based on SOA Suite 11g.

A few things to note:
a) I had to advertise fault-bindings / fault-policies.xml explicitly in composte.xml via


<property name="oracle.composite.faultPolicyFile">fault-policies.xml</property>
<property name="oracle.composite.faultBindingFile">fault-bindings.xml</property>

b) My policy is bound to the MasterCatchRemoteFault process, this is configured in fault-bindings.xml through

<!-- only applies for the MasterCatchRemoteFault process -->
<component faultPolicy="bpel-106-FaultHandling-faultpolicy">
<name>MasterCatchRemoteFault</name>
</component>

c) The faultPolicy name matches to the id defined in fault-policies.xml. In there I am reacting to a fault that is thrown out of the detail process.

<Conditions>
<faultName xmlns:custom="http://example.com/bpel_106_FaultHandling/DetailRemoteFaultThrowingProcess"
name="custom:aCustomBusinessFault">
<condition>
<-- rethrow the fault -->
<action ref="ora-rethrow-fault"/>
</condition>
</faultName>
</Conditions>

The full sample can be found here.

December 12, 2009

Using the event api to publish an event programmatically

Suppose your event is based on the below definition, namely the <process> element


<?xml version="1.0" encoding="UTF-8"?>
<schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://example.com/end2end_108_InvokingCompositeServices/HelloWorld_Sync"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="process">
<complexType>
<sequence>
<element name="input" type="string"/>
</sequence>
</complexType>
</element>
</schema>


and the event (InitiateHelloWorldEvent) itself is described with

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions xmlns="http://schemas.oracle.com/events/edl" targetNamespace="http://schemas.oracle.com/events/edl/HelloWorldEvents">
<schema-import namespace="http://example.com/end2end_108_InvokingCompositeServices/HelloWorld_Sync" location="xsd/HelloWorld_Sync.xsd"/>
<event-definition name="InitiateHelloWorldEvent">
<content xmlns:ns0="http://example.com/end2end_108_InvokingCompositeServices/HelloWorld_Sync" element="ns0:process"/>
</event-definition>
</definitions>

here is how you can build and raise this event programmatically.

// load properties from file
Properties props = SampleUtils.loadPropertiesFromFile();

System.out.println("Creating datasource to db backed EDN");
// create a datasource programmatically from properties and a connect string
DataSource dataSource = SampleUtils.initDataSource(props);

System.out.println("Creating BusinessEventConnectionFactory...");
// next step, create an AQ based connection factory
BusinessEventConnectionFactory factory =
new SAQRemoteBusinessEventConnectionFactory(
dataSource, dataSource, null);
System.out.println("Creating bizEvent connection...");
// on top we need a biz event connection, that captures security, and a few other pieces
BusinessEventConnection conn =
factory.createBusinessEventConnection();
// next step, create the event, callout to sampleUtils
BusinessEvent businessEvent =
SampleUtils.buildEvent((String)getInput().getValue());

BusinessEventMediator mediator = new BusinessEventMediator();
// and publish it via connection
conn.publishEvent(businessEvent, 3);

The event can be created with the code below ..


public static BusinessEvent buildEvent(String input)
throws Exception
{
QName eventName =
new QName ("http://schemas.oracle.com/events/edl/HelloWorldEvents",
"InitiateHelloWorldEvent");
BusinessEventBuilder beb = BusinessEventBuilder.newInstance();
// set the event name (that matches the QName of the EDL)
beb.setEventName(eventName);
// payload element as dom
beb.setBody(createElementFromInput(input));
UUID uuid = UUID.randomUUID();
beb.setProperty(BusinessEvent.EVENT_ID, uuid);
// the conversation id can help to find the composite instance later via conv id.
beb.setProperty(BusinessEvent.PROPERTY_CONVERSATION_ID, uuid);
return beb.createEvent();
}

The sample utilities that are used in this post can be found here

Weblogic SCA for Java, an introduction ..

Raghav from our core Weblogic Server team wrote a nice article on how to use Weblogic SCA for Java, which is based on the Service Component Architecture Spring C&I.
This allows java developers to assemble java components in a very SCA-alike fashion, and expose or consume services as EJBs or Webservices.
Fusion Order Demo for PS1 already ships with a bean assembly, exposed as EJB, that is built that way (the ExternalPartnerSupplierEJB)

Now when you make use of the Spring component inside Oracle SOA Suite, you are transparently using the above engine. In a nutshell - this is end to end java integration into the soa world - the SCA way.

You can find his article here.

As we are working on getting them ready for production in Patchset 2, we are keen on feedback - so please let us know what you think.

December 10, 2009

SOA Suite 11g: How to invoke composite services

another undocumented sample end2end-108-InvokingCompositeServices.zip shows how to invoke composite services via Event, REST, JAX-WS, and Direct Binding.

In a nutshell - you can only invoke what you declare to be invocable via a certain binding. In the sample you will see

<binding.direct> which is the direct, transactional java based binding
<binding.ws> which exposes a service via SOAP/http & rest enables it and
<business-events> which enables an event subscription.

enjoy - and let me know if you run into issues

December 9, 2009

SOA Suite 11g - some (long awaited) BPEL samples

I was trying to filter through the forums and many emails from customers / partners / and internal people - to come up with a list of samples that illustrate common issues

soa_samples_bpel.zip

The soa_samples_bpel.zip contains
bpel-102-AssignActivities illustrates how to work with advanced activities, such as copyList, or insertBefore
bpel-103-Loops illustrates how to work with arrays and collections, through xsl, flown and while loops
bpel-104-SynchronizationOfProcesses shows how to synchronize processes / or branches with each other (through signals / links & events)
bpel-105-Headers shows the usage of header variables between processes
bpel-106-FaultHandling demonstrates fault handling, with custom faults, and compensation
bpel-107-WorkingWithSDOAndEntities showcased the usage of SDOs and entity variables (in a simpler form than Fusion Order Demo does)
bpel-108-UsingXQuery is a port of the 10.1.3x based XQuery sample - showing how to use xquery for complex operations
bpel-109-UsingSchematronForAdvValidation Illustrates the usage of Schematron for context based validation within a bpel process (via bpelx:exec activity) and
bpel-110-WorkingWithRestillustrates how to call a rest based service (in this case google's robot) and how to invoke a composite via jax-ws http binding

Note that all of these are undocumented samples, so they are only code based. Once they'll go on samplecode.oracle.com - they will be nicely doc'ed and also contain build scripts.

December 7, 2009

Comparison: Oracle WebLogic Integration's Custom Control and SOA Suite Spring Component

Simone Geib from our team, based in lovely rainy London, and me set together a few weeks back and cranked out an article explaining how migrate the extremely powerful WLI custom controls over into a SOA composite leveraging the brand new Spring component.

The whole article can be found at http://www.oracle.com/technology/architect/soa-suite-series/wli_custom_control_spring_component.html

November 28, 2009

Intrinsic interoperability - what it is, and what it's not ..

The soa manifesto notes amongst other values
Intrinsic interoperability over custom integration

While the REST gang (and that's meant nicely) demands this one as the justification why every service should be based on REST (read architectural style) I would argue that this is at the very best a small part of the whole puzzle. Yet an important one (arguably HTTP is by far the widest understood protocol, with implied transport, security, and lastly CRUD type operations [create / update / delete & find] syntax)

Anne Thomas Manes (Burton Group, fellow co-author) for example noted in her blog post "Intrinsic interoperability is a function of semantic compatibility more than anything else. If you have to stick a transformation function into a communication path, you don't have intrinsic interoperability" - I like that, a lot actually ..

So here are my thoughts ...
a) Interoperability comes in multiple facets (protocol, transport & semantics [of data and shape])
b) REST as architectural style covers at the first two, yet being forced into 4 verbs (GET, PUT, DELETE, POST) is forced protocol interoperability, as opposed to intrinsic interop. IMHO
c) The key to interoperability, intrinsic that is, is first and foremost a widely accepted [readable/discoverable/interpretable] description of capability and a common understanding of the exposed data that is offered / consumed [that is the semantics]. Syntax comes second in my world.

So with all that said, yes it's pretty darn hard to "create" intrinsic interoperability, if you don't start on a green field (I think a putting green; nice, clean, and a little bumpy), or put a lot of thought into your incarnation (instance) of SOA in the first place

The key to enable real intrinsic interoperability is likely to be found in semantic / syntactic mapping that happens transparently at runtime (inside the connecting infrastructure) that powers services. Mapping MEPs / protocols / transports - is [unfortunately] the real world, and how systems (will) likely communicate over the next centuries.

However to really save cost in the long term [refer to "sustainable value" / "strategic goals"] - as opposed to the "stick a transformation in every communication path [courtesy of Anne T. Manes]" you gotta design your service landscape with intrinsic interoperability in mind.

a-1) Each service MUST describe its capabilities, in a commonly accepted [for your consumers] format. That includes [yet is not limited to] security, QOS, structure, responsibility, contact and pricing model, version (and change history)
a) Employ a [domain based] common data model
b) Use async' MEP patterns wherever possible
c) Expose services via multiple bindings [e.g. SOAP [jms/http], POX/HTTP, Java, JSON]
d) Offer forward based - as well as a backward based - compensation handling facilities
e) Employ REST-like concepts where it makes sense (data driven, CRUD type services)
and f) even with all that you'll possibly still need some sort of mapping / transformation [call it ESB, call it whatever else you like..] that allows all the not-so-intrinsic-interoperable pieces to participate happily ..

November 26, 2009

Fusion Order Demo - tips, tricks and traps

As the latest version of Fusion Order Demo introduced a few new features, deployment got a little more complex as well (behind the scenes that is).

I have seen people in the field hitting two issues, over and over again.

The first one manifests itself through the following in the ant output:

[wldeploy] Task 3 initiated: [Deployer:149026]deploy application ExternalPartnerSupplierEjb on soa_server1.
[wldeploy] Task 3 failed: [Deployer:149026]deploy application ExternalPartnerSupplierEjb on soa_server1.

[wldeploy] Target state: deploy failed on Server soa_server1

[wldeploy] weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: weblogic-sca, exact-match: false].

[wldeploy]

[wldeploy]

This happens because the ExternalSupplierEjb has a dependency on a shared library that get's deployed earlier - and in this case case could not be deployed. The key is to get "soa.server.oracle.home" in bin/build.properties right.

In my case this property points to "/scratch/cutschig/fmwhome/AS11gR1SOA". In a sibling directory of AS11gR1SOA you should find the wlserver_10.3 directory (in my case /scratch/cutschig/fmwhome/wlserver_10.3)

Secondly although it might seem deployment went through fine - you get
[clientgen] [ERROR] Invalid WSDL http://localhost:8001/soa-infra/services/default/OrderBookingComposite!1.0/orderprocessor_client_ep?wsdl during testing.

This means that your foreign.mds.type is NOT db and while compilation works, the deployment must fail, because the shared artifacts are simply not available on the remote server.

For the next version of FOD I'll make sure these problems can be found easier - sorry for the inconvenience.