Data Conversion

In the previous transformation example, information in Cust_No (alphanumeric and holding 9 positions) needs to be converted to all-numeric with a capability of 20 positions. The alpha component of Cust_No must be dealt with in another manner. It is possible to change the nature of the target application to accept letters, or the alpha component can be either deleted or converted. Deleting characters or converting them into numeric representations are examples of data conversion. The key to successful data conversion is to determine the data formats of the source and target applications, assess the differences between them (for example, which data elements need to be extracted and converted, and where they ultimately need to be placed), and adjust to them. Most integration servers can understand most message schemas through message identifications. Therefore, they automatically convert data to a workable format. However, sometimes it will be necessary to program a rule to address a specific data-type conversion problem. The conversion of numeric information to alphanumeric information (and vice versa) generally requires such a programmed rule.

Although many formats exist within most application integration problem domains, we will confine our attention to the following:

• Alphanumeric

• Binary integers

• Floating point values

• Bit fields

• IBM mainframe floating points

• COBOL and PL/I picture data

• BLOBs

In addition to these formats, there are a number of formatting issues to address, including the ability to convert logical operators (bits) between systems and the ability to handle data types that are not supported in the target system. These issues often require significant customization in order to facilitate successful communication between systems.

In data conversion, values are managed in two ways: carrying over the value from the source to the target system without change, or modifying the data value dynamically. Either an algorithm or a look-up table can be used to modify the data value. One or more of the source application attributes may use an algorithm to change the data or create new data. For example, attributes in the source application may represent "Amount Sold" and hold the value 8. Another attribute, "Cost of Goods Sold," may contain the value 4. However, in the target application, these attributes may have to populate a new attribute, "Gross Margin," which is the amount sold less the cost of the goods sold. In order to make this communication successful, the algorithm "Amount Sold minus Cost of Goods Sold" must be applied.

Algorithms of this type are nothing more than the type of data conversions we have done for years when populating data warehouses and data marts. Now, in addition to using these simple algorithms, it is possible to aggregate, combine, and summarize the data to meet the specific requirements of the target application.

When using the look-up table scenario, it might be necessary to convert to an arbitrary value. "ARA" in the source system might refer to a value in the accounts receivable system. However this value can be determined, it must be checked against the look-up table. Integration servers may use a currency conversion table to convert dollars to yen, which may be embedded in a simple procedure or, more likely, in a database connected to the integration server. The integration server may also invoke a remote application server function to convert the amount.

The application integration architect or developer may encounter special circumstances that have to be finessed. The length of a message attribute may be unknown, or the value may be in an unknown order. In such situations, it is necessary to use the rules-processing capability of the integration server to convert the problem values into the proper representation for the target system.