Hi,

i'm sorry...The Oracle Service Bus XQuery engine fully supports all of the language features that are described in the World Wide Web (W3C) specification for XQuery with one exception: modules

bye

So how do other people avoid having to copy and paste XQuery methods from one XQuery transformation to another?

In fact another possibility i use is the following.

Create an xquery application that you want to re-use, for example:
create_header($pars).

Then within another XQueries (create_message) you have to use the header as an external parameter, example (ASSIGN is the assign within a OSB pipeline)

ASSIGN $header := create_header($pars)
ASSIGN $message := create_message($header, $otherparameters)

This is not exactly what you want but you have created re-use and are able to unit test the xquery.

any plans for making it available on OSB?

May be you can define custom XPath functions for fine grained utilities.
Here is a good article on how to define custom XPath functions on OSB 11G.
http://eelzinga.wordpress.com/2010/05/10/oracle-service-bus-11g-using-custom-xpath-functions/

What we did is creating a seperate project in which we use most of XQuery stuff, using SaxonSA library to run and validate the queries.

This project adds the following possibilities for xqueries:
- Schema validation of XPath used in XQueries (including namespaces)
- XQuery syntax validation (with errors at the exact line and position where it fails.
- Allows the use of modules
- Reqression testing XQueries

Regrettably we can not do Java callout's from XQueries as this is not supported on the ESB.

We also build a simple 'flattener' that takes a module based, schema enriched XQuery and then generates the XQuery that can be used on the ESB itself. The flattened query is also regression tested.

Although it was quite some work to make it, it already has paid back the initial costs of the project in the second or third project we did. We since then have enhanced the project so it also can do regression message flow validation on the OSB (we already had valid input and output messages).

The tool also greatly improves the stability of the code on the OSB, and reduces development time as we can build the XQuery from a unit test environment that will point out typos and other xpath related problems.

We do have some fairly complex xqueries on the OSB, the number of xqueries in the project at the moment is 187 with 250 unittests.

So, if Oracle is not going to include it in the OSB itself (which seems lilkely at the moment), you can build such a system yourself !

Wim Veldhuis,
PharmaPartners BV

Hey mdsrobbins,

we have exactly the same problem. OSB XQuery code reusability is close to zero.

We have a hugh amount of transformations and unfortunaly we need to copy custom functions to all them. Nowadays our code is hard to maintain and message data enrichment is difficult to manage. We sadly need this functionality.

I have tested to outsource our code in custom functions by Java packages. Functionality was indeed available, but live editing is not possible due to compiled Java classes. Unless these custom functions are not deployable with WLST, we will not be capable to deliver fully automated OSB deployments. Besides, versioning the JAR next to the sbconfigs takes its effort on top (every additional artefact extends versioning complexity).

Does someone know, if the module import in OSB XQuery will be available in following releases (11g and up)?

Many greetings