More Apple System Profiler Fun

[dev_synaptech]

Hi All,

I have been slogging through Fenton Jones' great tutorial for bringing in ASP xml data into FileMaker. I have hit a wall with the project and wanted to submit my work to see if someone might have a better way for me to reinvent this wheel. So my goal is to pull specific pieces of data from various Apple machines (G3, G4, Intel, etc) from their respective system profile data. To control for the varieties of OS's and ASP builds, all of the machines are booting to 10.4.x volumes. I have built an Automator App to pull only the specific SPDATATYPES into a generic xml file (not the .spx ASP output).

So far so good. Using the examples on this board, I have constructed an XSL page to transform the XML data into a simple Filemaker database. I decided NOT to make the SPhardwaredataTYPE the parent record and the subsequent SPdataTypes children (matched by the serial number) for instances such as multiple ATA devices and multiple sticks of Memory (Bank 0, Bank 1 etc). But rather build one very long record with all of this xml data parsed into fields.

I didn't want to have separate XSL files, as I don't know how to automate the multiple transformation steps.

This, I think, is where my problem starts. I can bring the data in, but it seems as though the XML structure is not consistent accross different machines so the xsl file breaks down when you run multiple machine types through.

I have included my files and some sample xml docs to see if what I have done so far makes sense to anyone. }:|

Thanks !

ASP_Import.zip

[dev_synaptech]

So, to be more clear in my request.. Is there an XPATH expression that will allow me to pick out the nodes (and the following siblings) that I want to get from Anywhere in the System Profiler XML output? Or is it absolutely required to define the node within the XML structure to then grab the information you want. As I stated before the System Profiler XML node structure changes by machine and my current attempt at capturing segments of the entire structure is failing.

Any help in the regard would be welcome.

Cheers,

Cliff

[Fenton]

Yes. I had worked on your problem a bit, but I have not had time to finish the complete project; which would reliably import from any ASP xml file. The way that we first selected sections by only their relative position within the report was not the most reliable, though I believe it would work. But this is better:

Just substitute the name of each section; then use position from there (or further tests if necessary.



The other separate problem is what to do about subsections that may have one, or multiple entries. RAM is an example. This is much the same as any relational problem. It is a mistake, in my opinion, to try and do this all with 1 import, into 1 table. That is relationally incorrect; you would not build a FileMaker structure that way, and importing xml is no different; because it is also a hierarchal structure, usually with multiple "levels" of data.



If you have a separate table for RAM, then there is no problem if it is one or many. In fact doing fields RAM1, RAM2, etc. does NOT work with the xsl import. Because if there is no RAM2 you not only get no data, you get NO FIELD. Because the  tags are not produced for a node that is not there to be matched. The result is like doing a tabbed import when a column is empty; everything slides over. That's what you're seeing.



The solution, and it is not at all difficult, is to have separate xsl stylesheets for each table in your FileMaker file. A record will be created for-each RAM chip. Each of these separate imports would be importing from the same overall system profile xml file. But each would only have the fields it needed for its table. And possibly a field to tie them together relationally, a foreign key, like Serial Number, or MAC number. You can set the xml file's path into a global script variable, ie., $$xml_path, and the xsl files' into local variables, $xsl_path.



Since we are controlling these imports it would be easy enough to import the main hardware first, get its FileMaker auto-enter serial ID, then Replace that into a foreign key. That way you don't have to rely on data in the import for a relational key.



I would use AppleScript to get the list of xml files, then cycle through them, moving them to a "done" folder.



Here's xsl for the Memory section:

<?xml version="1.0" encoding="utf-8"?>



  

  

    

      0

      

      

      

        

        

        

        

        

        

      

      

        

          

          		

				  

					

					  

					

				  

							

	

            

              

                

                  

                

              

            

            

              

                

                  

                

              

            

            

              

                

                  

                

              

            

            

              

                

                  

                

              

            

            

              

                

                  

                

              

            

          

        

      

    

  

[dev_synaptech]

Fenton, thank you again for the assist on this project! I understand why keeping the data relational is important as it relates to the overall structure; the hope was to keep the selection of the data targeted with more precise queries... but alas, I'd like to be 19 again too.

OK, so I've built the separate XSL stylesheets and related tables(still having a slight problem with the ParallelATA section, the XSL works for the second device but has the "tabbed" column effect for the first device), but now the problems are "contained" within each set of related records and doesn't blow up the entire record.

So the workflow, at least so far in my mind, is that when the user scans the machine barcode into a field;

I'd like to then, take that field data use it as a part of the XML path declaration (as it's also a file name: e.g. /desktop/ASPFILES/uv1234bg1rg.xml), is that possible?

In terms of automating that's where I am in over my head: Let me see if I get this conceptually.

For each XSL stylesheet import, it has to be defined as a variable, also, the XML Path needs to be defined as a variable. Since this is a repetitive process, here's my logic: the XSL stylesheets will stay "constant", but the XML Path will always change, so should the global variables be the XSL stylesheets and the local variable be the XML Path?

So, if I have six XSL stylesheets, should I create six containers that hold the never changing values and call them from the script? Or should I paste them as a "value" in the variable definition?

Which leads me to my next question: exactly how do you get the variable information (XSL stylesheets and XML path declaration) into the import dialog or import process ? Or how does the import function call that variable data? I've tried two methods: pasting the XSL data directly into the "value" field, and defining a container to hold it then using that field as a calculated value. No joy on either.

Whew, I can feel my brain stretching..

Cliff

[Fenton]

The XML Import command was designed to do this. It has a file path space for 1 xml file and (optionally) 1 xsl file, for each import. This is where/how the xml/xsl tranformation takes place on import.

Yes, the XSL file path will be the same for any one table, 1 file per table. The XSL files (text) would therefore sit in a folder, so you'd know where they were.

The XML file would be different for importing a new machine. But it would be the same for a given "set" of imports for one machine; each to its own table. So you'd set it into a global variable at the start of the imports. But then the other table imports for that machine would use that same xml file.

I like to have 3 folders: xsl stylesheets, xml file(s) to import, and xml done (move each after their import routine is done, so you can do multiple xml files in succession if necessary). You would do this by using a command to list the folder; such as AppleScript's "list folder _the folder path_ without invisibles" (returns names).

Whether you declare a script variable to be global or not has to do with whether subscripts are going to be using it or not; the xml will be recalled by subsequent imports to the child tables. The xsl files will only be called by their own script/subscript, so its variable could be local, but could be global (no harm). So, even though the xsl files are fixed filepaths, that's not what determines which syntax of variable is used.

[digitaljunkie]

I have been slogging through Fenton Jones' great tutorial for bringing in ASP xml data into FileMaker.

Please share the wealth/love as I cannot find this intriguing tutorial.

Thanks

[Fenton]

I'm afraid there is no tutorial as such. I believe dev_synaptech was referring to an earlier discussion we were having on this.

http://www.fmforums.com/forum/showtopic.php?tid/181034/post/224723/hl//

I believe the current problems have more to do with relational design, and how to use multiple xsl stylesheets (files) to bring data into separate related tables.

Actually the "multiple" stylesheets is mostly just my preference, as it's easier for me to separate the xsl into shorter files. You could build all the xsl in one file. Then, during each import just match up the fields you want to import. I can see this being useful if you want to use the 'generate-id' function of xsl. But, with the power of FileMaker scripting, to pass and replace values during imports, I don't see the need for the above. As always, there's more than one way to skin a cat (where did that saying come from? -)

[digitaljunkie]

cool ill have a read up, thanks