Automated Deployment of EDI Properties; also useful for bulk import of Party Properties


Typical use of Deployment functions is to move settings across machines, development to staging and finally to production.


However another huge use of this feature is the ability to import Party/EDI settings from LOB and other such applications using the ‘import’ binding file. To enable this – user will need to create ‘a’ compliant XML and import it.


Just imagine how complicated initial setup would be without this functionality – 100s or 1000s of Party/EDI settings would be required to be manually created! Wonderful!!


 


 


Deployment of EDI Properties


BizTalk server 2006 R2 EDI subsystem can be configured through EDI Global properties and Party EDI properties. Deployment of these EDI properties is integrated with BizTalk Application Deployment and is available through Administration console and BTSTask command line tool.


 


 


Exporting EDI Properties:


While exporting bindings of BizTalk artifacts in an application, group or assembly (using Administration console or BTSTask); EDI Properties of all the bounded parties are exported automatically along with other party information.


While exporting bindings from an application or assembly, deployment tools provide an option of “Global Parties”. If this “Global Parties” option is selected:


 


·         EDI Properties of all the parties in the group is exported along with other Party properties.


·         Global EDI Properties are exported.


 


Activation of this feature is enabled in a few ways: while using Export Binding dialog – “Global Parties” the option is enabled as CheckBox control ‘Export Global Party Information; while using Export MSI dialog the option is enabled as Global Parties checkbox; and while using BTSTask command line tool the option is available as GlobalParties switch (BTSTask ExportBindings -Destination:value ((([-ApplicationName:value] | [-AssemblyName:value]) [-GlobalParties]) | [-GroupLevel]))


 


Importing EDI Properties:


EDI Properties are imported to the system while importing Binding XML file or MSI package using Administration console or BTSTask command line tool. While importing EDI Properties, bear in mind the following important points:



  • Existing EDI Properties will be overwritten. EDI Properties (or any bindings) for parties of the same name that already exist in the application are overwritten. If Binding File contains EDI Global Properties, existing EDI Global Properties will be overwritten.

  • You must reconfigure passwords. For security reasons, when you export a binding file, BizTalk Server removes the passwords for the bindings from the file (e.g. UNB6.1 and UNB6.2 fields are removed for EDIFACT Properties, and ISA1, ISA2, ISA3 and ISA4 fields are removed from X12 Properties). After importing the bindings, you must reconfigure these sensitive fields before processing EDI messages.

 


Porting EDI properties from LOB systems


If you have a Partner Management system having EDI properties for many partners, you may prefer to create the binding XML file and use the Import wizards or BTSTask command line tool.


 


Attached is a sample binding XML file, BindingInfo.Xml, containing Party EDI Properties and Global EDI Properties. We may publish a schema of binding file in a future Beta release; however a schema may be generated using the attached XML file.


 


(Content provided by Manoj – thanks Manoj!)


 


Namaste!


 


Suren


 

BindingInfo.xml


Comments (10)

  1. ericstott says:

    If I create a binding file to move parties from our test to our production box, is there a way to also migrate the control numbers?

  2. EdiBlog says:

    Control numbers cannot be moved from one environment to other through binding file. One unsupported way to configure control numbers programatically would be to populate the BizTalkMsgbox.EdiSequencenumbers table directly.

  3. ericstott says:

    I tried to copy the values from our current production box to the new production box, but I was getting constraint violations.

    This is very important, as I have 300 trading partners to update, and doing it manually thru the admin console is impossible.

  4. EdiBlog says:

    I would suggest using MSDN Forum for such questions.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/

    If the control number data in the current production box is passing all the constraints, how come the same data is failing in the new production box? The constraints are the same. Can you share the SQL Query you are using to move the data.

    Again, Please use MSDN form for quick answers.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/

  5. EdiBlog says:

    I would suggest using MSDN Forum for such questions.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/

    If the control number data in the current production box is passing all the constraints, how come the same data is failing in the new production box? The constraints are the same. Can you share the SQL Query you are using to move the data.

    Again, Please use MSDN forum for quick answers.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/

  6. ericstott says:

    I don’t have to do any migration from the EdiPartnerIncomingX12ICN table?

  7. EdiBlog says:

    EdiPartnerIncomingX12ICN tables stores the interchange control numbers of the incoming interchanges for duplicate detection. If that’s not your concern, you don’t have to migrate EdiPartnerIncomingX12ICN table.

    Please use MSDN Forum, I assure you that people on that forum are very nice and responsive.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/

  8. ericstott says:

    I have migrated the data from both the BizTalkMsgbox.EdiSequencenumbers and the BizTalkMsgbox. EdiPartnerIncomingX12ICN  but when I look in the party definition, I see 1 as the default value for trading partner 121, whereas on the original box it is 20034.

  9. EdiBlog says:

    The Party IDs in the current production environment might be different than in the new production environment. The EdiSequencenumbers table has PartyId as a key column. matching the party Id should solve the issue.

    I would like to reemphasize that this is not a supported way. There is no supported way for migrating EDI control numbers right now.

  10. EdiBlog says:

    Export/Import does migrate control numbers from one environment to other. It’s just the security information (ISA1-4 in X12) that we don’t export, but rest everything else is migratable. Sorry, I was confusing with some other functionality where we don’t copy the control numbers.

    If you export the BizTalk application (with global parties checkbox checked), all the Edi properties, including control numbers, are exported as MSI/binding file, which can then be imported back to any other environment. More information on this is available here:

    http://msdn.microsoft.com/en-us/library/bb743513.aspx

    http://msdn.microsoft.com/en-us/library/bb246048.aspx