I am attempting to use pub.web:documentToRecord to convert XML document created by recordToDocument back to a record as part of a transaction-restart capability.

When I invoke pub.web:documentToRecord with the XML string created earlier and the fully qualified record name specified in the recordName parameter, it is not creating the resulting record with the correct dimensionality. Three key recordlists specified as such in the record structure are created as records instead.

The Built-In Services Guide states that the “recordName” parameter of the documentToRecord service is used to “explicitly specify the order and dimensionality of elements. It is an alternative to using makeArrays and arrays to specify which elements are to be generated as arrays.”

My normal workaround would be to ditch the record name parameter and just specify the names of all of the recordlists to be created and set makeArrays to true. The problem in this case is that one of these element names is a record in one portion of the document and a recordlist in another (bad design perhaps, but it is what it is).

So, has anyone else seen this behavior in IS 4.6 SP2? Is there a workaround or patch? Is this fixed in IS 6.0?

Regards,

Mark Carlson

Hi Mark,

I have had minimal problems with this service. So if IS is making a record instead of an array it would seem to point at the possibility that the element in your XML is not matching the record and therefore is not being made into a recordlist. IS will put any values from XML into the resulting record even if they aren’t part of the document reference. Please check the exact path to your elements and make sure the names and structure match exactly.

Thing is, I create the XML using recordToDocument from the same record that I am referencing in the recordName parameter in documentToRecord.

Nothing happens to the XML between the time I create it and the time I attempt to turn it back into a record except that it gets written to and retrieved from a DBMS table.

Weird.

mdc

I found there were some strange things when not using the full record name… But using a record name fixed this.
An alternative is to create a little service to fix the records (I can post up the code tomorrow if you’re keen). Bit of a hack, but it fixes the case where you have input with single values.