7 Use Cases

Hardware Integrations

For Integrators accessing and using hardware peripherals connected to Linux Workstations, such as:

• Coin changers
• Scales
• RFID readers
• Liquor dispensing/tracking
• Scanners
• Automated coffee machines

Communication to connected hardware peripherals and food prep hardware with APIs can be accomplished through standard device ports (serial, USB, IP), or through proprietary I/O. The following sections provide more detail.

Standard Ports (Serial, USB, IP)

• Use standard Linux access. IP open ports are limited. See the Oracle Simphony Security Guide for more information.

• The port ranges from 8200-8400 is reserved for integration use.

• Access for additional ports can be enabled in one of two ways:

  • Through a custom CAL package. (See Deployment for more information.)

  • EMC workstation configuration.

Proprietary I/O

Examples include cash drawer, customer display, mag card reader.

Best Practice Recommendation

Concurrent Access: Only access peripherals for which you are the only application accessing that peripheral. Access conflicts will occur if two different applications or components attempt to access the same peripheral concurrently. This includes attempting to access a peripheral that the Simphony application is configured to utilize.

API Options

• PCWS API (Preferred)

  Note the Concurrent Access comment above.

• Updated JavaPOS drivers, which allow Integrators using Java to use industry standard calls rather than integrate to PCWS API.

  Note the Concurrent Access comment above.

• There is no OPOS for Linux.

Kiosk

A kiosk integrator builds their solution directly on top of a platform similar to a headless Simphony workstation, comprised of Oracle hardware, Oracle Linux for MICROS, and Simphony. The differences that make it a kiosk include:

• Custom CAL package with Integrator kiosk application
• Simphony POS Operations UI configured to not start on boot. Configured in the EMC.
• Chromium will start kiosk URL on boot. Configured via a custom CAL package.

The Integrator developed app runs on the above platform, and utilizes the following UI and API pattern:

• UI via HTML5 on Chromium browser (Chromium Embedded Framework)

  This is a direct HTML5 in Chromium, and not a Simphony HTML5 Custom Dialog Extensibility.

• STS API endpoint consumption on local host. STS Location API can be enabled for the kiosk workstation through the EMC.

  Figure 7-1 Kiosk Integration

  
  
  

Payment

Payment integrations consume the Simphony Payment Interface (SPI) API.

No Footprint Solution

In the preferred no footprint approach, there is no integrator code footprint running on the workstation. The payment device interfaces directly to the SPI API through a network IP connection on the workstation. This approach is suitable when interfacing to the resource constrained Workstation 5A.

Figure 7-2 No Footprint Solution: SPI API and Payment Device

Payment Connector Solution

If the no footprint solution is not feasible, a lightweight extensibility object can act as a payment driver/connector between the payment device and SPI. On the payment device side, connect using the Hardware Integrations use case pattern listed previously. On the SPI side, consume the standard SPI API.

Note:

If the Workstation 5A is a target hardware platform, the lightweight extensibilty object needs to be quite light. See the Workstation 5A section in Workstation Categories for more information on constraints, especially due to RAM limitations for integrations.

Figure 7-3 Payment Connector Solution: Payment Device, Payment Device Connector, and SPI API