I am installing TRIRIGA 3.5.0/10.5.0 on my local machine with WebLogic and Oracle 12c. But I am getting the following error:
[java] Connecting to system@jdbc:oracle:thin:@localhost:1521:orcl
[java] Exception encountered! java.sql.SQLException: ORA-65048: error encountered when processing the current DDL statement in pluggable database PDBORCL
[java] ORA-00959: tablespace 'TRIDATA_DATA' does not exist...
Installing to a pluggable database (PDB) or container database (CDB) is not supported in TRIRIGA 3.5.0. To resolve this, you will need to use the 3.5.2 platform installer or higher. Here is the 3.5.2 release note:
Installation: The installation of TRIRIGA Platform now supports connecting to Oracle via Service Name. This will allow you to use a RAC URL, or PDB installations. The installer will prompt for connecting via the older SID, or the Service Name as a section choice. (Tri-213951)
[Admin: This post is related to the 07.07.16 post and 01.26.16 post about getting an Oracle 12c error during install.]
We are currently planning our 3.5.2 upgrade, and I noticed in the 3.5.2 release notes that the “Reverse Association” flag is being deprecated in a future release. I’m assuming that the legacy queries which used this flag have been or are being changed and included in the application upgrades.
Is it possible that a list of these queries is published so that those of us who are not currently taking application upgrades can make the fixes manually? Or is there a way that we can easily query which queries are currently using this flag?
Here’s an SQL you can run to see which queries are using this flag. Note that while it will be fine to uncheck the “Reverse Association” flag for the vast majority of these queries, there may be some where this flag was intended and a larger redesign of the functionality is needed. I know I’ve purposefully used it once in the last ten years, but that was more to understand how it worked exactly and haven’t used it since…
Starting with the TRIRIGA 3.5.0 platform release, the Object Migration tool’s “Full Package” create mode was removed from the Object Migration tool. But with TRIRIGA 3.5.2, the new “Full Metadata Package” was added in its place.
From the 3.5.2 Release Notes
- Release Notes > Object Migration: The Create Mode field in Object Migration now contains a Full Metadata Package option. With this option, the export package contains all objects from the entire TRIRIGA system, except for most record data. The record data for Classifications is included in the package. However, any record data that is associated to the classifications is not included. This option replaces the Full Package option available in earlier releases.
From the 3.5.2 Knowledge Center
- New features > Create Full Metadata Package export option: You can create an export package that contains all objects from the entire system, except for most record data. The record data for Classifications is included in the package. However, any record data that is associated to the classifications is not included. This menu replaces the Full Package option of earlier versions.
- Creating an export package: To create a package that contains all objects, select Full Metadata Package. The package will contain all objects from the entire system, except for most record data. The record data for Classifications is included in the package. However, any record data that is associated to the classifications is not included.
Where is the information regarding IBM TRIRIGA Application Platform 3.5.2 and IBM TRIRIGA 10.5.2 features, installation, and more?
[Admin: This post is related to the 06.13.16 post about finding 3.5.1 and 10.5.1 information, the 12.11.15 post about finding 3.5.0 and 10.5.0 information, and the 10.01.15 post about finding 3.4.2 and 10.4.2 information. To see other related posts, search “where is the latest“ or “where can you find“.]
IBM TRIRIGA hosts a public beta for review and evaluation of our upcoming releases. You can access the site here. There is a very simple registration application that you must fill out, in order to gain access. That registration application can be found here (username: beta, password: signup).
We also have a public Slack channel to which you can request access, where you can engage development of new and upcoming features, as well as gain early previews of release notes and support matrices.
The IBM TRIRIGA beta is going to be refreshed to start our 3.5.3/10.5.3 beta on December 29th, and will be available again by January 3rd. During the refresh, the beta server will be unavailable. All previous user accounts will be removed, and registration will be required again to create new accounts and access the beta.
There’s also an IBM TRIRIGA demo site where you don’t have to register. Our TRIRIGA SaaS or “cloud” version has a viewable demo here.
[Admin: A similar message is also posted in the TRIRIGA Around the World Facebook group. This post is related to the 11.13.15 post about IBM TRIRIGA SaaS in the Cloud Shop.]
According to the release notes for 10.5:
“A new ‘External Mail From’ smart section is added to Notification BO and Form. The smart section is defined against triPeopleLink BO. The Notification workflow should be setup so that this section will be populated with the sender (From user) information. Also the email notification will look like it is coming from the user who sent it instead of the TRIRIGA System. (Tri-168369)”
When I perform a “Where Used” on the name and email fields in this section, it shows that they are not being used by any workflows. In other words, the section has been added to the notification form, but is not currently being populated from anywhere.
Does anybody know if this is working as designed? The wording of the release note is a bit ambiguous. I’m not sure if “the workflow should be set up” means we are supposed to configure this ourselves, or if it should be working OOB. Any guidance is much appreciated!
For this new feature to be implemented, any Notification workflow that sends an email will need to be modified to populate the sender (From user). The “From user” is not set by default.