Enterprise and Connection Manager Overview

This topic has information about the Connection Manager area of the Prism Administration Console. The Connection Manager area is where users configure data replication settings.
In the Connection Manager area of the Admin Console, users can:

• Initialize servers with data from the Point of Authority (POA)
• Configure data replication profiles to control what data is exchanged between servers in the hierarchy
• View lists of sent/received data links

This Connection Manager guide starts by giving 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.
Next, the guide lists best practices for replication, basic configuration steps and information about navigating the main areas of the Connection Manager user interface (Connections, Profiles, Initializations).
The next part of the guide has information about initialization. Initialization is a one-time operation that loads a new server with data from its POA and this is when users first need to use Connection Manager. Initialization typically sends all data types; however, larger retailers can use the ExportImportResources.exe tool to do bulk initialization of Inventory, Customers and Documents.
Next, the topic explains "Day-to-Day" replication. Day-to-day replication is used to replicate data from a store server to its POA and from a POA to a store server in near real-time. Unlike initialization, day-to-day replication usually involves sending only the data types required.

About the Prism Enterprise Hierarchy
Prism is typically deployed in a two- or three-tier hierarchy consisting of headquarters (HQ) at the top, an optional intermediate layer in the middle, and individual store servers at the bottom. Smaller enterprises can deploy Prism in a two-level hierarchy with store servers directly under the Prism HQ. Larger enterprises often use an intermediate level of Point of Authority (POA) servers between the HQ and store servers. The POA and store servers join the enterprise through a Technicians Toolkit process. This structured hierarchy enforces synchronization of data throughout the enterprise.

About the HQ Level
A single "HQ" system serves as the root authority for the company's servers.
Data created at the HQ flows downstream from the HQ to POAs and from POAs to stores
Data created at stores flows upstream to POAs and on to the HQ
You cannot send data directly from one store to another; to send data from one store to another store, data first must flow upstream to the POA and/or HQ 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 between servers. For example, the HQ will send documents, customers and other new or changed records can be sent from stores upstream to the POA and root authority. Likewise, things like new inventory items can be sent downstream from the root authority to the POA and stores.
About the POA Level
A server's Point of Authority (POA) is the upstream server in charge of enterprise data (from this server's point of view). Data is sent downstream by the HQ to the POA and then from the POA to the store server(s). Data is sent upstream by the stores to the store's designated POA and then from the POA to the HQ.
About the Store Level
At the store level, create a profile to communicate daily with the POA (Prism-to-Prism). When data is created/edited at the store level, it is communicated up the enterprise chain to the top. 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 then back down the hierarchy to the target store.
Joining the Enterprise
All servers other than the Prism HQ server must go through the Join-the-Enterprise process. Joining the Enterprise adds the server as a new node to an enterprise hierarchy. As part of the JTE process, the user must identify each 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 Prism HQ root does not have a POA and should be installed first

Basic Steps (HQ, POA, Store) for JTE, Initialize and D2D
The basic steps listed here are explained in more detail in following sections.
Prism HQ Server
1.Make sure the machine has a working TCP/IP connection to the server that will be the data source. This may be the root authority or an intermediate POA.
2.Install the full Prism stack (Apache, Prism Server, Prism Proxy). The root authority server machine should be the first server on which Prism is installed (subsequent servers will "join the enterprise" and take their place in the hierarchy under the HQ server).
3.Launch the Prism Proxy using the desktop shortcut and log in.
4.At the root authority, configure any Prism preferences and permissions that you want to propagate to the POAs or store servers that will subsequently be installed.
5.Install subsequent POA or store servers. Join each server to the enterprise and then initialize the server with data from the POA or root authority.
POA:
1. Install the full Prism stack (Apache, Prism Server, Prism Proxy, Prism DRS).
2. Launch Tech Toolkit at the HQ server:
Click the appropriate node in the server hierarchy and select "Add Server." If adding a POA server, select the HQ node and select "Add Server."
On the Identity screen, edit the default Controller Number (default = 1) and Controller Name (default = RPS). The Controller Number must be unique.
On the Verify screen, enter the new server's POA information (the HQ server is the POA for intermediate-level POA servers.
3. Launch the Prism Proxy and configure the following:

• Prism Proxy > Admin Console > Connection Manager > Prism Dashboard > Connections: Select the connection to the HQ server (or appropriate POA) and connect to the server.
• Prism Proxy > Admin Console > Connection Manager > Prism Dashboard > Profiles: Create a Prism-to-Prism profile. This profile will be used to initialize the new POA or store server.
• Prism Proxy > Admin Console > Connection Manager > Prism Dashboard > Initialization: Initialize the POA or store server with data from the HQ (or appropriate POA) using the Prism-to-Prism profile you created.
• Prism Proxy > Admin Console > Connection Manager > Prism Dashboard > Profiles: After initialization is complete, create a Prism-to-Prism profile for Day-to-Day replication of data from the POA back to the HQ.
• Prism Proxy > Admin Console > Connection Manager > Prism Dashboard > Connections: Select the HQ connection and link the Prism-to-Prism Profile to the HQ connection.

4. At each installation, create any additional profiles that will be needed for Day-to-Day replication and link the profiles to connections.
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 HQ (root authority). Second, install child POAs, join each to the enterprise and initialize with data from the HQ. 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 Authority (HQ) 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.