Where do you set or change the host name URL?


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?

[Admin: To see other related posts, use the Hostname tag.]

Continue reading

Is there a way to download the imported OM package from server?


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!

[Admin: To see other related posts, use the Object Migration tag.]

Continue reading

How do you pass a SAML link in a work task notification email?


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.

[Admin: For convenience, here are the meanings of the acronyms: Identity Provider (IdP), Security Assertion Markup Language (SAML).] 

[Admin: This post is related to the 08.18.16 post about lack of support for non-browser clients. To see other related posts, use the SAML tag.]

Continue reading

What is causing the “TRIRIGA security token” warning in CI?


When attempting to make a connection through the CAD Integrator 12.1.3.0 client (with TRIRIGA 10.5/3.5), we are seeing the following error in the security log:

2016-11-18 10:37:55,142 INFO [com.tririga.architecture.security.logger.SecurityLogger] Login Attempt -- To: [/pc/ci/dispatch] Account: [null] From: [10.3.x.xxx] Status: [FAILED]
2016-11-18 10:37:55,705 INFO [com.tririga.architecture.security.logger.SecurityLogger] Login Attempt -- To: [/pc/ci/dispatch] Account: [jackie.lu] From: [10.3.x.xxx] Status: [SUCCESS]
2016-11-18 10:37:55,720 WARN [com.tririga.XSS] XSS potential: Request did not come in with TRIRIGA security token: /pc/ci/dispatch From: 10.3.x.xxx [MID-485378064]

The client fails to establish connection. Any thoughts on what could be causing this? We do not have SSO configured, and the FRONT_END_SERVER setting has been checked.

[Admin: The same question is also posted in the TRIRIGA Around the World Facebook group.]

Continue reading

IV88857: TRIRIGA 3.5.1.1 BIRT report stack error


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.

Continue reading

Why are date fields in BIRT reports displayed one day off?


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.

Continue reading

How do you set FRONT_END_SERVER in the TRIRIGA application?


Customers may encounter the following issues, if the FRONT_END_SERVER property of the TRIRIGA application is not properly set:

  • 1. Application is accessed, but the resources do not load.
  • 2. BIRT reports or Crystal Reports do not render correctly.
  • 3. Gantt charts are not being displayed.

First, check the FRONT_END_SERVER property in these locations: (1) TRIRIGA Admin Console > System Manager > TRIRIGA Web, (2) TRIRIGAWEB.properties file. Note that the value should exactly match the URL that is used to go to TRIRIGA in the browser.

Second, if you use something like http:// tririga.samplelink.org/ to go to TRIRIGA, then the FRONT_END_SERVER should be tririga.samplelink.org. [Admin: This is actually incorrect. The protocol is no longer optional.]

Third, if you use a port to access TRIRIGA, that must be included as well.

[Admin: This post is related to the 12.14.15 post about using the FRONT_END_SERVER setting, and the 07.27.15 post about the FRONT_END_SERVER protocol being a requirement.]

Continue reading

Where can you find the TRIRIGA SSO troubleshooting guide?


The IBM TRIRIGA single sign-on (SSO) troubleshooting guide is found on the Troubleshooting SSO wiki page, under the SSO parent wiki page, in our IBM TRIRIGA developerWorks wiki.

Troubleshooting single sign-on

The single most important resource to use from the TRIRIGA Platform perspective is the requestTest.jsp page.  This is a page internal to the TRIRIGA platform that will display the different areas of the HTTP header, and allow you to debug and set the third-party configuration correctly… Here are some issues that are known to occur with single sign-on, for example, if it is not configured properly.

  • Invalid username or password error…
  • Map labels are shown only in English…
  • HTTP requests are no longer forwarded to TRIRIGA…
  • FRONT_END_SERVER…
  • Adding SSL/HTTPS into the mix…
  • CA SiteMinder…
  • CAD Integrator error reporting with IIS 7…

[Admin: This post is related to the 05.29.15 post about the latest information on TRIRIGA single sign-on (SSO), and the 04.06.16 post about performance issues seen with SSO-enabled environments. To see other related posts, use the SSO tag.]

Continue reading

Getting “broken pipe” messages with TRIRIGA on WebLogic


Imagine that you are in your company’s IT department. No users are complaining about TRIRIGA for weeks, and you decide to do some preventive work. Where to start? Well, let’s take a look at the server.log and see how smooth the system is running:

2016-01-30 01:22:10,896 ERROR [com.tririga.platform.error.ErrorHandler]([ACTIVE] ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.Default (self-tuning)’) Report handled exception: com.tririga.platform.error.PlatformRuntimeException: java.io.IOException: Broken pipe[MID-1070145274]

OMG, you see a lot of messages stating “Broken pipe”! There has got to be something wrong, right? Well, not necessarily. These messages are rather typical in a TRIRIGA system served by WebLogic. The first question you need to raise is: Is there a problem being observed in the front-end, especially related to performance degradation? If not, there is no need to take action about those messages.

But if yes, there are a few steps you can take to prevent performance degradation, related (or even not related) to those messages. Engage your DBA and ask for Automatic Workload Repository (AWR) reports. That should give you a feel for where long-running queries or heavy page loading occurs. No need to say it, but this does not occur in WebSphere.

[Admin: This post is related to the 02.07.16 post about “broken pipe” exceptions in the server.log.]

Continue reading