The resulting map serializes and deserializes multiple iterations (or none) of the object in <myList> no problem.
Original Message:
Sent: Thu August 24, 2023 11:57 AM
From: Rex Chan
Subject: Best practices for output specification
Performance should be the same regardless whether you are using JSON Template or imported Type Tree.
I can't comment on manually created Type Tree as I probably won't recommend it for JSON or XML.
Do make sure the JSON Template is not a large file as it could impact the map size. JSON Template should only be sample data that represents all the possible objects. I believe you need at least 2 repeating groups/element for multiple occurrences as it would affect the group Range (like 1:s).
------------------------------
Rex Chan
Original Message:
Sent: Thu August 24, 2023 10:46 AM
From: Nout Hoozemans
Subject: Best practices for output specification
Hi Rex,
Thanks for responding!
The idea, as you say, is to use JSON Templates -- a JSON sample message, fully populated with representative values, but with only a single item populating each array, as the type specification.
I'm considering three options for specifying JSON messages:
- Manually create an MTT (or manually modifying an MTT generated by importing a JSON)
My concerns here are:
- Changes are difficult to track, as the MTT is binary. You could export the MTT as XML, but then you'd have another separate document, even further removed from the source doc.
- There is a million different approaches for specifying the same JSON structures in an MTT. Each developer will have a different take on how to encode them.
- Complexity. No matter how fluently you speak MTT, it's still more complex and less transparent than a simple JSON message.
- The type spec is too far removed from the source document.
- Generating an MTT by importing a JSON, and using this without modification.
- and c. as above. In fact, the MTTs generated by importing JSON are not always a joy to work with.
- Using JSON Template messages directly
- Possible performance issues? I'm not sure how performant these generated MTXs are compared to either generated or manually constructed MTT's.
Are there any other considerations pertaining to these three options I could put in this summary?
Thanks!
------------------------------
Nout Hoozemans
Original Message:
Sent: Thu August 24, 2023 10:23 AM
From: Rex Chan
Subject: Best practices for output specification
Let me make sure I understand. The idea is to use a JSON Template or JSON Schema (relatively new) in the input or output card instead of a Type Tree (.mtt). I agree with this approach.
As you know, you can use XML XSD in the input or output card directly instead in the last few years. This eliminates the effort to Import the XSD as a type tree. When there is a change in XSD, it will be reflected in the map.
The same technique can also be applied to JSON Template or JSON Schema in v10.x (JSON Schema requires the latest release 10.1.x). No importer is required. When there is a change in the Template or Schema, it will be reflected in the map.
Just to clarify what is a JSON Template. It's sample data.. The Template however should consider all JSON objects, not just some objects. This is so that the map can parse any object in the real data.
------------------------------
Rex Chan
Original Message:
Sent: Wed August 23, 2023 03:54 PM
From: Nout Hoozemans
Subject: Best practices for output specification
Good morning!
I have some questions cq. opinions regarding (input and) output specification for ITX maps.
Given a landscape of fairly simple transformations, where for instance one or two layer XML is transformed into a similarly layered JSON for POSTing to a RESTful APIs, and supposing that we get output specifications from our back end suppliers in the form of model JSON documents (eg. comprehensive/representative sample messages), I would say that it's best for version control and maintenance to keep as close to the source of truth as possible, with as few layers of specification between that source and the implementation as possible, and use the JSON as a type doc *directly*, rather than produce an MTT for that JSON.
I know that there may be cases that necessitate producing an MTT, but I'd say that using JSON docs is a pretty solid *guideline*. You keep close to the RFC, you eliminate complexity of maintenance by limiting sources of truth, and improve transparency and maintainability (especially in the context of version control) by not using a binary as type specification.
That was the opinion part. Here comes the question part:
Am I wrong, and if so, why?
Thanks for your response!
------------------------------
Nout Hoozemans
------------------------------