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.]
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.]
There are many installation scenarios that can cause TRIRIGA reports, especially BIRT reports, to fail to export due to timeout. Microsoft Excel exports are often the ones that you can observe because all of the file formatting happens during export.
Let’s focus on WebSphere Liberty installations, but this recommendation can be used for other web servers with some tweaks. Mostly, this is related to timeout settings, especially for HTTPS (SSL/TLS) connections. A good troubleshooting test is to perform the same action in a non-HTTPS (HTTP) connection. Does the report export? If so, take note of the time needed to export it and plan to extend the timeout in the HTTPS connection to at least double the time.
Refer to the IBM Knowledge Center > WebSphere Liberty > HTTP Endpoint topic. Look for the “sslOptions”, and also double-check the “httpOptions”, for timeouts.
[Admin: This post is related to the 04.20.17 post about setting the TRIRIGA session expiration warning in the portal. To see other related posts, use the Timeout tag.]
I am trying to configure SSO with WebSphere Liberty (on RHEL 6.8 and TRIRIGA 10.5.0/3.5.0) with Active Directory. Once configured, I get the Windows authentication popup. It accepts my domain credentials, but instead of taking me inside the application, it takes me to the login page, where I have to input my local TRIRIGA profile login details. Can someone help me with this?
[Admin: To see other related posts, use the Active Directory tag or SSO tag.]
To keep TRIRIGA from dropping servers, I have to restart the TRIRIGA service every night. Does anyone else have to do this? If so, how are you doing it?
I execute the “shutdown.bat” then the “run.bat” via Control-M. The location of these two BAT files are: D:\Tririga_3.5.1\wlp\bin. But the “binserver.bat” file does not exist: D:\Tririga_3.5.1\wlp\binserver.bat start tririgaServer. I’m using the WebSphere Liberty Profile (WLP) and it’s set up as a Windows service as well. Can I just restart the Windows service instead of the BAT files? Why doesn’t the “binserver.bat” exist?
The “run.bat” file seems to work just fine, but my Control-M job gets hung up. So I would like to find another way to restart the service if possible.
[Admin: This post is related to the 06.16.16 post about restarting TRIRIGA on WAS Liberty Profile in Windows, and the 04.28.16 post about running a WAS Liberty Profile as a Windows service.]
I have set up single sign-on (SSO) with SiteMinder and Liberty, and both seem to be working fine. However, after login, when I attempt to access BIRT reports, I get the following in the DevTools security window:
Mixed Content: The page at 'https://hostname/html/en/default/platform/mainpage/mainpage.jsp' was loaded over HTTPS, but requested an insecure resource 'http://hostname/birt/frameset?_docId=2816263&_la…tem__triPaymentLineItem_-_Report_-_Future_Rent_Obligation_Detail.rptdesign'. This request has been blocked; the content must be served over HTTPS.
Similarly, when I attempt to open a record and navigate the tabs, I get the following:
Mixed Content: The page at 'https://hostname/WebProcess.srv?objectId=750000&…TypeId=10002490&action=Edit&managerType=query&altGuiListId=-1&inline=false' was loaded over HTTPS, but requested an insecure form action 'http://hostname/WebProcess.srv?objectId=880000&a…false&undeletable=false&requiredNotSet=0&requiredTabList=&requiredField=-1'. This request has been blocked; the content must be served over HTTPS.
In the first case, the report never displays, and in the second case, the record appears to entirely hang. Have any of you seen this before? Any ideas how to fix it?
[Admin: This post is related to the 08.20.15 post about getting a mixed content security error with Esri ArcGIS, and the 06.18.15 post about GIS mixed content messages. To see other related posts, use the SiteMinder tag or SSO tag.]
After upgrading to TRIRIGA 3.5.1.x or later, some customers are having issues with thumbnail images on reports and/or queries not being displayed correctly.
WebLogic incorrectly parses a JSP by adding white space that corrupts image thumbnails. Meanwhile, WebSphere and Liberty parse the JSP correctly. Moving forward, we resolved an issue where Oracle WebLogic was incorrectly interpreting TRIRIGA code, and injecting extra white space that caused thumbnail images to be displayed as broken images.