XML files in Priority

Two new programming projects landed on my desk today. That's not to say that they were completely new, but rather they had progressed from the conceptual stage to the prototype stage. Each one will require further development but I'm very satisfied with my progress today.

The first was reading barcodes with a mobile barcode scanner; the idea is that we will issue each worker in one department with a personalised scanner, each one with the worker's id. Every day the workers will be issued with a page listing all the tasks which they have to perform, where each task has its own barcode. The barcodes are read on the factory floor and are broadcast to a docking station which is connected to a computer running a specific screen in Priority. As a result, we can know on-line what has been produced and who produced it. This has been forced upon us because according to the standard times in each work order and the number of work orders completed, we seem to be overstaffed by nearly a factor of two in this department.

The second project is more complicated: this involves reading an XML file which is created by a computerised design program which is supposed to contain sufficient information for me (or rather, the program that I am writing) to create parts within Priority and to create a bill of materials. I've done similar projects in the past for two other design programs, but the incoming data was somewhat lacking. It looks like we are going to make a large investment in this program (both money and time) and finally we have the possibility of tailoring the interface to our requirements.

I sent the representatives a sample XML file which contained some of the data that I require, and they sent me back a full XML file which contains much more information than I require at the moment. I knew that I had once written some form of procedure in Priority for reading XML files but I couldn't find it. Then I remembered that I had previously written a blog entry on reading XML files, and once I found this, by the date I could find what I had previously written.

I tried to use what I had previously written, but this didn't work for unknown reasons. As I wrote then, although there is some mention of XML files in the documentation, as usual this is so opaque as to be useless.  Maybe I now have a newer version of the documentation, for this time it made a bit more sense (even though there is a mistake in the code); instead of writing an interface, I could use an external program which deals with all the XML parsing, presenting me with a table where each tuple has a row number (not important for me), a tag (i.e. the XML tag) and the value of the tag.

It didn't take me long to adapt the example to what I needed; one line per tag is somewhat awkward when I want to create a tuple consisting of several tags, but this was easily overcome. So quite quickly I had a program which read the XML file and saved the parsed version in an existing table (or work area, as Priority terms it). The next stage was to take the information in this table and turn it into the format required for creating parts and a BOM; this is somewhat tedious and finicky, but I've done it before so I copied almost word for word my original code into this new program, and soon I had a program which achieved this second stage.

There is one more stage which needs to be done in the program (GLOB_TOPSOLID.XML) but this will require the representatives and our engineering people to define exactly the required data. 

The lesson learned today is to use the XMLParse program instead of mucking around with a complicated interface.