Feeding your TRIRIGA information needs

Tag Archives: Front End

I installed IBM TRIRIGA Application Platform 3.5.3 in Linux CentOS 7. While running the TRIRIGA installer, I selected an embedded server, that is IBM WebSphere Application Server (WAS) Liberty Profile 17.0.0.2. This server is successfully installed and up and running.

From the log, I found that the server host where IBM TRIRIGA is accessed has an URL something like this: http://some.static.ab-xyz.com:8001. This URL value was taken by default. I did not provide this value. My question is: How do I change this host name URL? Where is the setting for this?

I’m not sure what log you’re looking at and what specifically you’re seeing. What is set as your FRONT_END_SERVER value in your TRIRIGAWEB.properties file?

Is it possible to download the imported OM package from the front end or server?

Yes. Go to Tools > Object Migration. Locate the OM package, click the “Copy Package” icon link to the left of the OM name, then in the upper-right, click “Export”. Give it a name, click “Export”, then it will ask you to “Open” or “Save”. I would “Open” the ZIP to see where it was stored. There you have it!

We are using IdP-initiated SAML, and we access TRIRIGA via a link that looks something like this: http://idpprovider/applications/Tririga. Can we pass this link in FRONT_END_SERVER in TRIRIGAWEB.properties so that users can click on the link that they get in a work task email, and they can be redirected to TRIRIGA?

SAML does not support basic authentication for non-browser clients. This is a SAML limitation. See the following APAR IV88274 link.

We’ve noticed with the change from TRIRIGA 3.5.1 to 3.5.2, there is some strange behavior when switching to the Admin Console. First, after logging into the front end of TRIRIGA (http://{servername}:9080), and second, after attempting to switch to the Admin Console (http://{servername}:9080/html/en/default/admin), this results in a blank screen (both in IE and Chrome).

It is necessary to close the window or clear the browser cache in order to access the Admin Console successfully. Is this intentional security behavior or something that we have misconfigured?

This is a known issue that was regressed with the security changes in 3.5.2. The workaround is to make sure you specify the endpoint for either page:

Instead of {servername}:9080, use => {servername}:9080/index.html

Instead of {servername}:9080/html/en/default/admin, use => {servername}:9080/html/en/default/admin/index.jsp

When running a BIRT report, you get a stack trace error in the front end telling you that the report does not exist or contains errors. There is no indication that the .rptdesign file is missing in this error, just a reference to a path to a file \userfiles…

The BIRT engine is generating and throwing the stack in the response. We needed to wrap the response from BIRT and scan for exceptions and stack traces. Moving forward, the stack trace will no longer be shown.

When displaying date fields from a query, the BIRT report is displaying one day before, e.g., 06/02/2015 shows 06/01/2015.

Legacy Date Only fields in the application are stored in the back-end database as Date and Time format, where the time is set by default to 00:00:00, as it is not used in the front end. The BIRT reports interprets this as the day before (midnight), while TRIRIGA displays this as the current day (zero hour).

To diagnose the problem, run a query directly to the database and check if the Date Only field also contains the time stored with it. Observe if the time is 00:00:00. To resolve the problem, update the records by adding one hour to the back-end database fields, i.e., modify fields from a format of 99/99/9999 00:00:00 to 99/99/9999 01:00:00. The BIRT reports will now consider the day as the same as the front-end TRIRIGA application.