none
EDI: Party Resolution and configuration RRS feed

  • Question

  • Greetings,

    I have a question, possibly a somewhat dumb one (Maybe this is just from my lack of knowledge of EDI), but here it is.

    When doing party resolution on the receive location (i.e.: identify the sender of the document), the helps states that it
    1) looks at ISA 5-6 and ISA 7-8.
    2) if 1 fails, it looks at ISA 5-6 only
    3) if 2 fails, it looks at the global properties.

    Using ISA 5-6 make sense to me, as they are the sender qualifier and sender identifier.  If I want to identify the sender, that's what I would use.

    However, why are ISA 7-8 used in identifying the sender?  This makes no sense to me as they are the receiver qualifier and receiver identifier.  I can see these being used to identify the party when it is the receiving trade partner but have no clue why they have anything to do with identifying the sender. 
     
    I know I can leave ISA 7-8 set to null and it will skip step 1 and use step 2 for identifying the sender, but I want to understand the reasoning for using ISA 7-8 in identifying the sender.

    I suspect I am overlooking something simple that will just make things fall into place, but I can't find that simple thing.

    Thanks in advance.

    Craig B.

    Wednesday, April 11, 2007 4:44 PM

Answers

  • Craig, ISA7-8 are used when you have multiple home organizations. A large Enterprise can have several subsidiaries with different ISA7-8 values and require different processing logic. However all the documents to that Enterprise might be sent to a central location. Hence to support this scenario, agreement resolution is done based on not only ISA5-6 but also ISA7-8. Hope this clarifies your question.

     

    -Samit

    Wednesday, April 11, 2007 6:02 PM

All replies

  • Craig, ISA7-8 are used when you have multiple home organizations. A large Enterprise can have several subsidiaries with different ISA7-8 values and require different processing logic. However all the documents to that Enterprise might be sent to a central location. Hence to support this scenario, agreement resolution is done based on not only ISA5-6 but also ISA7-8. Hope this clarifies your question.

     

    -Samit

    Wednesday, April 11, 2007 6:02 PM
  • Greetings,

    Thanks for your response.  Basically from the send perspective, you only care about the ISA 7 and 8 for large organizations then.

    I have been spending some time looking at the X12 properties as an Interchange Receiver now, and am somewhat confused there. 

    Ok, lets work with a simple example.
    Lets say we have 4 trading partners
    - Georges Grocery
    - Sammy's Store
    - Luigi's Lemon Farm
    - Olga's Orange Farm

    Initially, I am going to set up George and Luigi to exchange POs (edi 850s) and POacks (edi 855s).  George uses standard 4010, Luigi uses 5010, I am going to use BizTalk to convert between the two standards and send them on.

    So I configure two parties (GeorgesGrocery and LuigisLemons) to exchange an 850 from George to Luigi and an 855 from Luigi to George.

    Party: GeorgesGrocery
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: not set
        ISA 8: not set.

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: LuigisLemons
        ISA 7: ZZ - Mutually Defined
        ISA 8: GeorgesGrocery
        
    Party: LuigisLemons
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: LuigisLemons
        ISA 7: not set
        ISA 8: not set.

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: ZZ - Mutually Defined
        ISA 8: LuigisLemons

    Ingoring Sammy and Olga for the moment, would this be right?  From what I read in the documentation, the X12 as an interchange receiver properties are used for creating the ISA and GS segments when creating output EDI files going to the specified party.

    Assuming the above is right, the question that I am stumbling with is, what happens when George also starts sending POs (850s) to OlgasOranges (who returns 855s)?  I trust I would create a new party for Olga as follows:

    Party: OlgasOranges
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: OlgasOranges
        ISA 7: not set
        ISA 8: not set.

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: ZZ - Mutually Defined
        ISA 8: OlgasOranges
        
    Fine, but now the configuration for GeorgesGrocery (as an interchange RECEIVER) makes no sense to me now as ISA 6 is defined as coming from LuigisLemons.  What about Olga sending stuff back to George?  If these properties are used to create the ISA and ST records in the output EDI file, George would get an EDI interchange saying that LuigisLemons is the sender of the document (wrong) and GeorgesGrocery is the receiver (correct).

    Do I introduce a middle party (representing me, the converter) who would be the destination of things coming from either trade partner and the source of things going to those trade partners?

    Do I have to create a new Party for GeorgesGrocerys and configure the as an interchange RECEIVER specifically to handle the data exchange between George and Olga as well?  What about when Sammy starts sending things to Luigi and Olga as well?  I don't have to create new parties for all these combinations, do I?

    Thanks in advance..

    Craig B.
    Thursday, April 12, 2007 10:03 PM
  • Craig-

     What you are doing is essentially implementing a hub scenario where your BTS deployment is essentially a middleman and you want to set the original sending parties identification credentials as ISA5,6 in the outgoing message. Hence your intuition is correct - you would need to create a Party(essentially the party profile acts like an Agreement in your scenario) for each such Partner1-Partner2 interaction.

     

    e.g.

     

    Party: GeorgesGroceryWithLuigislemons
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: ZZ - Mutually Defined
        ISA 8: LuigisLemons

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: LuigisLemons
        ISA 7: ZZ - Mutually Defined
        ISA 8: GeorgesGrocery
        

    Party: LuigislemonsWithGeorgesGrocery
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: LuigisLemons
        ISA 7: ZZ - Mutually Defined
        ISA 8: GeorgesGrocery

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: ZZ - Mutually Defined
        ISA 8: LuigisLemons

     

        
    Note that at the Send Port there are three ways to resolve the Party -

    1. Resolve the party by matching the context property DestinationPartyName with the name of a party. This property can be set in a custom component; it is not set by BizTalk Server.

    2. If step 1 does not succeed, resolve the party by matching the sender qualifier and identifies, and receiver qualifier and identifier, in the context of a message with those in party properties. These properties can be set in a custom component; they are not set by BizTalk Server.

    3. If step 2 does not succeed, resolve the party by matching the send port that subscribed to the message with the send port associated with a party.

     

    If the same send port is associated with multiple parties, BizTalk Server will generate an error.

    If no party is found in steps 1, 2, or 3, the send pipeline uses the global party properties (its default pipeline properties) to generate the outgoing message.

    Hope this helps.

     

    -Samit

    Friday, April 13, 2007 12:09 AM
  • Greetings,

     

    Looking at the details about Party Lookup and Schema Determination (Send Side).  As mentioned in the previous message the EDI send pipeline will attempt to resolve the party using the DestinationPartyName, followed by 4 EDI properties if the first fails, followed by the send port followed by global properties.  The lookup results are used for construction of the ISA and GS segments of the output EDI file to be sent to the partner.

     

    So I put together a simple orchestration which takes a message in, constructs a new one (which assigns a value to DestinationPartyName and promotes it via a correlation set) to the message and sends it out. 

     

    What if I have my send ports tied to my parties?  (ie: Luigi wants EDI, Olga wants XML).  Should my orchestration set the DestinationParty property and push it through the role link for it to find the party to get the send port, and then, if that send method uses the EDI pipeline, it will then use the DestinationPartyName to get the EDI properties for the party, generate the EDI and write it out?

     

    For example:

    Party: LuigisLemonsWithGeorgesGrocery
       Send Port "SendToLuigisLemons", uses EDI pipeline.

     

    Party: OlgasOrangesWithGeorgesGrocery
       Send Port "SendToOlgasOranges" uses XML pipeline

     

    Process:  
    1) BTS Receives PO from GeorgesGrocery to LuigisLemons
    2) Message gets disassembled and routed to an orchestration
    3) Orchestration assigns values to the following properties in a new message via some magic it determines the destination party is LuigisLemonsWithGeorgesGrocery.
     - EDI.DestinationPartyName = LuigisLemonsWithGeorgesGrocery
     (alternatively, and probably much easier to set EDI.DestinationPartySenderIdentifier, EDI.DestinationPartySenderQualifier, EDI.DestinationPartyReceiverIdentifier, and EDI.DestinationPartyReceiverQualifier, from the original message properties EDI.ISA05 -> EDISA08)
     - BTS.DestinationParty = LuigislemonsWithGeorgesGrocery
    4) Pass this to a role link.  BTS picks out to use the LuigisLemonsWithGeorgesGrocery Party (based on DestinationParty) and then gets the send port for that party.
    5) The EDI pipeline on the send port from 4) looks at the DestinationPartyName (or whatever) and uses that to do party resolution to get the EDI properties.
    6) EDI properties retreived, EDI generated and written.


    Does this sound right, or am I way out to lunch on this?

    Thursday, April 19, 2007 9:23 PM
  • Hi ,

     

    I am also very new with EDI but have a 2002 solution with well over 1000 trading partners and (n) combinations of trading transactions between them that we are upgrading to 06.  Many are EDI to XML or flat or vice versa.  Having to create a separate party for each transaction possibility seems like a manintenance/configuration nightmare.

     Would it be possible to just have a central "Hub" organization, ie, your company, that acts as the intermediate.  You'd need a preprocessor to overwrite a section of the ISA to do this.

    For instance:

     

    Party: GeorgesGrocery
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: GeorgesGrocery
        ISA 7: ZZ - Mutually Defined
        ISA 8: MyCompany

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: MyCompany

      ISA 7: ZZ - Mutually Defined
        ISA 8: GeorgesGrocery

    Party: Luigislemons
    EDI settings
    - X12 - as an interchange SENDER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: LuigisLemons
        ISA 7: ZZ - Mutually Defined
        ISA 8: MyCompany

    - X12 - as an interchange RECEIVER
        ISA 1-4 default settings
        ISA 5: ZZ - Mutually Defined
        ISA 6: MyCompany

      ISA 7: ZZ - Mutually Defined
        ISA 8: LuigisLemons

     

    You could feasibly map all inbound EDI to a common canonical XML format, based on incoming file type (850, 855 etc) and publish it to the messagebox.  Code in an orchestration that handles any business logic with filters for "MyCompany" and the fileType may be able to handle re-setting the true recipient based context or content in the document.  Then the message would go back to the mesagebox and be picked up by the appropriate send port for the originally intended recipient.  We did something very similiar in 2002 and it seemed to work OK.  I'm hoping to be able to employ something similiar in 06 but am fairly inexperienced with the EDI stuff still.

    Thanks,

    Chris

     


    Thursday, April 19, 2007 10:47 PM
  • Greetings,

     

    My initial thought was to introduce an intermediary as you have described in your post.  However, the question then is: what in the source document tells you who the destination for this document is (other than the intermediary)?  I get the impression thats what the IS 6 and 8 are for.  ie: Who it's from, and who it's going to.   So I don't think introducing the intermediary will work.  (unless there is something else in the source document to give us routing information.  Or we use the Rules engine to perform some black magic to derive the true receiver)

     

    thoughts, comments anyone?

     

    cmb..

    Friday, April 20, 2007 4:25 PM
  • Hi Craig,

     

    That is correct we use other information from the document to determine the true destination or we pull the original inbound receiver data which we snapshot to the database upon receipt of the document. 

     

    The steps in the current implementation are:

    1. Receive document and snapshot original document (imagine we still get this for free in BT)

    2. We use a custom tracking table to save the guid related to the saved original so we can cross reference it later in processing.(this may be different in 06)

    3. Overwrite the routing info, that is the recipient, such that the ISA 8 tag is changed to us as the reciever. (I'm hoping we can still do this somehow before the EDI Recieve pipeline component fires)

    4. Custom Debatching and validation. (may not need to do custom do this anymore)

    5.Mapping ot the canonical schema based on doc type (850 = PO Schema) and published to the messagebox.

    6.Subscription filters for Orchestration pickup the message, other rules processing and logic to determine who the true recipient is by checking key fields in the canonical message and if that fails looking up the original snapshot EDI to obtian the original receiver code from there.

    7.Once we have the original receiver code, we overwrite routing in our canonical XML message in the orchestration such that we are now the sender and the original reciepient is the correctly added as the recipient.

    8.The message is published to the messagebox, mapping occurs when any subscribers for that receiver, messageType and other fields match and pick it up for send.

     

    There is allot of other processing going on but in a nutshell, this is how our routing works in the 2002 solution.  It has been beneficially in that a given partner can work with (n) partners and we only need one map per doc type to our canonical schema for that partner rather than n maps for every combination.  Same goes with parties, we only need the agreements of the sending parties to us and us to the receipient parties. 

     

    I doubt we will use the sendports directly on the parties as I think we want to go with direct bound sendports instead.  Again, very new to this and am not sure what will work and what won't yet.

     

     

    Friday, April 20, 2007 6:00 PM
  • Craig, Your solution looks logical. However I am not sure how will you figure out the DestinationName part. I will open a reuest for our team to make the API (resolve outbound party based on the four qualifiers) public but that will not happen during the R2 RTM timeframe.

     

    -Samit

    Friday, April 20, 2007 7:00 PM
  • Hi Samit,

     

    Thanks for your response.

     

    I have to agree with you on determining the DestinationName.  The only thing I can think of is using the Rules Engine with the values in ISA 6 and 8.  (ie: IF (ISA06 = GeorgesGrocery) AND (ISA08 = LuigisLemons) THEN DestinationParty = "LuigisLemonsWithGeorgesGrocery". 

     

    I was giving some more thought to this earlier and for determining the destination party.  I think it might just be easier to set up a send port, assoicate the send port with a party, use filters on the send port to look at ISA 8 for matches.  The EDI Send Pipeline will resolve the party based on the rules for party look up (Step 3 which states: If step 2 does not succeed, resolve the party by matching the send port that subscribed to the message with the send port associated with a party -- Unless I misunderstand that), and the outbound file will be generated based on the resolved party.

     

    cmb..

     

    Friday, April 20, 2007 7:42 PM
  • Hi Craig,

     

    In my design I was wondering about that as well.  If I have a send port out there that has subscriptions for a given partner and document type and it needs to go out as EDI can't I just use the regular pub/sub model and direct ports?  That is, my orchestration will figure out the destination partner and add it in the XML of the message, I am dealing with a canonical XML message in my orchestration, then publish it to the message box.  Any send port with a subscription should pick it up, if the send port has also been associated with a party for EDI, shouldn't it be able to find the correct schema for the matching published message based on party properties and allow for my outgoing send port map to map the canonical XML to EDI using desired properties at the party level.

     Apologies if this makes little sense, I'm trying to understand it as well.

    Thanks,

    Chris

    Friday, April 20, 2007 7:59 PM
  • Option 2 sounds much better as it will be easier to maintain send port filters then maintain rules. Hopefully you do not have a large number of parties(and hence Send port proliferation problem). You can request for a QFE of a public API to determine outbound DestinationParty based on the quadraplet.

     

    -S

    Friday, April 20, 2007 8:23 PM
  • Greetings,

     

    So, if I understand this correctly, You get in your message, convert it to your internal XML format.  Through the powers of voodoo in your orchestration, you come up with the true receiver of the message and publish it to the message box.

     

    Now, lets say your orchestration set the receiver to LarrysLimes and publishes the message to the messagebox (Direct Orchestration Port).

     

    LarrysLimes is expecting an EDI message.

     

    From my understanding, it would resolve is as follows (Samit should be able to confirm this):

    1) If you set up your send port with the correct filters (pick up all messages going to LarrysLimes of type PO).  The send port should get the message. 

    2) BizTalk would apply the map tied to the send port to convert the internal XML format to the EDI schema you want to send out to LarrysLimes. 

    3) The converted EDI document (still in XML form) gets passed to the EDI Pipeline for assembly. 

    4) The EDI pipeline will go through the steps outlined in Party Lookup in the documentation to determine which party to use to get the ISA, GS and ST segment values for the outbound document.

    1. Look at the DestinationPartyName
    2. If that fails, look at the 4 properties(can't remember them off the top of my head, they are in the docs)
    3. If that fails, use the party the send port is associated with
    4. Failing that, revert to global properties

    Once the party is found the EDI Send Pipeline builds the ISA, GS and ST segments (based on the configuration of the EDI properties on the party).

    It then writes the file to the appropriate adapter for transmission.

     

    The important thing to note is that the send port can't be used by more than one party, if it is, the EDI send pipeline would have no way to resolve the party.

     

    If the same send port is used by more than one party, then the party must be resolved by one of the first two steps.

     

    Does this help?

     

    Thoughts, comments, complaints, let me know.

     

     

    Friday, April 20, 2007 8:38 PM
  • Thanks Craig, Yes!

    That explains exactly what I am attempting to do.  Just was confused as to how to adequately describe the steps..

     

    The voodoo part in the orchestration will be a service that looks at various sections of content in the canonical XML to determine the true recipient, the inbound map may help with values for this, and the original, pre-overwritten EDI document may also be used if the receipient cannot be determined via the content.  Again the orchestration doesn't know or care whether the original message was flat/XML or EDI.

    This sounds ambiguous but it actaully works pretty well in our existing 02 system.

     

    Also, each sendport will have subscription for only one party/doctype.  Namely for configuration granularity at a partner level as we have > 500 partners

    ie. myPropSchema.destPartner="partnerA" and myPropSchema.docType = "po"

     

    The one area I'm still trying ot conceptualize is when an EDI document is recieved where I will store the original, non-modified inbound EDI and overwrite the reciever ISA piece.  I'm thinking a custom pipeline component ahead of the EDI Disassembler but I'll have to work with the document as a stream that is not XML and this could have some performance implications if I load the whole thing before parsing it.

     

    Thanks again for the feedback and clarifications.

    chris


     

    Friday, April 20, 2007 9:03 PM
  • Hey Samit,

     

    This place really needs to display threads as a heirarchy as opposed to one long list of posts. :-)

     

    Initially, for us anyways, there are only two partners, later it will grow way beyond two partners.  So we may end up with the send port proliferation problem at that point.  But this would be encountered anyways as each receiver may want the output in a different format and the pipeline on the send port controls that (well, the pipeline and the map). 

     

    I guess we could have a set of Dynamic ports (one for EDI, one for XML, one for FlatFile, etc) and then assign the appropriate dynamic port to the various parties.  At which point we would have to rely on party resolution though role links (I think, I haven't used role links before, so I am speculating about the role link thing).  Once the party is determined, and they use the dynamic EDI send port associated with the party, the EDI send pipeline on the send port would use the DestinationPartyName or the quadraplet for getting the EDI properties.

     

    Initially, I think I will just use the filters on the send port, and let the EDI pipeline resolve the party based on which party the send port belongs to.

     

    Any other thoughts, comments?

     

    cmb..

    Friday, April 20, 2007 9:19 PM
  • Excuse my ignorance but what is a send port proliferation problem?  Is this a physical limitation reagrding the number of supported send port sin BT 06?
    Friday, April 20, 2007 9:45 PM
  • Greetings,

     

    I believe the term means getting bogged down in send port management due to the sheer number of send ports..  Correct me if I am wrong.

     

     

    Friday, April 20, 2007 10:47 PM