Object Labels and Revisions
Starting in TRIRIGA 3.5.3, consider converting the TRIRIGA as-shipped objects that you renamed and modified back to the TRIRIGA objects from which they originated.
The purpose of the new conversion process is to enable the objects to use the new TRIRIGA object revisioning capabilities while preserving your object modifications. When you make future modifications to the objects, the modifications are saved in object revisions. Ultimately, the object revisioning and object labeling capabilities and tools aid in the future upgrade of your TRIRIGA applications.
For more information, see the documents, (1) “Converting your modified TRIRIGA objects to use the TRIRIGA revisioning features and application upgrade best practices” and (2) “Best practices for upgrading your TRIRIGA applications“.
[Admin: This post is related to the 09.24.15 post about the best practices for configuring and upgrading TRIRIGA applications. To see other related posts, use the Best Practices tag or Object Label tag.]
We have some corrupted records, which appeared across 2 different BOs so far. We can’t delete them from the application level, and the cleanup script won’t delete them either, because they can’t be found under the IBS_SPEC table. Does anyone have a SQL to properly cleanup those records from the T_ table?
[Admin: This post is related to the 02.10.15 post about purging records from a BO. To see other related posts, use the Cleanup tag or SQL tag.]
I noticed that after I check to add a field into a smart section that I am not able to uncheck the field after the BO has been published. Is there a way to uncheck the field? Or is my only option to delete the smart section in Data Modeler and recreate the smart section?
In Data Modeler, the smart sections show up in yellow in the association list. If the business object is in revision, and you click on the blue box to the left of the smart section in the yellow box, it will display the smart section field list. From there, you can select fields and click the Delete button to remove them. You may need to remove them from any forms using them before it allows the deletion though.
[Admin: To see other related posts, use the Smart Section tag.]
When the user go through the Object Label Manager to access a form and change the name. The system allows you to name it the same as another form, resulting in duplicate form names. There is currently no error handling for this. Meanwhile, if you access the form from the Form Builder itself and try naming it the same as another, the system will give you an error.
The issue was that the link into Form Builder from Object Label Manager’s Labeled Objects tab was not passing in the module ID and the BO ID for the form, thus the unique name validation for the module was failing to occur. This fix obtains the the module ID and BO ID for the form selected and correctly passes it to Form Builder. Moving forward, we resolved an issue in Object Label Manager, where opening a form from a link under the Labeled Objects tab would allow a user to change the name of the opened form to a name that already existed in the form’s module.
[Admin: To see other related posts, use the Object Label Manager tag.]
I recently set up a new environment in which I need to migrate the classifications (not just the record data) from the existing system. What is the fastest way to do this and ensure that the classifications are set up properly in the new system?
I migrated the BOs and forms. I checked the Include association for the BO to itself and with the classification BO. The form has been added to the “Includes/Forms” tab of itself as well as the classification form. But I still don’t see this BO added under the classification hierarchy when I click on “New” to create the root record.
[Admin: This post is related to the 03.29.17 post about creating a classification. To see other related posts, use the Classifications tag or Object Migration tag.]
When using a query and applying filters to classification or business object type fields, there are instances in which the data may not filter as expected. This can happen when the referenced classification or business object records are renamed, and the query is filtering on those name values. To summarize the scenario:
- (1) A user creates a record that contains a classification field, and populates that classification field with a value.
- (2) Another user changes the name of the classification record, which was used to populate the field in #1.
- (3) A user then runs a query that contains the field referenced in #1, and tries to filter values…
In order for filters to take effect for the most current value of a classification or business object type record when changed, records referencing those values in their fields must be updated. One approach to doing this is writing a simple workflow that updates the referenced data:
- Start Task: Workflow triggers on the classification object.
- Task 1: Gets the associated referenced object.
- Task 2: Clears the classification value.
- Task 3: Maps the classification field as the “Source” to the target field.
Note: For every object that the classification field references, the 3 tasks must be repeated. The workflow should only be triggered as an asynchronous process, since the workflow processing time will vary with how many records need to be updated.
[Admin: This post is related to the 06.08.17 post about SQL data not matching the viewed application data, and the 01.04.17 post about filters failing when using changed classification values. To see other related posts, use the Filter tag.]
When having two business objects (BOs) with the same name in different modules, and you select the “Validate” check box on DataConnect (DC) runs, this will cause an SQL statement (built to receive a single row, the BO name) to fail, since the logic does not include the module on the WHERE clause.
The DataConnect job issue was that the File-to-DC validation logic had SQL that assumed BO names are unique, and did not account for same-named BOs in different modules. This fix includes a module name parameter to the logic, so that the SQL knows from which module to retrieve the BO. Moving forward, we resolved an integration object File-to-DC issue involving the “Validate” check box. When the “Validate” check box was selected, the validation process would fail if the BO being validated had the same name as another BO in a different module.
[Admin: To see other related posts, use the DataConnect tag.]