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 220.127.116.11. 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.]
I need some clarification about the state transitions in an object. How do we decide that a record must be in “Read Only” mode for a particular state?
- (1) Check the “Read Only” property for all the transitions coming into that state.
- (2) Check the “Read Only” property for all the transitions going out from that state.
- (3) Both 1 and 2.
Let me know about this, or if there any other situations which can put a record in read-only mode for that state.
[Admin: To see other related posts, use the Read-Only tag.]
If you attempt to revise a project from the Schedule tab, where the Gantt chart is visible, your session is expired and you receive an invalid session error. The issue was observed in Internet Explorer and Chrome, but not in Firefox.
An analysis from a Fiddler trace shows that when revising the project in Chrome, this POST to GanttDataUpload.jsp seems to kill the session. In Firefox, for whatever reason, this POST doesn’t occur, and the state transition is successful. To confirm that this is the scenario you are experiencing, use the following technote to run a Fiddler trace and check for the same GanttDataUpload.jsp call: IBM TRIRIGA using Fiddler for tracing web browser traffic.
As a temporary fix, use Firefox. When the record is in a read-only state, no Save action should be called on the Gantt. Moving forward, we resolved the session-kill issue when the user performs a Revise action on a project in the Schedule tab.
[Admin: This post is related to the 08.18.15 post about using Fiddler to trace TRIRIGA web traffic. To see other related posts, use the Gantt tag or Fiddler tag.]
I have an issue where it is not possible for non-Admin users to trigger the Create state transition through our OSLC interface. Instead, we get the following error:
2017-06-27 13:08:10.301 UTC ERROR [com.tririga.platform.integration.oslc.OslcRequestDispatcherImpl](Default Executor-thread-34280) Failed to read message: null
2017-06-27 13:08:10.301 UTC ERROR [com.tririga.platform.integration.oslc.OslcRequestDispatcherImpl](Default Executor-thread-34280) Exception in OSLC call: com.tririga.platform.integration.oslc.OslcException. message=java.lang.ClassCastException: com.tririga.platform.metadata.domain.BoStateTransitionId incompatible with com.tririga.platform.metadata.domain.gui.GuiStateTransitionMetadata
The fact that I am able to create and associate the record using an Admin user says to me that this is related to permissions, but I’ve made sure that the user has full security access for both the BO/form it is trying to create, the BO/form that it is attaching it to, and all other BOs/forms that are associated to it, and it still gives me the error above.
When I open the created record that my Admin user created, it looks to be correct. But when I open the one that the non-Admin user tried to create, it shows an empty record. None of the fields are saved in a null state, which of course is because it didn’t get created, the Create state transition was not triggered. Any idea of what is causing this issue? And how to resolve it?
[Admin: To see other related posts, use the OSLC tag.]
Since TRIRIGA is new territory for a lot of you out there, and I have already received various queries about this, let’s take a brief look at the correct sequence to create a new TRIRIGA classification as follows:
- 1. Create a new BO within the Classification module, and add other fields, if needed.
- 2. Set up the Publish Name (BO Mapping). Tip: For classifications, you use the Name field as the lone field in the Publish Name to prevent entering duplicate classification entries. The Name field is in the Record Information section when you click Find in the BO Mapping tool.
- 3. Save the BO.
- 4. Create an association between the new BO and itself by using Is Parent Of. This action creates an Include. Note: Create this association from within the Data Modeler, not within the Association Manager. Also, when creating Includes, ensure that the Parent BO is in the Revision in Progress state before you create the association. Otherwise, the Include is not created properly.
- 5. Publish the BO.
- 6. Revise the Classification BO.
- 7. Create an association between the Classification BO and the new BO that was created in Step 1 using Is Parent Of. This action creates an Include.
- 8. Publish the Classification BO.
- 9. Copy the triClassification form and assign the new form to the BO that was created in Step 1. Add at least the Name field to the form.
- 10. Change the label of the new form to match the label of the new BO.
- 11. In the State Family, click Find to import the other states and transitions.
- 12. In the Includes/Forms tab, add the newly created form to the Includes list. (Add it to itself.)
- 13. Publish the form.
- 14. Revise the triClassification form.
- 15. In the Includes/Forms tab, add the newly created form to the Includes list.
- 16. Publish the triClassification form.
Thus far, we have the Classification definition metadata and no Classification records exist yet. In order to create records, follow the last 2 steps as follows:
- 17. From the Classification Hierarchy Master detail view, create the local parent for the new Classification as a child of the Hierarchy root record.
- 18. Create the actual new Classification records under the local root for the new Classification.
[Admin: To see other related posts, use the Classifications tag.]