... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)



Here is the final result.  ALDSP uses the first function in a data service as the submission function, regardless of which function was used to actually retrieve the data.  Therefore, that function must conform to the ALDSP rules, which are:

  1. The return type must match the return type of the data service (like all functions in a data service).
  2. The return type must have cardinality 1 or 0..1.
  3.  (i.e. a declaration like:  declare function submitter(args) as ReturnType*).

In addition, you must build the application before any submissions will work, unlike reader functions which will work right away.

The second requirement is not entirely obvious because by default the Workshop generates reader functions with cardinality 0..*.  However, somewhere in the ALDSP machinery this case is detected and the infrastructure quietly wraps a new cardinality 1 element around the result, typically named 'ArrayOfYourType' (or sometimes 'YourTypeArray' for nested elements).

I don't understand why ALDSP requires a wrapper element in the 0..N case, but not the 0..1 case.

Build Issues

Another thing I discovered is that if you accidentally add a BEA function pragma to a function (e.g. by copy-and-paste from another function) they will work when you test from within workshop.  But when you go to build the application you will get an error message like:

ERROR: workflow3.ds:1:: [ld:DsTest/MmSandbox/workflow3.ds]: The namespace of the function "{http://www.w3.org/2004/07/xquery-local-functions}wraprow" with arity 1 does not match the expected namespace "ld:DsTest/MmSandbox/workflow3".

The Workshop XQuery editor will complain about any functions (including local functions) in a data service file whose namespace does not match the target namespace of the service, but this warning is spurious as the file will still build, deploy, and function properly.  If you want to avoid the warning, declare the function in the target namespace instead.

Apparently, using "build application" in BEA Workshop is not sufficient for the environment pick up certain changes.  I moved a data service file from ".../schemas//bestpractice.ds" to ".../bestpractice.ds".  The environment did not pick up the change even after I did "build application" and even after a "clean" followed by a "build".  Only after I chose "Build EAR" was the change noticed.

Furthermore, some classes of changes (e.g. renaming a data service) may not be picked up by the Workshop test tool until after exiting and re-entering the Workshop application.

Blog Archive