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.]
In my current project, there was a suggestion to extract (updated) data from TRIRIGA, with a high frequency, and import it into some kind of data warehouse (DW) or business intelligence (BI) solution. Then, from there, perform more advanced reporting and analytics. Have other TRIRIGA solutions implemented something similar? Are there any TRIRIGA best practices or recommendations for staging area, extract-transform-load (ETL), DW, or BI reporting solutions?
[Admin: This post is related to the 12.15.16 post about the IBM TRIRIGA Connector for Watson Analytics. To see other related posts, use the ETL tag or Analytics tag.]
One of our customers is trying to apply all the best practices from the TRIRIGA documentation with different recommendations. One of them is regarding:
- ALLOW_SNAPSHOT_ISOLATION: SET ALLOW_SNAPSHOT_ISOLATION should be set to ON
- READ_COMMITTED_SNAPSHOT: SET READ_COMMITTED_SNAPSHOT should be set to ON
Their database department is telling them that if they activate this parameter, they could be doing “dirty reads”. Mainly, if they read and modify in the same tables at the same time. They said that other products control this situation. They wanted to know if TRIRIGA controls it. In case that TRIRIGA controls these situations, they will change it. Can you please confirm if they should set this parameter to ON?
TRIRIGA controls data integrity within the context of the web application. These settings for MS SQL make it behave more like Oracle and DB2, and we recommend that they be set to ON.
Our client is asking for the proper way to migrate project templates (the project itself, tasks, dependencies, roles) between instances. Object migration (they use TRIRIGA 3.4.1) doesn’t move (template) associations, so as a result, all records are created separately. Can I ask your recommendation on a right way to do it?
Are there any suggestions for tools or best practices on validating data after a legacy data load into TRIRIGA?
We are converting from 14 various legacy systems into TRIRIGA. And rather than relying on manual validation, we’d like suggestions for tools that could be used. Since the TRIRIGA database is so complex and convoluted, we thought it’d be best not to try compare scripts at the database level.
[Admin: This post is related to the 01.09.17 post about the best practice for localized data loading.]
What are the concerns about stopping my database for maintenance and leaving IBM TRIRIGA JVMs (JBoss, WebLogic, WebSphere) up and running at this point? Will they be reconnecting automatically after my database is up and running again? I need to programmatically schedule database maintenance for my TRIRIGA system.
When the database is down, the application server (JBoss, WebLogic, WebSphere) will be receiving connection issues to the JDBC component and JVMs will stop responding after that. If the database comes up again, the application server will not reconnect the JVM automatically. The JVM needs to be restarted manually after that.
The best practice for database maintenance requiring database shutdown will always be to shutdown all applications and sessions connected to it BEFORE the database itself. It gives systems the time to close the ongoing transactions gracefully.
If you need to coordinate database maintenance and JVMs automatic restarts, you need to create a batch script to manage that. This is a customized script (not under IBM TRIRIGA support) that will be stopping the JVMs first, then starting the database maintenance itself (likely stopping the database first), then restarting the database and firing commands to restart the application server IBM TRIRIGA JVMs.