IBM TRIRIGA and Cisco partnership provides scalable workplace utilization and occupancy monitoring
By Kendra DeKeyrel
IBM TRIRIGA and Cisco have teamed up to give you the tools you need to deploy location sensing using your existing WiFi network infrastructure. This solution helps you scale quickly and get faster, more accurate occupancy insights, to enable you to reimagine and streamline your connected spaces…
With this partnership, IBM TRIRIGA’s IoT and AI-driven insights application, IBM TRIRIGA Building Insights, now natively integrates with Cisco’s DNA Spaces cloud service. If you’re a space planner or manage facilities, you can quickly take advantage of these insights. With a lower cost to entry, you can understand how facilities are being used based on data coming in from an existing network…
If you need to quickly address new occupancy demands, please attend an IBM/Cisco webinar. Designed for space planners and facilities managers, we will explain how true occupancy insights enables you to make strategic space management decisions. Register today.
Join us on May 13 for IBM TRIRIGA Academy
Soon, we’re launching IBM TRIRIGA Academy. This is a new virtual learning platform designed for real estate and facilities professionals who want to create a smarter business. Participate in our sessions, schedule a demo, and interact with subject matter experts…
[Admin: This post is related to the 01.28.20 post about enhancing TRIRIGA UX Perceptive apps with artificial intelligence, and the 03.22.16 post about the former Watson IoT Academy, now moved to the Skills Gateway.]
In the IBM TRIRIGA Administrator Console, under Performance Monitor > Monitor a Single Value, several monitors are no longer listed.
The following changes were made in the Administrator Console, under Performance Monitor > Monitor a Single Value:
- CRYSTAL_QUEUE_AGENT_RUNNING is renamed to REPORT_QUEUE_AGENT.
- CLEANUP_AGENT_RUNNING is renamed to PLATFORM_MAINTENANCE_SCHEDULER.
- KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING were deprecated in a previous release and are now removed from the Performance Monitor.
Since the CRYSTAL_QUEUE_AGENT_RUNNING and CLEANUP_AGENT_RUNNING monitors are used for integration, only the performance monitor names are changed, not the values or URLs.
[Admin: This post is related to the 07.14.15 post about renaming CleanupAgent (Cleanup Agent) to PlatformMaintenanceScheduler (Platform Maintenance Scheduler). To see other related posts, use the Monitoring tag.]
Is anyone familiar with this error?
5/20/17 1:03:36:364 EDT] 000000b8 ThreadMonitor W WSVR0605W: Thread "server.startup : 2" (00000072) has been active for 712611 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.
[Admin: To see other related posts, use the Thread tag.]
In the Admin Console, Performance Monitor, when monitoring a single value, it returns bad results. Returns wrong agent’s status. Returns “false” for an agent status even if the agent is running. Returns “0” for the number of agents running even if multiple agents are running.
We needed to update the calls to various platform status APIs. Moving forward, we updated the Admin Console, Performance Monitor, Single Value to correctly obtain the status of the active agents. This means the AGENTS_RUNNING_COUNT, OBJECT_PUBLISH_AGENT_RUNNING, SCHEDULER_AGENT_RUNNING, and all other agent-related monitors will now correctly report the agent status and count. We also removed the calls to KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING as these no longer exist.
[Admin: This post is related to the 04.08.15 post about performance monitoring tools, and the 02.10.17 post about performance best practices.]
I have installed TRIRIGA 10.5.2/3.5.2 OOB in Sandbox 1. One thing I noticed is that I used to be able to run the TRIRIGA service as “SVC-CBRES-IWMS-DEV” and I used to display the following in a web page, but in 3.5.2, I am not getting the expected “Sign In Required” error.
In TRIRIGA 3.5.2, a security change was filtering out the Performance Monitor (Single Values) URL. We needed to remove the filtering of monitor.jsp. Moving forward, a security issue was fixed which made the performance monitors unable to work externally from the TRIRIGA Admin Console.
[Admin: This post is related to the 04.08.15 post about performance monitoring tools.]
In the TRIRIGA 3.5 platform release, a new feature was added allowing you to track the performance and monitor who runs queries and reports in Report Builder. A flag can be set on the report definition that will track who has run the report, and the time it took to retrieve the information from the database.
To enable report run history, open the report in the Report Manager and click “Track History” on the General tab. Note that enabling this tracking causes just a slight overhead, but it should still be used with caution. Once enabled, you will need to let your users use the system for a while, so that some data can be saved. Once a few days goes by, you can then start to analyze what is happening in your system…
- Which reports have run the longest overall?
- Of the reports that have run, which have the average longest runtime?
- For the users in the system, who runs the most reports?
- Of the users in the system, who have run the longest reports?