Can someone elaborate what is the use of the Instance ID field in the Application Metadata form? Why does it have to be -1? Also, can it be modified (say, using a workflow) at a later point of time while using the application?… Is an instance created when we put -1 as the Instance ID, which changes later on? If yes, can that be explicitly changed by some means? And what is the purpose behind it?
If you specify an application instance ID, that value will be used as a context ID for the primary data sources on your model. It works the same way as using the triplet-ds-context-id for child data sources. The difference is that application instance ID is a fixed value for the application and it will not be changed. The value -1 means that the instance ID is not used for this application. This is an application metadata, so there is no reason for a workflow to change that value.
[Admin: This post is related to the 02.25.26 post about building an app in the UX framework, and the 12.11.15 post about the UX framework.]
We’re seeing the following error in the server log:
Error executingsql: Sql[SQL=TRUNCATE WF_INSTANCE,DB transaction ID=(None)] Caused by: StatementCallback; bad SQL grammar [TRUNCATE WF_INSTANCE]; nested exception is java.sql.SQLException: Incorrect syntax near 'WF_INSTANCE'. [MID-2877677308]
Error executing sql: Sql[SQL=TRUNCATE WF_INSTANCE,DB transaction ID=(None)] Caused by: StatementCallback; bad SQL grammar [TRUNCATE WF_INSTANCE]; nested exception is java.sql.SQLException: Incorrect syntax near 'WF_INSTANCE'.
When WF_INSTANCE (workflow instances) are a high number, the TRUNCATE option runs into problems in some situations. Moving forward, we resolved an issue where massive amounts of workflow instances were running into an error when cleaning them up via the Platform Maintenance Scheduler (formerly Cleanup Agent).
When “Audit All Data” is turned on for a BO, the TRIRIGA platform is not correctly committing temporary data for records based on that business object. It appears that the “Save Permanent Record” workflow tasks (which are meant to commit temporary data for records of the BO) are trying to execute an audit of the object before it is created.
We needed to catch the SmartObjectNotFound exception… when smart section instance data is not committed, the parent record is committed, and “Audit All Data” is enabled. We improved how the exception is processed when temporary data is committed on a business object with auditing.
In one of our production instances, we have a table called TASK_RESULT_LIST containing almost one billion rows. What is the intent of that table and is there someway we can clean it up?
Anyway, when the Cleanup Agent runs, it is stopped with an Agent Interrupt Exception after 120 minutes (as per CLEAN_TIMEOUT in TRIRIGAWEB.properties). Though, it seems the Cleanup Agent doesn’t start the next day when that happens (or any following day until the process server is restarted). Is there some flag saying that the agent is already running and that flag is not getting reset when the agent is stopped due to hitting the CLEAN_TIMEOUT?
That TASK_RESULT_LIST is used to record workflow step instances. It is not safe to directly modify the table. The Cleanup Agent (a.k.a. Platform Maintenance Agent) is supposed to keep this table clean. Check the following TRIRIGAWEB.properties…
To help work around this, I would set the CLEAN_TIMEOUT property to 300. This will allow the Platform Maintenance Agent to run for a longer amount of time and clean up more records. The reason the table got so large, is that you had workflow instance recording on. Our recommendation is that workflow instance recording is never run in production, or for long periods of time. It is also not safe to truncate that table, as user action and approval tasks would be deleted and would no longer process. We also increased the default value of CLEAN_TIMEOUT to 300 in our next release…
Our customer has seen that sometimes when a Modify Metadata task has a unique constraint error on PK_GUI_INSTANCE recorded in the log, this causes the workflow instance to be saved and in turn creates a performance impact.
Does IBM TRIRIGA support multiple tabs on an internet browser for the same server? I want to open multiple tabs to open new sessions for the same server. Does IBM TRIRIGA support that?
No, this is not supported. Use a different internet browser instance or product for this purpose. When you open a connection to a server, the internet browser instance running will create files into the temporary folder or directory for that on the local or client machine. This includes cookies and authorization token information as well.
If you use the same internet browser instance and open multiple tabs accessing the same server, this will use the same temporary folder or directory area on the local or client machine. The same file names (conventions) will be used also since this is the same server being accessed. The second tab will be replacing the previous files and losing the connection information, and then invalidating any access to that server from that user.
We are currently using TRIRIGA to track our real estate leasing and capital projects. Recently, we have had 2 of our member firms from 2 other countries show interest in following the same TRIRIGA practices with leasing and capital projects as we currently follow.
My question is: How best can we have the 2 countries use the same TRIRIGA product we have, but just have another instance, instead of using our instance of TRIRIGA? This way, we would have 2 different instances for both of the countries. Also, is it possible to have country-specific logins so that users from one country can get into only their country’s instance of TRIRIGA?
[Admin: This post is related to the 09.05.16 post about getting started with Portfolio data.]
We have multiple TRIRIGA instances on our production environment. I’m wondering what is the best practice for deploying an object migration (OM) package in this kind of environment? Should we keep only one instance alive (and stop all of the other servers) before deploying the OM package?
We have an issue where stuck workflows will hang and not complete when we have Workflow Instance Recording set to “Errors Only”. It doesn’t happen every time and we haven’t found a way to recreate it. However, when we turn Workflow Instance Recording to “Always” on the server where the workflow is running, the workflow will complete. This occurs in both 184.108.40.206 and 3.5.1.x.
Has anyone seen this or know of a solution? We don’t want to have instance recording set to “Always” in Production.
[Admin: This post is related to the 05.09.16 post about workflows getting stuck, and the 04.26.16 post about performance when workflow instances are saved.]