This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
firstname.lastname@example.org - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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:
<metadata>[serialized Environment tree]</metadata>
<payload>[the actual payload]</payload>
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