Inside the MilramX Transfer Process

At the core of the MilramX Transfer Process are Data Transfer Objects (DTOs). These are essentially named subroutines which, at their simplest:

1. Call an Adaptor to fetch the latest updates to a table in a source database and then translate this data into the form of High Level Data Objects (HLDO).
2. Translate each source HLDO instance into an HLDO to be sent to the target system.
3. Call an Adaptor, with the target HLDO instance, to update a table in the target system database.

High Level Data Objects are sets of parameter name:value pairs, with each set being identified by a unique keyword, in the manner of a JSON string.

Each adaptor is driven by a set of metadata rules, which define how each HLDO parameter relates to either:

1. Fields within a database table, including indirections, for reading and writing data..
2. Calls to be made to web-services proxy routines to fetch and store data.

These rules can be imported from Excel spreadsheets, using the MilramX web-browser interface, and stored as XML metadata, which is used by each Adaptor to fetch and store data.

A DTO can fetch HLDO data from multiple sources and store the resultant data into multiple target systems, databases, and tables. It can also send Email or Text-Message Alert messages to a list of people, for each event that it detects by examining the HLDO data from the source system(s).

An important function of each Adaptor is to check the data it transfers to ensure that the data is formatted correctly for the DTOs or the target systems, which will consume the data. Adaptors also handle communications errors, especially with remote systems through their web-services interfaces.

MilramX comes with pre-built adaptors for a range of relational databases as well as adaptors for communicating with the BellHawk barcode tracking system, either through its web-services interface or by directly accessing the disk drive where the BellHawk database is stored.

The Transfer Process is run by the Launcher with the name of the DTO to be run. This DTO then gets the latest updates to the source database tables it is monitoring, by calling the appropriate Adaptor for the source system, before translating the data and calling an Adaptor for the target system.

The decision about which DTO to run next is made by the Launcher based on information stored in the Control database. This information, for each DTO, includes the times of day that the DTO can run, how often it should be run, and how important running the DTO is relative to other DTOs, when there is a conflict. 

A key feature of this architecture is that the HLDO adaptor rules for one system can be developed by a separate person from that developing the HLDO adaptor rules for another system. This enables the adaptor rules to be developed by experts in the respective databases without needing one person to be an expert in both. This also enables a business systems programmer to be able to develop the DTO rules without needing any detailed knowledge of the internals of either system.

In those cases where a simple mapping is required between the HLDO parameters of the source and target systems then a business analyst can set up mapping rules by importing these rules in the Form of Excel spreadsheets through the management console. Excel imports through the management console can also be used to define the rules for translating between the data record fields of databases or web-services interfaces and HLDOs.

For more information, please click here for a PDF download of the "MilramX Overview Data Sheet".