Skip to main content

UC API - Introduction

Introduction​

The Enactor Unified Commerce (UC) API enables Retailers to integrate custom user interfaces with the Enactor POS while retaining access to its full suite of retail capabilities. Rather than replacing the standard POS behaviour, the UC API exposes common Enactor operations as callable functions, giving Retailers fine-grained control over the flow and behaviour of their point-of-sale applications.

This document provides a complete technical reference for the UC API, covering how extension points, prompts and functions are implemented within the Enactor POS. Retailers can use this reference to integrate the standard UC behaviours into their own solutions and extend them to suit their specific business requirements.

This document is organised into the following sections:

  • Comparison with Existing Customisation Options - Explains how the UC API differs from configuration-based customisation and custom development using the Enactor Framework, and why it may be preferred.
  • Enactor POS Application Lifecycle - Describes the phases of the POS application (Startup, Sign On, Launch, Sale, Tendering, End Transaction) and where UC events integrate into each phase.
  • Enactor Unified Commerce API - Lists the nine UC extension points that are added to the Enactor POS, along with the global data available to each extension.
  • UC Extension Points - Provides detailed specifications for each extension point, including its location in the POS process, input/output data, and integration guidance.
  • UC Prompts - Documents the five standard prompts (Order Collection, Find Order, Find Customer, Find Product, Update Delivery Option), the phases they can be called from, and the functions each prompt supports.
  • UC Functions - A full reference for every callable function, including parameters, output data and error codes. Functions cover product selling, basket management, customer assignment, order handling and delivery options.

Comparison with Existing Customisation Options​

Enactor provides a number of mechanisms to customise the Enactor POS but these are currently limited to the following two options:

  1. Configuration based customisation - This allows a business user to customise the behaviour through the selection of optional behaviours that are enabled/disabled in the Enactor Back Office application. This has the following advantages:

    • It is easy to see what capabilities the Enactor POS provides and from those select which ones are required.
    • No development is required on the part of the Retailer.
    • The behaviours are tested and supported as a part of the Enactor release process.

    However, it is not possible for the Retailer to add new behaviours, or influence the existing behaviours beyond the scope of the configuration.

  2. Custom development using the Enactor Framework - This allows a developer full control on the behaviour of the Enactor POS. They can customise existing behaviours, or add new behaviours as needed. To support this behaviour the Enactor POS provides 'hooks' or 'extension points' that are ready for customisation in a supported way. This is designed on the assumption that the Retailer will continue to use the Enactor POS UI, while potentially extending it with new screen designs to support their new behaviours. The downside of this approach is that it can be difficult to control the flow of existing behaviours without completely replacing them.

The Enactor Unified Commerce API is a solution that parcels up common Enactor behaviours into functions that the Retailer can invoke as needed. While this is similar to the existing Enactor hooks and extension points, instead of requiring the Retailer to integrate with Enactor processes, this API allows the Enactor processes to be called as needed by the Retailer.

Enactor POS Application Lifecycle​

The following diagram shows the application lifecycle of the Enactor POS, and where the new Enactor UC events will integrate:

POS Application Lifecycle flowchart showing the phases from Start through Pre-Sign On, Sign On, Pre-Launch, Launch, Pre-Sale, Sale, Pre-Tendering, Tendering, and End Transaction. Blue circles represent main phases, green boxes represent state transitions and menu prompts.

Enactor POS Application Lifecycle. Blue circles represent the main POS phases. Green boxes represent state transitions (UC extension points) and menu prompts that can be invoked at each phase.

Startup - This phase includes the initial launch of the Enactor POS and covers the activities the POS will complete during the startup process. The Retailer cannot control the startup process of the POS, or add additional UC behaviours here (without using process overrides).

Pre-Sign On - This is a state transition between the Startup and Sign On phases. A UC extension point will be added here so that Retailers can have custom Sign On behaviours. If after completing this extension a valid User has been supplied, the POS will bypass the Sign On phase and navigate directly to the Launch phase.

Sign On - This phase is where the POS will be waiting for the Operator to enter their credentials. This phase will support a subset of the available UC behaviours, i.e. those that are applicable when there is no transaction or signed on user (for example Find Product, without the ability to add to basket).

Pre-Launch - This is a state transition between the Sign On phase, leading to the Launch phase. A UC extension point will be added here so that Retailers can add custom behaviours before the Launch screen is displayed. Note that if the Retailer uses this transition to add items to the basket, the Launch screen will be skipped and will automatically progress to the Sale phase.

Launch - This phase is where the POS will be displaying the Launch screen. In this phase the Retailer can call a number of UC functions. If they do so and then add items to the basket, the POS will automatically progress to the Sale phase upon attempting to return to the Launch screen.

Pre-Sale - This is a state transition between the Launch and Sale phases. A UC extension point will be added here so that Retailers can add custom behaviours before the Sale screen is displayed.

Sale - This phase is where the POS will be displaying the Sale screen. In this phase the Retailer can call most of the UC functions. They will have the ability to progress onto the Tender screen after performing a UC function if required. It will not be possible to return to the Launch / Sign On phase (without first Voiding the transaction).

Pre-Tendering - This is a state transition between the Sale and Tender phases. A UC extension point will be added here so that Retailers can add custom behaviours before the Tender screen is displayed. If desirable, the extension point can be used to redirect the flow back to the Sale phase. If the basket is 'balanced' after the extension completes, then the POS will immediately proceed to the End Transaction transition.

In Tendering - During this phase the Enactor POS will be capturing the Tenders and applying them to the basket. Enactor UC events will not be initially available here, however they may be supported at a later date.

End Transaction - This is the final state transition for a Transaction before it is submitted. A UC extension point will be added here so that Retailers can add custom behaviours immediately before the Transaction is printed and submitted for processing. Once that has been done, the POS will navigate back to the Sale or Launch screen, or will sign the User off, depending on configuration.

Enactor Unified Commerce API​

The Enactor Unified Commerce (UC) API is implemented as a number of extension points that will be added to the Enactor POS. These extension points will then have default implementations that support the standard Enactor UC behaviours. As a result a Retailer can choose to override the standard handling of the UC functions and provide their own implementations.

The extension points used by the Enactor UC API are:

Global Data​

The extensions are only provided data that is available as global data on the Enactor POS. The commonly used global data is summarised below:

Data KeyTypeDescription
enactor.mfc.BaseCurrencyICurrencyThe base currency this terminal is operating in.
enactor.mfc.DeviceIDeviceThe device entity representing the device the terminal is associated with.
enactor.mfc.LocationILocationThe location entity representing the location this terminal is a part of.
enactor.mfc.PosTerminalIPosTerminalThe terminal entity for the POS.
enactor.mfc.TransactionHandlerIRetailTransactionHandlerA handler that is responsible for managing the transaction itself. It will have the transaction available as a property.
enactor.coreUI.UserIUserAn entity that represents the signed-on user.
enactor.coreUI.UserLocaleILocaleAn entity that represents the locale of the signed-on user.