BizTalk to Incorporate Covast B2B Capabilities

A few days ago, Steve Martin announced that Microsoft have reached an agreement with Covast (the European software firm behind the Covast EDI Accelerator and the out-of-the-box Base EDI Adapter) to acquire their advanced B2B capabilities – this will be incorporated into a new feature pack which will be available as part of Software Assurance benefits to customers who license BizTalk Server, similar to the BizTalk LOB pack.

I’m reading between the lines here, but I believe Microsoft may have acquired the technology recently developed by Covast and GXS (a Value Added Network provider), otherwise known as the Covast B2B Suite for GXS Trading Grid, which includes:

  • New adapters to support Value Added Network (VAN) connectivity.
  • An EDI message repository which is stored in SQL Server offering seamless integration via EDI Explorer to Visual Studio (I hope supported by VS2008), allowing EDI message definitions to be imported as XSD schemas into BizTalk projects.
  • Real-time updates from VANs on EDI message delivery and trading partner receipt (something that was always a pain to achieve, especially when doing it through, erm…. snake based scripts).
  • New message standards for specific industry sectors.

There is no news on when this technology will be available from Redmond directly, however Steve’s post suggested that it will be available around the same time as R3. However, I’m not too sure how this fits into the bigger picture: the original Base EDI Adapter was simply the Covast EDI Accelerator with all the handy bells and whistles removed.  This accelerator did the job of EDI document translation admirably but I would have thought that after the release of BizTalk 2006 R2 and its own native EDI handling capabilities, the majority of customers would have made the transition away from costly third party software to the R2 capabilities. Releasing more Covast based technology may just muddy the waters for us EDI types…. I hope that won’t be the case and the BizTalk Team provides native R2 EDI integration into this functionality.

That said, I’m pleased to see that Microsoft believes BizTalk has many more miles to go – this new announcement should certainly keep me occupied until Oslo arrives!

More information on the Covast B2B Suite for GXS Trading Grid can be found online at the Covast website.

Covast EDI Accelerator – No Authorization for Document Type

Earlier this morning, we received the following error from our production Covast EDI Accelerator implementation:

Error encountered: ERROR (13), interchangenr 61059 :
No authorization exists for this document type. Check the port properties.
sender: [Senders Trading Partner Name][DEFAULT], recipient: [Recipients Trading Partner Name][DEFAULT], source format: [3 2 1 ], source document: [Purchase order message]

We were thrown by the fact that the trading partner in question successfully sends several batches of orders per day (for the last several months) without issue – why were we encountering this problem today?

It turns out that the interchange batch in question was sent with an incorrect syntax identifier and version of UNOA2:


we were expecting an identifier of UNOA1.

Syntax identifier settings can be found in the receive port configuration dialog for the EDI Accelerator under the ‘Supported Document Types for EDIFACT/X12’ as shown below:

Covast EDI Accelerator Receive Location Configuration
Only messages with an syntax identifier that is the same as that defined in the receive location settings can be accepted [by that receive location] – you will need to advise your trading partner of the error and ask them to resubmit, modify the file yourself and resubmit or add another receive location with the alternative identifier.

BTS2006 EDI Base Adapter – Error Occurred in the File System Connector

I installed the BizTalk 2006 base EDI adapter for the first time last night to investigate the differences between the Covast EDI Accelerator and the Base EDI Adapter (the base adapter technology is produced by Covast).

While working through the XML-to-EDI tutorial it became apparent that things were not quite right with my configuration – I was constantly receiving the following error:

Error encountered: ERROR (120) :
An error occurred in the File System connector. Check the details.Cant make a connection to \TITANAEEDIDocsHomeDocumentsPickupEDI. Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.Foldername: \TITANAEEDIDocsHomeDocumentsPickupEDI, Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.

It would appear that on installation, a share is created that points to C:Documents and SettingsAll UsersApplication DataMicrosoftBizTalk Server 2006EDISubSystem. The SubSystem folder contains all of the goodies required to make the Base EDI Adapter work – esp.ini, the engine input file (EIF) and Documents directory which provides a message store while the adapter is doing its magic.

The error above however is a little misleading, as it has nothing to do with a network component or the specified name being incorrect. Instead, the EDI Subsystem Users group is not granted access on this share under the default installation. Simply adding the group (with full control) will resolve this error.

It does make me wonder why the installation insists on creating a share to point to the aforementioned location as this directory information is actually held in the SQL Server database. The only reason I can see for using this method is on multi-server installations, where the EDI SubSystem resides on a network share, rather than a local directory. This makes sense, but I’m not too sure behind the reasoning on a default [local] installation.