I’m using the TRIRIGA integration object (File method) to import data into the space BO. I created the Data Map properly, but my records are not importing because of the following error:
“Could not get recordId for smartSection[triCurrentSpaceClass] on row, column with value. Record was not saved.”
Even though I selected the Smart Section filter and mapped it to triNameTX, the integration object fails. Any thoughts?
[Admin: To see other related posts, use the Integration Object tag.]
So I just learned that I can’t use the Object Migration tool to migrate record data between two TRIRIGA environments. For example, I have two environments on different servers on the same application and platform version. If I try to use OM to migrate the Record Data only, for instance, the Building Equipment records, not all of the associated records will get migrated and certain smart sections do not get properly migrated either.
What are some other options that I could use to quickly migrate this data? I was thinking the Data Integrator (DI) method, but that would be tedious because I have over 100,000 records.
Ideally, DI should be used for the initial load. If the data is available somewhere else, you can look into Integration Object or DataConnect. You can populate staging tables and then run the integration. In your workflow, you can have logic to create any dependent records (such as organizations or contacts) based on the staging table data.
[Admin: To see other related posts, use the Integration tag or DataConnect tag.]
We have an issue with duplicate opportunity rows in the building’s Assessment tab. The issue seems tied to the building system class smart section and the underlying table reporting against it, T_TR_DEF_LI_IT_TR_BUI_SY_CL, while in a building record, Assessment tab, when we create a new opportunity, fill in the building system class smart section (not the building system item one), and create draft.
If a user then tries to change the building system class, but then decides to not save and instead just closes the form, the row that is entered into the table T_TR_DEF_LI_IT_TR_BUI_SY_CL for the temp data, is not removed when the record is closed without saving. Which results in the opportunity query on buildings displaying the opportunity twice. This seems to be a general issue with the use of these tables, since it also happens when you do the same steps on a work task and a facility project; an extra row remains in T_TR_WO_TA_TR_FACILIT_PROJ.
Has anyone else encountered this issue and found a way to correct it? Using the steps below, can anyone confirm that the issue happens for them as well?
This issue is being addressed through PMR 12839,082,000 / APAR [IJ00504].
[Admin: To see other related posts, use the Assessment tag.]
In the IBM TRIRIGA 3.5.3 and 10.5.3 release, the Group object was redesigned to leverage query sections, instead of a single large smart section. The query sections improve the performance and usability of the Members tab by paginating the results, and providing filtering capabilities. These application changes are a part of the IBM TRIRIGA 10.5.3 application upgrade object migration (OM) package, but can be applied to systems running older application versions.
To help anyone who would like to apply the Group enhancements to an environment not running 10.5.3, the 10.5.3_Group_Query_Enhancement.zip can be downloaded from the Attachments tab. This is an unsupported object migration (OM) package that includes the Group form, queries, and workflows that were created to enhance the application. This OM package can be imported into an environment running on the 3.5.3 platform release.
Note: This enhancement requires the 3.5.3 platform release for the “Add” and “Delete” functions to work within the query section. There are new custom tasks that are called by workflows that handle the adding and removing of group member records, when users or groups are selected. Before applying this OM to a production system, the OM package should be tested in a test or development environment first.
[Admin: This post is related to the 03.07.16 post about best practices for managing your security groups. To see other related posts, use the Security tag.]
I am working with payment line items in a UX app. We have a single-record smart section for a RE contract lease. I want to create a payment line item from a UX app and populate the smart section. Do I need a “smart section” child data source of the “payment line item” data source? For fields in a smart section, how should they be identified? By “label” from the Form Builder or by “name” from the Data Modeler?
You should create a child data source of payment line items: (1) You have your “payment line items” data source in place. (2) Use the ID of the current payment line item (the one you’re trying to edit) as a context-id for your child data source (the one containing the RE Contract). You may get something similar to the following code…
Then, you can handle the “ReContractForPaymentLineItem” object through the binding created: ReContractForPaymentLineItem.name, ReContractForPaymentLineItem.status, etc.
[Admin: To see other related posts, use the UX tag or Data Source tag.]
I’m currently working on an application upgrade. When I generated a comparison report, I found a weird conflict. The “Live Link” option belongs to smart sections, but in the report, this option is available for a classification field. Should we ignore this conflict? Because there is no “Live Link” option in the Data Modeler for a classification field.
I noticed that the smart section won’t update even if the association changed. Is there any other place that the smart section is stored beside the SYSKEY column?
If you want to update a smart section when a specific association is made from some other process, you will need to trigger a workflow on the association event, and than map the “Associated Object” as a source map to the smart section.