Topic
  • 1 reply
  • Latest Post - ‏2013-05-12T20:57:19Z by bernard H
6BFT_Brendon_Flanagan
2 Posts

Pinned topic Datapower & WTX Map & Multiple Input & Output Cards

‏2013-04-15T23:39:01Z |

 

When data is received back into a processing rule, and where you have a DPA file that contains a map that has two input cards and two input cards, can you explicity say what input and output cards to use.
 
Scenario is where my map on the input side is fixed format, ie fixed length when a good response and another fixed length when a bad response.  So I want to say to start off with which input card to use and conversely what output card to use.
 
Or, can you only ever have one input card and one output card in a map, unless you form all data required by all cards in variables first, ie the second input card is in a variable, but the first input card was your server response.

 

  • bernard H
    bernard H
    5 Posts

    Re: Datapower & WTX Map & Multiple Input & Output Cards

    ‏2013-05-12T20:57:19Z  

    if I understand well the question....

    You won't be able to RUN a compiled TX map unless all inputs are supplied by the caller (DataPower flow or Message Broker Flow) or available directly to TX (e.g. a local file read, or database query, or queue get, etc.). The map will simply not start and exhibit the error 'source not available' if you pass just one of the two inputs.

    So the solution is either:

    A) merge both inputs to one: build a single type tree / single input that combine both candidate structures

    B) keep two inputs, but populate the unused input with a fake value or explicit "empty" value (as can be specified for an item in a type tree). Yet, given the complexity in passing multiple inputs to a WTX node (requires a collector node), the previous solution is definitely better.

    C) variant of A: refactor the two-input global map in 2 single-input / single-output functional maps, that are in turn called by a new "control map" itself taking the variant inputs as opaque payloads wrapped under a suitable header/marker so that the control map can choose the functional map to invoke. The opaque payload is thus only parsed by the functional map when invoked, itself producing variant outputs that can also be returned by the control map as opaque payloads back to the invoker.

    My recommendation is solution C.