Sharing insights into the world of Restaurant POS
I try to climb at least one 14,000ft peak in Colorado each year. I once met a guy who told me he thought climbing 14ers was boring (he had done several). His complaint was that every climb was about the same: you get above the tree line, climb over a bunch of boulders, and then you sit at the top of a mountain and see pretty much the same type of view each time: a bunch of other mountain tops. Well, I suppose what the guy said is technically true, but believe me, does he ever miss the point of climbing a mountain, especially one of the highest points in the U.S. where spectacular views abound! And the journey up and down is never the same no matter what mountain you are climbing.
On this post I want to focus on the technical aspects of Micros POS Integration. For today I will focus on the Micros 3700 platform but also make some points about the 9700, Simphony 1, and Simphony 2 platforms.
It’s important to understand that Micros (now Oracle), offers at least 5 different POS systems for Restaurant and Hospitality (Micros 3700, Micros 9700, Simphony I, Simphony II, and E7). And yes, Micros 8700 systems are still in the field as well! Each of these has their own APIs, which means that if you want to develop solutions to support all of Micros / Oracle, you are looking at creating at least 5 different integrations!
In my opinion, the Micros 3700 system is bloated as it suffers from a lot of legacy design features that make setup a really ponderous task. For example, I recently tried to count all the configuration options available in the Micros POS Configurator. I came up with approximately 4600! Although the POS Configurator has an integrated help system, getting the configuration right so that your integration will function properly can be a big challenge. So purchasing support from Micros can really make sense. It’s not cheap, but it can save you a lot of time and frustration.
The Micros 3700 Platform has 3 different APIs available for third-party integrators, as well as a large, accessible relational database. These are SIM, Res POS API, and Stored Value Card. I’ll discuss the Micros database, also.
SIM stands for “System Interface Module” and is a common way of creating a Micros Interface. SIMs are written in ISL (Interface Script Language), a Micros specific programming language. SIMs allow you to create custom interactions with Micros users on the FOH terminals. SIMs work by inserting keystrokes into the POS as if a user was doing it. SIMs are also designed to process events that happen on the terminal such as starting a check, adding an item to check, adding a payment, etc. They provide a means to interact with another program running on the Back of House server. You can extract data off the current check and insert data onto a check, plus you can send requests to printers. You can really do a lot of things with SIMs, but you want to avoid developing SIMs for a number of reasons. First, on the business side, the Micros customer will need to have a SIM license from Micros activated, which is another $800 to $1000 per location that restaurateurs will have to spend to use the product. Second, SIMs are hard to write. There are really no development environment tools to write a SIM and the only way that you have to debug the code is to run it on a live terminal; additionally, the programming resources in the ISL language are quite primitive compared to other modern languages. You won’t be able to reuse anything you to create in a SIM with any other POS platform. In my opinion, the main documentation about programming a SIM is very difficult to use (however quite extensive). SIMs error-handling mechanisms are intended to tell the terminal user what went wrong – there isn’t a way to get an error back to your program – all you know is that the process stopped working. SIM modules do provide you a way to customize printing on Micros, and can be a good mechanism for capturing real time data from terminals.
RES POS API
The RES POS API allows you to add and update checks, including making payments. You can also query for checks and send print jobs to the printer. This API is a COM interface and you can easily manipulate it using Microsoft Visual Studio (.NET). The Micros API has just a few calls; each call supports a large number of parameters, which can be either good or bad, depending on your point of view. It’s typically bad while trying to get the interface working, as gaining the knowledge to properly build all the structures to properly place an order takes some time. However, Micros does provide a method in the API to test different data pieces in the order, which is a definite help. A nice feature of the Micros API is that it will accept an “incomplete” item order. In other words, while an order for a dinner salad may require a salad dressing selection, the Micros API will typically accept the order without specifying the required modifier. This definitely makes it easier to get a working interface in place since you can always enrich it later. The Micros order placement API does not have specific areas where you enter in customer data or “non item” data such as an order ready time or delivery address. Micros does provide a place to enter in free form text onto the check so that this information is printed (although I find forcing Micros to print this information is sometimes challenging because the configuration has to be exactly right). You can use the Micros API to process credit cards through the POS.
There are 2 ways to use the interface: either locally, on the Micros Server via COM or via a web service interface (intended for remote use, but can be used locally as well). It’s extremely important to select which way you are going to implement the interface up front because each requires a different Micros license. If you use the web service interface, then in theory you don’t have to have any custom code running locally on the Micros Server. However, as the API doesn’t give you any access to the Micros Menu you may have no choice but to run code locally if reading menu data is important to you.
When you purchase this API, Micros does provide some sample code to show you how to use these interfaces.
You can use both Micros SIM and the RES POS API together at the same time, but you will need both a SIM license and an RES POS API license. You definitely want to use the RES POS API for adding items to checks and processing payments (you can do this with SIM, but it can be really problematic due to the lack of error handling).
The Micros RES POS API seems to be fairly stable when it comes to ongoing operations. The Micros API is either working or not working; restarting the machine is usually sufficient to recover if an issue occurred.
Stored Value Card API
If all you are looking to do with Micros is provide a payment or loyalty integration, then the Stored Value Card API may be the right choice for you. This API works with 3700 (and I think some other platforms as well). The API provides functionality so that you can implement a collection of services associated to perform Redemptions, Refunds, Balance Inquiries and Transfers, and Coupon functionality. The setup of the Micros Store Value Interface is straightforward, but entails quite a few steps. The SVC interface of course requires a separate API license from Micros then the RES POS and SIM licenses.
The Micros Database can be a real challenge to understand. Micros uses the Sybase Database System for the 3700 platform, so it’s straightforward to access. However, a typical Micros Database has 950+ tables, which can make it very daunting to even figure where to start looking for data of interest. I think the database is horrendously complicated. While I like to think I finally have a decent understanding of the menu data structures in Micros, honestly, I always have to go back to my notes and review my code each time to get it straight and remember all the different table names. As a rule, I never add new tables to a POS system database; I always build something exterior to it when needed. I have learned that while adding something to the system database might seem the natural thing to do from a developer perspective, the reality is that when you do, you open yourself up to all kinds of support issues whenever the POS dealer or manufacturer get involved. They almost always fix the issue and leave third-party applications left to fend for themselves (i.e.: wiping out what you have setup in the DB).
Micros 9700 Platform
The Micros 9700 system is equipped with 2 Web Service APIs, one for extracting configuration information about the POS so you can have enough information to place an order and the other for actual placement of the orders. The Configuration Web Service certainly provides a rich level of Menu Information.
Simphony I / Simphony II Platforms
The Simphony I and Simphony II platforms are very similar in architecture. Both are cloud based POS platforms; what this means is that the POS applications run locally (not as a web app) on Micros workstations, but the back end management and reporting tools are hosted in the cloud.
What this means from an integration perspective is that in reality you may not be able to directly access the Database of these POS Systems (typically Microsoft SQL server but can also be Oracle) without extensive discussions with the customer. More typically, for each of these systems, to get data out, you will need to rely on the customer providing you with custom reports generated thru the My Micros web portal. These reports can be configured to run automatically an then emailed to you. You will need to create a solution to parse the data from these reports.
What makes the Simphony platforms challenging from a POS Integration perspective is that the APIs for the two platforms have significant differences. The Simphony I API is much more robust then the Simphony II API. With Simphony I’s API, the facilities are there so you can get detailed order and menu information, place order (create new checks and add to existing checks), and make payments, allowing you to create a variety of robust solutions without needing to get direct database access. The same cannot be said of the Simphony II API; for some reason, critical functionality such as obtaining line item detail via the API is lacking. This means that for many applications built for Simphony II, realtime database access will be required, which may be challenging to obtain given PCI security concerns.
Depending on what Micros platform you are targeting, there are a number of integration points to consider. Micros does provide substantial documentation for all these interfaces; you need to study, carefully, the limitations of each interface before you start your project. It’s critical for you to understand how you want your interface to work in conjunction with the POS, recognizing where you have flexibility in your business model so you can compromise if needed to circumvent limitations placed on you by the Micros POS.
For my next blog entry, I’ll focus on technical integration of the Positouch platform.