Skip to Main Content
IBM Sterling

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 (

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:

Search existing ideas

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 your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Categories Integration Servers
Created by Guest
Created on Jul 20, 2018

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.

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.

  • Guest
    Sep 16, 2021

    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
    Jun 14, 2019

    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.

  • Guest
    Sep 10, 2018

    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)

  • Guest
    Sep 5, 2018

    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
    Jul 23, 2018


  • Guest
    Jul 23, 2018

    It would be good for ITX to access the whole message