none
EDI Processes RRS feed

  • Question

  • Hi all,

    I am new to BizTalk and I am trying to understand how to properly build a multi-partner\multi-connections EDI process.

    So this is my scenario....

    1. Send\Receive EDI through a VAN connection.

    2. Send\Receive EDI via AS2 from certain Trading Partners.

    3. send\Receive EDI via FTP from certain Trading Partners.

    4. I might have up to twenty Trading Partners, if not more.

    I have built similar EDI processes using Emanio Trading Partner, Cleo Lexicom, and Mercator mapping tool. In Emanio Trading Partner I had Networks, which were the connection (AS2, FTP, etc) to the TPs direct networks or our VAN. Within the networks, I had the Trading Partners utilizing the network connection. When the EDI was received, the EDI was sorted to the proper mailboxes(850, 860, 852, etc) of the TPs and a 997 was being placed into the Mail Out Ready mailbox and sent back to the TPs. For sending 856s, 810s, etc. I would retrieve the data from our ERP system, map the data, place it into the proper TP mailbox, translate it to EDI, and send it. I did this for many years. Now that I am starting to implement a similar process in BizTalk, I really need to understand how to properly do it right from the beginning. With that said, I have been watching a lot of BizTalk training videos, reading articles, reading books, and building some testing processes. So I now have a basic understanding about the Parties, Parties Agreements, EDI configuration in the Agreement, Send Port, Receive Port, Receive Location, Pipelines, etc.

    I am hoping that I can get some input from the BizTalk Experts here as to how to build my EDI processes. In other words....

    1. How many BizTalk Applications do I build, one per Trading Partner? I really would like to keep my Schemas, maps, etc separate as much as possible.

    2. How would an Orchestration help me?

    3. How about pipelines, will I only need the EDISend, EDIReceive, AS2Send, AS2EDISend, etc. or will there be cases where I will need to create my own pipelines.

    How are the BizTalk EDI experts doing it in the real world? With Emanio Trading Partner, it would not take me long to get a Trading Partner up and running as I did it for many years. For my mapping I used the Mercator (Now IBM Websphere as far as I know) mapping, tree designer, and Database designer (connectivity). For automating my processes I used some C#\VB.NET applications and the Windows scheduler. 

    Hope the message is not too long, but I really need to understand how to properly build this process as it will be a very critical part of our systems.

    Thanks in advance.

    Sunday, April 6, 2014 6:14 PM

Answers

  • I'd refer you to the BizTalk EDI Tutorial @http://msdn.microsoft.com/en-us/library/aa560270.aspx which would guide you towards your end goal.

    Basically in BizTalk, EDI is implemented as a series of Assembler/Disassembler for the purpose of message parsing/validation. Then you use the concept of BizTalk Parties to enroll your partners and vendors. You create the process for handling the specific EDI messages and when sending/receiving make use of the BizTalk Orchestration Roles. The Orchestration Roles internally works in association with BizTalk Parties so you do not really have to keep modifying the process every time a new vendor needs to be brought in.

    The BizTalk Parties control the send ports (you will assign the send port to each party) which takes care of different transports associated with different vendors. In the orchestration when you create a RoleLink and assign a Send Port to it and during a message construction use the assign party statement as below

    EDIPartnerRoleLink(Microsoft.XLANGs.BaseTypes.DestinationParty) = new Microsoft.XLANGs.BaseTypes.Party(<Partner Identification Property Value",<Partner Property Name");

    it will result in BizTalk automatically selecting the pot associated with the party. As part of role links, a rolelink is created when you publish the orchestration to which you need to enlist the parties.

    The first time would be a bit of a stretch as you mentioned having 20 odd parties but after that, add/removing is a breeze and the most important thing being that the PROCESS continues to be ONLINE and DOES NOT NEED to be stopped, etc.

    Regards.

    Monday, April 7, 2014 5:07 AM
  • 1. BizTalk Application can be one of two things, the container in BizTalk Administrator or a Visual Studio Solution.  Either way, I prfer to keep them at a 1/1 relationship if practical.

    So, the decision becomes how do you partition the applications?  With EDI, I find that a particular app is either primarily Messaging or primarily Business Process.

    Messaging apps will exchange a set number of transaction types with any number of trading partners.  In this case, each TP doesn't really matter so much, it's getting the PO into you LOB app.

    Business Process apps are more focused on the integration with a particulary partner on a process, exchanging several transactions to suport that.

    The artifacts needed to support each would be in their own Solution and then Application.

    2. All we can say is when an Orchestration makes sense, use it.

    3. Maybe.  It will depend on you process and requirements.  Unfortunately, EDI has lots of nuances that can only be addressed in a custom Pipeline with Custom Pipeline Components.

    First do all the EDI tutorials.  Then start building the app(s).  At some point, you will see how things are grouping togeather and how they should be spearated.  Don't be afraid to re-organize when you see this.

    Do one thing from the beginning, use separate Schemas for each Solution.  You can change the namespace on each Schema so that it's a different MessageType from the others.  Meaining you can have to 850 Schemas deployed for two different Apps so long as their namespace is different.

    Monday, April 7, 2014 6:41 PM
    Moderator

All replies

  • I'd refer you to the BizTalk EDI Tutorial @http://msdn.microsoft.com/en-us/library/aa560270.aspx which would guide you towards your end goal.

    Basically in BizTalk, EDI is implemented as a series of Assembler/Disassembler for the purpose of message parsing/validation. Then you use the concept of BizTalk Parties to enroll your partners and vendors. You create the process for handling the specific EDI messages and when sending/receiving make use of the BizTalk Orchestration Roles. The Orchestration Roles internally works in association with BizTalk Parties so you do not really have to keep modifying the process every time a new vendor needs to be brought in.

    The BizTalk Parties control the send ports (you will assign the send port to each party) which takes care of different transports associated with different vendors. In the orchestration when you create a RoleLink and assign a Send Port to it and during a message construction use the assign party statement as below

    EDIPartnerRoleLink(Microsoft.XLANGs.BaseTypes.DestinationParty) = new Microsoft.XLANGs.BaseTypes.Party(<Partner Identification Property Value",<Partner Property Name");

    it will result in BizTalk automatically selecting the pot associated with the party. As part of role links, a rolelink is created when you publish the orchestration to which you need to enlist the parties.

    The first time would be a bit of a stretch as you mentioned having 20 odd parties but after that, add/removing is a breeze and the most important thing being that the PROCESS continues to be ONLINE and DOES NOT NEED to be stopped, etc.

    Regards.

    Monday, April 7, 2014 5:07 AM
  • Thank you for your reply Shankycheil.

    So, how about the number of BizTalk applications? I believe there is a size limit or something, correct? So, since I could potentially have many different schemas, that could be a problem. The training videos I have watched, only go through one EDI trading partner process. There is no mention as to how to handle multiple trading partners.

    Thanks. 

    Monday, April 7, 2014 6:07 PM
  • 1. BizTalk Application can be one of two things, the container in BizTalk Administrator or a Visual Studio Solution.  Either way, I prfer to keep them at a 1/1 relationship if practical.

    So, the decision becomes how do you partition the applications?  With EDI, I find that a particular app is either primarily Messaging or primarily Business Process.

    Messaging apps will exchange a set number of transaction types with any number of trading partners.  In this case, each TP doesn't really matter so much, it's getting the PO into you LOB app.

    Business Process apps are more focused on the integration with a particulary partner on a process, exchanging several transactions to suport that.

    The artifacts needed to support each would be in their own Solution and then Application.

    2. All we can say is when an Orchestration makes sense, use it.

    3. Maybe.  It will depend on you process and requirements.  Unfortunately, EDI has lots of nuances that can only be addressed in a custom Pipeline with Custom Pipeline Components.

    First do all the EDI tutorials.  Then start building the app(s).  At some point, you will see how things are grouping togeather and how they should be spearated.  Don't be afraid to re-organize when you see this.

    Do one thing from the beginning, use separate Schemas for each Solution.  You can change the namespace on each Schema so that it's a different MessageType from the others.  Meaining you can have to 850 Schemas deployed for two different Apps so long as their namespace is different.

    Monday, April 7, 2014 6:41 PM
    Moderator
  • Refer to http://msdn.microsoft.com/en-us/library/bb226541.aspx which is EDI Interface Developer Tutorial


    Monday, April 7, 2014 6:54 PM
  • There is a restriction on the number of applications but NOT on the number of orchestration under A application. If you're using standard version then one of the options would be to club all your EDI related processes under one Application (they may continue to be under their own VS Project) and you could share a common set of schemas and pipelines across these projects.

    If in one of the processes you need to handle multiple schemas then you could always use the XmlDocument type to accept multiple messages into the same process type and using the EDI properties such as message type, etc. process them through one orchestration. If for each message there is a distinct action to be performed then I would not recommend the above approach because you'll have to tear down that orchestration for every change and impact all the associated processes.

    Regards.

    Tuesday, April 8, 2014 4:28 AM
  • Thank you all for your replies.

    However, I really want more concrete answers as to what you guys are doing. In other words...

    1. How many BizTalk Applications do you currently have, one, two, etc.? How about naming conventions, TPEDIReceive, TPEDISend, TradingPartnerNameEDI, etc.? I know this could be irrelevant, but I would like to know.

    2. How are you guys handling the incoming EDI for multiple Trading Partners?

    3. How are you using the orchestrations, if you are using them?

    4. How are you sending the EDI for multiple trading partners? How about batching?

    5. How are you handling multiple connections? 

    6. How about pipelines?

    7. Receive and send ports? This I understand, though.

    8. Receive Locations? The same for this. What I had for my EDI process was trading partner folders, TestTP1, TestTP2, etc. Inside the folders I had Incoming and Outgoing, then 850s, 860s, 997s, etc. according to the type of message.

    So, if you ask me... I can describe the whole EDI process (with details) incoming and outgoing of using the applications I mentioned in my original message. That is what I am hoping that you guys can explain. Well, not every single detail, but something that will tell me exactly how you guys are doing it.

    What I have done so far in BizTalk is build sample applications where I can drop a file in a directory, simulate sending it to our ordering system(a test folder), and generating the 997. My next step will be to place it in our DB, process it and generate an 810 and an 856. So far, I have used only receive ports, send ports, and receive locations. No orchestrations or customized pipelines. That is why I am trying to understand how the real BizTalk experts are doing the EDI.

    Really appreciate your help.

    Thanks in advance.

     

    Tuesday, April 8, 2014 5:52 PM
  • So, here's the thing, the answers to these question would be radically different for every EDI implementation I've done becasue each customer is in a different situation.

    All anyone can really say is, sure, maybe, maybe not, if it works :).

    My advice would be to not worry about it so much right now.  Keep developing the solution and you will eventually see how all the pieces are fitting togeather and where some natural boundries are.  Then, you can organize the artifacts around what you know, not what you or anyone else speculates.

    If you have any specific questions or would like advice on a particular scenario that isn't supported out of the box, we're always here to help.

    Tuesday, April 8, 2014 6:13 PM
    Moderator
  • Thank you guys again for your replies.

    I guess I will have to just do it as described in the books and videos. I was hoping to get real world examples.

     
    Friday, April 11, 2014 7:07 PM