Table Top Ordering - Ziosk

The first set of challenges center around dealing with the differences in the way we do things and the way Ziosk expected us to do things. The Ziosk software made the following assumptions:

• It expected us to have credit card preamble lengths stored in the database.
• It expected to have a full access ODBC connection available with a password saved in it.
• It expected us to have table numbers that matched the database object numbers (the database clearly has a field for the table's name, but Ziosk was not setup to use it).

Solving these challenges required:

• Creating a new database user for Ziosk, assigning only the permissions it actually needed, and creating a new ODBC connection to support it.
• Adding preamble lengths to our credit card settings.
• Programmatically modifing the object numbers of the tables to match the table number strings (except in the case of alphanumeric table names, which were outside the scope of this anyway).

The second set of challenges revolved around getting three different middlewares to work together. While Ziosk did have support for Micros KDS (Kitchen Display System), we were using a solution from QSR Automations. After working with QSR, it was determined that the current solution would not support data coming from the Micros RESAPI (which Ziosk uses to send items to Micros), and an additional layer would have to be configured between the current one, and the KDS Server.

Putting this all together involved:

• Installing and configuring the new KDS agent, assigning it a pair of TCP ports that were not used by any other part of our system.
• Reconfiguring our current KDS agent to send its data to the new KDS agent, which in turn passed data to the KDS server.
• Configuring the Ziosk agent to send KDS data to the new KDS agent.
• Determining what settings on the new KDS agent were necessary (as it included much of the same functionality of the current agent, and the settings on both agents changed how items were routed).

Finally, I had to set all of this up to be installable by anyone (in the intrests of being able to package it as a cohesive installer), and assist with a large part of the QA testing.

All in all, I learned a good deal about how our sub systems communicate with each other (and what sort of data is being sent), a healthy understanding (and disdain) for the QA process, and how to go about dealing with third parties (that I may or may not have wanted to strangle sometimes).

Automation of Workstation Stability Research

This was one of the few projects I got to do in C#. At the time, we had just completed a major upgrade (moving to a newer version of Micros), and were having stability issues with a particular model of workstation. Store management was having to reboot the workstations everytime this happened, even though it was just the Micros client that had stopped. In addition, we were pulling logs from the workstations whenever we were informed of these issues, in an attempt to track down the issue.

My basic requirements were simple: they wanted an icon on the workstation desktop that would restart the Micros client, and email us to let us know the client had crashed. Given that we were pulling logs each time, I took this one step further, and added the automation of that to the application.

The application design was fairly straightforward, but it did involve the use of a set of classes I had not used before, mainly the WMI classes. The source code was structured like so:

Functions

• SendAlertEmail(): Pulls the IPAddress of the host machine to determine which WS Number (based on the last octet), then email back to us an alert using the SMTPClient class.
• GetWSModel(): Uses the WMI ManagementClass to pull system information and determine the model, then returns a string with the model information.
• GetLogs(): Pulls the System and Application event logs, as well as the Dr Watson logs for the older model machines. Uses WMIC's nteventlog on Windows 7, and wevtutil on Windows XP/POS Ready 2009 to actually pull the logs, and the GetWSModel() function to determine which it should pull.
• RestartOps(): Checks current running processes for our POS Client (named ops.exe, hence the function name). If none exist, it starts a new instance. If it's already running, it tells the user.

if(RestartOps())
{
    GetLogs();
    SendAlertEmail();
}
                

To wrap this project up, I created a clean RT icon to go with the desktop shortcut, and wrote an script for Micros CAL to install the package on a specific WS model.

While not a seriously complex project, it saved us from waiting to hear of these issues, then manually pulling the logs, and provided the stores with a means to quickly get their POS Client restarted.

Automation of Training Video Updates

This was another project done in C#, and involved the use of a Ruby Tuesday specific library to write to our database (which from what I've read of it, uses the standard SQLClient class). The problem involved our "Rally Videos": short training videos that the staff watch on the workstations. We had a process in place to add new videos to this, but every time we did, we would have to write and deploy a new SQL script to update the touchscreen buttons to match the videos. We were already in the middle of a project to increase the number of available video buttons, so we decided to look at the feasability of automating this.

The idea beghind this application was very simple; it read in 10 lines from a text file (to match the 10 video buttons we made available), formatted the database update string, and executed the update statement against the database. The application was then set up to run shortly after the last video copy was scheduled (as the videos were downloaded to the server during off hours, then copied out to the workstations at a certain time each week). Because we already had a process for them to deliver the videos, they now simply had to drop off a list of titles along with them, and we no longer had to write a new script (and change control documentation), every time they changed videos.

Automation of Employee Data Cleanup

This is the most recent major project I completed, and hasn't been installed yet. As it stands, our system does not have a method for purging old employee data. This can be a problem when a store goes to rehire someone, as the system retains their old job information, and sometimes has to be manually updated to allow the rehire. In addition, we were running into issues with the assignment of IDs for employees that did not use magnetic cards on the POS system. Sometimes IDs would get assigned that are supposed to be reserved for the next hire, and the system would not allow them to complete that hire.

To resolve this, I created a store procedure, which was added to our end of day process. The stored procedure looked at the date an employee was terminated, and compared it to a configurable value in the database. If they had been terminated longer than the value set, they were removed from all applicable tables. It then reset all IDs that were not assigned to a card.

Though the logic in this procedure was nothing new to me, I learned exactly what tables an employee needs to be removed from, and how to programmatically add a stored procedure to a Micros autosequence (which has to be put in 4 different tables).