Why is there a JDBC exception with TRIRIGA on WebSphere and DB2?


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.]

Continue reading

Why doesn’t canceling the BIRT request stop the report process?


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.]

Continue reading

How do you fix failure to export reports to Excel due to timeout?


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.]

Continue reading

IV95388: TRIRIGA Reserve Outlook add-in fails when using only TLS 1.2


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.]

Continue reading

Why is the DataConnect staging table empty after OM import?


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.]

Continue reading

Why is there a connectivity issue with TRIRIGA and DB2 on RHEL?


Recently, I have been getting some connectivity issue with TRIRIGA 3.5.2.x and DB2 on (Red Hat) RHEL 7.2. The connection between TRIRIGA breaks suddenly and the app crashes. When I see the error logs, it says:

2017-04-20 08:01:33,694 ERROR [com.tririga.design.smartobjecttype.dataaccess.DBConnectionDAO](DataImportAgent) FAILED DATA CONNECTION java.sql.SQLNonTransientException: [jcc][t4][2043][11550][4.18.60] Exception java.net.ConnectException: Error opening socket to server localhost/127.0.0.1 on port 50,000 with message: Connection refused (Connection refused). ERRORCODE=-4499, SQLSTATE=08001 DSRA0010E: SQL State = 08001, Error Code = -4,499
...
Caused by: com.ibm.db2.jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][2030][11211][4.18.60] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - insufficient data (-1). Message: Insufficient data. ERRORCODE=-4499, SQLSTATE=08001
at com.ibm.db2.jcc.am.kd.a(kd.java:328)

On the login page, it asks me to contact the system administrator. I have to restart the app and the database to make it work again. Interestingly, the app and the database server are on the same machine/VM. As always, any help is appreciated.

This almost looks like an ipTables or some sort of SecureLinux function getting in the way of the network connection and terminating it. Have you tested it by turning off the seLinux services and ipTables? If it runs better, then start adding rules to prevent the secure frameworks from stepping on the network connections.

Continue reading