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 188.8.131.52. 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.]
IBM has been recognized by many within the open-source community as a leader in open-source technology, and believes that our leadership in open source is a differentiating value for our clients. There are very many advantages in including the right open-source libraries and an extremely small number of disadvantages. Please read “IBM’s approach to open technology” for a complete understanding of IBM’s commitment to open source.
Within the IBM TRIRIGA Platform, we use over 125 different open-source libraries and packages to enhance the deliverable. A full listing of these libraries, and their accompanying licenses can be found in the notices.txt file under the \license\ directory of every TRIRIGA Platform install.
During TRIRIGA install, we encountered “Build Failed” and the Oracle WebLogic log contained the following. What happened?
####<Jan 23, 2018 4:47:14 PM ART> <Error> <Deployer>
<S-Tririga> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <7bf5687e-a5eb-47f9-9610-fd0f96db07ae-0000042e> <1516736834996> <BEA-149265> <Failure occurred in the execution of deployment request with ID "7285840482438638" for task "2". Error is:
[Admin: To see other related posts, use the WebLogic or Installation tag.]
Our customer has seen an issue when installing TRIRIGA 3.5.3 (Linux, Server build number: 276955) on an existing database (on 3.4.2 / 10.4.2). Everything goes well until starting up the server. Generally, TRIRIGA will run a database upgrade on the first startup when a build number difference is detected.
In the OM log, we notice that TRIRIGA tried to import the upgrade OM package… The import process started with the triPlatformObjectLabelManager package, but it failed to import a navigation item, which is newly created for Object Label Manager. I haven’t found any log which can explain this failure. I’ve checked the NAV_ITEM table. This navigation item wasn’t there before the upgrade process. Then all of the other packages are stuck on a pending status. Nothing happens after “Creating package from Zip file”. This behavior causes a lot of SQL update failures.
Meanwhile, on our Dev environment (Windows, Server build number: 279835), the upgrade went very well. You can find the difference in the logs. The OM log was set on “Debug” level on both servers. Note that the build number is slightly different between these two enviroments. Have you seen this kind of issue? Where can I find more details about the navigation item import failure?
[Admin: This post is related to the 02.17.17 post and 05.19.16 post about inconsistent OM validation results. To see other related posts, use the Object Migration tag or Upgrade tag.]
I am attempting a clean install of TRIRIGA 3.5.3 and according to the logs, it appears that the installation was successful within the was-ant.log. But I receive this error in the ant.log… When I access the application, I was unable to pull up the login page. Checking the server logs, I noticed these errors… The odd thing is that when I did a TRIRIGA 3.5.3 install on WebSphere Liberty, it worked perfectly…
The errors seem to indicate that you selected an upgrade, not a new install. Are you sure you selected a new install? Some of the environment properties that are needed to start up do not seem to be available. Did the database get created or are you pointing at an existing database? What happens if you do a select * from environment_properties on the database you are using?
The DB2 exception you are receiving seems to indicate you are running out of statement handles, but it’s hard to see this happen with a successful install.
[Admin: To see other related posts, use the WebSphere tag or “install error” search phrase.]
In a standard OOB installation of TRIRIGA on Windows Server 2012 R2, it gives the user group the “Execute” and “Special” permissions to the TRIRIGA folder. We are concerned from a security perspective: Why are the “Execute” and “Special” permissions needed for a standard installation? What are the minimum permissions needed for TRIRIGA to function correctly?
You can remove the user group “Execute” permission on Windows. Only the service user needs permissions to read from the install directory, and/or execute WebSphere Liberty under the TRIRIGA install directory (if so installed).
[Admin: To see other related posts, use the Permission tag or Security tag.]
We have already upgraded our platform to 184.108.40.206. We are currently in the process of upgrading our application from 10.3.2 to 10.5.2.
For the application upgrade, we have set up a staging environment with an initial install of 10.5.2 and we have configured all BOs, forms, and other objects to meet our current customization. My question is: What if we import the IBM upgrade OM packages (sequential from 10.4 to 10.5.2) to our current environment (which has all customization)? It would definitely overwrite all the customization and configuration, but does it affect the record data as well (e.g. lease records)?
When it overwrites the customization at the BO and form level, would it corrupt the record data since some of the custom fields on the records won’t exist at the BO level any more? And what happens after we import all our customization back in the current environment from the staging environment?
The short answer is: You wouldn’t apply the IBM upgrade OM packages. Instead, you’d build OMs in your now customized 10.5.2 environment and then apply them to your current environment.
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]