IBM Sterling Ideas

Shape the future of IBM!

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:

Post your ideas

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
1. Post an idea
2. Upvote ideas that matter most to you
3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notifications on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

read/write IIB environment tree in ITX plugin

Other IIB transformation engines can access all parts of an iib message (environment, local environment, ...). But the current implementation of the ITX plugin only allows to work with the payload of an iib message.

 

Please enhance ITX plugin so that we can also read/write the iib environment tree.

  • Guest
  • Jul 20 2018
  • Not under consideration
What is your industry? Banking
How will this idea be used?

Customers using ITX in IIB can build better message flows, because ITX can access metadata directly / no need to build workarounds with custom output messages in ITX that need to be parsed again in IIB.

  • Admin
    Luke Raiano commented
    16 Sep, 2021 03:41pm

    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.

  • Guest commented
    14 Jun, 2019 01:32pm

    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.

  • Guest commented
    10 Sep, 2018 11:22am

    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)

  • Admin
    Luke Raiano commented
    5 Sep, 2018 03:24pm

    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?

  • Guest commented
    23 Jul, 2018 01:42pm

     

  • Guest commented
    23 Jul, 2018 12:58pm

    It would be good for ITX to access the whole message

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.