I’ve noticed that the triStatusCL column of the T_TRIPEOPLE table has been defined as VARCHAR2(1000) by default. Can we resize it using SQL? What’s the impact? According to my understanding, all of the classification type fields are defined in the same way, correct?
This is actually set by design, and uses a thousand characters for compatibility reasons. But there might be a size change based on platform changes in the future.
[Admin: To see other related posts, use the Character tag or Classifications 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.]
The IBM TRIRIGA Connector for Business Applications (CBA) has the saveRecord() method. If saveRecord() runs without an action parameter, it triggers not-audited field validation (read-only, formulas, etc.). Is it fine to use this method without an action name?
For example, saveRecord could call a state transition by its name in a parameter. But a record could be in any state, so this state transition could be not-applicable to the current state. What if a record receives the wrong transition? (I guess InvalidActionNameException.) Should this situation be handled by process design? Or by state validations in the code which is difficult to maintain? Or another way?
[Admin: To see other related posts, use the CBA tag or Connector tag.]
We are running TRIRIGA 10.5.2 and 188.8.131.52. Some of our lease records are getting stuck in “Processing” status after we try to activate the record. Since it is processing, we have no buttons at the top to Revise, Save, etc. This only happens sometimes, and only to lease records that have payment schedules. From the looks of it, all the payment line items do get created. A couple questions:
- (1) Is there a fix to this to keep it from happening again?
- (2) Can these records that are stuck in processing be pushed to active or do they have to be re-entered?
I was actually able to apply a workflow fix provided by IBM so that this will not happen going forward. So far, it has been working as planned…
With regards to getting the leases “unstuck”, I created an editable query, imported the State Transition Actions (on the Advanced tab in the query form), and ran the report to select and process the “stuck” leases. This worked with no issues and I did not have to delete or retire the leases. They were functioning properly after getting them out of the “Processing” state.
[Admin: This post is related to the 01.12.16 post about records getting stuck. To see other related posts, use the Performance tag or Workflow tag.]
When the Operations team was changing a job plan, the wrong date was entered, and it created over 1,800 work tasks. They have since tried to retire them and they changed to Draft status. To get rid of these, can the job plan itself be retired?
[Admin: To see other related posts, use the Job Plan tag.]
I’ve noticed that if the record is read-only in its current state, we can still edit this record via the editable query. Is it possible to set editable fields, or the whole record, to read-only conditionally? For example, according to status?
Unfortunately, the platform does not handle this requirement. I would recommend adding a request for enhancement (RFE) for consideration in a future release.
[Admin: To see other related posts, use the Editable tag.]