App Connect

App Connect

Join this online user group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  Creation of Manifest File.

    Posted Mon November 08, 2021 02:49 AM
    Edited by Preethi B V Mon November 08, 2021 07:11 AM
    Hi Team,
                  In a common message flow which has multiple manifest file(XML or JSON), where each manifest file which will call the ESQL file for some process based on some parameters is true.
                  How to create that manifest file and to call a transformation ESQL file based on its parameter. How to incorporate that file in our flow.

    Thanks,
                  


    ------------------------------
    Preethi B V
    ------------------------------


  • 2.  RE: Creation of Manifest File.

    Posted Mon November 08, 2021 10:56 AM
    Hello Preethi,

    From what you're describing, I would look at handling this one of 2 ways.

    First, you could have a common routing flow. Where based on something common within the message itself you could route the message to either a full message flow to handle that message type, or you could do this as a sub flow. The question is when and where you want to message transactionality to be committed. If it's a subflow, the transactionality will stay with the routing flow, which is going to slow the entire process down rather than having a commit and allowing the new flow to process the message. Personally, I would prefer to use the full message flow to separate the transformation logic from the routing itself. The routing flow will be much busier, so I'd keep what it's doing to a minimum and shift the transformation to a separate flow specific to that transformation so you can independently scale the processing for the transformations that are used the most and require the most resources.

    Second, instead of routing things the way I've mentioned above, you could still route, but instead of using separate flows, you can just call a commonly defined function or procedure to handle that specific transformation. While this is certainly an option if you only have a couple choices for routing, it could become bloated rather quickly.

    I guess what I'm saying is I'd stay away from a 1 flow does everything model as that's going to make it harder to keep up with changes and will affect your overall performance.

    ------------------------------
    James E. (Jim) Berube
    Technical Account Manager (TAM) - Specialist, IBM Expertise Connect
    IBM Cloud and Cognitive Software
    ------------------------------