IBM Sterling Ideas

formerly Watson Supply Chain

Submit new product ideas for Watson Supply Chain solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed. Order Management, Store Engagement, Watson Order Optimizer, Inventory Visibility, CPQ and Call Center are now part of Watson Supply Chain

Connect with IBM experts and your peers on the Supply Chain Collaboration Community and the Order Management Interest Group

Submit ideas for other Watson Customer Engagement Products:

Watson Marketing
Watson Campaign Automation
Watson Commerce

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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 20 2018
  • Needs More Information
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.

What is your industry? Banking
What is the idea priority? High
DeveloperWorks ID
RTC ID
Link to original RFE
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 23, 2018 12:58

    It would be good for ITX to access the whole message

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 23, 2018 13:42

     

  • Admin
    Luke Raiano commented
    September 05, 2018 15:24

    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?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    September 10, 2018 11:22

    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)

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Jun 13:32

    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.