Conference rocks::dec_edi

3139.0. "Lookup bug in V3.1" by NNTPD::"[email protected]" (Nicolas) Tue May 27 1997 09:06

Hi

above the input from a problem that a custome had, and that looks like a bug:

Application Files come in DEC/EDI, and may contain messages for various
partners. First we do the oubound mapping from INHOUSE to UN/EDIFACT. 
There, based on the information in the control record of the application file,

the system finds out to whom the messages are destined.
($PARTNER=$LOOKUP(partner_out, field_from_control_record)) 
So, it creates a transmission that contains many envelopes, one for each 
partner. We export this transmission file and bring it immediately back in
with
import. Now, we have many envelopes in the file and the system realizes that 
the data is destined to many partners. So it finds the appropriate application

names and partner names and prepares the documents separately for all the 
partners.

Fine, this all works great, IF the lookup tables for the partner informations 
are defined correctly. What happened with UNIFER (Sender Application )was, 
that one partner was not defined in a lookup table, which is used in the 
outbound mapping from inhouse to edifact. 
This was still in the test phase and the lookup entry had been forgotten. 
The inhouse file had messages for two different partners, and for 
one partner(x) there existed a lookup entry. The first messages in the inhouse

file where for partner x, that did have the entry. After that there followed 
the messages for the partner y, which did not have this lookup entry. 
Instead of stopping the mapping and producing an error when it came to the 
documents for partner y, the mapper used the �old" value of the lookup and 
defined the partner to be the same for all the messages in that file. 
Instead of producing a transmission file with two envelopes, it created a 
transmission with one envelope, destined to partner x. 
In the second conversion of course, it looked like the messages were all going

to one partner, and so they got all sent to partner x.

Had the situation been such that the messages for partner y were the first
ones,
then $PARTNER would have had no value, and the trade post would have failed. 
Now that it first found the value partner x, then it just continued using that

value. Is this a feature of decedi mapper? To us it seems to be a bit
dangerous
one, as the messages end up going to the wrong partners.

Mr. Klein told me that this is not just a problem with the values of $PARTNER,

but that it is a general lookup feature, that there is no error produced if no

entry is found. If the lookup has not been used �ealier" in the same mapping 
round, then the mapper puts a blank in for the value it did not find, and if 
the lookup has been used before, then it puts the value that happened to be 
the last value searched from the same lookup. 

Hope you understand these "easy" description, if you nee more imput contact
me.

P.S. It's the same customer that still wait for the correction of the X.400 
     problem !!!

Nicolas

[Posted by WWW Notes gateway]