What is the best way to implement a mobile app that will record the time spent in maintenance? Is the OSLC integration the best way to do this connection?
[Admin: To see other related posts, use the Mobile tag or OSLC 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.]
When a BIRT report is launched in TRIRIGA on the Reports tab or elsewhere, a Progress Bar popup appears with a “Cancel” button.
- 1. If I click “Cancel”, will that kill the Select statement that is running against the database on the database server?
- 2. If I click “Cancel”, will that release the database connection that is used when a BIRT report starts to run?
The answer to both questions is “No”. The thread will be consumed until the Select statement is complete. There is no messaging included in the log that the Select process was orphaned due to user interaction. The process simply continues to run until the results are retrieved and then stops. So, effectively:
- 1. No, canceling a request will not kill the Select statement.
- 2. No, the thread remains unaware that the request was canceled.
When the results are returned, the thread will process them, and then hit the canceled thread. There may be a message in the log warning about an IO socket being disconnected, or some other exception dealing with the dead connection.
[Admin: To see other related posts, use the Thread tag or BIRT 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.]
Due to security regulations, certain customers must disable TLS protocols 1.0 and 1.1. However, when they do this and use only TLS 1.2, they lose connectivity from the TRIRIGA Reserve Outlook add-in.
The problem was that the add-in was compiled with .NET 4.0 which doesn’t support TLS 1.2. The fix is to explicitly force support for the TLS 1.2 protocol. Moving forward, the IBM TRIRIGA Workplace Reservation Manager add-in is now able to communicate with the TRIRIGA server over the TLS 1.2 protocol.
[Admin: To see other related posts, use the Add-in tag or TLS tag.]
I have created an object migration (OM) with its workflow. The execution works well on the Development environment. But after an import of the OM package with all objects needed, the execution didn’t work on the Test environment. The object migration launch works. The triIntegration workflow launch works. The execution of the request works in SQL Server. The connection in my object migration works.
But there is no row in the staging table S_CSTPHINTERMARCHECONTRAT. Also, I see in the logs:
Calling SQL: [INSERT INTO S_CSTPHINTERMARCHECONTRAT(DC_JOB_NUMBER, DC_CID, DC_SEQUENCE_ID, DC_STATE, DC_ACTION, DC_GUI_NAME, TRIIDTX, CSSTPHHPIDRATTTX, CSTPHRETIRETX) VALUES (?,?,?,?,?,?,?,?,?)] with params[402, 0, 1, 1, 4, cstPHInterMarcheContrat, 2013/M0166, 101GT, ]
I found the problem. The configuration of the integration object was for the Development environment and not for the Test environment.
[Admin: To see other related posts, use the DataConnect tag.]