About

Introduction

RedIron built an RIBroker framework to combine the RIBroker functionality with a Web–based interface for viewing, managing the client functionality and viewing the client results. This powerful combination allows for both a broad holistic view off register status and activity (Pulse) as well as extending specific POS level functionality (Enterprise). Retailers use Enterprise to extend a POS application's native functionality to third–party systems. EFT, CRM, E receipts, E Com and Loyalty system integrations are handled with via RIBroker and Enterprise. Enterprise manages the configurations for both the POS system and external hosts enabling the two applications to interact real time. RedIron has focused on extending functionality for many different POS platforms over the past two decades. Enterprise adds a centralized platform to manage and distribute RedIron updates to all registers. Retailers use Pulse to unlock the critical information needed to view performance, stability and consistency to their selling platforms. Retailers can now be proactive and minimizing outages, diagnosing hidden issues and validating solution SLAs. These are key metrics in enhancing the customer experience.

Why was Pulse created?

RedIron has been working with retailers and point sale solutions for over 20 years. During this time, we have worked with many POS systems, developing new functionality and extending functionality through integration to other application or systems.

Over the last 20 years, many things have changed. Modems have changed to Ethernet to WIFI, DOS & OS2 are gone. Many flavors of windows, Java, Cloud are now present. Simple isolated registers are gone. Terminals now connect to many servers.

With all this change, we have found a few things never change.

  • There are always issues.
  • An issue is usually a result of a hidden root cause problem
  • Finding the problem is hard, fixing the problem is easy.
  • The statement “Nothing has changed” is very rarely true. Minor changes are often disregarded or forgotten that could relate to the issue.

We were sure there was a better way to address these truths.

How does Pulse Work?

Pulse is a cloud-based managed service using a thin client that collectively captures and consolidates information from terminals such as POS registers (nodes). Pulse specifically targets retail–centric details with the single objective of optimizing the store–level performance.

Pulse is extremely flexible in targeting varied data outputs and is vendor agnostic. Pulse uses the existing terminal data to proactively capture events and details otherwise uncaptured and lost.

Thin Client

A lightweight client resides on all terminals. The client downloads a configuration profile from the cloud service, executes the parameters of the configuration and uploads the output to the cloud service.

Standardize – version monitoring

A cash register will use multiple vendor software offerings; each software has versions, updates and possible configurations all residing on the register. This can easily run into hundreds if not thousands of files. If the files and configurations are not aligned, a standard behavior is compromised.

Some of the files such as dll files will have a version (part of the compile process), other files like ini or vendor configuration files will not.

  • Pulse’s solution to this problem is to target either a file or a directory and create a HASH value of that target. If the file or content of a directory are identical from any given terminal, the HASH value is the same. Using this approach, Pulse can target a file or group of files on any terminal and use the HASH value to show dll or configuration variances.
  • Pulse can target Windows registry values and WMI objects. For Microsoft operating systems, details about the operating system version, service packs, Java, OPOS, JPOS, .net or C++ on the terminal can now be reported.
Activities – observations and archives

A cash register as a computer will perform tasks that are scheduled or transparent to an operator. Network drops and re-connections, anti-virus scans, POS software data updates (item, promos, taxes), POS end of day. A cash register will also run a POS application with an interactive use for retail functions like Sale, Return, Time Clock, Shipping / Receiving. All these activities tracked or posted in either application logs or an event viewer.

Pulse’s approach is to define a target (log file or event in the windows event log) and a definition of the event as it is natively posted to the target. The target and definition are then exercised on every terminal (node). If the definition is found in the target, Pulse captures that as an observation, along with the corresponding data archive.

  • Observations are a very focused result.
  • Observations are events that happen on the terminal any time the terminal is running.
  • Archives contain the exact details defining the observation.
Client Auto Update:

The Pulse client will download and apply any feature configuration changes or updates published by the Cloud Service. Enabling Auto Update is set at a profile level allowing the retailer to manage Pulse versioning by profile.

Cloud Service
Centralization:

Terminal details, version values, observations and archives are uploaded to the Pulse cloud service.

The frequency is configurable to address different network bandwidths and availability.

Accessibility:

Pulse is accessed via URL and is accessible via computer, tablet and phones via browser.

The Pulse service requires user log in and password.

Users are assigned roles (privileges). The Pulse service supports user and role management.

Visualization:

Pulse Dashboard allows creation, modification and deletion of any number of graphs.

  • Every user has their own dashboard content.
  • All terminal data (observations and versions) is available for viewing.
  • Graphs support multiple data types, selectable time-frames and filtering.
  • Any data type can be shown in bar, scatter or line form and in any colour.
  • Any data point on any graph can be drilled down.
  • Any graph can by dynamically re-sized.
Download Archives:

Pulse observation text is derived from a log, an event viewer or data target collection. This text can be downloaded for just the observation or the full text from all targets. This provides a very detailed context for all activity during that specific point in time.

Daily Summary:

Pulse observations quickly shows a daily count of all observations from all nodes. Observations support a drill down to node and observation details.

Terminal Management:

Pulse Node displays all nodes, last contact time, the profile the node belongs to, profile version and enabled status. Individual nodes can be drilled down for full node detail. Tags (creating or using existing tags) can be assigned to one or more nodes. Nodes can be moved from one profile to a different profile.

Why use Enterprise Pulse?

True Visibility
  • Know exactly what is on each terminal.
  • See all abnormal software or operating system instances.
Accountability
  • Verify SLA times such as EFT transaction processing or End–of–Day processes.
  • Confirm software updates, network availability.
Proactive collaboration
  • Enable third-party accounts access for application archives and log files.
  • Identify areas of optimization with measurable objectives.
Flexibility
  • Pulse targeting for observations and properties is a configuration exercise.
  • While Pulse is targeted for retail fully configurable, creating third-party accounts in Pulse provides access to software archives and log files.
  • Areas of optimization can be identified.

What are the technical elements used on the server side?

  • The server can not initiate any activity with any client.
  • All communication uses TLS 1.2 encryption.
  • The server is a load balanced Oracle cloud instance.

Engagement Process

Terminal Review

RedIron will review the terminal OS & application(s) output to confirm the data targets for capture. If RedIron does not have a lab, RedIron can create a very open configuration to capture all the data output. This data can then be used to confirm the data targets for capture. The targets are confirmed with the customer and the targeted configuration is published.

Data Validation

The published profile exe is installed in select customer terminal locations and data is gather over the next three to five weeks. A joint review of the data is it is presented in Pulse is done to ensure the results are aligned with the expectations.

Deployment

The published profile exe is installed in the remaining production terminals and data is gather over the next three to five weeks. A joint review of the data is it is presented in Pulse is done to ensure the results are aligned with the expectations.

Client Install Process (Pulse or Enterprise)

Client Install Requirements

Enterprise is written using Microsoft .net framework.

  • The Broker client requires either .net versions 3.5, 4.6(+) or 8.0 installed on the register.
  • Clients communicate to the server on port 443; (standard HTTPS port) utilizing TLS 1.2 encryption.
  • The install.exe shell size is approximately 200 KB.
  • The client footprint install is approximately 60 MB including the profile definition.
  • In an operational state, the client will consume 20 to 35 MB of hard drive space as it caches terminal data for server upload. This space is recycled as part of the upload process.
Update Frequencies

The client has three different frequenies to get updates. Choose the frequency that best matches the install scenario and desired usage.

Never

This frequency will bundle an installer shell with the full binary assemblies and configurations needed for operation on a register. A stand-alone frequeny will never communicate to the server for any new updates (configuration setting or binary assemblies).

What are the benefits of this frequency?

  • No network connectivity to the server is required.
  • A retailer can manually control the distribution and installation process to all registers. This is useful if the distribution and installation process has third-party dependencies (such as a POS application update and Broker update that are dependent on each other).
On Restart

This frequency will bundle an installer shell with the full binary assemblies and configurations needed for operation on a register (file size can be 20+ MB). At this frequency the install will communicate to the server for any new updates available (configuration setting or binary assemblies) only during restart of the service.

What are the benefits of this frequency?

  • Connectivity to the server is not required. Configuration and version updates are still managed on the server side.
  • The frequency reduces the network traffic (downloading current binaries and configurations) for the installation process. The retailer can download the installer and push that exe to the registers independent of the install. This will not consume network bandwidth during the installation process. The installation process will call out to the server but will not download any files if the installer is current. Doing this type of installation works well when the installer is downloaded & installed within a short time frame. If the installer is downloaded then configuration changes and binary updates are on the server, the installer will use network bandwidth for the update.
Polling Schedule

This frequency will bundle an installer shell with the full binary assemblies and configurations needed for operation on a register (file size can be 20+ MB). At this frequency the install will communicate to the server for any new updates available (configuration setting or binary assemblies) for every configured time defined in the profile. If the server is not available, the installer will continue to periodically call for these files.

What are the benefits of this frequency?

  • This installer will always use the latest binaries and configurations.
  • If the retailer is creating a golden image and wants to include a broker installer, this is the one to use as it will always get the latest. Note that as part of using a golden image to create registers, that process must ensure the image is on the network when the installer is run.
  • This will always install the latest version, even if an older installer is used. The installation process will call out to the server frequently to make sure the install is alway up to date. This process will not download any files if the installer is current. This means the same installer can be used at any time to do the install as it will always contact the server for the latest.
Installation

Each option requires the installer package to be on the register, which can be run from any directory.

Manual install:

  • Run the exe to launch the user interface.
  • When done, click OK to close the installation pop up.

Silent or Scripted Install:

The install is logged in the event viewer and supports a /q flag for silent installations. The installation process performs the following steps:

  • Starts installation.
  • Unzips the package and contents are logged.
  • The RIBroker service is created and started.
  • The binaries / configuration files are loaded (or downloaded then loaded if not already existing on the client).
  • Applies binaries.
  • Applies configuration settings.
  • Installation completed.

The default Broker client location for the installation is C:\ProgramData\RedIron Technologies\.

Un-Install

When the client is installed, an uninstall.exe file is created. Running this file will remove the broker client files. Running this with a -clean flag will remove the broker client files and http://broker.net service.