See what the NCR Counterpoint integration can do →

NCR Counterpoint runs on the subscriber's own server rather than in the cloud, so connecting it to iPaaS.com means installing two components alongside Counterpoint and then pointing the iPaaS.com subscription at them.

This article walks through that installation from start to finish. Work through it in order — each stage depends on the one before it.

These steps assume a fresh IIS installation using default paths. If IIS already hosts other applications, or non-default paths are needed, the steps still apply but the specifics will differ. Subscribers or their MiSP should involve a qualified IT professional in that case.

A standard installation has two components, and both are required:

The two work in opposite directions and are not alternatives to each other. CPHive carries data into Counterpoint and answers requests from iPaaS.com; CPWebhooks tells iPaaS.com when something in Counterpoint has changed so that iPaaS.com knows to ask.

Both components depend on supporting objects in the Counterpoint database, which are installed separately as part of this process.

CP Extender is not part of a standard installation. It is a separate optional component covering capabilities such as gift cards, loyalty, pick tickets and image handling, and it is not required for the integration described here. Subscribers whose project includes it should follow CP Extender: Setup separately.

Three references have to line up, and most failed installations are one of these being wrong:

Gather the following before starting. Most of these come from the subscriber's IT team, and several have lead times:

Note which iPaaS.com deployment the company was created in — staging and production have different addresses, and CPWebhooks must be pointed at the right one.

The installation files are published as a release package in the iPaaS.com install repository:

https://github.com/ipaas-com/CPHiveInstall/releases

Download CPHive-Package.zip from the most recent release, then right-click it and choose Extract All. It contains three further zip files, one per stage of this installation:

Versions. At the time this documentation was written, the current release is v2.1.0. Always take the most recent release rather than a specific version, unless iPaaS.com Support has directed otherwise.

If there is any doubt about which release applies to a particular Counterpoint version, confirm with iPaaS.com Support before installing.

CPHive runs on .NET 6.0, which must be installed on the server hosting IIS before CPHive will start.

If IIS was installed after the hosting bundle, install the bundle again — it registers itself with IIS at install time and will not be picked up otherwise.

Carry these steps out on the server hosting Counterpoint.

CPHive must have its own application pool. Staging and production instances must not share one.

If CPHive is installed on a different server from the Counterpoint top-level directory, the application pool needs an identity that can reach it. A local IIS user cannot access a remote directory, so a domain account — or pass-through account — with access to both the CPHive folder and the top-level directory must be set as the application pool identity. Involve an IT professional if this is unfamiliar.

The application pool account also needs full control of the CPHive DDCache folder, where CPHive stores its cached copy of the Counterpoint data dictionary. If the pool runs as ApplicationPoolIdentity, grant IUSR and IIS_IUSRS full control of that folder.

The server hosting CPHive must be reachable from iPaaS.com over an SSL-encrypted domain name — for example https://cp.example.com/CPHive/. How this is done varies dramatically between networks, so it cannot be covered step by step here. Unless the subscriber's team is comfortable with this, they should work with a qualified IT professional to configure the access safely. At minimum:

Both CPHive and CPWebhooks depend on supporting objects in the Counterpoint database — the change queue that CPWebhooks reads, the table that records which events are subscribed to, and the triggers that populate the queue when a record changes.

This step is required. CPWebhooks cannot start without the change queue, and no trigger event reaches iPaaS.com until the triggers exist.

This should be done by, or alongside, the subscriber's Counterpoint support partner.

The scripts also convert objects carrying the older naming used by earlier versions, so they are safe to run against a database that was previously connected to an earlier release.

A database installer ships alongside the scripts and performs the same work. Running the numbered scripts directly is recommended, because each step is visible and any failure is easy to isolate.

The file is JSON, so any backslash in a path must be escaped — written as a doubled backslash.

The top-level directory must end with a trailing separator. CPHive appends the dictionary and company alias folder names directly onto it, so without one those paths are built joined together, and the connection test reports the directory as missing or inaccessible even though it exists.

Settings are read when the site starts. After any change to the configuration file, stop and start the website — or recycle its application pool — before testing again. This applies every time the configuration is edited, not just during installation.

CPHive publishes an interactive API page that includes a built-in health check. This is the fastest way to find a configuration problem, and it checks more than any other single step in this article.

The response also confirms, individually, that the database connection, the Counterpoint top-level directory and the data dictionary are all reachable, and reports the directory CPHive is running from and the Windows identity it is running as. Resolve anything it reports before continuing.

Generate the data dictionary cache. After the health check passes, run the token endpoint for a valid Counterpoint user id from the same page, then confirm a serialized data definition file has appeared in the CPHive DDCache folder. If the folder is empty, the application pool account is missing permission to it — correct the permissions, restart the application pool, and repeat.

Important: the cache is built from the Counterpoint data dictionary as it exists at the time. If custom fields are added to Counterpoint later, the cache must be regenerated, or mappings referencing those fields will fail.

The remaining settings on this screen — First Order Date, Store, Drawer, Station, User, Template Customer, Default Customer, Next Customer, Tracking #s in CP, Item Description From, Inventory Qty Method, Inventory Location and Qty Stock Threshold — are optional at install time and control how the integration behaves once it is running. What each one does, and when it is needed, is covered in NCR Counterpoint Connections and Settings.

Save the file once the settings are complete.

Open an administrator command prompt: click Start, type cmd, right-click Command Prompt and select Run as administrator.

Create the service by running the command below, entered as a single line. The quotation marks are part of the command and must be included.

A SUCCESS message confirms the service was created.

Then start it:

One service per Counterpoint database. A server hosting several Counterpoint databases needs one CPWebhooks installation per database, each in its own directory and each created with a distinct service name.

Several features are not active after a standard installation and need a further step carried out against the Counterpoint database. A feature in this state produces no error — it simply never transfers automatically. If an optional feature appears to do nothing, this is the first thing to check.

There are two kinds, and it matters which one applies. At the time this documentation was written:

Scripts for both cases are supplied per feature in the optional-scripts folder extracted from CPHiveDatabaseInstallScripts.zip. Only run the script for a feature that is actually in scope, and restart the CPWebhooks service afterwards.

Important: do not use the scripts published in older feature documentation for kits, location groups or category assignments. Those were written before the feature shipped with the installer, and re-running them against a current installation duplicates the trigger event records and fails, because the database trigger already exists.

Important: the scripts for features that are not shipped create database triggers on live Counterpoint tables. A mistake in a trigger can prevent records from being saved in Counterpoint. Apply them to a staging database and validate the feature end to end before running them against production.

Note that some of these features' trigger events are not offered for selection in Inbound Data Flows even once enabled in the database. Subscribers or their MiSP should validate any optional feature end to end in a staging environment before relying on it in production.

Image synchronisation is handled by Image Mover, which is part of CP Extender — the optional component described under What gets installed above. It is not part of a standard installation, and it cannot be configured without CP Extender already installed on the Counterpoint server.

Subscribers whose project includes image synchronisation should install CP Extender first, following CP Extender: Setup, and then configure the image service following Configure Image Mover. Otherwise, skip this step.

Confirm the installation end to end before handing over:

These checks confirm the plumbing works. To populate reference data for the first time, use Initialization rather than repeated Manual Syncs — see NCR Counterpoint Connections and Settings for the entities that support it.

Transfer errors surface at Dashboard / Integration Monitoring / Error Logs.

Common installation problems:

If logging was turned up during commissioning, turn it back down before go-live. Both components ship set to record errors only, which is the correct setting for normal running. Detailed logging records the full content of every message; leaving it on degrades performance and can cause transfers to time out. Restart the component after changing it.

For further assistance, contact iPaaS.com Support.