DSXchange

Hi Folks,

We are encontering a problem with xml files that contain nested records (repeating groups). Datastage is pretty much fabricating data for fields that don't appear accross all the records of a repeating group.

For example, the file below contains 2 addresses for the customer 55000. The second address doesn't contain the zip attribute, so if you process this file using the XML input stage in order to extract the 2 addresses (key=address id) into a sequencial file, you will end up with 2 records, and the second record will have the zip attribute added and the content will be the same as the last one's. I would've expected to see the attribute created with null, but that's not the case. Interestingly, we have datastage v6.0 here with xml pack1.0, and it works ok, I mean the attribute gets created with null content. Not sure if this issue wast introduced by xml pack 2 or by datastage 8.5.

Any thoughts?


<?xml version="1.0"?>
<customers>
<customer id="55000">
<name>Charter Group</name>
<address id="1">
<street>100 Main</street>
<city>Framingham</city>
<state>MA</state>
<zip>01701</zip>
</address>
<address id="2">
<street>720 Prospect</street>
<city>Framingham</city>
<state>MA</state>
<zip>01701</zip>
</address>
<address>
<street>120 Ridge</street>
<state>MA</state>
</address>
</customer>
</customers>

Is "nil" support defined the same way in both environments?

hard to say, but indeed, normal behavior for this would be for you to receive nulls for elements that don't exist in that lower node....

...but carefully check which column on the output link has your "repeating element" (key = yes). That may have sometihng to do with it. It should be one of the address elements that you expect will always exist....

Ernie

Hi Ernie,

The address id is set as the key for the repeating group. The issue is not with the repeating group, it's with the absence of attributes. In ds 6.0, it worked fine, absent attributes are created with null content, in version 8.5 columns are created too and random values put in them. We raised the issue to IBM support but they don't have a clue either.

I haven't seen this fail, so my suggestion would be, using your tiny document sample, to play with some possibilities:

a) move the repeating element. right now you have it on an attribute....usually that works, but who knows. Make it "street" and see if/how the behavior changes for the missing zip.

b) add another column, for the "whole" address. (have the xpath just end at .../address/ ....make that the key. See if/how the behavior changes.

c) using your test document, add a containing element that surrounds addresses (something like <all_addresses> and </all_addresses>. See if/how the behavior changes.

Ernie