About
This guide is modeled around the Centrak minifi integration, but can generally be used as a checklist to verify any vendor setup.
Checklist
Part 1 - Setup
TeleTracking® Real-Time Locating System Application Server - Check TIR requirements (TeleTracking Real-Time Locating System Technical Information Reference ) and refer to the latest released version.
Anti-Virus settings - check directory/sub-directory exclusions AND Active scanning exclusions
Disable unused LSC streams - Remove/disable LSC streams not in use.
Rest Connector Installation -
If upgrading the Rest connector, backup the connector.ini. Install Rest on the LSC server as a general rule of thumb. This way the TeleTracking® Real-Time Locating System application server CPU/memory consumed is restricted to Tele applications only.
Connector.ini - a) for Orion - ENABLE_30_SERVER=1, b) for Pegasus - ENABLE_30_SERVER=0. If this is incorrect, tags will appear in the Rest PCSniffer tool as “0”.
Connector.ini - RTLS-2371 - The Rest Connector.ini setting (WORK_FLOW_ASSET) should be set as follows: (WORK_FLOW_ASSET= 2), so that no button press events are processed for Asset/Dial-status tags. For tags with FW versions (173, 52, 50), enabling button press events for these status tags will result in button press “spamming” from the Rest connector.
LSC/Rest Streaming Fields - Ensure the LSC streaming fields/ports required for the Rest connection are correct. With the Rest connector and LSC on the same box, click “Verify Streaming Settings” in the Centrak REST Config Tool, settings tab.
Validate hardware data in the Rest PCSnifferTool - Make sure incoming traffic in the Centrak PCsniffer utility shows monitors/tags normally. We’ve seen tags/monitors appear as “0” previously, caused by incorrect Rest config settings (step 4 above).
Validate there are no extraneous hardware feeds from Rest or LSC - Make sure each TeleTracking® Real-Time Locating System install (the TeleTracking® Real-Time Locating System Integration service specifically) has only a single Rest feed from each LSC server. There may be extra streams(s) left behind that were used by the old Windows driver.
Rest Connector functional validation - Initially, ONLY enable 1 outbound stream from Rest, add in additional streams after functional validation passes for the single stream. Verify data for AssetTracking tags and TempTracking sensors in the apps.
Disable old NIFI instances - Kill the old NIFI interface (if previously installed), delete/zip directories, and disable the Apache NIFI (nssm) service.
TeleTracking® Real-Time Locating System Integration Service - Check the processes associated with the service in Task Manager. The description for the Java process should indicate 'Zulu Platform x64 Architecture”. If not, JAVA_HOME needs to be created or re-pointed to the installation location of Java packaged with the integration service installer (…\TeleTracking\TeleTracking Centrak RTLS Integration\OpenJava). Also, check to be sure that the integration service is listening over ports 8025-->8034 via the command line by running “netstat -ano”.
Part 2 - System Validation
As a starting point to test system health, it's useful to first test the Tele application side in isolation with the Rest feed disabled. We can do this by applying load the TeleTracking® Real-Time Locating System integration service with Postman or JMeter. This will help identify whether there are any “slowness” issues on the Tele-application side - which has historically been caused by incorrect/missing Anti-Virus exclusions.
After that’s done, enable the Rest feed into the Integration service and repeat Postman tests to be sure updates via simulated tags are immediate.
Recommend running the following tests immediately after installation to check for throughput characteristics.
With TeleTracking® Real-Time Locating System debug enabled, run Postman in isolation (Rest disabled) – updates in Asset should occur immediately
Repeat with Postman runner at 1 loc change every 1 secs, for 10 mins. Observe location changes are reflected in the Asset UI. At the end of the test, updates should stop immediately in the UI, which indicates there are no queue buildups in the TeleTracking® Real-Time Locating System Integration service.
In the TeleTracking® Real-Time Locating System log with debug enabled, check for exceptions, and especially publication times to Asset Tracking/Clinical Workflow® Suite/ (Capacity IQ® or Capacity Management Suite®) – should be ~100-200msec top end.
Check for Clinical Workflow® Suite/ (Capacity IQ® or Capacity Management Suite®) publication event failures, if integrated. If these fail (seen as retries in TeleTracking® Real-Time Locating System log with debug enabled), updates in Asset will be affected, and appear sporadically in the UI.
Once all the above have run through clean, run Postman in parallel with the hardware feed (Rest) enabled. Verify updates in Asset WRT to test tag(s) are still immediate with the Postman updates.
For multi-threaded load generation, JMeter can be executed to generate load if the hardware feed is “light”.
While Postman/JMeter tests are being executed, check system performance (CPU/memory) metrics in Task Manager. Aside from validating memory and CPU hold steady, also observe Ruby processes for both Asset and Temp. Each app will have 4 Ruby processes corresponding to the Mongrel load balancer threads. Memory usage for these should hold steady.
Running Postman in parallel to Rest enabled is important because this allows us to see how a single tag will update while actual hardware traffic is being applied to the system. Note that updates in the Asset UI reflect when the TeleTracking® Real-Time Locating System engine processed the tag update, not when the Rest connector sent the update. So even though we see an update occurred just seconds ago in the UI, that update may have been sent by the Rest connector hours ago. This “delay” condition is a symptom of the TeleTracking® Real-Time Locating System integration service building queue data, likely caused by incorrect A-V exclusions.