Our customer has seen an issue when installing TRIRIGA 3.5.3 (Linux, Server build number: 276955) on an existing database (on 3.4.2 / 10.4.2). Everything goes well until starting up the server. Generally, TRIRIGA will run a database upgrade on the first startup when a build number difference is detected.
In the OM log, we notice that TRIRIGA tried to import the upgrade OM package… The import process started with the triPlatformObjectLabelManager package, but it failed to import a navigation item, which is newly created for Object Label Manager. I haven’t found any log which can explain this failure. I’ve checked the NAV_ITEM table. This navigation item wasn’t there before the upgrade process. Then all of the other packages are stuck on a pending status. Nothing happens after “Creating package from Zip file”. This behavior causes a lot of SQL update failures.
Meanwhile, on our Dev environment (Windows, Server build number: 279835), the upgrade went very well. You can find the difference in the logs. The OM log was set on “Debug” level on both servers. Note that the build number is slightly different between these two enviroments. Have you seen this kind of issue? Where can I find more details about the navigation item import failure?
[Admin: This post is related to the 02.17.17 post and 05.19.16 post about inconsistent OM validation results. To see other related posts, use the Object Migration tag or Upgrade tag.]
I am working on creating scripts for the TRIRIGA application. I am using HPE LoadRunner for this purpose. As the TRIRIGA application uses GWT-RPC calls, we have some encrypted content being communicated between the TRIRIGA server and browser. We did use the web debuggers and tools, but this content is encrypted.
Do we have the option in TRIRIGA to enable it to use the JSON or any other readable format, rather than GWT-RPC, by default? It will enable us to capture the decrypted content and change the data for replay of our scripts as we need.
[Admin: This post is related to the 03.11.15 post about sharing a correlation file for LoadRunner.]
The use of the IN clause is grossly inefficient and it is used, not once, but twice. At first, it was causing full table scans. The index creates helped, but that is a band-aid. The query should be rewritten since all tables can easily be joined on the transaction_id column.
Indexes have been added, and budget data access is now sent through SQL logging, so that the times can be found in debug performance logging. Moving forward, we resolved a performance issue with financial rollups and budget transactions. The SQL is as efficient as it can be. The use of joins did not result in a query plan that was any better.
The TRIRIGA integration object’s XML post type requests are not correctly encoding UTF-8 characters. As a result, double-byte characters, although they appear correctly in the server.log when the integration object’s “Debug” is clicked, are seen by the receiver as “??”.
The issue was that XML post type requests were not correctly handling UTF-8 characters. The fix is to include UTF-8 content binding when the entity is being added to the request. Moving forward, we resolved an integration object HTTP post scheme issue, where multibyte characters were not being correctly handled in the outgoing HTTP request. Please note with this fix, if for some reason your integration object HTTP post scheme configuration leaves the Content-Type field blank, and the Content-Type is not defined in the Headers field, then the Content-Type of the HTTP request will default to: “Content-Type: text/plain; charset=UTF-8”. On prior releases, it defaulted to: “Content-Type: null”.
Is there any alternative way to troubleshoot custom tasks in IBM TRIRIGA workflows? We have a need to troubleshoot some custom workflows, but we do not want to use Workflow Instance recording set to ALWAYS, because this can have a big impact on system performance and consume lots of resources.
IBM TRIRIGA has made documentation available on how to have DEBUG class and code incorporated into the IBM TRIRIGA library directory, and then use them on workflows to trace their current status and variable values. The results will be printed out in the server.log file. Note that the documentation is provided “as-is” and it is under under no warranty. We recommend that customers apply it on lower environments (Dev, QA, Test) first to test this out and confirm its effectiveness. The IBM TRIRIGA wiki documentation is: Simple Workflow Logging Custom Task.
[Admin: This post is related to the 04.20.16 post about using a custom task for basic workflow logging.]