XML, XSLT and DFSORT, Part Three - Multiple XML Input Files
MartinPacker 11000094DH Visits (11109)
While I was putting together the original three posts in this series a number of thoughts struck me, amongst which two really cried out for further investigation:
Thought 2 I'll deal with in a different post. This post relates to thought 1.
In the example I've given there are three item elements, representing three transactions. I'm not sure that's entirely realistic:
Certainly there will be many times (for example configuration files) where everything is in the one file. But consider the following scenario:
XML documents arrive in a directory, each representing a single transaction, or maybe a batch of them. In the rest of this post it doesn't matter whether there's more than one transaction in a file, only that there will be multiple files overall. In the previous three posts I've talked about processing a single file with XSLT and passing the results to DFSORT (in a manner the latter can work with). The technique outlined won't (unaltered) process more than one file at a time.
I'd like one DFSORT processing run to handle multiple input XML files. Perhaps you run a batch job every hour to process all the transactions that arrived as XML files, or perhaps daily. The rest of this post shows you one way of doing this. It's a relatively small change to the XSLT stylesheet.
Here are the three transactions, as if they arrived in separate files:
XSLT can't directly process a list of files concatenated together. But you can do it if you can create another file. Here's an example:
If you can create such a file - perhaps by scanning an "incoming transaction file" directory - you can easily coax XSLT into processing the set of files. Here's a stylesheet that can do it:
There are two things to note in this stylesheet:
This "indirection through a transaction file" technique is very powerful.
In practice you might have an "inbound transaction XML" directory that you scan with a program that creates the transaction reference file, invokes (eg) Saxon and then invokes DFSORT, finally deleting all the succ
I think the challenge in this is knowing when the transactions have been successfully processed and so the inbound files can be deleted. You'd have the same problem if - instead of creating a transaction reference file - you created one large XML file from inbound files. (In fact this is easier.)
Anyone feel like - in any z/OS-supported language - writing something to scan a directory for XML files and create a transaction reference file like the one above from their names?