I had to post about this article when I saw it on thedailywtf.com - I’ve actually worked with (big public sector) customers who have consultants recommending this kind of thing…
Archive for November, 2006
When developing schemas, it helps to identify all of the necessary distinguished fields before deploying the solution into production. Making changes to a deployed schema can introduce un-needed complexity and pain if used across multiple projects.
Unlike promoted fields* however, it can be difficult to identify all of the necessary distinguished fields before deploying the solution (the business will always have a new requirement that needs you to subscribe to the one field you haven’t distinguished following the latest schema refresh…)
To help me identify distinguished fields I use the unique/constant rule:
- Unique = unsuitable. Unique fields will always contain data that is likely to change with each message instance (e.g. an order reference, invoice reference delivery date) or data that may change on a frequent basis (e.g. order date, delivery date) - It is highly unlikely that you will be required to subscribe to fields that change with each message instance and if you do, ‘why?’ should start to crop up in conversations with co-workers!
- Constant = suitable. Constant fields will always contain similar data (e.g. trading partner id, party name, routing id etc.), or data that could be considered as an enumeration (e.g. we are using a ‘message status’ field to identify how far through our core B2B process the message is, the statuses can be any one of MAPPING_COMPLETE, CONFIGURATION_COMPLETE or VALIDATION_COMPLETE).
The image above is a screenshot of version 2 of our core order message showing distinguished (constant) elements and attributes. Fields that are unique (message tracking guid, message guid, original message reference and source filename) are not promoted.
* In my experience, promoted fields are usually identified during the [orchestration] development phase.
I recently spoke with a member of the BizTalk EDI Product Team on e-mail about the feature set between 2004/2006 and 2006 R2 after reading several interesting articles about the forthcoming R2 improvements.
The team have now published a post on their blog providing a feature comparison between BizTalk 2002, 2004/2006 and 2006 R2. As an EDI junkie, the following features are particularly appealing:
- The ability to create custom schemas (I work with a number of trading partners who use EDIFACT 92.1 as their default message set!), although there is a large set already supported.
- Outbound and inbound message batching/de-batching, including the ability to suspend individual messages or an entire transaction.
- No need for additional adapters - all assembling/disassembling *appears* to occur in specialised send and receive pipelines.
I hope these new features will bring BizTalk the B2B/EDI market adoption that have previously required costly (yet excellent) third-party adapters.
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 \\TITANAE\EDIDocsHome\Documents\PickupEDI. Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.Foldername: \\TITANAE\EDIDocsHome\Documents\PickupEDI, 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 Settings\All Users\Application Data\Microsoft\BizTalk Server 2006\EDI\SubSystem. 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.
One of the noticeable omissions from the excellent SQL Server 2005 product is the Service Manager, a tool which provides a quick visual indication as to the state of a local or remote SQL Server instance.
It would appear that I’m not the first to notice this and an excellent freeware version has been produced by Jasper Smith.
This version requires the .NET 2.0 framework, supports both SQL Server 2005 and 2000 versions, and provides interfaces to manage (besides SQL Server): SQL Agent, Analysis Services, Full Text Search, MSDTC, SSIS, SQL Browser and Reporting Services!
Furthermore, there appears to be a very healthy development cycle. Great work Jasper!
Screenshots
Service Manager running in the taskbar:
Service Manager options:
