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 (X Ray) as well as extending specific POS level functionality (Enterprise). Retailers use Enterprise to extend a POS application's native functionality to 3rd 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 2 applications to interact real time. RedIron has focused on extending functionality for many different POS platforms over the past 2 decades. Enterprise adds a centralized platform to manage and distribute RedIron updates to all registers. Retailers use X-Ray 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.
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 or extending functionality through integration to other application or systems.
Over the last 20 years, many things have changed. Modems 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 other servers.
With all this change, we have found a couple of things never change.
We were sure there was a better way to address these truths.
X-Ray is a cloud based managed service using a thin client that collectively captures and consolidates information from terminals such as POS registers (nodes). X-Ray specifically targets retail centric details with the single objective of optimizing the store level performance.
X-Ray is extremely flexible in targeting varied data outputs and is vendor agnostic. X-Ray uses the existing terminal data to proactively capture events and details otherwise uncaptured and lost.
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.
- X-Ray’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, X-Ray can target a file or group of files on any terminal and use the HASH value to show dll or configuration variances.
- X-Ray can target Windows registry values and WMI objects. For MS operating systems, the operating system version / service packs, Java, OPOS, JPOS, .net or C++ on the terminal are now known.
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.
X-Ray’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, X Ray 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 X Ray 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 X Ray versioning by profile.
Centralization:
Terminal details, version values, observations and archives are uploaded to the X Ray cloud service.
The frequency is configurable to address different network bandwidths and availability.
Accessibility:
X Ray is accessed via URL and is accessible via computer, tablet and phones via browser.
The X Ray service requires user log in and password.
Users are assigned roles (privileges). The X Ray service supports user and role management.
Visualization:
X Ray 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:
X Ray Observation are based derived from text from a log or event viewer. This text can be downloaded. The download can be just the observation or full text from all targets. This provides a very detailed context for all activity during that specific point in time.
Daily Summary:
X Ray Observation quickly shows a daily count of all observations from all nodes. Observations support a drill down to node and observation details.
Terminal Management:
X Ray Node displays all nodes, last contact time, the profile the node belongs to, profile version and enable 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.
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.
The published profile exe is installed in select customer terminal locations and data is gather over the next 3 to 5 weeks. A joint review of the data is it is presented in X Ray is done to ensure the results are aligned with the expectations.
The published profile exe is installed in the remaining production terminals and data is gather over the next 3 to 5 weeks. A joint review of the data is it is presented in X Ray is done to ensure the results are aligned with the expectations.
Enterprise is written using Microsoft .net framework.
- The Broker client requires either .net version 3.5 or version 4.6(+) 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 megs.
- The client footprint install is approximately 60 megs including the profile definition.
- In an operational state, the client will consume 20 to 35 megs hard drive space as it caches terminal data for server upload. This space is recycled as part of the upload process.
The client has 3 different installers. Choose the installer that best matches the install scenario and desired usage.
Stand Alone: A Stand Alone installer bundles the installer shell with the full binary assemblies and configurations needed for operation on a register. A stand alone install will never communicate to the server for any new updates (configuration setting or binary assemblies).
Why do I want to use this type of installer?
- If there is no network connectivity to the server.
- If a retailer wants to manually manage / control the distribution and installation process to all registers. This is useful / desirable if the distribution and installation process has 3rd party dependencies (such as a POS application update and Broker update MUST are dependent on each other).
Off Line: An Off Line installer bundles the installer shell with the full binary assemblies and configurations needed for operation on a register (file size can be 20+ megs). A Stand Alone install will communicate to the server for any new updates (configuration setting or binary assemblies) just in case there are updates available that are not included in the installer.
Why do I want to use this type of installer?
- There is connectivity to the server and I want to use the Server side to manage configuration and version updates.
- Reduce the network traffic (downloading current binaries and configurations) for the installation process. The retailer can download the Off Line installers and push that exe to the registers independent of the install. The installation process will call out to the server but will not download any files if the installer is current. This will not consume network bandwidth during the installation process. 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 behave like the Web installer and use network bandwidth for the update.
Web: A Web installer contains the installer shell, but no binary assemblies and configurations needed for operation on a register. The installer is very small (file size less than 1 meg). A Web install must communicate to the server for the binary and configuration setting needed to complete the install. If the server is not available, the installer will continue to periodically call for these files.
Why do I want to use this type of installer?
- 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 Web installer is run.
- There is no bandwidth concern for downloading the binaries and configuration. This means the same Web installer can be used at any time to do the install as it will always contact the server for the latest.
Copy the installer to the register. The installer can be run from any directory.
Manual install:
Clicking or running the exe will launch a UI based install; click OK to close the installation pop up.Silent or Scripted Install:
The installer exe support a /q flag for silent installations.
The install is logged in the event viewer. The installation process performs the following steps:
- Start installation.
- Unzip package (contents is logged)
- Create / start RIBroker service.
- Load or download binaries / configuration files.
- Apply binaries.
- Apply configuration.
- Installation complete
The default Broker client location for the installation is C:\ProgramData\RedIron Technologies
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 Broker.net service.
