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?
To address performance-related issues in the installation of the TRIRIGA Application, this article provides suggestions and recommendations for the IBM TRIRIGA MS SQL Server database environment. It also provides monitoring and troubleshooting steps to quickly discover and prevent performance and instability degradation… This article addresses the following key areas:
- General best practices
- TRIRIGA-specific recommendations
- Performance monitoring
- Problem resolution…
MS SQL Server performance problems can be difficult to pinpoint and require inspection into many aspects of the environment. There is no magic button or specific step-by-step actions to locate every performance issue. Instead, there are guidelines for diagnosing and troubleshooting common performance problems. This article will provide a general methodology for diagnosing and troubleshooting MS SQL Server database instability and performance problems in common scenarios.
Configuration, tuning, and sizing issues for MS SQL Server may lead to various instability and performance issues from the database end. The instructions listed below should be reviewed, confirmed, and applied by the customer’s database administrator whenever necessary… Here are some basic best practices that should be implemented on production MS SQL Server environments…
[Admin: To see other related posts, use the Best Practices tag.]
In TRIRIGA, when firing the triRetire action/transition for the triPeople BO, the following workflows will be triggered:
- triPeople – triRetire – Remove TRIRIGA User and Read Only Dependant Records
- triPeople – Synchronous – Remove TRIRIGA User My Profile
This moves the record to the Retired state, so they are still retained in the system. The only transition that is able to remove them from the database is setting them to NULL. Each People BO record occupies 50 KB in average, so if you are performing a massive removal, for instance, removing 100,000 records, this means about 5 GB being processed and worked on by the triRetire process at that time. Using triRetire is the only supported process for archiving triPeople BO records.
If there is a need to perform a massive retire process in the system, Data Integrator may not be a good choice. Using Web Services will be a better option, but this could be enhanced to look at the number of workflows in the queue by looking at the “monitor.jsp”… for the numeric value…
In most manufacturing plants, the demands on FMs are high; but the data is insufficient or nonexistent… Without this kind of information, FMs are left to rely on planned preventive maintenance (also known as PMM or Planned Maintenance) schedules, which can be expensive and can cause unnecessary downtime…
Instead, equipment failures can be predicted by monitoring the energy demand of certain systems and devices. Monitoring, tracking, and analyzing device-level energy consumption data is much easier and less expensive than most FMs realize; and the benefits of such granular data are immense. When we install wireless, non-intrusive sensors on each of our devices, and aggregate the data through a cloud-based analytics engine, we can monitor, track, benchmark, report, and detect anomalies, all in real-time.
For example, a compressor that has begun to cycle more frequently than usual, or is out of sync with the external temperature or humidity, will display an energy profile that is characteristic of a particular failure mode. Or a conveyor motor that overloads and trips out can create a costly bottleneck in the process. Correcting these anomalies can increase operational efficiency and productivity, and it can also optimize and reduce energy consumption…