4 Runtime Environment

The Simphony extensibility is the primary avenue through which Integrators develop code to run on Simphony workstations.

SIM/Extensibility Platform

Linux integrators must consider the platform differences between Microsoft Windows, Linux, and Android platforms, as summarized in the following table:

Table 4-1 Extensibility Platform Differences

Feature Microsoft Windows Linux Android

OpsContext core dialogs

Yes

Yes

Yes

HTML5 UI/dialogs

Yes

Yes

Yes

SIM

Yes

Yes

Yes

.NET Extensibility

Yes

Yes

N/A

WPF dialogs

Yes

N/A

N/A

.NET WinForms dialogs

Yes

N/A

N/A

Custom Styles

xaml

CSS

CSS

.NET Framework

4.6.2

Mono 6

N/A

C/C++ Native DLLs

Yes

N/A

N/A

C/C++ Native Executables

Yes

Yes

N/A
Custom Dialog Extensibility
Custom HTML5 Dialogs in Extensibility can be assumed to be available in all platform deployments (denoted by the “HTML5 UI/dialogs” line in the above table). This module was created in Simphony 19.2 specifically to allow cross-platform integration compatibility. Simphony extensibility (SIM/C#) has traditionally only had a primitive user interface functionality. The SIM “Window” feature is limited to form entry and C# has no built-in user interface functionality. Microsoft Windows extensibility applications can use .net forms/WPF to build complex user interfaces. These technologies are not available on Linux or Android. Simphony 19.2 introduced a new feature which provides an extensibility API for displaying complex dialogs across all platforms. The technology to achieve this is HTML5 running isolated in an iframe or separate browser instance. The benefits to this design are:
  • HTML5 is a standard and familiar technology, with industry wide population of HTML5 capable developers.
  • HTML5 renders rich, animated UI experiences.
  • HTML5 is platform independent. HTML5 dialogs render identically on Microsoft Windows, Android, and Linux.
  • Isolating the HTML5 dialog gives the extensibility a safer sandbox to execute code.
  • The renderer is CEF (Chromium embedded framework). This technology is standard for most browsers.
HTML5 Extensibility API Details

See the Oracle Simphony HTML5 Extensibility Developer Reference Guide for more information on the following topics:

  • API Basics
  • Raising the Dialog, with sample code
  • Example HTML5: simple dialog, functioning centered dialog, dialog styling, database image references, custom and unknown resource event
  • Extensibility Callbacks: calling method, results status, system keyboard
  • Web Directory Dialogs

Application Launch

Figure 4-1 Application Launch Framework


This image show the Application Launch framework.
  • The CAL Service is the only process automatically started by the OS when the Workstation boots. At startup, CAL checks to see if any updated packages are available before its launches the autostart apps. Do not install or run any other OS service or daemon process.
  • The CAL service runs applications using the unprivileged 'posuser' account.
  • The CAL allows multiple applications to be launched (for example, ServiceHost and KDS Controller). This is an enhancement from Microsoft Windows CAL which only allows a single app to be automatically launched. However, unlike Microsoft Windows, there is only a single instance of ServiceHost.

Considerations on Oracle Linux for MICROS

  • In Linux, all UI interaction is through a Chromium browser showing POS Operations or the KDS Display in a single X display (there is no Desktop or Windows manager). XAML/WPF is not available.
  • The Linux client uses mySQL (or SQLite, see below) for its database. For the Workstation 5A, Linux computing resources are low, and SQLite operates as a database. Both may restrict possible functionality.
  • Managed 'non-UI' code moves quite well to Linux but it may need review, as Mono is not a 100% implementation of the .Net Framework.
  • Microsoft Windows native code / native DLLs do not transfer directly to Linux.
  • IP network ports lock down but can open for use in cases that need them via custom CAL packages. See the Oracle Simphony Client Deployment Guide for details on opening additional ports. Standard open ports are documented in the Oracle Simphony Security Guide.
  • TLS Certificate handling is different on Linux. See Certificate Handling below for more information.
  • Do not run anything with a root privilege. The POS apps only run as the restricted posuser.
  • Security-Enhanced Linux (SELinux): Enabled by default in Enforce mode.
  • Workstation firewall locked down with ‘deny all’ by default, and a collection of ‘allow’ entries for specific enumerated needs. This includes outbound as well as inbound traffic.
  • Linux does not allow more than one ‘UI’ application to be started; that is, KDS Display and ServiceHost applications cannot run concurrently.
  • There are six Linux virtual consoles available:
    • VC1 and VC2 are reserved for CAL and Simphony.
    • VC3 is reserved for future Oracle use.
    • VC4 through VC6 are available for use by Integrators.
    • VC Switching: During the development process, virtual console switching can be accomplished with Ctrl Alt F1-F6 on a physical keyboard.
  • 64-bit OS:

    Note:

    64-bit BIOS is required. See the hardware upgrade documentation for instructions.
  • There is no native registry on Linux. Mono provides registry emulation using XML files.

Certificate Handling

This section is relevant for Integrators who connect to external TLS endpoints that have non-standard certificate utilization not covered by pre-installed certificates.

Note:

Changing the security posture of the workstation is a privileged operation and must be carefully considered.

Under Microsoft Windows, .NET integrates with the Microsoft Windows certificate store. In Linux, there is no single Certificate Store. Simphony focuses on TLS communications using the Mono framework. Current Mono versions (v6 in our case) use Boring TLS for TLS communications by default, and this has its own Certificate storage and structure. Additional low-level details are out of scope for this document and are not needed for Integrators. The following sections are a summary for the Mono scenario and some others.

Best Practices and Guidance
  • Mono 6
    • Add cert to ‘system’ Certificate Store as below
    • Run Mono utility cert-sync which will synchronize to Mono Store
  • Chromium
    • Obtain Root CA certificate (and intermediate certificate if applicable)
    • Convert to PEM format (use openssl if required)
    • Use certutil to import into NSS store
  • System Certificate Store (assuming suitable CAL permissions)
    • Get Root CA certificate (and intermediate certificate if applicable)
    • Convert to PEM format (use openssl if required)
    • Put PEM format version of the certificate into /etc/pki/ca-trust/source/anchors
    • Run update-ca-trust

Note:

Oracle Restaurants does not recommend the use of self-signed certificates in production workstations.

Standard Linux Considerations

This is a list of notable differences when moving Windows Integrator code to run on Linux:
  • Linux is case-sensitive for paths and file names.
  • Directory separator, use System.IO.Path to generate paths.
  • Runtime directory is different for Linux/Windows.
  • Linux user permissions are locked down more than Windows.
  • Path names use only forward slashes.