Managing SIMs in Micros 5.7 without using Micros’ Enterprise Management

This is more of a way around a restriction in Micros RES added in version 5.6: SIM files are stored in the database and expected to be managed via Micros Enterprise Management. For one of my clients the use of EM for this was undesirable, while others simply don’t use EM in the first place. Without EM, the only built in solution is to connect to each location and add the file in POS Configurator, obviously a solution that is plain unacceptable for any larger corporation.

With this change, SIM files are now stored in the Micros database as micros.isl_file_def. The schema looks like this:

• isl_file_seq – a sequence number (integer) and primary key
• obj_num – an object number (integer)
• name – text, the display name for the ISL file
• path_name – varchar(254), the file path of the ISL file, usually a macro defined by Micros
• file_name – varchar(254), the file name of the ISL file
• content – text, the contents of the ISL file
• hash_size – unsigned small, the length of the hash, usually 60.
• hash_data – varchar(128), a SHA_256 hash that identifies the SIM file by its contents.
• last_updated_by – a sequence number (integer), the employee who last adjusted the row in POS Configurator.
• last_updated_date – a timestamp, the time the row was last updated in POS Configurator
• dev_mode_date, a datetime, the last time Dev mode was enabled in POS Configurator for this row.

The contents and hash have to match the SIM file on a workstation for Ops to load it. Inserting the contents from a file are pretty simple: load the file into a temporary table, then insert the contents into the isl_file_def table. The hash_data, however, is generated by POS Configurator, and there does not appear to be a way to generate one programmatically.

What does work, however, is to generate a hash_data string on one machine and insert it into another. So, one could add the ISL file in a lab machine, pull the hash_data string, and use it to insert the ISL file row into the rest of the machines.

Credit for creating this method goes to Derek Anderson, my former co-worker at Ruby Tuesday. Using the logic he devised, I was able to create a reusable installer, which reads in an INI file containing the hash data, obj num and path of each sim, and inserts them into the database via ODBC. An INI file was required due to the contents of the hash_data string, which sometimes contains ASCII control characters that are not valid in XML or JSON.