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 220.127.116.11. 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.]
Is it necessary to have a separate Microsoft IIS server for every IBM TRIRIGA application server?
It is not a requirement to have a separate Microsoft IIS server for every IBM TRIRIGA application server. Your IT team should determine if this is something that they want or need to do.
[Admin: To see other related posts, use the IIS tag.]
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.]
I added a new date field, cstReminderDateDA, to a custom business object. For existing records, there is a requirement that cstReminderDate be set to the value of an existing date field (cstDueDateDA) minus 30 days, i.e. cstReminderDateDA = (cstDueDateDA – 30). This would be pretty straightforward, except that both cstReminderDateDA and cstDueDateDA are stored as numeric fields in our Microsoft SQL Server database. How do I populate cstReminderDateDA?
IBM TRIRIGA stores the date as epoch time. See the following wiki link explaining this. If you do some searching, you will find some functions available for SQL Server for data calculations.
[Admin: To see other related posts, use the Epoch Time 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.]
I made a big import of data in TRIRIGA, but the resources were not enough to proceed. So I have to stop TRIRIGA and truncate all events to stop the import. But now, the database log never stops growing and crashing the database. Is there a way to clean up and make TRIRIGA stable?
If this is Microsoft SQL Server, this may be related to the following SQL Server defect: SQL Server crashes when the log file of tempdb database is full in SQL Server 2012 or SQL Server 2014.
[Admin: To see other related posts, use the SQL tag or “sql server” 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 are seeing servers dropping out of the “Active Servers” table in the Admin Console > Agent Manager page. We are running multiple environments, each with platform version 18.104.22.168 with two UI and two process servers, and have experienced this across multiple environments. Current observations:
- Both UI and process servers can drop out, and it’s not the same server every time.
- Servers can be accessed and logged into, even if they are gone from the “Active Servers” table.
- A restart of the server will make the servers appear again.
Our current approach is to monitor daily and when a server drops, take a look in the logs for that day. Any other ideas? What controls when servers are listed or not in the “Active Servers” table in the Admin Console > Agent Manager page?
[Admin: To see other related posts, use the Admin Console tag.]
Is there a way to clear server caches without logging into the Admin Console?
Beginning in IBM TRIRIGA Platform 3.5.1, TRIRIGA delivered an enhancement for this to be done via workflow. The pertinent release notes can be found from this wiki page. Here is an excerpt from the release notes on the topic:
A custom task class has been added for workflow which triggers a global cache clear across all servers.
You can create a custom task and specify the following in the class field: com.tririga.platform.admin.cache.web.CacheProcessingCustomTask $RefreshAllCache
The custom task will perform a global cache clear on the server where the workflow runs as if it were triggered from that server’s Administrator Console. (Tri-211723)
[Admin: To see other related posts, use the Admin Console tag or Cache tag.]
We have quite a lot of rows in the extended formula queue that started to back up since Aug 29. At one point, we had over 900K in the queue and the process server is processing it pretty slowly. As of Sep 8, the system is still processing the queue. We are adding daily on average over 125K rows to the EF_QUEUE table.
We tried starting and stopping the Extended Formula Agent and Formula Recalc Agent and tried rebooting the process servers. We swapped the agents to run on different servers. We also ran the segment shrink on the EF_QUEUE table and gathered statistics. It is still extremely slow. We still have over 500K in the queue.
In parallel, we did open the platform logging on the extended formula activity and cache building, and we are working to identify the processes that can be fixed to reduce the multiple calls to the Extended Formula Agent queue. Do you have any recommendations to speed up the process to clear the extended formula queue?
Review the following two APARs. They may need to be applied to your environment to address this issue: (1) Platform: APAR IV87030. (2) Application: APAR IV87104.
[Admin: This post is related to the 07.28.16 post and 05.04.16 post about the Extended Formula (EF) Agent not processing and backing up the queue. To see other related posts, use the Extended Formula tag.]