WRITE-XML() From Datasets ... - Forum - OpenEdge Development - Progress Community
 Forum

WRITE-XML() From Datasets ...

  • Guys,

    Can anybody provide an example of code that produces an xml document using the write-xml() method from a dataset, which goes more than (2) levels deep?  I see scads of examples for the typical order/orderline, but nothing that goes deeper.  For example:  Order - Shipments - Items (Order has shipments, which has items).

    I can get it the output xml to mirror the xml document I am coding to except I can't get the items node to fall under the shipments node.  Am trying to figure out how to represent this 'third' level, or layer, of data.  I am assuming has to do with the data relation.

    Thanks.

    Dave

  • Hi Dave,

    It is the NESTED option on the DATA-RELATION phrase that causes WRITE-XML() to nest child records within parent records in the XML document.

    ...DATA-RELATION shipItemRel FOR Shipments, Items RELATION-FIELDS (...) NESTED...

    Regards,

    Robin

  • Yeah, I understand about the data relations and I ended up getting the correct xml output thru trial and error, but not really sure why.  The way it stands, I ended up having to create (3) additional temp tables that seem to act as "links" to the main parent records (Orders/Items/Shipments), along with (6) data relations.  I wish Progress would put more complex examples in their documentation - it really would help those like me who are new to datasets and xml.  Everything I find is basic parent-child relationships, like order and order line.  There's nothing for when you get complex like in my case; Order can have item(s) and it can have shipment(s), and these shipments can also have Item(s).

    Here is the temp table definitions and the data relations.  Creating it this way was the ONLY way I found that would produce the output xml document in the EXACT format as the xml document I received as an example to code against.  If anybody feels anything in here is redundant, feel free.  I think my main question is why I had to create these "link" temp tables when supposedly using the "nested" option is all that is required.

    def temp-table SupplierOrdersLink
      XML-NODE-NAME "SupplierOrders"
      field supplierOrderId as char xml-node-type "hidden"
        index idx is primary unique supplierOrderId.
     
    def temp-table ItemLink
      XML-NODE-NAME "Items"
      field supplierOrderId as char xml-node-type "hidden"
        index idx is primary unique supplierOrderId.

    def temp-table ShipmentLink
      XML-NODE-NAME "Shipments"
      field supplierOrderId as char xml-node-type "hidden"
        index idx is primary unique SupplierOrderId.

    def temp-table SupplierOrders no-undo
      XML-NODE-NAME "SupplierOrder"
      field dealerPONumber  as char
      field supplierOrderId as char
      field supplierCustom1 as char
      field orderStatusCode as char
      field orderMessage    as char
      field discounts       as deci
      field OtherCharges    as deci
      field Total           as deci
        index idx is primary unique supplierOrderId.   
     
    def temp-table OrderItems no-undo
      XML-NODE-NAME "Item"
      field supplierOrderId   as char xml-node-type "hidden"
      field supplierSKU       as char
      field productName       as char
      field quantity          as inte
      field cost              as deci
      field ItemStatusCode    as char
      field ItemStatusMessage as char
        index idx is primary unique supplierOrderId supplierSKU.

    def temp-table ShipItems no-undo
      XML-NODE-NAME "Items"
      field shipId            as char xml-node-type "hidden"
      field supplierOrderId   as char xml-node-type "hidden"
      field supplierSKU       as char
      field productName       as char
      field quantity          as inte
      field cost              as deci
      field ItemStatusCode    as char
        index idx is primary unique ShipId supplierSKU.

    def temp-table Shipments no-undo
      XML-NODE-NAME "Shipment"   
      field supplierOrderId as char xml-node-type "hidden"
      field shipId          as char
      field shipper         as char
      field trackingNum     as char
      field shipDate        as date
      field shippingCost    as deci
      field shippingTotal   as deci
        index idx is primary unique SupplierOrderId ShipId.
     
     
    def DATASET OrderUpdate
      for orderId
          ,SupplierOrdersLink 
          ,SupplierOrders
          ,ItemLink
          ,OrderItems
          ,Shipments
          ,ShipItems
          ,ShipmentLink
         
          DATA-RELATION drSuppLink FOR SupplierOrdersLink, SupplierOrders
          RELATION-FIELDS(SupplierOrderId, SupplierOrderId) NESTED

          DATA-RELATION drItemLink FOR ItemLink, OrderItems
          RELATION-FIELDS(supplierOrderId, supplierOrderId) NESTED

          DATA-RELATION drSuppItem FOR SupplierOrders, ItemLink
          RELATION-FIELDS(SupplierOrderId, SupplierOrderId) NESTED
         
          DATA-RELATION drShipLink FOR ShipmentLink, Shipments
          RELATION-FIELDS(supplierOrderId, supplierOrderId) NESTED
         
          DATA-RELATION drSuppShip FOR SupplierOrders, ShipmentLink
          RELATION-FIELDS(SupplierOrderId, SupplierOrderId) NESTED
         
          DATA-RELATION drShipItems FOR Shipments, ShipItems
          RELATION-FIELDS(ShipId, ShipId) NESTED
         
      .

  • From looking at your ABL example, you're trying to make non-relational XML data fit into a relational ProDataSet.  There are nestings of XML elements that are not temp-tables because they contain no fields, and you are creating "hidden" fields in order to be able to make up a relationship that WRITE-XML will be able to use.  The XML appears to also require an node to be the child of more than one parent, which is not allowed in the ProDataSet relational model.

    So, unfortunately, the trial and error approach is your option.

    We do have an enhancement planned for 11.0 to make more of these types of XML formats mappable to a Dataset without as much intervention by the ABL developer.

  • And an xml document is (has to be) a tree structure that has one root node. Each node other than the root has exactly one parent.

  • So, what you're essentially telling me is that because of the potential comlexity of an xml structure (as well as the current limitations of the ABL), that there isn't an easy method to employ; you've got to improvise like I ended up doing it, right???

    It would be cool (or wishful thinking) if a future release of the ABL would allow me to pass it an xml structure and it would spit out all the temp table definitions that would be required in order to successfully use the write-xml() method to replicate that same xml document.

    But, as I mess with this stuff more, it will probably become easier to understand.

    Thanks to all for the info!

  • From looking at your ABL example, you're trying to make non-relational XML data fit into a relational ProDataSet.  There are nestings of XML elements that are not temp-tables because they contain no fields, and you are creating "hidden" fields in order to be able to make up a relationship that WRITE-XML will be able to use.  The XML appears to also require an node to be the child of more than one parent, which is not allowed in the ProDataSet relational model.

    he  has a valid XML so there are no child with more than one parent

    he  tries to get the data out from dataset not to fill one and anyway I  think it's perfectly relational the format he use... it's very common in XML to have the child records 'grouped' below the parent node in an extra XML node (Orders->Order, Order, ...), this is exactly what he does by adding those extra 'link' tables while it should have been easier if there were some XML format related properties in data-relation object (like if data-relation name is defined group the child table records within a XML node with that name).

    what you get now with nested is something like

        

             

              ...

             

                  

                   ...

             

             

                  

                   ...

             

              ...

        

    while it's really more common to have something like that

        

             

              ...

             

                  

                       

                        ...

                  

                  

                       

                        ...

                  

                   ...

             

        

    We do have an enhancement planned for 11.0 to make more of these types of XML formats mappable to a Dataset without as much intervention by the ABL developer.

    seems like this is not considered so very non-relational after all