Supplemental Data Store for Control Numbers

In reviewing the utilities developed in this chapter you can start to get the feeling of how a comprehensive file conversion application might look. Such systems usually have internal data stores for things such as configuration information and auditing. In this chapter we have such a data store for interchange and group control numbers. It has been very common for application developers to implement such data stores as relational databases. Having made the choice to store information about file descriptions as XML documents, we are already on the path to using XML documents as our data stores. For reasoning very similar to what we used in Chapter 6 when considering how to store our file descriptions, we'll now formalize this decision to use XML documents for all our data stores.

The data store described here is a preliminary implementation and will probably evolve as the Babel Blaster project develops. For that reason, and because it isn't normally directly accessed or manipulated by users, I give only a high-level description and don't discuss the schema.

Control numbers used in generating interchange and functional group headers are maintained in EDIControl.xml. In moving toward Babel Blaster version 1.0, this file is located in a BBHOME directory defined by a system property in the Java implementation and an environment variable in the C++ implementation. For this version of the utility, we're only concerned with control information related to outbound documents, that is, those where X12 is the target format. This information is captured in the X12OutboundControl Element. Table 9.7 shows the organization of this Element. Indentation in the Element column shows hierarchical relationships.

The XMLToX12 utility creates the appropriate entries in the EDI control document if they don't already exist. If they do exist, the LastInterchangeNumber Element and the appropriate LastGroupNumber Element are updated. The X12 standards are not very specific about control number management, so there are several different approaches. Some EDI management systems allow the users to maintain several different interchange sender IDs and to associate more than one group sender ID with an interchange sender ID. The small to medium business users for whom this book's utilities are targeted probably don't need such comprehensive functionality, so I track only control numbers generated by the receiver ID. Interchange control numbers are maintained by the trading partner's interchange receiver ID and incremented by one for each interchange generated. A separate group control number is maintained by the trading partner for each combination of group receiver ID and functional group type. The group control number also is incremented by one for each group generated.

Table 9.7. Organization of the X12OutboundControl Element

Element	Attribute	Schema Language Data Type	Comments
TradingPartner			Tracks the control information for a trading partner. One TradingPartner Element is required for each unique interchange receiver ID.
	ReceiverID	token	The interchange receiver identifier in ISA08.
	LastInterchangeNumber	positiveInteger	Used to populate the interchange control number in ISA13.
FunctionalGroup			Tracks the control information for each functional group type sent to the trading partner.
	ReceiverID	token	The application receiver's code in GS03.
	FunctionalIDCode	token	The functional identifier code in GS01.
	LastGroupNumber	positiveInteger	Used to populate the group control number in GS06.