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.]
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.]
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.]
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.]
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 [PDF] 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.]
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…
In some cases, additional layers of network devices will alter the http or https traffic generated on the application server sent to the client’s browser. Here are some tips to help troubleshoot behavior:
- Have the direct connection to the application server temporarly unrestricted, and allow logins directly to the application server port. For example, access http://appserver01:8001, http://appserver01:9080, http://appserver01:7001. If the issue cannot be observed at that level, then step one layer back (Web Server) and run the test there. If it works, then step one layer back, and test on the Load Balancer, or Security Filter layer.
- Once the layer that introduces the problem has been identified, engage with the support team for that layer, and explain the situation. A network trace, Fiddler log, or screenshot of the browser with the developer tools console open greatly increases the chances of tracking down a specific configuration change on the load balancer or security filter layer.
Common issues encountered:
- Blocking some files from being downloaded from TRIRIGA, or being sent through notifications. For example .xls or .pdf files with Russian or Cyrillic characters.
- Blocking some requests that seemingly have special characters, or combination of characters. For example, a double slash ( // ) contained within the path or request string.
- Altering the protocol scheme from https to http. Depending on the ssl termination point, browsers may request non-secure content when accessing secure https urls.