Sometimes you may need to modify your existing EDI template(s) for reasons such as:
- A trading partner uses an extra filed for segment ABC
- A trading partner uses loop ABC before loop DEF
- My DBA wants to add some extra properties for the table primary keys
It is perfectly fine to go ahead and do any of these changes. The rule of thumb is to maintain the baseline version in a separate project, and to move all partner specific customization into their own projects. This way the baseline version is shielded from any changes and all new modifications are safely isolated into their own containers.
Trading partner specific customization
For example - let's assume that you exchange X12 4010 EDI messages with multiple trading partners. A new trading partner comes along, however they use custom representation of BEG segments, which introduces a new property and marks the release number at position 4 as mandatory for validation.
Your EDI templates for X12 version 4010 are bundled in a project called EdiFabric.Sdk.X12.Templates.V004010. To apply the required modifications do not change the baseline templates but create new versions of them.
Your baseline looks like this:
Then create a separate project, for this particular trading partner only, let's call it Custom1:
We also added a new file, EF_X12_004010_TS850.cs, to which we are going to apply all the modifications. Ensure to add a reference in this new project to the original baseline project.
Open EF_X12_004010_TS850.cs and apply the following modifications to the BEG segment:
The changes are:
- A new class BEGCustom1 was created and it inherits from the baseline BEG. This way all your existing mapping code for BEG will still work.
- The new class retains all its DOM properties - [Segment("BEG")]
- One of the properties is hidden by using the C# new keyword (you can also use override). This tells the parser to ignore the property in the base class and use this one instead. This way the type of the property or its validation\DOM attributes can be changed.
- The hidden property re-defines its DOM and validation attributes, and also introduces a new one - [Required]
- A new property is added at position 13 - NewField_13
The modification will let the new template to support the following BEG segment:
where NEWVALUE is at position 13.
To start using the modifications instead of the original, a new class of the target transaction needs to be created:
This new class retains all the properties from the original (inherited) TS850, but uses the modified BEG segment instead.
We now have two projects defining a template for purchase order (TS 850), so how to tell the parser when to use which one ?
All modifications can be dynamically loaded by using a load factory. Every EDI document identifies the sender by the Sender ID in the ISA\UNB segment. This identifier is unique across the trading partners you'll be exchanging messages with.
For our scenario above, we need to identify the trading partner that uses the modified BEG segment and to load the TS850 template from the customized project. For all other trading partners we will be loading the baseline version of the TS850 template.
Let's assume that this trading partner ID is CUSTOM1 and when we receive EDI document from this partner:
ISA*00* *00* *16*CUSTOM1 *1B*RECEIVER1 *071216*1406*U*00204*000000263*1*T*>~
we will load the modified template:
and tell the reader to use this logic when reading EDI documents:
var ediReader = new X12Reader(ediStream,