IBM Sterling Transformation Extender

Sterling Transformation Extender

Come for answers, stay for best practices. All we're missing is you.


#Sterling
#Supplychain
 View Only
  • 1.  Handling Binding after 7.5..

    Posted 03/17/10 08:25 AM

    Originally posted by: repanzer


    I am 99.99% sure, that the way you would handle binding would be;
    IF(Condition 1 that binds input, f_Map1(record:in1),

    else

    f_BindMap(In1))

    So, instead of doing condition 2 after the "else", because of the binding, you pull your entire input into another functional map with no look ups or anything to any fields, to avoid the binding.
    Then in the "Bindmap",
    If(condition 2 that binds input, f_Map2(record:in1), fBindMap2(In1)
    Then in the "bindmap", you run your second condition here, because if you did it fmap1, binding would be a problem.

    I just had tried this in 8.1, and it didn't work.

    I had this;
    IF(Condition 1 that binds input, f_Map1(record:in1),
    else
    f_BindMap(In1))
    It didn't "hit" condition 1, though it was in the data, and I am 99.99% sure that's how you're supposed to fix it.

    But as soon as I changed it to;

    IF(Condition 1 that binds input, f_Map1(record:in1),
    else
    f_BindMap(Something in my output))
    It worked. All I did was change the argument to f_Bindmap to something already built in my output, and not something in my input, and it ran.

    Anyone encounter binding in 8.1? Or anyone know if I am just recalling the way to handle this incorrectly?

    thanks!!
    #IBM-Websphere-Transformation-Extender
    #IBMSterlingTransformationExtender
    #DataExchange


  • 2.  Re: Handling Binding after 7.5..

    Posted 03/18/10 05:06 PM

    Originally posted by: repanzer


    I had opened a log with support on this, before i remembered how i used to handle it, which was to do make 2 copies of the same input object I'm querying, which support gets into;
    IF(Condition 1 that binds input, f_Map1(record:in1),

    else

    f_BindMap(In1,In1))

    FROM IBM SUPPORT;
    We have further reviewed the map design with the development team and determined the following information.

    We noticed that the same object that is used twice in the IF is also used in the functional map call, so it is "bound" twice.

    If we want the rule to run with no binding, we will have to add a fourth card to that map, so the functional map call will not bind with either if the EXTRACTs.

    The following is the modified map rule:

    = IF (PRESENT(EXTRACT(VERSION Field:GSAREC:In1, CHG_CAT_DTL_CD Field:GSAREC:In1="ADC")) |
    PRESENT(EXTRACT(VERSION Field:GSAREC:In3, CHG_CAT_DTL_CD Field:GSAREC:In3="RTN")) ,NONE,
    f_MapRecieverlx(RECV_ADDRESS:GSAREC:In4,GSAREC:In4))

    With this additional change, that line 47 output goes away. (There are still 16 (of the original 17) instances of "N1*CN*recieverdefault" in the data.)

    This is a data binding problem, but there is more than just data binding.

    I was mentioned that the rule returns NONE: when a rule returns NONE, we check whether we can run the rule again with different data, and, if so, we do so. Because of this, it looks like the rule is actually doing the EXTRACTs, while in fact, with data binding, the EXTRACTs behave like IFs.

    If the rule were simplified as...

    = IF (PRESENT (EXTRACT (VERSION Field:GSAREC:In1, CHG_CAT_DTL_CD Field:GSAREC:In1="ADC")), NONE, f_MapRecieverlx (some unrelated parms))

    ...then the EXTRACT would behave like an extract: it would find all the instances of GSAREC:In1 whose CHG_CAT_DTL_CD Fields were equal to "ADC", and return their VERSION Fields.

    If we change the parms to the functional map to what they are in the actual rule, the following is becomes the map rule:

    = IF (PRESENT (EXTRACT (VERSION Field:GSAREC:In1, CHG_CAT_DTL_CD Field:GSAREC:In1="ADC")), NONE, f_MapRecieverlx (RECV_ADDRESS:GSAREC:In1, GSAREC:In1))

    ...and GSAREC:In1 is bound, since it occurs twice in the rule. Now EXTRACT has to behave like an IF: it can only look at one instance of GSAREC:In1, since both references to GSAREC:In1 have to refer to the same instance.

    So it is as if the rule were:

    = IF (CHG_CAT_DTL_CD Field:GSAREC:In1 == "ADC", NONE, f_MapRecieverlx (RECV_ADDRESS:GSAREC:In1, GSAREC:In1))

    That rule does not contain a series-consuming function, so we look at the GSARECs one at a time. If the first GSAREC's CHG_CAT_DTL_CD Field is equal to "ADC", the rule returns NONE and we try again with the second instance of GSAREC, and we keep going until we find a GSAREC whose CHG_CAT_DTL_CD Field is not equal to "ADC", at which point we call the functional map. We will call the functional map unless all the CHG_CAT_DTL_CD Fields are equal to "ADC".

    Adding the second condition (the second EXTRACT) does not really change much, since the data is already bound; now if the CHG_CAT_DTL_CD Field is either "ADC" or "RTN" we will return NONE; otherwise we will eventually call the functional map, and we will call the functional map unless all the CHG_CAT_DTL_CD Fields are either "ADC" or "RTN".

    We do not fully understand what the rule is supposed to do, but it seems like the intention is to call the functional map if none of the instances of CHG_CAT_DTL_CD Fields are equal to "ADC" or "RTN".

    If that were what we were trying to do, the we could use the following map rule...

    = IF (OR (MEMBER (CHG_CAT_DTL_CD Field:GSAREC:In1, {"ADC", "RTN"}))), NONE, f_mapRecieverlx (RECV_ADDRESS:GSAREC:In3, GSAREC:In3))

    ...which says that if there are not any CHG_CAT_DTL_CD Fields that are equal to "ADC" or "RTN", call the functional map. Note that we still had to use an extra card, to prevent binding between the GSAREC in the OR function and the one in the functional map call.
    #DataExchange
    #IBMSterlingTransformationExtender
    #IBM-Websphere-Transformation-Extender