Why are BIRT report parameters failing in TRIRIGA 3.5.2?

I’m seeing an issue with report parameters in BIRT. I’ve added a report parameter and bound it to a filter condition. The report runs perfectly in Eclipse. But when I uploaded the same to TRIRIGA, it’s giving me errors while the report is rendering, after entering the parameters. Surprisingly, null checks have been implemented using a script at the table level as well as on the filters, so that optional parameters are dealt with. Here’s the exception trace…

This may be related to a known issue resolved in APAR IV96587. Try the most recent fix pack and see if it resolves the issue.  If it does not, I would put in a PMR.

[Admin: This post is related to the 11.13.15 post and 07.03.15 post about having issues with BIRT report parameters. To see other related posts, use the BIRT tag.]

Continue reading

IV97614: Cannot revise project in Schedule tab with Gantt section

If you attempt to revise a project from the Schedule tab, where the Gantt chart is visible, your session is expired and you receive an invalid session error. The issue was observed in Internet Explorer and Chrome, but not in Firefox.

An analysis from a Fiddler trace shows that when revising the project in Chrome, this POST to GanttDataUpload.jsp seems to kill the session. In Firefox, for whatever reason, this POST doesn’t occur, and the state transition is successful. To confirm that this is the scenario you are experiencing, use the following technote to run a Fiddler trace and check for the same GanttDataUpload.jsp call: IBM TRIRIGA using Fiddler for tracing web browser traffic.

As a temporary fix, use Firefox. When the record is in a read-only state, no Save action should be called on the Gantt. Moving forward, we resolved the session-kill issue when the user performs a Revise action on a project in the Schedule tab.

[Admin: This post is related to the 08.18.15 post about using Fiddler to trace TRIRIGA web traffic. To see other related posts, use the Gantt tag or Fiddler tag.]

Continue reading

How do you activate GC tracing for WebSphere Liberty (WLP)?

How do I activate Garbage Collection (GC) tracing for my IBM TRIRIGA application running on WebSphere Liberty Profile (WLP)? I need to start tracing GC for WLP to check if there are performance or stability issues due to GC runs.

[Admin: This post is related to the 09.29.14 post about tracing WebSphere GC runs for a TRIRIGA server.]

Continue reading

How is the performance when workflow instances are saved?

It is strongly recommended to set WF_INSTANCE_SAVE to ERRORS_ONLY in any environment where you care about performance. There is a dramatic performance impact if it is set to either PER_WORKFLOW_ALWAYS or ALWAYS. There will be an lesser impact if it is set to PER_WORKFLOW_PRODUCTION. Any workflow set to save will be 2-3 or more times slower in processing.

In a production environment, there is no reason to have every single workflow saved, as any debugging or tracing should occur in a lower (Dev or QA) environment. The performance impact of this setting far outweighs any perceived benefit of having the extreme baggage of the workflow instances saved in your database. There is at least a 2-3x performance gain when moving to ERRORS_ONLY. In addition, millions of rows can be added to the workflow instance and task tables. The Platform Maintenance Scheduler (Cleanup Agent) will take a very long time when it processes these tables. The constant deletion and addition of rows to these tables will thrash your tablespaces, causing them to become very fragmented, and wasting a huge amount of physical disk space.

The WF_INSTANCE_SAVE setting is so important that the value of NEVER was renamed to ERRORS_ONLY in 3.3.0 to highlight the fact that errors would be saved in workflows, thereby avoiding the unnecessary use of PER_WORKFLOW_ALWAYS, PER_WORKFLOW_PRODUCTION or ALWAYS in production environments. If an error is encountered, the NEVER or ERRORS_ONLY will save the workflow instance out for further inspection.

[Admin: This post is related to the 04.06.16 post, 09.11.15 post, and 07.14.15 post about issues with saving workflow instances.]

Continue reading

Why does the log grow quickly if WF_INSTANCE_SAVE is “ALWAYS”?

Why does the Microsoft SQL Server transaction log file get too big quickly if WF_INSTANCE_SAVE is set to “ALWAYS” on the IBM TRIRIGA product? We have set WF_INSTANCE_SAVE to “ALWAYS” in the TRIRIGAWEB.properties file, and we see the Microsoft SQL Server transaction log file getting too big really quickly, until it consumes all available disk space on the database server. Why does this happen?

When you set WF_INSTANCE_SAVE to “ALWAYS” in the TRIRIGAWEB.properties file, the code will start recording all workflow actions and details in specific tracing log BOs/tables in TRIRIGA. This will drastically increase the database activity due to all of the inserts in this tracing table, and the MS SQL Server Transaction log file will quickly start getting bigger and bigger as time goes by, until you may run into a lack of disk space on the database server.

Our IBM TRIRIGA Best Practice for System Performance document does not recommend you to set WF_INSTANCE_SAVE to “ALWAYS” in the TRIRIGAWEB.properties file at all. This property needs to be set to “ERRORS ONLY” to reduce the database activity regarding any tracing information from workflow runs.

[Admin: This post is related to the 08.26.14 post and 11.06.14 post about performance best practices.]

Continue reading

How do you use Fiddler to trace TRIRIGA web traffic?

When using the IBM TRIRIGA product, I am experiencing an issue that might be related to the network layer and I want to trace the web traffic for troubleshooting purposes. How can I use Fiddler for that purpose? I need to trace and analyze the incoming and outcoming network package flow for my Internet Browser session while troubleshooting an issue impacting the IBM TRIRIGA product and I want to use Fiddler for this purpose.

Fiddler is a third-party tool for monitoring requests made and received by a web browser. This information is often invaluable when troubleshooting a problem with the IBM TRIRIGA product. Due to the nature of IBM TRIRIGA, an error message may not always display the true cause of the error. A Fiddler trace will help by logging all HTTP requests or responses that may have been made. Fiddler can be downloaded from the following URL… http://www.telerik.com/fiddler

Continue reading 

How do you clean up millions of workflow instance records?

Is there an alternative way for cleaning up millions of IBM TRIRIGA workflow instance records? We have set Workflow Instance Recording to Always and this has been this way for lots of days. When running the Cleanup process for the first time after that, this takes too many hours to complete due to the millions of records kept in wf_step_inst BO/table. Is there any alternative and safe way for us to get rid of the unnecessary wf_step_inst table’s records faster?

First, Workflow Instance Recording should be always set to Errors Only, except if you have a lower environment (testing, development) and you want to trace some workflows runs. But this needs to be a temporary effort and you need to set this back to Errors Only as soon as you are done with your analysis. If this is kept set to Always, all workflow runs will save tracing records to the database. This will impact overall performance hugely and will keep too many records in the database, making your Cleanup process take way more time than expected when running. Setting Workflow Instance Recording to Errors Only is a requirement, based on our IBM TRIRIGA Best Practices guide.

Continue reading 

How do you trace WebSphere GC runs for an IBM TRIRIGA server?

How can I trace WebSphere Garbage Collection (GC) runs for a specific IBM TRIRIGA server (JVM) I have? How can I set it up properly? Need to know the impact of GC runs on system’s overall performance and determine if further tuning is needed for my IBM TRIRIGA system. Garbage collection (GC) is an integral part of the Java Virtual Machine (JVM) as it collects unused Java heap memory so that the application can continue allocating new objects. The effectiveness and performance of the GC play an important role in application performance and determinism. The Garbage Collection (GC) runs will be recorded on the native_stderr.log file located at folder “…ibm\websphere\appserver\profiles\\logs\”.

Continue reading