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 (22.214.171.124) or it will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.
- Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server. Set the following properties…
- Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
- 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…
- 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.]
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.]
We are currently using TRIRIGA 10.5.1/126.96.36.199. 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 188.8.131.52 and 184.108.40.206. 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 220.127.116.11, 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.]
After applying the TRIRIGA 18.104.22.168 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: This post is related to the 05.18.17 post about reports with filters creating long URIs in 22.214.171.124. To see other related posts, use the Filter tag.]
It looks like TRIRIGA 126.96.36.199 changed the way that reports are generated. After we enter a user filter and refresh, a very long URI is generated, which causes an error on the IBM HTTP Server: “Request-URI Too Large”. Previously, with an OOB query, the URL might look like: /html/en/default/reportTemplate/viewPageReport.jsp. But now, the URL is excessively long.
It looks like the filter details were sent in as headers to the server. But now, they are included in the URI. This is a major change for a fix pack and I believe that it shouldn’t have been included. This pretty much limits the number of columns and user filters that a report can have. Our environment is hosted by IBM and we don’t have access to the back-end server.
We will be addressing this issue in our next fix pack.
[Admin: This post is related to the 05.26.17 post about getting an error that the URL is too large for queries with filters. To see other related posts, use the Filter tag.]
After upgrading to TRIRIGA 3.5.2, we are facing an issue on editable queries, where the locator fields are not populating after selecting a value from the popup query. Also, it logs out after we select a value, click “OK”, and refresh. Has someone faced the same issue? Or is it a known issue?
This issue is resolved in the 188.8.131.52 Fix Pack and is now available on Fix Central. The readme file for 184.108.40.206 can be found here.
On TRIRIGA 3.5.2, the system functions that take parameters in workflows are broken. If I use any system function with parameters such as AddMonth, GetDays(), UppercaseCount(), etc., the parameter value will move outside the parentheses of the system function.
Can anyone reproduce this issue? It is critical and affecting many workflows since it is found on system functions. This issue is seen once clicking out of the workflow switch and then clicking back onto it again. This issue was found on a clean TRIRIGA 10.5.2/3.5.2 install on Windows Server and MS SQL Server 2016.
This was reported as an APAR IV91759 and is targeted to the 220.127.116.11 Fix Pack. You can contact Support, and request the 18.104.22.168 LA01 that contains the fix.
[Admin: This post is related to the 01.09.17 post about the workflow expression editor not saving correctly.]