Use Case: Migrating Legacy Data in Real-Time
For legacy data that still runs on legacy hardware or uses old formats that is still needed in real-time, MAE provides the platform to fetch the data, transfer the data, and make the data available via modern means such as JSON, XML, or REST API.
You have modernized your infrastructure, but you're being held back by dependence on legacy data - perhaps on legacy equipment - that is not going away anytime soon:
All of these examples are problems because data is hard to access without some sort of bridging technology. Or perhaps bridging technology is in place, but it is not outdated as well. Regardless, data is now needed in JSON format, XML format, or accessible via REST API.
How do you acess this legacy data in real-time?
MAE has a number of capabilities for accessing legacy data.
MAE's IoGW component enables any MAE application to use the serial port as a MAE resource. Create a MAE application that issues commands through the resource to fetch data and shares that data with other MAE components.
If you already have programs/scripts that access the serial port to fetch the data, then a read-only MAE resource can be setup to run that program/script and provide the fetched data back to the requestor.
If your root MAE server does not have an available serial port or is not phyiscally close enough to the legacy equipment, you can deploy something like a Raspberry Pi as a MAE spoke; then connect it to the legacy equipment to enable IoGW to fetch the data.
If the legacy equipment does not have a serial port, but you can get an adapter to access it via USB, then MAE can treat the USB port as a serial port to achieve the above results.
Just as the previous section described how data can be fetched, the same can be performed to push data into the legacy system for write-only data. One IoGW resource can be configured for reading the data; another IoGW resource can be configured for writing the data.
MAE does not have a decoder for every known format, but you can develop a data decoder. MAE internally represents data in an XML/JSON data structure, so once you convert your data into that structure, it is ready to be encoded into XML or JSON as text or shared with another program that understands XML or JSON - such as a REST API daemon.
A database table is a collection of records with field data that may not be readily or practially fetched and pushed using pre-existing scripts. In this case, you'll want to create a MAE component that controls the serial port connection to legacy equipment to give it finer control over the fetching and pushing of data. This new MAE component can virtualize the data schema to make it logical and predictable for fetching and pushing data.
If the source database simply grows, your new MAE component may choose to push all new data to a modern database table.
MAE has created all the mechanics of receiving, decoding, encoding, and responding to REST API calls as well as a prototype daemon (see maerest) as a code starting point. Modify the prototype and integrate it with the IoGW resource(s) that you configured to make that data available via REST API.
Does this solution look like a fit for your organization? Reach out to HanoverSoft at +1 (919) 270-6712 or info@hanoversoft.net to discuss.
Use tioreg to configure access. For example, if the data is on MAE spoke macon, serial port /dev/ttyS0, accessible at 9600 baud with a resource name of CmdPort, use this invocation:
tioreg -add CmdPort serial://macon/ttyS0?baud=9600
Next, make sure the IoGW binary is installed on the MAE spoke. IoGW automatically instantiates a copy of itself on the spoke to access resources that are local to that spoke. To see the status of all instances across all spokes, use tstatus to run
tstatus iogw.*
Actually, the "S" in USB is "Serial". A USB is a serial device. Its device name is in the form of /dev/ttyUSBn, where n is the USB logical device number. For example, if data on MAE spoke macon, USB port 0 with a resource name of CmdPort, use this command:
tioreg -add CmdPort serial://macon/ttyUSB0
To configure a resource to contain the captured output of a command, you'll add a pipe using tioreg. For example, if the program is /usr/local/bin/getdata and the resource should be named FetchXData, then run
tioreg -add FetchXData pipe://macon/?exec=/usr/local/bin/getdata
When resource FetchXData is accessed, all output from getdata will be available to read. For example:
IOPort dataport;
dataport.open(sourceName);
string data;
if (dataport.valid()) {
while (!dataport.eof()) {
unsigned char c= dataport.getchar();
data= data + c;
}
}
To configure a resource to push data through a command, you'll add a pipe using tioreg. For example, if the program is /usr/local/bin/putdata and the resource should be named SaveXData, then run
tioreg -add SaveXData pipe://macon/?exec=/usr/local/bin/putdata
When resource SaveXData is accessed, all input to putdata will be written. For example:
IOPort dataport;
dataport.open(sourceName);
string data= "New data\n";
if (dataport.valid()) {
dataport.puts(data);
}