Enterprise Connection Manager

Prism 1.14.7 Connection Manager Guide PDF

Prism 2.0 Connection Manager Guide PDF

This topic has information related to replicating data between Prism servers, including:

• Background information about the Prism enterprise hierarchy structure and how data flows throughout the enterprise
• Requirements for joining a new server to the enterprise
• Steps for initializing a new server with data from another Prism above it in the hierarchy (a "point of authority" or POA)
• Information about creating profiles and assigning them to connections
• Troubleshooting information
• Information about how specific data types are replicated

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 with fewer than 50 stores can deploy Prism in a two-level hierarchy with store servers directly under the Prism HQ. If the enterprise has more than 50 stores, there must be an intermediate level of Point of Authority (POA) server between the HQ and the store servers. The POAs and store servers join the enterprise through a Technicians Toolkit process. This structured hierarchy enforces synchronization of data throughout the enterprise.

  
Enterprise Hierarchy Notes
HQ
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.
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). In a deployment of fewer than 50 stores, the HQ server can serve as the POA for the store servers. Deployments of more than 50 stores require an intermediate POA level between the HQ and store servers. 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.
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, if the enterprise has more than 50 stores, 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 Prism 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:
[Note: Depending on the complexity of the setup, there can be one or more levels of child POAs under the Prism HQ server. If the deployment has more than 50 stores, an intermediate-level POA is required (one POA per 50 stores.)]
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

• 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.

 

Navigating Connection Manager
The Connection Manager area of the Admin Console provides an interface for working with
Connections, Profiles, Day-to-Day replication and Initialization.
The Connection Manager area is divided into a set of dashboards. Select the appropriate dashboard for the task you want to accomplish:

Dashboard	Description
Prism Dashboard	Work with Prism-to-Prism connections, profiles and initializations
Custom Dashboard	Work with custom connections to external systems

Prism Dashboard
The Prism Dashboard is divided into the following tabs:

Tab	Description
Connections	Select the Connections tab to add, edit or remove connections to other Prism servers.
Profiles	Select the Profiles tab to add, edit or delete Prism-to-Prism profiles.
Day to Day	Select this tab to display the results of Day-to-Day replication. For each job, you can drill-down to view failure/success of individual resources and records.
Initializations	Select the Initializations tab to start Prism-to-Prism initialization.

Custom Dashboard

 

The Custom Dashboard is for custom connection activity (e.g. a Prism customization). You can use it for creating custom profiles and viewing results of Day-to-Day replication to and from a custom connection.

Notes
Status reporting for messages on the inbound side only.
Custom connections are not replicated to other systems.
Connection tab will only contain the Prism Connection information.
Profiles Tab contains Sender profiles defined on the Prism side; in other words, sending data From Prism to another system and from another Prism system to this system.

Initialization, JTE and D2D Replication
About Initialization
Initialization is the process of loading a new Prism server with data. In the case of a POA or Store server, the data comes from an existing Prism server. Typically initialization is a one-time process, done at the time of install. The amount of time required to initialize Prism will depend on the size of your database, especially the size of inventory and customers. The larger the data set, the more time is required. Please set aside enough time for initialization to complete. Initialize servers in the proper order, starting with the PrismHQ server at the top of the hierarchy and then POAs, and then store servers.

 

Delete Batch
If you need to delete an initialization, make sure that the initialization message queue has finished processing and then click the Delete button. If you delete an initialization while it is still processing, some messages will be stuck in the queue. A confirmation is displayed. Click Yes.

Failed/Stopped Initializations
Initialization can take a long time for larger databases and can sometimes fail to complete successfully. If an initialization fails or is stopped for whatever reason:
Create a new Sender profile that starts from the resource after the last COMPLETED resource. For example, if the initialization was in the middle of the Inventory resource when the failure occurred, the new Sender profile should include Inventory and the rest of the resources to the bottom of the list. Run initialization again using the new Sender profile.
When you create a new Sender profile and restart, it may take a while to process the first resource (the resource that was being initialized when the failure occurred). This is because the program must do a slower UPDATE operation on each of the resource's records that are already in the tables. Once the program finishes the updates and reaches the unprocessed records for the resource, it switches to the much faster INSERT operation. There currently is no way to restart a failed/stopped initialization from the specific point of failure. The entire resource in which the failure occurred must be sent again.

Restart PrismMQ after Deleting Replication Records
The key service involved with replication, PrismMQ, caches records aggressively to improve performance. If the record is in the cache, it is assumed that the record exists and PrismMQ doesn't need to confirm its existence in the database. This is usually not a problem; however, it can become a problem if you have deleted replication-related records (e.g. replication status) from tables while troubleshooting. The record you removed as part of your troubleshooting efforts may still be in the cache. Therefore, you should restart PrismMQ as soon as possible after deleting replication-related records. Restarting PrismMQ will clear the cache.

Join the Enterprise
Join the Enterprise refers to the process of adding a new server to the existing enterprise hierarchy. All servers except for the root authority (HQ) server must join the enterprise before initialization. The server being added must have online connectivity to the POA to manage enterprise data or use enterprise features and the user doing the setup must know the IP Address, FQDN or hostname information for servers. All servers other than the Prism HQ server must go through the Add Server/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.
The server must have online connectivity to the POA and the user doing the configuration must know the IP addresses or FQDNs.
1.    At the HQ server machine, launch. To access Tech Toolkit, enter the following in the browser address bar: /TTK
A list of prism servers is displayed on the left side of the screen. If this is the first POA server and it is yet to join the enterprise, only the HQ's own server will be listed.
Highlight the server and click the hamburger icon. Select Add Server.

2. On the Identity screen, enter the IP Address or FQDN of the server that is joining the enterprise. Enter the username and password that will be used to connect to the server.
Click the arrow button to proceed.

 

3. Prism will attempt to connect to the new server. Notice that the Controller Number and Controller Name match the Installation Defaults entered on the POA1 server.
On this screen, you can edit the Controller Number and Controller Name, if needed.
Click the arrow button to proceed.

4. When you click the arrow button, the JTE process starts.
As part of the JTE process, core resources are imported. The core resources are certain basic resources that are required for initialization. When the initialization of Core Resources is finished, click the checkmark button to finish.

 
The server you added is now listed in the menu. The new server's listing is indented to show that is located under the HQ server in the enterprise hierarchy.
 

Day-to-Day Replication
Day-to-Day (D2D) Replication refers to the sending of data on a regular basis between servers. Unlike initialization, which is typically a one-time operation that sends all available data downstream, Day-to-Day replication occurs on a regular basis, in each direction, and sends only the needed subset of data resources.
D2D replication is carried out by creating one or more profiles that include the desired resources and then linking each profile to the correct connection. When creating profiles for D2D, you select the specific data types needed by the receiving location. This reduces overhead and replication times. Resources that are unlikely to change, like Departments or Vendors, can be excluded, or sent only occasionally. You can use the Advanced Filters feature to apply fine-grained control over the specific records that are replicated.
When a server joins the enterprise, Prism performs a type of mini-initialization and copies a group of resources known as the core resources from the POA to the subordinate system. The core resources are resources that are required for initialization to take place. As a result, when you go into the Profiles area on the Prism Dashboard, you will see a Core Resources profile already exists. The core resources profile is read-only and by default is not included in Day-to-Day replication.

Prism Dashboard - Day to Day Tab
The Day-to-Day tab is split into two sub-tabs: Completed and Pending.
The Completed tab displays a list of the day-to-day replication records for the server. For each resource, you can see the number of records sent, received, and the number of failed records. When you drill down, it shows the messages that have been completed (i.e. put on the message bus).
The Pending tab shows messages that are in the process of being put on the message bus.
If you click a connection (server), it shows summation information of all pending messages in the queue for that server that are Pending and IN Process for delivery to the bus. You can select a server to drill down to the list of resources sent. With a resource selected, you can then drill down to view individual SIDs.

Element	Description
	Records that have been sent to this server.  Click the link to display the list.
	Records that have been sent from this server. Click the link to display a list of the records sent from this server.
	Errors. Click the link to display the list.
	A green arrow pointing up indicates the server is currently up. A red arrow pointing down indicates the server is currently down.
	When several servers are available, you can filter the list. Type the name of the machine. Click the icon to filter for only servers with errors.
	Click the link to refresh the server list.
	Shows the total number of links sent to this server and the number of errors.
	Displays the number of batches included in the replication results.

The data in the Identifier and Status columns is a link. The Date is the date of the initialization, not the date the record was created or updated.
If you click in the Identifier link it will take you directly to view the data which was sent. This view will show the last modified date/time for the record.
If you click on the Status link it will simply show the message in the status line.  This is useful if there is a long message which cannot be seen completely within the width of the status column.

Connections
To replicate data between two Prism servers, the servers must establish a TCP/IP connection. Data is replicated according to the instructions specified in the profile assigned to the connection. Each end of the connection can use a different profile when replicating data to the other end of the connection.
How do servers establish a connection?
When adding a server to the enterprise, the user must enter the IP Address or FQDN of the server's POA. The JTE process creates a connection between the server and its POA and copies core resources to the new server.
Linking Profiles to Connections
Connections are listed on the Connections tab of the Prism dashboard. If the Connected Only checkbox is selected, only connections to servers that are up and have a working connection are displayed in the list. To view the profiles associated with a connection, click the connection. The profiles involving that connection (in each direction) are displayed. For data to be sent via a connection, the Linked checkbox must be selected. Selecting the Linked checkbox links the profile to the connection. If you want to stop sending data, clear the Linked checkbox. Note: More than one profile can be linked to a connection in each direction.

Connection Fields

Field	Description
Connected	If selected, indicates the connection is established and currently connected.
Active	If selected, indicates the connection is active and available for use.
Remote Address	The IP address of the other side of the connection.
Remote Description	A description of the other side of the connection. By default, displays the IP address of the server on the other side of the connection, but can be edited.
Local Address	The IP address of the user's server.
Local Description	A description of the local machine's part of the connection.

Prism Dashboard - Connections tab
The Connections tab displays the server's connections to other servers. The Remote Description column lists the individual Prism servers installed. The Remote Address column lists the FQDN or IP Address of the machine. You can filter the list by typing a remote name or number into the Filter text field. Each connection must have a profile assigned on both the Send/Receive sides. You can select the Connected Only checkbox to view only servers that are currently connected. Click the Show Un-Linked link to display unlinked profiles.

Filter by Remote Description
You can type the name of a Remote connection in the text box to automatically filter the list of connections. This is especially useful when there is a long list of connections.

Display Connected Only
By default, only connections for connected installations are displayed. If you clear the checkbox, any unconnected installations are displayed, too.
Creating Connections to other (non-POA) Machines
There is no restriction as to the connections you can create. If you have credentials to another system, you can create a connection to it. At a store server, the connection to the POA is all you need to replicate data to other systems in the enterprise.

Profiles
A profile specifies the resources that will be replicated from one end of a connection to another. There are three types of profiles that you will work with. The dashboard you are using determines which profile types are available.

Profile Type	Description
Prism to Prism	For sending data from one Prism server to another Prism server. Available on the Prism dashboard

To replicate data, you must link a profile to a connection. Only linked profiles are used for replicating data. If a connection does not have a profile linked for one or both directions, data will not be sent in the unlinked directions. You can define one profile that specifies the data that is sent from Store 001 to its POA, and a different profile for data sent in the opposite direction, or you can reuse the same profile. You can define as many profiles as needed. The important thing is that you link a profile to each side of the connection.
You can specify which subsidiaries are included in Profiles. You can select any or all Subs. If you select All Subs, then all Subs that currently exist will be selected, AND ANY SUBS ADDED IN THE FUTURE. Selecting this option helps ensure that any new subs added to the company are included when replicating data using the profile. Keep in mind that when this option is selected, any new subs will be added automatically. If this is a concern, then you can select the individual subsidiaries.
You must add the profiles you want to use for initialization and the profiles you want to use for day-to-day.
It is important to select the correct resources for profiles. Make sure you understand the data types you want to replicate so you can include the appropriate resources in the profile.

Copy and Import Profiles
Users can copy an existing profile, create a new profile at the desired location, and import (paste) the contents into the new profile. In early versions of Prism, users had to create profiles at each location. This process was tedious and error-prone. Now, users can copy an existing profile and then import (paste) the contents into a new blank profile at a different location. The only restriction is that the profile being created must be of the same type as the copied profile. This enables a user at a central location to create profiles and then assign the needed profiles to individual locations. This simplifies the profile creation process and helps ensure consistency.
When you display a profile in edit mode, at the bottom of the screen is a Copy button. Click the Copy button to copy the profile's contents to the clipboard.

Next, start a new profile of the same type that was copied. At the bottom of the Create Profile screen is an Import button. The Import button is only available if you are creating a profile of the same type (e.g. Prism-to-Prism). 
If you click the Import button, the contents of the copied profile (except the Name) are copied into the new profile.  
 Enter a Name for the new profile. Make any other needed changes. Save the profile.
Add/edit/delete profiles on Connection Screen
Previously, a technician would use Remote Desktop to go into each individual server to create/edit the profile. This was very time consuming and added significant support costs to Prism deployments.
Profiles can be created, edited and deleted from the connection screen.

Button	Description
	Create a new profile. This shortcut launches the Create Profile dialog for the type of connection you are working with.
	Select the checkbox to link the profile to the connection. Clear the checkbox to unlink the profile.
	Edit the profile.
	Delete the profile.

Notes

• When a profile is linked, the delete button is disabled
• Delete and edit functionality are disabled for internal profiles (core resources)
• When creating or editing a profile from the connection screen, the profile type is auto-detected based on the server and connection type

Advanced Filters
Advanced filters allow you to apply logic to return only certain records from the server. The basic syntax for a filter is (ATTRIBUTE,OPERATOR,CRITERIA). The attribute is the name of the attribute to search in, the operator provides the type of comparison, and the criteria is the value to look for.

Available Comparison Operators
The current operators you can use in a filter are as follows:
•    EQ - Equal to
•    NE - Not equal to
•    LT - Less than
•    GT - Greater than
•    LE - Less than or equal to
•    GE - Greater than or equal to
•    NL - Is null
•    NN - Not Null
•    LK - Like

Exceptions

While most of these operators use the pattern mentioned above, there are a couple of exceptions.
•    In Inventory, the Active flag is not true false but rather 0, 1. Your filter will therefore need to be modified to say (active,eq,1) not (active,eq,true).
•    NL and NN do not accept a criteria element e.g. filter=active,nn
•    LK filter uses a as a wildcard. For example s matches all entries starting with s
Resource Filter Examples
Note: The filters are not case- or space-sensitive.

Example	Description
(Active,eq,true)	Send active customers
(Active,ne,true)	Send inactive customers
(Cost,le,4.50)	Send inventory items with a cost less than or equal to 4.50
(AdjNo,gt,200)	Send adjustment memos with an Adj No value greater than 200.

Compound Filters
Compound filters can also use AND and OR clauses with parenthesis to establish grouping. e.g. (FirstName,eq,jack)AND(LastName,eq,harkness)

Filtering Documents by Subsidiary
Here's an example of filtering documents by subsidiary for Prism Day-to-Day replication.

1. Create a new filter in Connection Manager.    
2. For the filter, select the Document resource.    
3. Click the Advanced Filter link.    
4. Enter a filter for the subsidiary whose documents you want to send. (sbsno,eq,2)    
5. Click the Back button and then save the profile.     

Core Resources
The core resources are resources considered to be core and not necessarily part of the standard day-to-day traffic. Generally they are defined as those resources that would be replicated from the POA to its members, but not necessarily back to the POA from a member. The following are the core resources: Controller, Tenant, Subsidiary, CustomSchema, Transformdesign, Season, TaxArea, PriceLevel, Currency, StoreType, Store

• Core Resources must be selected for Prism Day-to-Day replication
• When creating initialization profiles, the Core resources must be explicitly added if desired

The best and easiest way to correct replication , is to edit your D2D P2P profiles. Add Core Resources, select ALL resources, then uncheck: Controller, Customschema, Store, Subsidiary, Tenant, TransformDesign, Subsidiary, Tenant and Transformdesign. This is because they are already in the un-editable ‘CoreResources' profile.
Core resources replicate in both directions.
Central Resources
When creating a new profile, you will see a check box for Central Resources. The only resource included in the Central Resources is ltycustcentral. If you are using customer loyalty, you will need to create a profile that includes the central resources and initialize stores using that profile.
Create Profile screen showing central resources (ltycustcentral resource):

You can specify which subsidiaries are included in Profiles. You can select any or all Subs.
If you select All Subs, then all Subs that currently exist will be selected, AND ANY SUBS ADDED IN THE FUTURE. Selecting this option helps ensure that any new subs added to the company are included when replicating data using the profile. Keep in mind that when this option is selected, any new subs will be added automatically. If this is a concern, then you can select the individual subsidiaries.

Review, Troubleshoot Replication
Use "Show Successful Records" setting for troubleshooting only
By default, the successful records sent during replication are not preserved. This helps keep hard drives from getting filed with the files. However, during troubleshooting and other times, you may want to change this setting so that you can drill down and see individual records. The default value for Show Successful Messages is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to True, large quantities of unneeded data (sometimes millions of rows) could be preserved. Therefore, the setting should only be changed to True when doing troubleshooting. Before Initialization, edit the PrismMQService.ini file so that the PreserveSuccessRecords setting is set to TRUE and select the Show Successful Messages checkbox on the Prism Dashboard > Initializations screen.

Reprocess Errors
If any errors occur during initialization, you can correct the problem and then reprocess the specific links that failed. You can click a server's link to drill down to view more information.Click the column header to sort the list by the Failed column. This brings the errors to the top of the list.  Next, go into the resource with the errors. Select the individual elements you want to reprocess and the click the Reprocess Selected button. If you click the View button, you can see details about the selected resource. You can see a lot of info on this screen, so scroll to the right to display more columns.
If Replication, Initialization Fails or is Stopped
If replication services are interrupted (reboot, computer freezes), Day-2-Day replication will resume where it left off. Initialization can take a long time for larger databases and unfortunately, initialization can sometimes fail to complete successfully. If an initialization fails or is stopped for whatever reason, here is what you should do:
Create a new Sender profile that starts from the resource after the last COMPLETED resource. For example, if the initialization was in the middle of the Inventory resource when the failure occurred, the new Sender profile should include Inventory and the rest of the resources to the bottom of the list. Run initialization again using the new Sender profile. When you create a new Sender profile and restart, it may take a while to process the first resource (the resource that was being initialized when the failure occurred). This is because the program must do a slower UPDATE operation on each of the resource's records that are already in the tables. Once the program finishes the updates and reaches the unprocessed records for the resource, it switches to the much faster INSERT operation. There currently is no way to restart a failed/stopped initialization from the specific point of failure. The entire resource in which the failure occurred must be sent again.
Pause/Resume Initialization
You can pause/resume the initialization process. You cannot pause the Sender, but each downstream system that is consuming the resources being sent can be paused and/or resumed.
There are some key properties in the PrismMQService.ini file that are related to this feature. These properties are set to True by default. The user will need to change to false if they don't want the performance hit.

[PRISM]
INITGUARANTEEDMESSAGEDELIVERY=True
RESUMEINITONSTARTUP=True

[V9]
INITGUARANTEEDMESSAGEDELIVERY=True

By setting ResumeInitOnStartup to true if a consumer does down during an initialization, when it is restarted it will resume initialization automatically. In tandem with this property the user must also set the INIGUARANTEEDMESSAGEDELIVERY to true on the sending server for whichever initialization type he wants to guarantee that if RabbitMQ goes down that no messages are lost.
Here's a typical situation when this setting can be used: Lets say you start an initialization and realize the consumer's 20 thread default is too low for the power of the machine. Now, you can pause that consumer, change the thread count and then resume the consumer. Initialization will pick up where it left off with the new thread count. If a consumer stops responding for some reason, when PrismMQ restarts, the initialization can resume either automatically or manually by the user.
In contrast, if GMD is set to False, then some messages may be lost if there is a RabbitMQ Failure (not just a PMQ failure). In such a case, even a restart of initialization will likely get stuck and not finish, and the initialization will have to be cancelled and restarted from the last completed resource.
Slower Initialization when using INIGUARANTEEDMESSAGEDELIVERY
When turning on GMD for a system that has both sender and consumer on same system will slow down initialization somewhat for this system and any others that might be included in an initialization batch with this system. If these properties are set to false then Pausing and resuming will still work as long as RabbitMQ on a given consumer does not go down.
Cancel or Delete Batch
You can cancel or delete a batch. The buttons to cancel or delete a batch are available on the View Initialization tab. These buttons enable technicians to kill initialization for one or more servers. This saves technicians from having to wait until the entire initialization runs to completion.

• If you cancel an initialization batch, all running initializations will be stopped.
• If you delete an initialization batch, all messages currently in the queue will be lost.

 
Sent and Received Messages
The Sent Messages and Received Messages area enables you to drill down the replication hierarchy and view replication information by resource or even by individual record. Click a server's link to drill down to view more information. Click the column header to sort the list by the Failed column. This brings the errors to the top of the list.
Next, go into the resource with the errors. Select the individual elements you want to reprocess and then click the Reprocess Selected button.
If you click the link, you can see details about the selected resource.
Initialization Guaranteed Message Delivery
This setting is typically only used during troubleshooting. If enabled, PrismMQ takes special steps to ensure that no messages are lost if there is a RabbitMQ failure. If Initialization Guaranteed Message Delivery is set to False, then some messages may be lost if there is a RabbitMQ Failure (not just a PrismMQ failure). In such a case, even a restart of initialization will likely get stuck and not finish, and the initialization will have to be restarted from the last completed resource.
If you enable Init Guaranteed Message Delivery, then you also should enable Resume Init On Startup.  
By setting ResumeInitOnStartup to true, if a consumer does down during an initialization, when it is restarted it will resume initialization automatically. In tandem with this property the user must also set the INIGUARANTEEDMESSAGEDELIVERY to true on the sending server for whichever initialization type the user wants to guarantee that if RabbitMQ goes down that no messages are lost.
There is a performance hit to using this setting. These properties are set to False by default. After changing the properties to True and doing troubleshooting, the user will need to change InitGuaranteedMessageDelivery and ResumeInitonStartup to False to avoid the performance hit.
Here's a typical use case: Let's say you start an initialization and realize the consumer's 20 thread default is too low for the power of the machine. You can pause that consumer, change the thread count and then resume the consumer. Initialization will pick up where it left off with the new thread count. If GMD is set to False, then some messages may be lost if there is a RabbitMQ Failure (not just a PMQ failure). In such a case, even a restart of initialization will likely get stuck and not finish, and the initialization will have to be restarted from the last completed resource. Turning on GMD for a system that has both sender and consumer on same system will slow down initialization for this system and any others that might be included in an initialization batch with this system.

Here are the how you should configure the settings for both the PrismMQService.ini file.
[PRISM]
INITGUARANTEEDMESSAGEDELIVERY=True
RESUMEINITONSTARTUP=True

Adjust Customer History Process for High Volume Locales
If you will be operating Prism in a high-volume environment in which all or most of the customers are defined customers in the database, special configuration is required to ensure that Customer History is processed more quickly than the default setting of once every 15 minutes. In a high-volume environment, when using the default Customer History settings, transactions will accumulate before the next processing. By setting the processing timer to a smaller value, e.g. two minutes or five minutes, customer history will be processed more quickly, preventing the build-up of unprocessed transactions.
Launch Technician's Toolkit. On the top toolbar, click the Scheduler icon.  
Navigate to the Schedule Manager area. Locate the Customer History Daily Process.
Right-click in any cell and select Open Form View.
In the displayed Form View, navigate to the Repeat Every (minutes) field. The default setting is 15, which means the process is run every 15 minutes. Change it to a smaller value, such as 2 or 5.
 
•    High Volume POS transactions for CH purposes means transactions with customers that have an account. If half of the transactions are to customers without an account with the store, CH processing ignores those when fetching documents to process - so no impact on memory.
•    When setting Repeat Every to a lower number, Days of Run History should be reduced to 2 or 3 so that Prism is not storing needless thousands of run history records.
•    These edits can also be made directly in the Scheduled Task grid.
•    Default Start & End Times should be tweaked per store business hours. Otherwise CH will run needlessly and create task run records.

Leave the Enterprise
Warning: Extreme caution must be used when leaving/rejoining the enterprise. If a server leaves and then later rejoins the enterprise, the server must rejoin in exactly the same position as it was in before. The Prism controller hierarchy, which provides the way to track all activity within an enterprise, can be easily disrupted by servers leaving and then rejoining the enterprise in a different position. In other words, once the enterprise structure has been set, it shouldn't be rearranged. Therefore, carefully consider the desired server hierarchy before installing servers.
Administrators can leave the enterprise. This sometimes is necessary due to store closings or changes in the corporate hierarchy. Leaving the enterprise will remove records from the POA and local machine. Later, the machine can rejoin the same POA, if desired. This enables retailers to adapt to changing circumstances while maintaining the integrity of the replication hierarchy.
Neither removing or leaving will change the v9 connection. This can be done manually in the Connection manager in AC. Removing a server from the enterprise is intended for the case when a machine is down and will not be brought back online. If a machine will be brought back online then the recommended practice is to bring the machine back online and leave the enterprise.
When a remote leaves the enterprise (or is removed from the enterprise by the POA), care must be taken to avoid errors. We recommend that you disconnect the machine from the network first, and then leave the enterprise at the remote. If the machine is connected to the network, it will try to communicate with the old POA.
Leaving the Enterprise Rules and Notes
The v9 connection is left in place. You must manually remove this connection. If you don't remove the connection, data may continue to be sent from the Prism server to the old POA.

• Unless otherwise noted, all the data from the enterprise remains on both sides of the separation.
• The Controller records for the opposite side of the separation are Archived.
• The Remote Connection records connecting each side are deleted

If a server leaves (or is removed from) the enterprise, the server must be configured for a new POA with which it will communicate. This includes:

1. Disconnect the machine from the network first. If the machine is connected to the network, it will try to communicate with the old POA.    
2. Go into the Prism Technician's Toolkit.    
3. Select the connection that you want to leave the enterprise.    
4. Click the Leave the Enterprise button.    
5. Enter login credentials for this server's POA. Click OK.    
6. Delete the old POA connection. Add a new connection to the new POA Oracle server. 
7. Edit the Default Address in the Installation Defaults area of preferences.    

Remove Subordinate Server
If a server is forcibly removed (in other words the subordinate is not online for some reason) the proper recovery if the remote system either:
Is brought back up and desires to remain independent of the enterprise (it has no knowledge that it left the enterprise
It is desired to restore the system to the enterprise
(Note: If the system will be offline permanently, no action is needed)
SCENARIO:
1. An enterprise is set up.
2. A subordinate server in the enterprise goes down.
3. At the Root Authority, it is determined that the best course of action is to remove the subordinate (e.g. because the server will be down for an extended time).
ACTIONS:
At the down servers POA, Remove the powered-down Server from the enterprise.
IF DESIRED FOR THAT SYSTEM TO RE-JOIN ENTERPRISE AT A LATER DATE:
At the Removed system, log into TTK, it will show the former enterprise tree (since the system has no knowledge it has been removed from the enterprise)
At the Removed system, log into the subordinate server's former POA (this is required for the next step).
At the Removed system, select the menu icon associated with the local Server (the removed subordinate server) and select Remove. Now the enterprise tree will correctly reflect that this system is not attached to an enterprise.
At the POA which this server will re-join, follow the "Add Former Server" process,

Rejoin the Enterprise
If a server identity file was saved (see previous section), then you can reference the file when reinstalling Prism. Using the Server Identity file ensures that the correct Controller, Subsidiary, Store and Tenant table records can be used.
After reinstalling Prism on the machine using the Server Identity File, launch the Tech Toolkit.
Select the hamburger icon for the desired node and select Re-Join the Enterprise.

Protected Fields
At the HQ or POA, certain fields that are important to tracking inventory and customer values can only be modified by documents (cannot be manually edited). This protects the integrity of inventory valuations and customer balances and ensures that the values are not overwritten during Day-to-Day replication. In Prism, we refer to these fields as Protected Fields.
When replicated from a subordinate to a POA DOES NOT OVERWRITE the key fields at the POA.
When replicated from a POA to a subordinate, the files DO OVERWRITE the key fields at the subordinate.
The following tables list the protected fields in inventory and customer records.
Customer table:

CreditLimit	CreditUsed	StoreCredit
FirstSaleDate	LastSaleDate	LastReturnDate
LastSaleAmt

Invn_Sbs_Item table:

FirstRcvdDate

LastRcvdDate

LastSoldDate

Invn_Sbs_Price table:

Price

Invn_Sbs_Qty table

Qty	TransferInQty	TransferOutQty
SoldQty	RcvdQty	OnOrderedQty
ASNInTransitQty	LatOnHandQtyDate	ToInOrderedQty
TOInSentQty	ToOutOrderedQty	ToOutSendQty
PoOrderedQty	SoOrderedQty	SoSentQty

RabbitMQ
The PrismMQ service plays a key role in data replication. PrismMQ, built upon the familiar RabbitMQ messaging platform, facilitates the processing of data from system to system.
This section of the document provides information about PrismMQ configuration settings and using the RabbitMQ administration console to monitor messaging activity.
PrismMQ Caching Behavior and Troubleshooting Considerations
PrismMQ, caches records aggressively and therefore does not always check the database to confirm whether a particular record actually exists. If the record is in the cache, it is assumed that the record is in the database. This aggressive caching behavior can become a problem if you have deleted replication-related records (e.g. replication_status) from tables while troubleshooting. In that case, the record may still be in the cache even though the record is deleted from the database. If the record is still in the cache, Prism assumes it is still in the database. Therefore, you should restart PrismMQ as soon as possible after deleting replication-related records. This will clear the cache.

Server Mode
The Server Mode configuration option for the PrismMQ service helps improve performance for high-performance, multi-CPU systems (four CPU cores or more) when high-throughput and increased processing power are needed. For example, during initialization, the server is trying to quickly import and process many records; however, Windows default power management settings can end up throttling performance on high-performance machines. Server Mode enables you to bypass some of these default Windows power management settings so that servers can make more efficient use of available computing resources.
Enabling Server Mode results in increased CPU usage. We recommend that you only enable Server Mode when it is needed and then disable it when no longer needed.

Limitations
Limited to systems with four CPU cores or more.
Server Mode is intended  If you use the same machine as both a server and a workstation, then you probably shouldn't use Server Mode. The Server Mode feature is meant for machines dedicated for use as a server.
Intended for use on a temporary basis during times when increased processing power and throughput are needed.
Server Mode is one of the configuration options for the PrismMQ service. The PrismMQ Service controls many settings related to replication, including the number of threads available during replication.
By default, the thread counts for Prism and V9 Day-to-Day and Initialization are set to half the CPU Count (CPU Count / 2). This setting ensures that Prism doesn't consume too much of the CPU power when it is first installed.
When Server Mode is enabled, the maximum thread count for Prism and V9 Day to Day and Initialization is set to one less than the total number of CPU cores (CPU Count - 1). Consumer threads will spin up as needed and spin down when no longer needed.
If you later disable Server Mode, the thread counts will be reset to the defaults. (Five threads for Day to Day, 20 for initialization). To enable Server Mode, edit the PrismMQ configuration file in the Service Manager area of Tech Toolkit. The Server Mode checkbox is found toward the bottom of the configuration screen, in the "General" area.

Compression Threshold
The PrismMQService.ini file has a Compression Threshold parameter that helps avoid problems when replicating large files, such a large Promotions file. The Compression Theshold parameter has a default setting of 100KB. This means that any payload greater than 100KB will be compressed.  Setting the parameter to "0" will turn off compression. A typical 10MB file will compress to about 200KB.

Resume Initialization at Startup
If you set ResumeInitOnStartup to true, then if a consumer does down during an initialization, when the consumer is restarted it will resume initialization automatically. VERY IMPORTANT: In tandem with this property the user must also set the INIGUARANTEEDMESSAGEDELIVERY to true to guarantee that if RabbitMQ goes down, no messages are lost. For example, if you start an initialization and realize the consumer's 20-thread default is too low for the power of the machine. You can now pause that consumer, change the thread count and then resume the consumer and it will pick up where it left off with the new thread count. Also, if a consumer goes down for some reason or stops responding for some reason, when PrismMQ restarts Initialization can resume either automatically or manually by the user. IF GMD is False then some messages may be lost in the event of a RabbitMQ Failure (not just a PMQ failure) and even a restart of initialization will likely get stuck and not finish, and then have to be cancelled and restarted from the last completed resource. NOTE: YOU CANNOT PAUSE THE SENDER, BUT EACH DOWNSTREAM CONSUMER SYSTEM CAN NOW BE PAUSED AND OR RESUMED.

Replication of Specific Data Types
The following table has notes about replication of specific data types.

Data Type	Replication Notes
address types	The "addresstypes" resource replicates the address types defined in Admin Console > Node Preferences > Data Types.
adjustments	The "adjustments" resource replicates adjustment memos (quantity, price, cost) and is available on all profile types.
allocation patterns	Allocation patterns are replicated using the "allocationpattern" resource.
asn vouchers	ASN vouchers are replicated using the receiving resource. The receiving resource sends both ASN vouchers and vouchers. Shipping package numbers and other batch receiving information replicates as part of the ASN voucher.
biometrics	The "biometric" resource replicates biometric login information. Two database columns play a key role in biometric login: user_name and empl_name: The EMPLOYEE table includes user_name and empl_name columns. The BIOMETRICS table includes empl_name column. The user_name column is unique across all subsidiaries. When a user does a regular log in using user name and password, the server looks in the EMPLOYEE table and tries to find a matching record. The employee resource is a core resource and cannot be filtered or excluded from replication. As a result, you can use the user_name and password of any employee and login to Prism at any store. The empl_name column is unique within a single subsidiary. When a user logs in using a fingerprint, the server first looks in the BIOMETRICS table and retrieves the empl_name and sbs_sid. The server tries to match the retrieved information with a corresponding empl_name and orig_sbs_sid in the EMPLOYEE table. If a match is found, the server uses the user_name and its password from the EMPLOYEE table for the login. The biometrics resource is not a core resource; therefore, you can apply a filter or simply not replicate the resource. If you want to filter your data by subsidiary but still want all fingerprints to be replicated you must create a separate profile that only includes the biometrics resource and do not apply any filter to it. The rule is: empl_name + orig_sbs_sid from EMPLOYEE table MUST match empl_name + sbs_sid from BIOMETRICS table. Therefore when you create a biometrics record, you should pass empl_name and sbs_sid equal to empl_name and orig_sbs_sid (important! Not employee sbs_sid but employee orig_sbs_sid) of the employee who you are creating the fingerprint for. This resource is only available for Prism-to-Prism profiles.
calendar	This refers to the retail calendars used for reporting purposes.
charge terms	The "chargeterm" resource replicates customer charge terms (used on receipts tendered by Charge).
comment	[needs research]
coupon sets	Use the couponset and couponsetcoupon resources.
country	The "country" resource replicates countries.
currency	The "currency" resource replicates the currencies added or edited in Admin Console > Global Preferences > Currency > General.
customer	The "customer" resource replicates customer information (except UDF, loyalty information, class and store credit, which are handled by separate resources).
customer class	The "customerclass" resource is available on Prism-to-Prism profiles.
customer document history	In Prism, certain key data about each transaction and its items is stored as part of the customer record. This data is replicated along with the customer record. If a customer is available at an installation, then the customer history will be available, too, although the full document may not be. If a user wants to view a document that does not exist locally, then the document will have to be viewed at the POA (or the document can be replicated separately). If you want to view a document that does not exist locally, make sure the customerdocumenthistory resource is selected. The "customerdocumenthistory" resource is available on Prism-to-Prism profiles.
customer loyalty	customer: Included in the customer resource: customer loyalty point balances and customer loyalty levels. Make sure the customer resource is replicated to the Loyalty server. inventory: The Loyalty Server needs the inventory resource to lookup Points Earned and Price in Points values for item-based loyalty programs as well as item-reward program information for items. Make sure the inventory resource is replicated to the Loyalty Server ltylevel: Use this resource to replicate loyalty levels and programs. ltylevelprogram: Use this resource to replicate loyalty programs for loyalty levels.
customer udf	This refers to the options available for each customer udf field. The "customerudf" resource is available for all profile types. In Prism, define customer udf fields in Admin Console > Node Preferences > Customers > UDF Fields.
dcs	Department information is replicated using the "dcs" resource.
docposflag	This refers to the options available for each POS flag field. In Prism, define POS flags in Admin Console > Node Preferences > Transactions > POS Flags.
document	Documents created in Prism BEFORE the profile is linked to the connection ARE NOT replicated. Only documents created AFTER the profile is linked to the connection are replicated.
document designs	There is no resource for replicating Document Designs; however, Document Designer includes an "import/Export" feature that can be used to copy document designs between locations.
documentfeetype	The documentfeetype resource is used to replicate the fee types defined in Admin Console > Node Preferences > Transactions > Fees/Shipment.
drawerevent	Drawer Events are replicated via the "drawerevent" resource. Important! The Pop Drawer event is NOT replicated. The Paid In, Paid Out and Cash Drop drawer events ARE replicated. In addition, Z-Out drawer open events are replicated via the drawerevent resource.
email types	Email types added or edited in Prism are replicated using the "emailtype" resource.
employee	The "employee" resource controls the replication of general employee information.
employeeudf	The "employeeudf" resource is used to replicate user-defined fields for employees.
exchangerate	The "exchangerate" resource is used to replicate exchange rates defined in Admin Console > Global Preferences > Currencies > Exchange Rates.
fees	The documentfeetype resource is used to replicate the fee types defined in Admin Console > Node Preferences > Transactions > Fees/Shipment.
grid formats	The "griddata" resource controls the replication of grid format information (defined in Admin Console > Node Preferences > Grid Formats) Changes to grid formats made at the Corp, Subsidiary, or Store level will replicate with other preferences. Workstation settings will not replicate. Any workstation-specific grid format settings must be made at each individual workstation that needs them.
images	Images are not replicated.
inventory	Inventory information is replicated using the "inventory" resource.
invnlot	Inventory item lot number information is replicated using the "invnlot" resource.
invnserial	Inventory item serial number information is replicated using the "invnserial" resource.
inventory styles	Inventory item style information is replicated using the "inventorystyleview" resource.
invnudf	This refers to the options available for each inventory udf field. In Prism, define inventory user-defined fields in Admin Console > Node Preferences > Merchandise > UDF Fields.
job	Job titles are replicated using the "job" resource.
kit component	Kit component information is replicated using the "kitcomponent" resource. Kit components are the individual items that together comprise a kit item.
languages	The "language" resource replicates languages added (or changed) in Prism.
markdowns	The "markdown" resource replicates scheduled price markdown information (created using Price Manager).
mediatype
permissions	Information about the permissions assigned to each employee group is replicated from the POA to a subordinate. If you change preferences at the Corp/Sub/Store level, then the following will occur: Root Authority will automatically propagate to POA & vassal POA will automatically propagate to vassal In no case will changes flow up the enterprise.
pi sheet data	PI sheets and their counts are replicated using the "pisheetdata" resource.
pos flags	The posflag resource is used to replicate POS Flags defined in Admin Console > Node Preferences > Transactions > POS Flags.
price level	Price levels are replicated using the "pricelevel" resource.
preferences	Preferences are replicated as part of the Core Resources. The Core Resources are defined as those resources that are replicated from the POA to its members, but not back to the POA from a member. If you change preferences at the Corp/Sub/Store level, then the following will occur: Root Authority will automatically propagate to POA & vassal POA will automatically propagate to vassal In no case will changes flow up the enterprise. When defining preferences, it is important to be aware of the various levels and which level you are changing: Corporate, Subsidiary, or Store (Workstation preferences are never replicated). Each of the levels of preferences exist at every Prism installation and can be configured by users (regardless of whether the installation is the Corp HQ, a Subsidiary server, a Store, or an individual workstation). When joining the enterprise, the server will inherit preference settings from the POA (Corp, Sub, Store levels). Store level changes will only affect that store.  Therefore if a user drills into Store 1 and makes changes, systems will not see the changes unless the WS is assigned to that store. If the Root Authority changes a Corp-level preference and the store has a store level setting for the same preference, the store's preference wins.
promotions	The "pcppromotion" resource is responsible for replicating promotions. Add the pcppromotion resource to individual profiles to replicate promotions from one. When you press the Broadcast button, promotions are prepared for replication. Promotions are sent one promotion per message (instead of one large message with all promotions). If the promotion contains a long list of items it will still be a large message, but not as large as before. Also, since promotions are now sent as multiple messages, they can be processed in parallel with multiple day-to-day consumer threads. A field in the PCP_PROMOTION table - PUBLISHED_DATETIME - tracks the date and time when that specific promotion was broadcast. The PUBLISHED_DATETIME is compared to the MODIFIED_DATETIME on the same record and if the MODIFIED_DATETIME is older than the PUBLISHED_DATETIME, the promotion will NOT be sent when you press the Broadcast button. This means that only those promotions edited after the last broadcast will be sent. The Promotions list is created and managed at the headquarters location (or designated central location). The headquarters location then broadcasts the list to stores. Important! When you broadcast promotions, Promotions will be overwritten at the locations that receive the broadcast. The actual promotions that can be used at each individual store will be limited to those promotions assigned to the store itself or to "All Stores." Broadcast Promotions from HQ to Stores Currently, any location can broadcast Promotions simply by clicking the Broadcast button on the interface.; however, you should only broadcast Promotions from the HQ server down to the child POAs and stores. If stores broadcast promotions back up to the POA, then there is a chance that promotions priority can be duplicated at locations across the enterprise, leading to unexpected results. The "pcppromotion" resource is available for Prism-to-Prism profiles only.
purchaseorder	Replicates purchase orders.
purch fee type	Purchasing fee types. These are the reasons for fees on purchase orders. Define purchasing fee types in Admin Console > Node Preferences > Purchasing > Vouchers > PO/Voucher Fee Types.
reasons	Reasons are short labels that help explain why a certain action was taking by a user (e.g. granting a discount). In Prism, define reasons in Admin Console > Node Preferences > System > General.
receiving	The "receiving" resource replicates receiving vouchers.
regions	This resource replicates corporate regions (created in Admin Console > Global Preferences > Regional Inventory > Corporate Regions.
scales	The "scale" resource is available for all profile types.
scale patterns	The "scalepattern" resource is available for all profile types.
season	Seasons can be assigned to items and price levels when using seasonal pricing. In Prism, define seasons in Admin Console > Global Preferences > Season.
shipping methods	The "shippingmethod" resource is used to replicate the list of shipping methods (e.g., USPS, FEDEX) .
store	Store information is replicated using the "store" resource
store credit	The CreditLimit, CreditUsed and StoreCredit fields are "protected" fields. This means that when replicated from a subordinate to a POA DOES NOT OVERWRITE the key fields at the POA.When replicated from a POA to a subordinate, the files DO OVERWRITE the key fields at the subordinate.
subsidiary	Subsidiary information is replicated using the "subsidiary" resource.
tax areas	The "taxarea" resource replicates tax area information, including tax rules (created in Admin Console > Node Preferences > Taxes > Tax Areas).
tax codes	The "taxcode" resource replicates tax codes (created in Admin Console > Node Preferences > Taxes > Tax Areas).
till	This refers to the till records. In Prism, define tills in Admin Console > Node Preferences > Reporting > X/Z-Out.
time clock records	The "timeclock" resource replicates check in/check out records for employees.
title	This refers to the titles (Mr., Mrs., Dr., etc.) that can be assigned to Customers and vendor contact persons. In Prism, define titles in Admin Console > Node Preferences > Data Types.
touch menus	The "touchmenu" resource replicates the touch menus defined in Admin Console > Node Preferences > Touch  POS.
tranfeetype	The tranfeetype resource replicates fee types for transfers, defined in Node Preferences > Transfers > General.
transfer orders	This resource replicates transfer orders.
transfer slip	The "transferslip" resource replicates transfer slips.
transfer slip comments	Transfer slip comments are not replicated at the current time. You can enter comments on transfer slips in the Transfer Slip Details area of the slip.
transfer resolution rules	The "transrules" resource replicates the Transfer Resolution Rules defined in Admin Console > Node Preferences > Transfers > Resolution Rules. These rules dictate how the system will handle discrepancies in the sent/received items and quantities on out slips when compared to the voucher on which the items were received.
usergroup	The usergroup resource replicates employee groups.
userpasswordhistory	The userpasswordhistory resource is used to replicate passwords.
vendor	This resource replicates vendors.
vendor invoices	The vendorinvoice resource replicates vendor invoices.
vendor udf	This refers to the options available for each vendor udf field. In Prism, define vendor udf options in Admin Console > Node Preferences > Merchandise > Vendors > UDF Fields.
vouchers	Vouchers are replicated using the "receiving" resource.
z out reports	The zoutcontrol resource is used to replicate Z-Out reports.

Preferences overwritten by POA when Joining the Enterprise
When defining preferences, it is important to be aware of the various levels and which level you are changing: Corporate, Subsidiary, or Store (Workstation-level-defined preferences are never replicated). Each of the levels of preferences exist at every Prism installation and can be configured by users (regardless of whether the installation is the Corp HQ, a Subsidiary server, a Store, or an individual workstation). When joining the enterprise, the server will inherit preference settings from the POA (Corp, Sub, Store levels). This is usually the desired behavior. A downside is that if you have configured custom preferences at any level, those custom settings will be overwritten by the POA's settings during JTE.

Replicating Preferences from Prism to Prism (POA to New Server)
Currently if the POA has already been set up and you connect a new system to this POA the preferences are not sent to the new server. The user must make an edit to the POA preferences to have the new system get the POA's preferences. In future versions, users will be able to propagate preferences to from an existing Prism server to a new Prism server (Prism-to-Prism).

Forcibly Removing a Server
If a Server is forcibly removed (in other words the subordinate is not online for some reason) the proper recovery if the remote system either:
Is brought back up and desires to remain independent of the enterprise (it has no knowledge that it left the enterprise
It is desired to restore the system to the enterprise
(Note: If the system will be offline permanently, no action is needed)
SCENARIO:
1. An enterprise is set up.
2. A subordinate server in the enterprise goes down.
3. At the Root Authority, it is determined that the best course of action is to remove the subordinate (e.g. because the server will be down for an extended time).
ACTIONS:
At the down servers POA, Remove the powered-down Server from the enterprise.
IF DESIRED FOR THAT SYSTEM TO RE-JOIN ENTERPRISE AT A LATER DATE:
At the Removed system, log into TTK, it will show the former enterprise tree (since the system has no knowledge it has been removed from the enterprise)
At the Removed system, log into the subordinate server's former POA (this is required for the next step).
At the Removed system, select the menu icon associated with the local Server (the removed subordinate server) and select Remove. Now the enterprise tree will correctly reflect that this system is not attached to an enterprise.
At the POA which this server will re-join, follow the "Add Former Server" process,