OL Learn

Dynamic XML input based on requirements


Suppose I have a XML input file with the following format:


I have several order documents that fall into 2 categories:
1. The document starts with static information:
customer information
product information
other information
This static information is the same for each order so that is why it is displayed first
After this static information a table is displayed with one row per order (so in this example 3 rows)

2.	Each order is displayed on one page with the static information.
	So with the xml example above I'll have 3 pages

The addresses I can make conditional so only use the addresses above the orders block (/xml/addresses) when a document
in category 1 is encountered. Show addresses per order when a document in category 2 is encountered.

Is it possible to do what I want in 1 data mapper or is it unavoidable to use multiple data mappers for this specific case?

I’m not quite sure I understand what you are looking for. Can you just post a mock-up of the output you want to obtain?


Here is the output for case 1:

And here is the output that I want for case 2:

When I try to acomplish this in the data mapper I have the problem where I must set the Input data specifically based on my case. So for case 1 the delimiter element /XML
For case 2 the delimiter element would be /xml/orders/order
Unfortunately I cannot see a way to program this. So I must then use 2 data mappers and check in the workflow what type of document I have and based on that select which data mapper to use.
Or I use a preprocessor and run some kind of transform over the xml before I start processing it. Unfortunately in the preprocessor I do not have access to the information in the XML yet to determine the type of document. So then I must read the xml twice: 1 for reading the document type and once again for applying a transform.
If I receive a lot of files then this will take up a lot of time.

Is there some way to solve this without using 2 data mappers?


I’m still not entirely sure I understand your use case, but let me put it this way:
If the data model you are extracting for document 1 is different from that of document 2, then yes, you must use two separate DM configs. From what I can gather, document 1 must extract all the orders as a detail table, whereas document 2 must extract each order as a separate record.

You could probably cobble something together to fit both cases inside a single data model, but then your templates will have to deal with an awkward data model, probably requiring some complex scripts. So the question is: why would you want to do that? In terms of ease of maintenance and performance, you’re better off creating two separate data mapping configurations.

Remember that in the DataMapper, it is easy to skip over records you don’t want to process and even better, in version 2019.2, you can stop processing the entire file at any moment if you want. So I would definitely recommend you create specialized DM configs, one for each case.


You are correct that document 1 shows all order info in a detail table on a single page (as long as it doesn’t overflow) and document 2 shows each order per page.
We would like to maintain one data mapper because we expect a lot of changes since we are working on a new order management system so the database is going to change a lot over the next couple of months with a lot of additional fields. When we have multiple data mappers we have to change each one separately.
Right now I am more leaning towards applying a transform (xslt) on the xml in the process based on the document type whenever necessary. When all information that needs repeating for all orders is in a single section I can copy that into all order sections and make sure that the input data element is set to the root level for the orders.
I can keep the structure of the xml the same so then use 1 mapping but create additional sections whenever I require this.

Skipping records or stopping the process altogether is not what I need because I require information from all records so everything needs to be there.