We understand the importance of this. We intend to review at a future date, but not in the current horizon for these types of requests. Please re-open in Q2 if this is still a requirement.

So the basic problem is: How can we exchange data between IIB (the runtime) and ITX (the plugin)? First there was no integration between message sets (IIB) and typetrees (ITX), so the data from the other tool is always a BLOB that needed to be parsed. But that was not efficient, because you had to use an ITX parser for BLOB data that was already structured in IIB.

That problem is already solved thanks to the connection between XMLNSC (IIB) and native XML (ITX). So all the XMLNSC messages in IIB can already be accessed in ITX without parsing it again. That's the trick we currently use in order to access payload and metadata. So we created an XMLNSC structure like this:

<root>
  <metadata>[serialized Environment tree]</metadata>
  <payload>[the actual payload]</payload>
</root>

And that's what each and every map in the ITX plugin is using on its input card with native XML. It doesn't need to be parsed, that's good, however it would be even better to take this optimization one step further. Why do we need this XML message containing metadata and payload in the 1st place? Because there's a limit of 1 single input card in the ITX plugin. Since our metadata is basically the data that can be found in the Environment tree, we'd prefer to access the environment tree in the ITX plugin directly on an input card of its own. That way packaging metadata together with payload in one tool and separating it in the other would be obsolete.

So here's what we like to see:
1.) add an option to the ITX plugin in order to activate input card #2, which will contain the Environment tree
2.) implement a serialization type for the Environment tree in IIB the same way as you've done with XMLNSC and XML native, so that ITX does not have to parse the data, but can re-use the serialization of IIB
3.) provide an ITX typetree for that serialization

My focus here was on the input side ot ITX. You might think of solving the same issue on the output side as well. There we're not limited to 1 card only. And we actually don't need to WRITE much data from ITX into the environment tree, so maybe your current implementation with PUT() is already sufficient for us.

Here are a few examples:

- environment contains routing data of the message; some mappings need to know their routing

- environment contains metadata like "initial filename ot source system"; some mappings need to know the filename, because it contains business information like the report's date

- mappings that want to set the "filename for destination system" need to access the environment, because the file adapter after the mappings expects the filename there

Currently our workaround is to work with an artificial data structure in the ITX mappings that contains everything, all the metadata, the payload and we even have separators for multiple output messages. Parsing works like this:

IIB: input=blob, builds artificial structure with metadata+blob, calls ITX plugin

ITX 1st stage: input parses artificial structure, calls RUN(ITX 2nd stage), input card #1 = payload, input card #2 = metadata

ITX 2nd stage: input parses ic#1 with specific parser for payload (xml, cobol, csv, ...) and ic#2 with metadata structure; builds new artificial structure for output (again: metadata+payload)

ITX 1st stage: parses artificial structure, can forward it completely to iib, but can also do some stuff already that needs to be done within the transaction of the ITX 2nd stage

IIB: parses artificial structure, separates metadata (-> written into environment) from payload(s) (-> blob)

Can you provide more information?  How would this be used, what exampie use case can you provide?  What part of the meta-data can you not access currently?  What are you double-parsing?

It would be good for ITX to access the whole message