Kbase P65478: Converting a ProDataset to XML and back - basic guidelines
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
18/11/2008 |
|
Status: Verified
GOAL:
Converting a ProDataset to XML and back - basic guidelines
GOAL:
How to build a ProDataSet out of an XML document
GOAL:
How to convert XML to a DataSet
FACT(s) (Environment):
OpenEdge 10.0x
All Supported Operating Systems
OpenEdge Language Category: ProDataSets
FIX:
When setting up a mapping between an XML document and a 4GL Dataset, the XML schema is important, as this will indicate which elements and/or attributes will be table fields, and which will translate into tables.
Keeping in mind that XML uses a hierarchical data model, while the Dataset uses a relational one, the main issue with converting one into another is transforming the data schema to suit the different models.
Generally speaking, the following guidelines apply when converting a Dataset schema to an XML schema:
1. The XML document root node will be the equivalent of the Prodataset object handle. Any specific properties of the Dataset should be included as attributes of the root node, or as elements directly under the root node depending on the property. (A description of the dataset would be an attribute, a data-relation sub-object would be an element.)
2. Each table in the dataset will be a branch-level node. The XML element name would match the dataset table name to allow easy identification.
3. Dataset table fields each appear as a leaf-level node under the table node. The XML element name would again the dataset field name. The element would contain the field value, any further information such as format would be stored as attributes.
4. If the dataset table is a parent table (ie. Orders), child tables (ie. Orderlines) will be branch nodes under the parent table. Usually the elements for these nodes will be defined after the parent table's "field" elements.
5. To ensure data integrity and to allow easy processing of the XML, the definitions should be added to the XML document as DTDs. When building the DTD, keep in mind that each record in a dataset table will be a separate instance of the matching hierarchical structure in the XML document.
When converting an XML schema to a dataset, the first thing to do is to build a "raw" schema based on the DTDs in the XML document. The following guidelines apply:
1. Create a Dataset object, based on information found directly under the XML root node.
2. Create a temp-table for each branch node defined in the XML DTD.
3. Each leaf-level node is added as a field to the temp-table that matches it's parent node.
4. Add fields to each child table to store the key values of it's parent table. (A grandchild table will include key values for both the parent and grandparent).
This schema can then be refined by adding indices to the temp-table and data-relations to the dataset.
Keep in mind that if the schemas are known, the dataset can be built using static 4GL code as opposed to building it dynamically at runtime - this will be easier to debug and more efficient to execute.
Once the schemas are in place, copying the data over from one object to another becomes relatively simple.
To copy a dataset into an XML document, use nested queries to walk through the records of the dataset and create and populate the relevant XML elements (branch level element for the record, leaf level elements for the field values).
To copy XML into a dataset, the reverse applies: Walk through the hierarchical tree in the XML document, create records for the branch level elements and assign field values according the the leaf-level elements. Take care to ensure the key values for parent tables are added correctly to the child tables.
Of course, the above guidelines are just that - guidelines. They will not be relevant in all cases, or there may be more efficient ways to achieve the desired result. Common exceptions are:
- If the purpose of the generated XML document is to transfer data from one system to another in bulk without further processing, the table fields and their values could be written as attributes of the "record" elements in the XML, which would significantly reduce the size of the generated XML document.
- The XML document may contain what would be table field v.alues in a mixture of "field" elements and attributes of "record" elements. This will have to be taken into account when populating a dataset.
- A dataset can have multiple top-level tables, for example it can have Orders and Items as top-level tables, and Orderlines as a child table of both (m-n relation split into 1-m and 1-n relations). This doesn't translate very well to a hierarchical data model. The XML standard offers a number of advanced techniques to cover such situations, which will have to be taken into account when building an XML document from a dataset or the reverse.
Due to the above exceptions and the frequency with which they can occur it can be nearly impossible to write generic conversion procedures without implementing a schema mapping repository - and building such a repository is not a small task.
It is likely more practical to write separate conversion procedures to map the different XML schemas to the relevant Dataset schemas and back..