Leveraging XML with SolidWorks EPDM

You may have heard the term "XML" thown around with everything from blog feeds to 3D models but the underlying technology is pretty simple and extremely powerful.  "eXtensible Markup Language" (XML) is an extensible language, meaning that anyone who uses it can customize the structure in order to apply it to their application, for sharing structured data outside of the application in question.  Much of our blogging communty refers to their "feed" which is a continually built file that contains all the contents of their blog site in an XML file that is referred to RSS.  Really Simple Syndication (RSS) is a standard for communicating a blog or podcast's data utilizing the XML standard.  Here is a simple examle:

<xml>

<quiz>

<question>

What is SolidWorks Heard?

</question>

<answer>

A podcast covering SolidWorks related tips and tech news.

</answer>

</quiz>

</xml>

The structure displayed above is completely customizable and can have many sub items in order to show the hirachy of a more complex data sequence.  A good example would be if you wanted to show configuration specific file properties within a single part file.

In SolidWorks Enterprise PDM, XML is used as the universal language to communicate to ERP/MRP systems.  By using this standard format, the issues with having to code custom conduits in order to talk to each end (PDM <->ERP/MRP) are avoided and that data simply can be parsed by each system independantly.  This approach also reduces the amount of systems that data needs to be entered into, allowing PDM to do the product management, ERP/MRP system managing the other critical systems while sharing this common data thread through XML.

XML can either be imported in or exported out of EPDM by setting up rules in the Administration tool based on certain criteria the user determines.  Once these rules are defined, an action in the workflow performs the operation of pushing or pulling, typically metadata, for use within the system.

There are, however, a few stipulations to utilizing this data for import. One, the XML file must contain a variable for each file that can be recognized and matched within the database.  The variable "Filename", for example, would need to be written by an action that grabs the actual file's name and writes it to that file's "Filename" variable. Once this is set, the XML now has something within it's contents that can be paired to the database. And two, every item, or "Filename" of the XML  must exist in the database before the import action is performed.  This means that you cannot pre-import data into the database before the files have been checked into the database.  Since the import action needs to match the data up first, it has to exist in order to be accepted by the system.

Once these two criteria are met, the data is written to a temporary table till the action in the workflow is performed, then writing the data to the file data card. One fail safe test is the XML file should dissapear if the system accpets the file, so if the file sticks around longer than your polling interval, something went wrong.  If something does go wrong, don't look in the EPDM logs for the import issues, these issues exist in the Event Viewer in Windows and will give you good feedback on what when south!

Overall, utilizing XML is a great step towards streamlining all data-based systems to communicate without running into the all too familiar file format war or custom conduit woes!~Lou