Object Labels and Revisions
Starting in TRIRIGA 3.5.3, consider converting the TRIRIGA as-shipped objects that you renamed and modified back to the TRIRIGA objects from which they originated.
The purpose of the new conversion process is to enable the objects to use the new TRIRIGA object revisioning capabilities while preserving your object modifications. When you make future modifications to the objects, the modifications are saved in object revisions. Ultimately, the object revisioning and object labeling capabilities and tools aid in the future upgrade of your TRIRIGA applications.
For more information, see the documents, (1) “Converting your modified TRIRIGA objects to use the TRIRIGA revisioning features and application upgrade best practices” and (2) “Best practices for upgrading your TRIRIGA applications“.
[Admin: This post is related to the 09.24.15 post about the best practices for configuring and upgrading TRIRIGA applications. To see other related posts, use the Best Practices tag or Object Label tag.]
We understand that sometimes with new TRIRIGA platform and application version releases, a new version of Crystal Server will be required (tested by IBM and supported) in order for our existing Crystal Reports to function. Deviation from the tested and supported version of Crystal Server identified in the compatibility matrix is considered to be a significant risk.
From what we have been told, the version of TRIRIGA is tightly coupled with the supported version of Crystal Server.We are looking for a better understanding of how clients who may be using a shared Crystal Server across their enterprise handles upgrades to the TRIRIGA platform. Because our business recommended the use of their enterprise Crystal Server with our existing TRIRIGA application, we would like to understand the issues and risks of going with using a shared server where the upgrade schedule (annually) differs from our TRIRIGA upgrade schedules (2 years for platform, 5 years for combined application/platform).
Are there other clients of IBM who use a shared enterprise Crystal Server? When they want to upgrade TRIRIGA, do they always have the appropriate supported Crystal Server version paired with TRIRIGA? If not, what are other accepted (if risky) solutions? Potentially, if we went with the enterprise Crystal Server, it would likely often be further ahead than the version recommended by our platform.
[Admin: To see other related posts, use the Crystal tag.]
Regarding the setup and breakdown tasks for rooms, the Start and End times of these tasks are only influenced by relevant service assignment matrix (SAM) service level agreements (SLAs), and not by the Room Setup and Breakdown times of the space. If there are no SAM records, the duration of the task is taken as 0 (i.e. the Start and End times are the same).
The Start and End date-times on the reserve work task records that were created for the Setup and Breakdown times on the space were populating the values from SAM (not the reservation). The issue has been resolved to populate the date values from the space by adding a new list value “Use Reservation” to the “Task Assignment Dates Rule” list field on the service plan record, which is used for service plan records that are created for reserve functionality. This will allow the dates to be used from the reservation and not SAM.
Also, the list values “Available Mid-Reservation” and “Available for Entire Reservation” in the “Reserve Service Type” list field on the reserve work task template have been removed, since our current structure does not support these two values for the reservation use case.
Note for upgrade customers: These list values have been removed from the as-shipped application. These values will not be removed through an object migration (OM) package. So, you have to manually remove these values from your environment if they are not being used anywhere.
[Admin: This post is related to the 11.16.16 post about searching for rooms with setup and breakdown times. To see other related posts, use the Reservation tag.]
After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?
The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:
- Login to the Admin Console.
- Go to the “Cache Manager” managed object.
- Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
- Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
“INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
- Logout of the Admin Console.
- Stop the TRIRIGA JVMs via the WebSphere Admin Console.
- Delete the logs in the <TRIRIGA install>/log folder that has server.log.
- Clear the WebSphere temporary cache folder.
- Restart the TRIRIGA JVMs via the WebSphere Admin Console.
[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]
We are currently using TRIRIGA 10.5.1/22.214.171.124. If a particular portal section with a report has a result set of more than the property “Max Records Displayed”, then the results are not shown, and the portal section just keeps loading. Why?
However, the behavior is fine if the results returned are within the limit set in the portal section. Also, when the section is maximized, we can see all the results. It works in the case of a hierarchy query too.
We had a defect/APAR where the Max Records Displayed parameter was being ignored, and the entire result set was being pulled back. The issue is resolved in 126.96.36.199 and 188.8.131.52. Here is the release note: “Portal section queries display the maximum results that are specified in the Portal Builder. (Tri-237640-IV87771)”
I believe this fix will resolve your problem. In 184.108.40.206, queries are returning the entire result set, and are not stopping at the max count. My recommendation is to upgrade to the the fix pack with this fix, and see where you stand after that.
[Admin: This post is related to the 08.16.16 post about portal sections not showing the defined number of results. To see other related posts, use the Portal tag.]
In TRIRIGA, the Component ID for a field changed after upgrading. For example, in TRIRIGA 3.5/10.5, the Component ID for the “User ID” text box on the login page was: textbox(“User Name”). But in 3.5.2/10.5.2, it changed to: textbox(“User ID”). This is impacting our automation test. Each time we upgrade to a new version, we need to check and change our automation test script. Is it possible to keep these Component ID values fixed?
[Admin: To see other related posts, use the QA tag or Testing tag.]
We recently upgraded our customer to TRIRIGA 3.5.2. Thus, we had to upgrade the CAD Integrator to 220.127.116.11. Previously, when we used the Smart Attach, only 2 required fields were present: Current Use Space Class and Default Layout. But now, we have these additional required fields: Room Type, Reserve Calendar, Reserve Display Room Name, and Usage Unit. How can we turn off or disable these extra fields? The customer is not using Reserve yet.
In TRIRIGA, by default, the Reserve tab is not visible. But if the user clicks the Reservable check box in the General tab, then the Reserve tab is visible. So, the key is that the Reservable tab is not visible in the form metadata by default. Hence, CI would not consider those fields as required.
However, I assume that in your configuration, these Reserve fields are required? So, if a user creates a new space, they have to fill out the required Reserve fields before they can create it, right? CI is just attempting to emulate this situation.
[Admin: To see other related posts, use the Integrator tag.]