This page discusses the additional steps needed to add EDIFACT routing interfaces to a production. Be sure to perform these tasks in the same namespace that contains your production. When you create rule sets, transformations, and search tables, do not use reserved package names; see Reserved Package Names.
Also see Overriding the Validation Logic.
Defining Routing Rule Sets for EDIFACT
For general information on defining business rules, see Developing Business Rules.
When you create a routing rule set for an EDIFACT routing interface:
Defining DTL Data Transformations for EDIFACT
Your routing rules might need one or more data transformations.
For general information on defining DTL data transformations, see Developing DTL Transformations.
When you create a DTL data transformation for EDIFACT documents:
On the Transform tab, Source Class and Target Class should both be EnsLib.EDI.EDIFACT.DocumentOpens in a new tab.
Source Doc Type should match the schema category name assigned by the business service.
Target Doc Type should be the name of the target schema category. This must match a schema category name that you have loaded into InterSystems IRIS.
Use the EDIFACT Document Viewer Page to test your transformations, as described in Available Tools.
To integrate the DTL data transformation in the production, enter its full package and class name in the Transform field of a routing rule set.
Defining EDIFACT Search Tables
The EDIFACT search table class, EnsLib.EDI.EDIFACT.SearchTableOpens in a new tab, automatically indexes the EDIFACT document ID, which it gives the name Identifier.
If you need more items to search, you can create a subclass. The subclass inherits the Identifier property, plus the infrastructure that makes search tables work. For details, see Defining a Search Table Class.
Note the following points specific to EDIFACT:
See the list of EDIFACT separator characters, in the reference for the Separator setting.
In this case, InterSystems IRIS supports an additional value for PropType. You can use DateTime:HL7 in addition to the types listed in Using Virtual Documents in Productions.
Handling Repetitions in EDIFACT Documents
Some segments in EDIFACT documents can repeat or be used within loops. The repeat and loop structure can be either expressed implicitly or explicitly. InterSystems IRIS can handle either implicit or explicit repeat and loop structures, but the document must either specify all repeats and loops explicitly or all implicitly. When InterSystems IRIS is parsing an EDIFACT document and encounters the first repetition or loop, it determines whether the document is using implicit or explicit repeats. It then parses the remainder of the document using the mechanism found in the first repetition or loop. When it is parsing an EDIFACT document, InterSystems IRIS treats a mixture of explicit and implicit repeat mechanisms as an error.
If an EDIFACT document is using implicit indication of repetition, a segment is represented as a three letter label (such as UNH), followed by the data element separator and data (the data elements and components). No information explicitly indicates which repetition of a segment or a loop a particular segment is in. But if an EDIFACT document is using explicit indication of repetition, a repeating segment is expressed as the three letter label, followed by the component separator and the control numbers, followed by the data element separator. For a segment, ARA, which is a repeating segment, this may look like ARA:1+data. For a segment, DET, which is in Group 2, which is nested in Group 1, this may look like DET:1:1+data. Only those segments which can repeat or which are inside a loop are expressed using these control numbers.
By default, an EDIFACT document retains its implicit or explicit repetition indication when output to a file. You can convert an EDIFACT document with implicit indication to explicit by using the ConstructExplicitClone method, and you can convert an EDIFACT document with explicit indication to implicit by using the ConstructExplicitClone method.