You can configure TRIRIGA to use Tivoli Directory Integrator as its ETL runtime engine to run ETLJobItems from within TRIRIGA.
Before you begin
Install Tivoli Directory Integrator, if not already installed, on all the TRIRIGA systems that could run a TDI ETL Job Item. During the TDI install:
- Make note of the installation directory you enter on the Destination panel. You will enter this value later in TRIRIGAWEB.properties.
- Select either installation type. TRIRIGA requires only the TDI Server component.
- When prompted for the location of the Solution Directory, you can select any option. TRIRIGA specifies its own solution directory at runtime. However selecting the option “Use Install Directory” may simplify troubleshooting.
- Make note of the value you enter in the Server Port field on the Server Port Values Panel. You will enter this value later in TRIRIGAWEB.properties.
- Clear the “Start the Configuration Editor” check box on the Install Complete panel.
- Note: This step is very important for TDI/TRIRIGA integration to work. After you have installed Tivoli Directory Integrator, update it with the recommended fix packs (per TRIRIGA support matrix). TDI must be at least at FP04 (18.104.22.168) or it will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.
- Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server. Set the following properties…
- Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
- Edit TDI global.properties file to allow TRIRIGA to check and stop the TDI server from localhost without requiring authentication and authorization certificates. Set the api.remote.ssl.on property to false to tell TDI to trust requests from localhost…
- Start Tivoli Directory Integrator Agent from TRIRIGA Admin Console and verify that it starts successfully…
[Admin: This post is related to the 08.03.16 post about installing, upgrading, or uninstalling TRIRIGA TDI, and the 05.01.16 post about documentation on developing TDI with TRIRIGA. To see other related posts, use the TDI tag.]
Does anyone have any experience in extracting TRIRIGA data from the database directly through Oracle SQL Developer? I am trying to extract through SQL code, and combine in one table, the data from triSpace, triSpaceClassCurrent, and triSpaceStandardsSpec. The idea is to create a single table with all spaces, space classifications, and space standards.
[Admin: To see other related posts, use the Oracle tag or SQL tag.]
We have some corrupted records, which appeared across 2 different BOs so far. We can’t delete them from the application level, and the cleanup script won’t delete them either, because they can’t be found under the IBS_SPEC table. Does anyone have a SQL to properly cleanup those records from the T_ table?
[Admin: This post is related to the 02.10.15 post about purging records from a BO. To see other related posts, use the Cleanup tag or SQL 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 looking for an approach to the above issue which will keep the page alive. We have tried alternatives such as explicitly calling a data source. And we are looking at handling session cookies.
The UX app can make sure it does not time out by making a call to a specific end-point. You can make an Ajax call to the following URL, which will update the last access time and keep the session alive:
[Admin: This post is related to the 05.08.17 post about keeping the UX app session alive and connected. To see other related posts, use the Timeout tag.]
I am getting a strange error when I am trying to deploy to TRIRIGA with the WebSphere Application Server (WAS). TRIRIGA doesn’t come up and throws an exception. Interestingly, when I point a Liberty application on the same DB2 database, it works well. I have confirmed with my network team that this is not a network connectivity issue. Here are the error logs:
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: DB2 SQL Error: SQLCODE=-805, SQLSTATE=51002, SQLERRMC=NULLIDR1.SYSSH200 0X5359534C564C3031, DRIVER=4.18.60 DSRA0010E: SQL State = 51002, Error Code = -805...
Have you checked to see that both the Liberty server and the WAS server are actually using the exact same version of the DB2 driver (db2jcc4.jar)?
[Admin: To see other related posts, use the DB2 tag or JDBC tag.]
I need to update a secondary database whenever there are changes in one of the records, or if a new record is created in an object. Can anyone help me with this?
Write a custom task, and run it from the workflow when there is a change.
[Admin: To see other related posts, use the Custom Task tag.]