Feeding your TRIRIGA information needs

Tag Archives: Business Object

We want to integrate IBM TRIRIGA with FileNet using CMIS 1.1, but we need to know what is all of the standard metadata that TRIRIGA sends to FileNet. For example, the file name, date creation, date modification, document type, document size, TRIRIGA user owner, etc. And if it is possible to send custom metadata when creating new custom fields in the Document business object? How can we do it?

The following properties are sent as part of the integration: Document Name, Document Type, Document Path. The Owner is going to be the CMIS username as defined in the TRIRIGAWEB.properties. Further custom metadata is not supported. The purpose of the CMIS integration is to have the binary content not stored in the TRIRIGA database as BLOBs.

[Admin: This post is related to the 07.26.17 post about CMIS FileNet integration issues, and the 12.02.16 post about integrating with CMIS and ECM solutions. To see other related posts, use the CMIS tag or ECM tag.]

The short answer is that IBM TRIRIGA sees this as an unsupported customization of the Group record. Let’s clarify this further. Even though technically, behind the scenes, Groups are record data, they are currently considered TRIRIGA platform-owned and so, controlled BOs (business objects).

The platform controls exactly what Group data the object migration (OM) can export/import. Thus, any fields added to the Group BO will not be recognized by OM when exporting/importing Group records. Modifications to any platform-owned and controlled BOs are not supported. This does not just apply to Group BOs only.

If the BO is a platform-controlled object and any changes are not supported, then why does the platform currently allow changes to it?

IBM TRIRIGA currently does not prevent users from modifying any BOs, even the ones that are specifically necessary for core platform functionality. The Group BO, Document BO, and triPlatformObjectLabelManager BO are just a few examples. Although the platform does nothing to prevent users from modifying these BOs, TRIRIGA does not support the modification of any of these.

For these core platform BOs, the object migration tool is designed to pull exactly what it needs for the designed platform functionality when exporting/importing the record data tied to these BOs. In other words, any modifications will compromise the TRIRIGA platform integrity, so it becomes an unsupported action if done so.

The wiki on Core objects in TRIRIGA Application Platform functionality details the core platform business objects that should not be modified. Meanwhile, for the expressed requirement to see Group modifications exported/imported with Group record data, a request for enhancement (RFE) was submitted and will be considered for a potential platform change in a future TRIRIGA release.

[Admin: This post is related to the 11.07.17 post about core objects you shouldn’t modify. To see other related posts, use the Groups tag or Object Migration tag.]

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

I added a new date field, cstReminderDateDA, to a custom business object. For existing records, there is a requirement that cstReminderDate be set to the value of an existing date field (cstDueDateDA) minus 30 days, i.e. cstReminderDateDA = (cstDueDateDA – 30). This would be pretty straightforward, except that both cstReminderDateDA and cstDueDateDA are stored as numeric fields in our Microsoft SQL Server database. How do I populate cstReminderDateDA?

IBM TRIRIGA stores the date as epoch time. See the following wiki link explaining this. If you do some searching, you will find some functions available for SQL Server for data calculations.

We are on TRIRIGA 3.5.2 and 10.5.2. We have a business need to add another level in the Geography hierarchy (under City). Technically, it is possible to change the hierarchy to add another BO associated to the triCity object. But we wonder if there is an impact on the standard behavior of TRIRIGA? If not, then what is the best method? To create a new BO? Or to create a city hierarchy under the city like a space under space? Has someone already done this kind of modification?

Creating a new BO would be the usual method. You would need to be sure that you create the parent/child association so that you locate the new BO type in the hierarchy. For the most part, the workflows in Location are BO level, but it would be useful to review your environment to see if any customizations have been made.

We have already upgraded our platform to 3.5.2.1. We are currently in the process of upgrading our application from 10.3.2 to 10.5.2.

For the application upgrade, we have set up a staging environment with an initial install of 10.5.2 and we have configured all BOs, forms, and other objects to meet our current customization. My question is: What if we import the IBM upgrade OM packages (sequential from 10.4 to 10.5.2) to our current environment (which has all customization)? It would definitely overwrite all the customization and configuration, but does it affect the record data as well (e.g. lease records)?

When it overwrites the customization at the BO and form level, would it corrupt the record data since some of the custom fields on the records won’t exist at the BO level any more? And what happens after we import all our customization back in the current environment from the staging environment?

The short answer is: You wouldn’t apply the IBM upgrade OM packages. Instead, you’d build OMs in your now customized 10.5.2 environment and then apply them to your current environment.

I have some records in the classifications hierarchy. These classifications are now associated to several BOs, like building equipment and tasks. I want to delete some of the values in the classification hierarchy because they are values we do not want users to use in the future. I understand that the best practice is the change the status of the record to “Retire” for audit purposes. But if we decided to just delete those records, what is the impact to any of the associated BOs? Would I have to create a workflow to remove the associations?

There are certain classification records that are used in forms, workflows, and/or queries. If you delete one of these records that are used in the application, you will in effect, lose some application functionality. Take, for example, “triClauseType” (Lease Clause), where several of these classification values are used on the Lease Clause form to determine which sections of the clause to unhide.

I suggest a best practice would be to look in the Data Modeler for the business object of the classification you want to delete records on. Select the triNameTX field and click ‘Where Used’. If nothing comes back you should be pretty safe to make changes to that classifications record list (add, delete, modify). If you see any workflows, queries, forms, etc., come back as using this field, you’ll need to analyze each to determine if your business needs them. However, I’d suggest pushing back against the business and advise that the application requires the values in question.