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