Which core objects should you avoid in making modifications?

The following objects are core objects in TRIRIGA Application Platform functionality and any modifications to these objects are not supported by TRIRIGA.

Any TRIRIGA-shipped Business Objects belonging to the following Modules should not be modified. Care should also be taken in modifying any Forms, Queries and Workflows belonging to the following Modules as platform functionality can be affected. (There may be other objects not included in this list.)

• Document
• Group
• Mail
• System
• triGIS
• triIntegration
• triOslc
• triPlatformDBTableManager
• triPlatformMeta
• triPlatformObjectLabelManager
• triPlatformPerformanceAnalyzer

[Admin: To see other related posts, use the Best Practices tag.]

Do you need to include module as selected object in the OM package?

I added new fields to a BO, and went to Object Migration to package the BO for export. I noticed that when I search for the changes to that BO, it sometimes list the module as a possible selection. Do I need to include the module as a selected object in the OM package? I usually ignore the module from the OM package, but wondering I’m if there will be a problem down the road by doing so.

If the module was imported previously to the target environment, then no, you do not need to import it again when you bring in the changes from the BO.

[Admin: To see other related posts, use the Object Migration tag.]

IV97419: Object Label Manager has forms with the same object name

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.]

IV96036: DataConnect issue with same BO name in different modules

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.]

IV95403: Locator query select is not showing module-level queries

If you open up an out-of-the-box form and go to a locator field in the form, the query that is listed as a part of the field’s “Locator Query” properties may not appear when you click the picker and view the list of queries.

An example of this problem is seen in the triContract > triLeaseAbstract form’s triLocationLookupTX field. The query “Location – Find – Active Property, Building, Structure, and Retail Location or Lease” is listed as the locator query, but if you click the picker next to that field, you cannot actually select that query.

If we need to show all of the queries based on the module, then we need to check if the BO is the base BO, then ignore it and retrieve all of the queries based on the moduleId. Moving forward, we resolved an issue where the locator query against a base BO will now return all of the queries in that module.

[Admin: To see other related posts, use the Locator tag.]

What are the triLocationLink and triGeographyLink BOs used for?

I noticed that some workflows reference the triLocationLink and triGeographyLink business objects. What is the purpose or function of these two business objects?

They’re meant to allow defining a single association relationship to any BO under the Location or Geography modules. You’ll notice that a smart section such as Primary Location on the Real Estate Lease record is a smart section to LocationLink rather than any specific BO under the Location module such as Building, Land, or Property.

How do you create a TRIRIGA classification?

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.]