Software AG Products 10.7 | Integrating On-Premises and Cloud Applications | Processing Flat Files | Concepts | How Is a Flat File Schema Used to Parse Records? | Record Identifiers
 
Record Identifiers
A record identifier looks at a record and extracts an identifier out of the data. Integration Server uses that identifier to connect the record definition in a flat file schema with a particular record in the flat file. The name of the record definition must match the value obtained by the record identifier. When creating a flat file schema, you can choose from one of two methods of record identification:
*Starts at position record identifiers compare the value that occurs in the record, at the specified offset, to all the record names defined in the flat file schema. Note that the Starts at position identifier cannot distinguish between all types of record names. For example, if you name records “Rec1” and “Rec,” some instances of “Rec1” may be identified as “Rec,” because “Rec1” begins with “Rec.”
*Nth Field record identifiers use the value of the specified field as the record identifier. These identifiers count from zero (0). For example, if 2 is specified, the third field is used as the record identifier.
Integration Server processes the longer record identifiers first and then the shorter record identifiers.
Integration Server does not perform any kind of normalization on input provided in the flat file schema or when comparing or processing values retrieved from a file. You must enter carefully the exact Unicode character values you want to search for in an instance of the flat file you are describing. For example, you should differentiate wide (sometimes called multi–byte or zenkaku) characters from their narrow (or single–byte) equivalents when processing Asian characters. Another example is the use of Unicode combining and pre–composed sequences. In all cases, fields are matched using a strict binary comparison of Unicode character values in the separate fields.
Note:
Exercise care when selecting the encoding of the file being processed. Some encodings are very similar to one another. For example, the Shift–JIS and MS932 encodings commonly used with Japanese language text are very similar, but they map some characters differently. This can result in Integration Server not finding a match where you otherwise would expect one to exist.