Updated: May 8, 2024 2:17pm

Enterprise and Connection Manager Overview

This topic has information about the Connection Manager area of the Prism Administration Console and data replication in general. Data replication is the sending/receiving of data between two Prism servers, for example a store sending transactions to the headquarters or the headquarters sending new inventory to a store. Using profiles, you select the specific types of data to send (customers, documents, inventory, etc.). Initialization is a specific type of data replication that loads a new server with data from an existing server.. 
In the Connection Manager area, you can:

  • Initialize servers with data from the server's Point of Authority (POA)
  • Configure data replication profiles to control what data is exchanged with other servers
  • View lists of sent/received data links

This guide includes: 

  • Background information about the Prism enterprise hierarchy. Understanding how Prism servers are organized makes it easier to understand how data can (and cannot) be replicated among the servers in the enterprise. 
  • Best practices for replication.
  • Join the Enterprise information
  • Initialization information. 
  • Day-to-Day replication information

About the Prism Enterprise Hierarchy
Prism is deployed in a hierarchy, or tree structure, with a single ROOT authority sitting at the top of the hierarchy (e.g., a server at headquarters). In less complex enterprises, individual stores can replicate data directly to the ROOT authority. In more complex enterprises (e.g., more than 100 stores), individual stores replicate data to an intermediate Point of Authority and the POA replicates data with the ROOT. Each server (except the ROOT) must join the enterprise through a Technician's Toolkit process. This structured hierarchy enforces synchronization of data throughout the enterprise.

Prism hierarchy

About the ROOT
A single system serves as the ROOT (or top-level / ultimate) Point of Authority (POA) for the company's servers.

  • Data created at the ROOT flows downstream from the ROOT to POAs and from POAs to stores.
  • Data created at stores flows upstream to POAs and the ROOT.
  • You cannot send data directly from one store to another; data first must flow upstream to the POA and/or ROOT and then downstream to the destination node.
  • By creating "profiles" in Prism Connection Manager and linking those profiles to connections, you control the data that is sent between servers. For example, the store servers will send documents (transactions), customers and other new or changed records upstream to the POA and ROOT. Likewise, the ROOT will send things like new items downstream to the POAs and stores.

About the POA Level
A server's Point of Authority (POA) is the upstream server in charge of enterprise data (from a store server's point of view). In smaller deployments, the ROOT server can serve as the POA for the store servers. Larger deployments typically use an intermediate level of POA servers between the ROOT and store servers. Data is sent downstream from the ROOT to the POAs and then from the POAs to the store servers. Data is sent upstream from the stores to the POAs and then from the POAs to the ROOT. 
About the Store Level
At the store level, create a profile to communicate daily with the POA. When data is created/edited at the store level, it will b communicated up the enterprise chain to the ROOT. Store servers are not allowed to replicate data directly with each other; instead, the data must first flow up the hierarchy to the POA and ROOT and then back down the hierarchy to the target store.
How Connection Manager Profiles Replicate Data throughout the Enterprise
In Connection Manager, you define profiles that specify the data types to send. You then apply the profile to the connection between servers in a specific direction (downstream or upstream). The process of defining profiles and applying them to a connection is explained later in this topic.
Sample profiles and replication flow

Joining the Enterprise
All servers other than the ROOT must join-the-enterprise. Joining the Enterprise adds the server as a new node in the enterprise hierarchy. As part of the JTE process, the user must identify the server's POA. 
Prerequisites for Joining the Enterprise

  • The server must have online connectivity to the POA
  • The user doing the configuration must know the IP addresses or FQDNs
  • The machines must be on the same version number of Prism (e.g., 1.14.7 or 2.0.1; however, different build numbers within the same version are allowed).
  • The Prism ROOT does not join the enterprise. Install and configure the ROOT first and then join servers as subordinate nodes to the ROOT.

Replication Best Practices

  • Use a VPN to connect each side of a connection. RabbitMQ, the messaging program used to replicate data between Prism servers, transmits data in plain text; therefore, it is recommended to use a VPN to replicate data.
  • Install Prism servers from the top down. First, install the ROOT server. Second, install child POAs, join each to the enterprise and initialize with data from the ROOT. Third, install store servers, join each to the enterprise and initialize with data from the appropriate POA.
  • To initialize a node, the node must be on the same Prism version as the POA.
  • Edit the default Controller Name and Controller No of POA and store servers in Tech Toolkit when adding the server. The Controller No of each controller must be unique within the enterprise.
  • To access or edit a node, the server must be up and running.
  • To send data out from a server, you must create a profile and link it to a connection.
  • Nodes can modify the controller data for themselves and any subordinate nodes (in Tech Toolkit).
  • Any node other than the root authority can leave the enterprise; a superior node can remove a subordinate node that is offline via the "Remove Subordinate" option in Tech Toolkit.
  • At the ROOT server, create a separate profile for each subsidiary to prevent each subsidiary from getting overwhelmed with data from other subsidiaries (if the data from other subsidiaries is not needed).
  • Avoid generating unneeded traffic by being careful about what data is replicated and where it is sent. For example, if you turn on replication of all resources at every location, it could cause the replication message queues to back up and prevent data from being delivered in a timely manner.
  • You cannot send documents directly from one store to another. A POA can create documents and send them to stores, and a store directly under the POA can create documents and send them to the POA; however, two stores under a POA cannot send documents to each other without first going through the POA.
  • Certain fields that update quantity and cost are designated as protected fields. These protected fields will update values at a subordinate server when replicated from a POA to a subordinate. When data is replicated from a subordinate to a POA, the protected fields are not updated. See the "Protected Fields" section.
  • For effective communication between web clients and the Proxy, the Proxy should point at a server on the local network. This enables the proxy to fulfill its primary purpose, which is enabling web clients in the POS lanes to communicate with printers and other POS hardware. If you need to change the server to which the Proxy points, first uninstall the Proxy and then reinstall the Proxy, this time pointing to the desired local server.