Types of Interface Descriptions
The xBus knows three different types of interface structure descriptions in XML.
They can be distinguished by their application area:
- Record transfer with transformation
- In Configuring a Record Transformation
the exact format of the involved interface descriptions is explained.
- Record transfer on byte array basis without transformation
- The interface descriptions for this case are structured like the first ones. But they
contain less information about the fields - only their lengths. Furthermore they offer
less possibilities for identifying record types in an interface file. The only supported
method is using record type identifiers in the records.
- AS400 program calls
- Input and output parameters are stored in XML structures. These are Described by
- Using record type identifier is the easiest and fastest way to find out the type
a record. It is advisable to use it whenever possible.
- If the
RecordIdentification attribute of the
<Lines> section in a structure description is set to
TypeIdentifier, only this identifier parsed from the record line
is used to determine the record type during parsing. Order and cardinality information
is ignored in this setting.
- The simple structure description format for byte array transmission without record
transformation only allows the identification by type identifiers. In this setting
a bypass may be used to process interface files which contain only one record type but
this record type does not contain a type identifier. The identifier length has to be
set simply to zero and the identifying string to the empty one.
- The full-fashioned structure description for record transformation situations does
not allow setting the identifier length to zero.
Roughly spoken two opposite approaches to specify the record type fields are
- Each field is defined according to the underlying interface
- Fields are grouped and specified as one single item if they can be
transfered as a group without modification and without
worrying about system-dependent string lengths or line breaks in the field
The first alternative leads to easy-to-read specifications in the sense that its
just like the interface specification documents. Furthermore most transformations
can be defined without dividing field values into substrings.
If performance is an important issue, the second alternative is better. Furthermore
the resulting XML structure description are easy-to read that the contain less
Remember that the field specification is just for the internal processing. Field
names carry not semantics in sense of particular system behavior. This is only
achieved by characterizing the fields using the attributes like "Format". The
separation into fields can be chosen freely to support the desired transformation
or the treatment of system-dependent string lengths and "in-field" line breaks