Bpel 4 people / Bpel 4 newbees

One of the main goals I’m trying to reach is to advise customers on how to start implementation of SOA in their organisation by using a coaching approach instead of implementor approach.

In other words, guide and coach the development teams of each customer in getting familiar with SOA concepts and getting their hands dirty ;o))
The developers themselves are tought BPEL, Web Services, XML and XSD through basic hands on session, workshops in a practical way and then they start designing bpel processes.

What’s very important is this process is that each person needs to do the brainwork, in other words always start from scratch, don’t define a synchronous or asynchronous process, no define an empty process and build it up yourself.

What’s very interesting when guiding and coaching people in becoming a SOA expert, is understanding the way they think and handle functional requests and problems in a SOA Technology. This gives me the opportunity and possibility to focus more on how to better advice and guide people in learning SOA, e.g. BPEL.

The most interesting points to consider and think about when being a teacher in SOA or being a student are the following:

Being a teacher:

  • be passionate, patient, non technical, use metaphors and most don’t use abbreviations or buzz words, this ain’t cool ;o)

Basic knowledge before starting BPEL/ESB/OWSM/Mediators … Integration:

  • Web services (synchronous versus asynchronous)
  • Xml and xsd (how to define, how to work with xml data (xquery, xpath, …)

You need to be able to understand following principles:

  • Fault handling
  • Compensation handling
  • Transaction handling

Following abbreviations mean something to you:

  • JCA, JNDI, EDA, SOA, WSDL, WSIF, SOAP, JMS, RPC

How to get started when designing bpel processes:
One of the interesting tricks I’ve learned when guiding a customers’ developer in learning bpel was that he defined an empty bpel process where all needed activities where pseudo-coded.

In other words when you need to define your first bpel process using the use cases defined and described by your analysts, you just design the bpel process using empty activities which describe each needed task/action in your process.

This empty process is deployable and can then be iteratively implemented by the designer when the visual flow is checked upon with the functional developers. => THIS IS A GREAT INSIGHT and WAY OF THINKING and a very visual approach to enabling business processen (thanks to Yves for the tip !!!)

The most interesting part when starting with SOA development is that everyone that’s involved in this process is learning; it’s a learning organization where every person’s knowledge and expertise is augmented!

Playing around with 11g

Playing around with Database 11g features and SCA 11g functionality (technology previews), I’ve came across some issues which you may find interesting to now/comprehend:
Native PL/SQL WebServices (11g Feature):

  • Procedures or functions need to have in- and output-parameters when using 11g webservices in 10.1.3.1 bpel processes
  • You can’t work with rowtypes as return variables => not supported
  • XDB Username & Password authentication is needed for native pl/sql web service calls, when invoking native pl/sql webservices from BPEL. Add following properties to your partnerlink:

Jdeveloper 11g Tech Preview:

  • You can’t connect to AppServer 10.1.3 (it will be applicable in the production release)
  • You can run existing 10.1.3.1 bpel processes in Jdev 11g when you’ve installed bpel in the embedded OC4J (nice to know)

You need less clicks to get to view audit data in your bpel console and it’s all using one single source of truth, one console, one management environment. Finally you’re used to working in bpel, esb, Jdeveloper … well now you need to get used to the new, improved environment.

minoccurs=0; nillable="true not interpreted in Web Services

In one of the previous posts I’ve defined a workaround concerning the nillable attribute being ignored when invoking web services using xsd’s defined in the following manner.

Because in bpel you’re not able to define the xsi:nil-attribute at design time, you need to define this manually.

The xsi:nil=true-attribute is the solution to tell web services that this attribute, if empty, needs to be ignored. In this way serialization and deserialization will work, otherwise you will always run into NullPointerException.

What’s the cause of our problem when talking about bpel [metalink Note:403586.1]:
The XSLT transformer used by BPEL was not originally designed to pass xsi:nil attributes.

What’s the proposed solution [metalink Note:403586.1]:
To transfer xsi:nil values from source and target schemas in a transformation, make use of xsl:choose and xsl:when as shown below:

What you could also do is in the web service proxy wizard, which is generated for a given wsdl-document change the serializer-classes. Though this isn’t really the approach you woudl wan’t to consider because now you’re changing generated code, which will be changed when the wizard is run again.

The following important message is shown in your proxy generated classes that urges you to not change the generated code ;o)

// !DO NOT EDIT THIS FILE!// This source file is generated by Oracle tools//
Contents may be subject to change// For reporting problems, use the following//
Version = Oracle WebServices (10.1.3.3.0, build 070610.1800.23513)

What you can do, on your own responsibility, is to change the literal_serializer classes which were generated for each object used in your webservices payload. You need to change the setNullable-method for each attribute from ‘false’ to ‘true':

if (
matchQName(elementName, ns1_adresId_QNAME) )
{
myns2_string__java_lang_String_String_Serializer.setNullable( false );

if (
matchQName(elementName, ns1_adresId_QNAME) )
{
myns2_string__java_lang_String_String_Serializer.setNullable( true);

Another possibility is to create a Service Request and define an Enhancement Request so this manual tweaking isn’t necessary anymore in the future … that’s what I’m doing as well/

BPEL Process Invocation from different UI’s – Best Practices

In my previous thread I’ve talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by ‘Hajo Normann’ about this:


It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven’t seen any benchmarks regarding this or haven’t received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)