EDI Pipeline Components
Click here to download the PDF Installation & Configuration Guide
Generate Native Instance & Validate Native Instance Editor Support
A vital feature for developer productivity when developing
schemas and maps, “Generate Native Instance” and
“Validate Native Instance” are features sadly lacking adequate
support in BizTalk since BizTalk 2002. These
features save developers hours by adding the ability to:
• Test a map directly with a native EDI file as an input when
mapping from EDI to another format
• Test a map directly with a native EDI file as an output when
mapping from any format to EDI
• Parse native EDI files into their XML equivalent as defined by the
XML schema to allow it to be more human readable
• See what a native EDI file would look like in order to conform to
a given XML schema
Context Property Overriding Support
Almost all properties defined for both the EDI dis-assembler and assembler components can be overridden at runtime by overriding the configured value with a value provided in the appropriate message context property.
EDI Envelope Preservation via Message Context
Until now, retaining and retrieving the EDI envelope values in BizTalk has been complex and not something possible without custom coding or configuration. With the Bryn EDI Runtime, all EDI envelope values are promoted to context properties defined in custom property schemas which are installed as part of the runtime.
Customised Control Number generation
Control numbers for the interchange, functional group, and message can be configured in the assembler components to be system generated or can be explicitly set via context properties and also the pipeline UI. Functional group and message control numbers can also be set to Count Within Parent which indicates the number should increment within the scope of it’s parent. For example, each functional group within the interchange, and each message within the functional group (or each message within the interchange for EDIFACT if no functional groups are used), will be numbered incrementally, with the seed beginning at 1.
System generated control numbers can also be customised allowing for trading partner/application specific control numbers to be generated.
The Bryn EDI Runtime installs with a simple database which is used to generate unique control numbers for the interchange, functional group and message. This is achieved by stored procedures which log the BizTalk Message ID of the message being output by the assembler, and in return provide the next generated number from the database table.
The stored procedure to call for each level is configured in the assembler component via the Database Details property. It is therefore extremely simple to create new table and stored procedure definitions in the database which perform the same role, independent of other stored procedures. These stored procedures can then be called from pipelines which are specific to certain trading partners or applications that require their own control number seed and increment.
Control Number Logging
Interchange control number & BTS MessageId logging in the EdiDb, which allows correlation between a generated control number and the BTS MessageId. This feature therefore enables the tracked BTS message to be traced through with HAT/BTS Tracking.
Note: Only system generated control numbers are tracked to the EdiDb. Therefore, if the control number was set via overriding the appropriate context property, or was set to be count within parent, the EdiDb is never touched.
Schema Customisation
In contrast to existing BizTalk EDI tools, customising EDI schemas for the Bryn EDI Runtime is as simple as customising a native XML schema. The runtime determines an XML node’s EDI type based on certain criteria, based on the Schema Format configured. Therefore, as long as the schema adheres to the required structure, naming and annotation standards defined by the schema format, the runtime will interpret the schema without issue.
Multiple XML schemas representing the same EDI message type support
Multiple XML schemas representing the same EDI message type is supported. This allows multiple trading partners which use the same EDI message type (e.g. an EDIFACT IFTMIN D 99B), but have customised schemas representing this EDI message, to co-exist in the BizTalk system without issue.
This configuration is supported due to the manner in which schemas are selected. See Inbound Schema Selection for a description on how schemas are chosen by the EDI dis-assembler components. For the assembler components, the BizTalk message type (i.e “namespace#root node name”) is used for schema selection. The message type must match a schema configured in the list via the pipeline UI.
Schema Based Property Promotion
Schema based property promotion is supported via the EDI dis-assembler components. This allows properties to be promoted directly from the message data, just as the Flat File and XML dis-assemblers do.
However, outbound property demotion is not supported by the EDI assembler components. Therefore, to demote values from the message context into the message data, the message will need to be first run through the XML Assembler before passing it through to one of the EDI assemblers.
Customised Date & Time Formats
All date & time fields provide a customisable date/time format field which can be customised to any format supported by the .net framework’s Convert class. This offers great flexibility in being able to generate EDI with almost any given date and time format.
Support of Multiple Schema Formats
Multiple schema format support is provided by the runtime. The current release provides support for all BizTalk EDI schemas from BizTalk 2000 through to BizTalk 2006. Covast Accelerator Version 2 schema formats are also supported.
The following options are available for the Schema Format in the current release:
BizTalk2000 – Indicates the schema adheres to the required structure, naming and annotation standards used by both BizTalk 2000 and BizTalk 2002.
BizTalk2004 – Indicates the schema adheres to the required structure, naming and annotation standards used by both BizTalk 2004 and BizTalk 2006.
CovastAcceleratorV2 – Indicates the schema adheres to the required structure, naming and annotation standards used by the Covast Accelerator Version 2.
Schema format support is provided via schema managers which manage specific types of schemas. For this reason, the Schema Format property must be specified whenever specifying a schema. By specifying the Schema Format, you are indicating to the system how to interpret a schema’s structure in an EDI sense; for example, how to identify which XML nodes are segments, data elements etc.
Schemas must adhere to the required structure, naming and annotation standards defined by the schema format so the runtime can interpret the schema without issue.
Contact Bryn at ++61 3 9370 2414 or email sales@bryn.com.au for further details.