Can you run the IBM TRIRIGA script after applying the 3.5.x fix pack?


Can I still run the TRIRIGA “SetVarCharColsToNumeric” script after I have applied the 3.5.x fix pack?

Yes. You can apply the script regardless of the TRIRIGA platform version. But it MUST be applied BEFORE upgrading the application.

[Admin: This post is related to the 04.28.17 post about running the MS SQL “SetVarcharColsToNumeric” scripts. To see other related posts, use the Scripts tag.]

Continue reading

Advertisements

Why is the lease record stuck in “Processing” during activation?


We are running TRIRIGA 10.5.2 and 3.5.2.2. Some of our lease records are getting stuck in “Processing” status after we try to activate the record. Since it is processing, we have no buttons at the top to Revise, Save, etc. This only happens sometimes, and only to lease records that have payment schedules. From the looks of it, all the payment line items do get created. A couple questions:

  • (1) Is there a fix to this to keep it from happening again?
  • (2) Can these records that are stuck in processing be pushed to active or do they have to be re-entered?

I was actually able to apply a workflow fix provided by IBM so that this will not happen going forward. So far, it has been working as planned…

With regards to getting the leases “unstuck”, I created an editable query, imported the State Transition Actions (on the Advanced tab in the query form), and ran the report to select and process the “stuck” leases. This worked with no issues and I did not have to delete or retire the leases. They were functioning properly after getting them out of the “Processing” state.

[Admin: This post is related to the 01.12.16 post about records getting stuck. To see other related posts, use the Performance tag or Workflow tag.]

Continue reading

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

How do you configure TRIRIGA for Tivoli Directory Integrator (TDI)?


You can configure TRIRIGA to use Tivoli Directory Integrator as its ETL runtime engine to run ETLJobItems from within TRIRIGA.

Before you begin

Install Tivoli Directory Integrator, if not already installed, on all the TRIRIGA systems that could run a TDI ETL Job Item.  During the TDI install:

  • Make note of the installation directory you enter on the Destination panel. You will enter this value later in TRIRIGAWEB.properties.
  • Select either installation type. TRIRIGA requires only the TDI Server component.
  • When prompted for the location of the Solution Directory, you can select any option. TRIRIGA specifies its own solution directory at runtime.  However selecting the option “Use Install Directory” may simplify troubleshooting.
  • Make note of the value you enter in the Server Port field on the Server Port Values Panel. You will enter this value later in TRIRIGAWEB.properties.
  • Clear the “Start the Configuration Editor” check box on the Install Complete panel.
  • Note: This step is very important for TDI/TRIRIGA integration to work. After you have installed Tivoli Directory Integrator, update it with the recommended fix packs (per TRIRIGA support matrix). TDI must be at least at FP04 (7.1.1.4) or it  will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.

Procedure

  1. Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server.  Set the following properties…
  2. Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
  3. Edit TDI global.properties file to allow TRIRIGA to check and stop the TDI server from localhost without requiring authentication and authorization certificates. Set the api.remote.ssl.on property to false to tell TDI to trust requests from localhost…
  4. Start Tivoli Directory Integrator Agent from TRIRIGA Admin Console and verify that it starts successfully…

[Admin: This post is related to the 08.03.16 post about installing, upgrading, or uninstalling TRIRIGA TDI, and the 05.01.16 post about documentation on developing TDI with TRIRIGA. To see other related posts, use the TDI tag.]

Continue reading

Changing functionality in TRIRIGA to fix security vulnerabilities


In this day and age, security is a very hot topic. As soon as one vulnerability is addressed and mitigated, another one is found. It is a vicious circle of identifying and addressing vulnerabilities that does not seem to let up. In our fix pack release notes, information regarding the mitigation of vulnerabilities that were addressed without an APAR is listed. And sometimes, a vulnerability is addressed as an APAR.

The reason I am mentioning security vulnerabilities is that sometimes, when they are resolved, there is an impact on existing functionality, which may not always be clear. Sometimes, the result of fixing vulnerabilities can “change” functionality. As an example, in the TRIRIGA 3.5.2 release, external URL navigation items will now open in a new window to avoid cross-origin scripting vulnerabilities…

As the product develops and security vulnerabilities are found and addressed, it could mean a change in how something works. Reading the release notes can be a source of information, but it may not always be clear why something changed. We all know change is hard, especially when we are so used to it working in a certain way. I don’t know about you, but if the change was made to address a security vulnerability, I can live with that and accept the change.

[Admin: This post is related to the 04.07.17 post about APAR IV94912 where “External URL” navigation items may no longer work. To see other related posts, use the Security tag or Vulnerability tag.]

Continue reading

Why does the report portal section keep loading forever?


We are currently using TRIRIGA 10.5.1/3.5.1.1. If a particular portal section with a report has a result set of more than the property “Max Records Displayed”, then the results are not shown, and the portal section just keeps loading. Why?

However, the behavior is fine if the results returned are within the limit set in the portal section. Also, when the section is maximized, we can see all the results. It works in the case of a hierarchy query too.

We had a defect/APAR where the Max Records Displayed parameter was being ignored, and the entire result set was being pulled back. The issue is resolved in 3.5.1.2 and 3.5.2.2. Here is the release note: “Portal section queries display the maximum results that are specified in the Portal Builder. (Tri-237640-IV87771)”

I believe this fix will resolve your problem. In 3.5.1.1, queries are returning the entire result set, and are not stopping at the max count. My recommendation is to upgrade to the the fix pack with this fix, and see where you stand after that.

[Admin: This post is related to the 08.16.16 post about portal sections not showing the defined number of results. To see other related posts, use the Portal tag.]

Continue reading

IV96587: Getting error that URL is too large for queries with filters


After applying the TRIRIGA 3.5.2.2 fix pack, if you have an editable query with at least 10 filter columns, when you filter on the report, you will get the URL error.

We needed to implement the same code from viewPageReport.jsp to viewPage.jsp. Moving forward, we resolved an issue, where filtering on an editable query will make the URL big enough to break the specified limit for URLs on Internet Explorer.

[Admin: A similar article is also posted in the IBM TRIRIGA blog. This post is related to the 05.18.17 post about reports with filters creating long URIs in 3.5.2.2. To see other related posts, use the Filter tag.]

Continue reading