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.]
We have upgraded the TRIRIGA platform to 18.104.22.168 and started upgrading the application from 10.2 to 10.5.2 in incremental order (10.3, 10.3.1, until 10.5.2). To minimize the outage and complexity during production implementation, we have been suggested to take a final OM package after completing 10.5.2 deployment, and apply all the customizations which might have been impacted with the upgrade. This final OM package will contain all the changes from 10.2 to 10.5.2.
Our question is on the patch helpers: Can we run all the patch helpers (from 10.3 to 10.5.2 in order) after importing the final OM package?
Also, we are running the Varchar-to-Numeric script before importing the application upgrade packages. This script is taking a long time (almost a day in two test environments), but when we tried in another environment, it’s running for more than 2 days and still didn’t get executed. Is it normal for this script to run like that? Or will it be an issue? There are no differences between the environments.
I wouldn’t recommend doing the upgrade in one package. Usually, it ends up being quite large and it will cause issues. The IBM-recommended way is to perform each OM, then run the patch helpers. Once you have upgraded the OOB OM packages, you can have one OM which has your custom objects…
[Admin: This post is related to the 10.25.17 post and 04.28.17 post about running “SetVarcharColsToNumeric” scripts. To see other related posts, use the Scripts tag.]
I’ve made some modifications to a handful of forms that are connected to CAD BO Mapping records (e.g. triEmployee, triSpace, triFloor, etc.). I’ve updated the label to follow the traditional TRIRIGA customization standards and relabeled them with “cst” such as “cst-triSpace”. However, in AutoCAD, when I attempt to Smart Attach and/or Publish drawings, I get an error that seems to point towards the GUI Name of the form not lining up to the CAD Mapping. How do I get CAD Integrator to pick up the same form but with a different label?
When renaming those forms, you must make a few changes to the CAD backend:
- 1. Create new CAD Mapping records that point to the new form. I recommend checking the old mapping records to make sure all fields are added properly.
- 2. If you added any required fields, I believe that they need to be added to the CAD Mapping record.
- 3. Open the CAD Hierarchy and make sure each node is pointing to the new Mapping record that you created from Step 1.
- 4. Update the form on the CAD Label Style to point to the new form.
Note: If you are on a newer platform, I recommend keeping the form names as “tri”, and using object labels to manage versioning.
[Admin: To see other related posts, use the Integrator tag or Object Label tag.]
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.
[Admin: To see other related posts, use the Epoch Time tag.]
What is the best way to handle calculated fields that need to reference the Current Date or System Date? For example, I have a number field in the Building BO called Building Age. To calculate the Building Age, I had to create another field called “cstCurrentDateDA” to store the current date the Building record was created.
From there, I take the Current Date minus the In Service Date of the building. However, let’s say I wanted the Building Age field to get updated daily. In my current design, I would have to probably create an asynchronous workflow to update the “cstCurrentDateDA” field and then trigger a Save action to get the extended formula against the Building Age field to fire.
Is there a better approach to dealing with field variables that rely on the Current Date or System Date? Instead of creating a custom field to store the Current Date to act as a constant factor?
[Admin: To see other related posts, use the Date tag.]
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.
[Admin: To see other related posts, use the Geography tag or Organizations tag.]
We have already upgraded our platform to 22.214.171.124. 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.
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]