webMethods 10.2 | Service Development Help | Working with Flat Files | Concepts | What Is a Flat File Dictionary? | When Should I Create a Flat File Dictionary?
 
When Should I Create a Flat File Dictionary?
The decision to define records in a flat file dictionary versus in a flat file schema depends on the type of flat files that you intend to parse. The Electronic Document Interchange (EDI) ANSI X12 standard defines a large set of document structures that reuse the same record, field, and composite definitions many times. Defining these records, fields, and composites in a dictionary allows for them to be reused throughout the entire set of EDI ANSI X12 document flat file schemas. Reusing definitions reduces the amount of memory consumed by Integration Server.
EDI ANSI X12 also has different versions of these documents (for example, 4010). Each version of the document set should have its own dictionary. In this way, you can be certain that changes to a record, field, or composite between versions are maintained.
A more complex scenario would involve multiple families of documents and multiple versions of those families. An example of this is EDI ANSI X12 and UN/EDIFACT documents. One dictionary should be created for each version of EDI ANSI X12 documents and one dictionary should be created for each version of EDI UN/EDIFACT documents. A separate dictionary would not be required for each flat file schema in the same version. All flat file schemas in one version of the same family should use the same dictionary.
In a scenario in which you intend to parse only one flat file, or flat files that do not share record, composite, or field definitions, you can define these elements directly in the flat file schema. This allows for the entire document to be edited in a single view, without referencing a flat file dictionary.
If a clear choice does not exist between these two scenarios, the best approach is to create the definitions in the flat file dictionary and reference them in a flat file schema. The definitions then can be reused at a later time.

Copyright © 2017-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release