none
EDI Data Sort RRS feed

  • Question

  • Hi all,

    When getting the EDI data from our VAN through a webservice, we might be getting it from different TPs within the same request (file). Is it possible to sort the incoming data before it's put in the MessageBox? The reason I am asking is because a previous developer created a costume pipeline that modifies the incoming EDI raw data, by adding a segment to the P01 loop. Thing is, if we modify the incoming data without first sorting it, the costume pipeline adds the segment to every P01 instance of the entire file. Perhaps this is not the best way this should have been handled.

    Thanks in advance.

    Tuesday, August 19, 2014 3:49 PM

All replies

  • What do you mean by 'sort'?

    You are probably correct in that modifying the EDI was not the best option.  Exactly why is that done?  Perhaps we can advise you on how to overcome that.

    Tuesday, August 19, 2014 5:48 PM
  • Hi Boatseller,

    Th reason the developer did it was because the Trading Partner is not sending a data element qualifier "VP" and data within the P01 segment. They are sending the info through the PID segment. So, I guess the the EDIReceive pipeline must have been complaining about the missing data or something. So, since we will be receiving data from different TPs within the same file, now I need to figure out how to overcome this. That is why I was asking if there was a way to sort\divide the data by ISA control number or something before it goes into the MessageBox and place it into individual folders for example. This way I can continue using the current application and build another application(s) to process the other TPs.

    Hope this is clear.

    Thanks.

    Tuesday, August 19, 2014 6:31 PM
  • It seems clear.

    It this scenario, the better approach would have been to either modify the main schema to accommodate all Trading Partners or deploy two schemas, one specialized for this Trading Partner and one unmodified schema for everyone else.  This is opposed to modifying the EDI itself.

    You can specify which Schema to use in the Agreement.

    If you have to maintain the existing workaround, then you have to develop a workaround for that workaround.  You can write a custom Disassembler Pipeline Component that splits the incoming stream at the Interchange and sniffs out the Sender Id and Promotes it.  This component would not parse the EDI, just split the text stream at the Interchange level (ISA/IEA). Then you can route each separate Interchange based on the Sender ID.

    • Proposed as answer by Angie Xu Monday, August 25, 2014 1:37 AM
    Tuesday, August 19, 2014 7:10 PM
  • Boatseller,

    "It this scenario, the better approach would have been to either modify the main schema to accommodate all Trading Partners or deploy two schemas, one specialized for this Trading Partner and one unmodified schema for everyone else.  This is opposed to modifying the EDI itself." I did something similar sometime ago using the Mercator mapping tool. I think I simply mapped the incoming data using a similar or the same EDI schema for input and output. On the output, I simply added the additional data. Then within the map that was supposed to process the incoming data, I simply pointed it to the modified data location. I was thinking of something like that with BizTalk. Thing is that BizTalk converts it to XML through the EDIReceive pipeline. So, now on the map to process the data, instead of using the EDI 850 schema, I might need to create a new schema. Wait..... can I use the EDI 850 schema after it was converted to XML? Maybe I can. That's something to try.

    Wednesday, August 20, 2014 2:27 PM
  • The thing is, it's hard to give advice without knowing exactly what that Pipeline Component and exactly what 'problem' it was trying to solve.

    Start from the beginning.  Are you absolutely sure you can't use the standard 850 Schema for this Trading Partner.  If not, please share the exact issue/error you getting.

    Maybe it's just a Mapping issue which should be fairly easy to solve.

    Wednesday, August 20, 2014 2:44 PM