Having issues with OM packages & nav items during upgrade to 3.5.3

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

Continue reading

Is there a way to see the ci.log error when CI Smart Attach fails?

Is there a way to see the error generated when the CAD Integrator shows the following message? “The Smart Attach process failed. Please contact IBM Support.”

I’m getting this error after I verified there are no errors when I get to the point to attach the CAD drawing via AutoCAD. However, I’m getting this vague error. I modified the log4j file in the config directory to “DEBUG” mode. However, there are no logs generating in my laptop. Is this where the log file should have generated?

C:\ProgramData\IBM\TRIRIGA\CAD Integrator\log\ci.log

Okay, I was able to locate the “ci.log” file in my Windows folder. I had to set the Folder Options in Windows to show hidden folders because the “ProgramData” folder is a default hidden directory. However, after opening the “ci.log” file, the errors in the log is not organized in a way that can easily be debugged. There’s no error code to reference to research either via IBM or AutoCAD support portal…

Continue reading

Is there a way to enable TRIRIGA to use JSON not GWT-RPC calls?

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

Continue reading

UX: How do you debug your UX app?

Debugging hints

  • Import statements. Make sure that you include the “import” statement that’s needed. There is no error in the browser Dev Tools console when you forget. It just doesn’t show the component that you expect. This page talks about it.
  • Attribute names. The Polymer help text still shows old camelCase attribute names in their examples. Those are left over from version 0.5. For version 0.9, the XML attribute names are lower-case with hyphen (or dash) separators. For example, iron-media-query shows “<iron-media-query query=”(min-width: 600px)” queryMatches=”{{queryMatches}}”></iron-media-query>”. But actually, in version 0.9, you need to use query-matches, not queryMatches.
  • Data source actions. If you configure an action with a workflow, and that workflow has a property Object Type “-Any-“, then the Business Object field should be blank.

Continue reading

IV87340: Inefficient SQL used when financial rollups are executed

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.

Continue reading

IV87787: Integration object HTTP post can’t send UTF-8 characters

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

Continue reading

Is there an alternative way to debug custom workflow tasks?

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

Continue reading