When to Use Custom XPath Functions in the SOA Suite

If you want to know how to create custom XPath functions, then have a look for example at Anthony Reynold's Blog entry on the topic. I have little to add to that excellent posting except for how to add parameters, which is done using the <param> tag as in the following example:

And the following simple piece of Java code to get the parameter from the list:

  public static Object compressGuid(IXPathContext iXPathContext, 

                                    List arguments) {
    String guid = (String)(arguments.get(0));

    ...
  }


If you want to know when or why to use custom XPath functions, then read on.

Before I come to some sort of a conclusions, first let's discuss some of the specifics of the mechanism of adding custom XPath functions.


One Function, One Class

First observation is that a custom XPath function is exposed by a class that implements the IXPathFunction interface. This interface enforces implementation of a call() method which executes the XPath function. As there can be only one call() method in the class, it can realize only one function. So if you want to implement more functions you will need to create as many classes as there are functions. To support reuse you can let each of those classes extend an (abstract) super class that will contain the common behavior and (static) reusable attributes.


No Runtime Versioning

A second observation is that the class to implement an XPath function ends up in a jar file that is deployed in the SOA infra structure. A class is not a service, so there can be only one implementation of that class at the same time. If you need to deploy a new version of the XPath function while keeping the previous one, you either need to put it in a different package or give it another name. On top of that you will also have to give the <function> another name (in the example resulting in a compressGuid, and compressGuid2). How ugly do you want it to get? An obvious other aspect is that the XPath function by definition is reusable for everybody that is deploying on the SOA engine on which the jar file is deployed.


No Right-Mouse-Click Deployment

By now you will realize that you cannot simply deploy a new version of the jar file on the server by just right-mouse-clicking it and then choose "deploy", and that this is for a reason. You will have to copy the jar file to a specific folder, run an ant script, and restart the server.


Conclusion

Custom XPath functions is not the silver bullet to do any type of Java embedding in SOA or BPM processes. Especially as a BPM developers you just might have hoped for this as, unlike in BPEL, there is no Java Embedding activity in BPM (also for a good reason you might argue, but that's another blog entry).

You should only create XPath function for specific types of cases, while applying some best practices:

1. Only use it for XPath functions that clearly fits between all other already available XPath functions. An example is an XPath function I just created (based on the brilliant algorithm of my dear colleague Tonio Voerman), which compresses the 32 character Oracle GUID into 30 characters (because the column in which we have to store it, is only 30 characters long). After all the (existing) oraext:generate-guid() is also an XPath function.
2. Be sure that the XPath function indeed is an obvious candidate for reuse (our compress-guid() function will be used by every BPM process). Otherwise, other solutions like including a Sprint Context in your composite, probably are better.
3. Do your utter best to get the proper requirements for the interface, and functionality, to prevent you find yourself in a situation (and trouble) where you have to deploy a new version of the function next to an existing one.
4. Test the XPath function thoroughly, preferable using some unit-testing framework like JUnit

Unbelievable, this is actually the first time in my life that I manage to post two entries on the same day. Normally I don't even find the time to do two in a week, or even a month for that matter!

OBPM 11g Multi-Langual Process Models

Sometimes simple things are simple!

Take for example creating process models that you can show in 2 different languages. With OBPM this is so simple, that I at first I could not find it because I was looking in the wrong place.

That is: simple if you realize that you can also access (BPM) Project Preferences from the BPM Navigator (next to the Project Properties that can be accessed from the Application Navigator). But once found it's dead simple. Just add an extra language on the languages tab, as shown in the next figure.

You can then enter a second localized label to the pool, events, activities and gateways by going to its properties, and then click on the globe and enter the label.

After that, you can modify the language of your model on the fly by changing the default language, for example from English:

into Dutch:

If you were paying attention, or looked carefully, you will have noticed that I was not mentioning the role and sequence flow. Alas, those are not multilingual.

Oh, and eh... there is a small bug. The label of the pool only refreshes after reopening the model.