Why aren’t Group record changes copied through object migration?


Why aren’t Group record changes copied through object migration?

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

Continue reading

IV96283: Copying blank spaces into a required field is still saved


If you make a field required, such as the “Description” field, and you copy and paste spaces from a Word document into the “Description”, you will be able to submit the request. Essentially, you have a submitted record, where the “Description” is required but still blank. Meanwhile, if you attempt to create a request with a “Description” where you manually enter the spaces, it will not let you submit it.

Moving forward, a text field value containing only spaces and/or carriage returns will be considered as empty, and will fail the required field validation, if applicable.

Continue reading

IV94038: Copied template is saved but does not display changed name


After changing the name and copying a template, the name change is saved in the database for the copied template. However, it displays a “Copy of” the original name. In other words, the name stored in the database is different from what is being displayed in the TRIRIGA interface. So when you copy a template, it fetches a different name from the database and concatenates “Copy of” with that name. This seems incorrect from the front end.

Moving forward, we fixed an issue where the capital project template name was modified and then copied, but the copied template was not created with the modified name. This happens only for non-US English users only.

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

Continue reading

How do you copy your Oracle DB schema for TRIRIGA Support?


To create a logical copy of your TRIRIGA database schema, use the Oracle data pump for exporting database dump files. More information can be found here in the Oracle Help Center. It is recommended to run these steps from your database server with a privileged database user, and to stop the TRIRIGA application beforehand.

(1) Create directory object in Oracle where you want to download the dump. Information on how to do this can be found here in the Oracle Help Center.

(2) Run the export command expdp as follows. Substitute the variables properly.

expdp <db_admin>/<admin_pw> DUMPFILE=<dpump_dir>:<filename>.dmp SCHEMAS=<schema_name> LOGFILE=<dpump_dir>:expschema.log

[Admin: The same article is also posted in the Watson IoT Support blog.]

Continue reading

Do you get unexpected results with Data Integrator in TRIRIGA?


The most pervasive issue I have seen overall has been problems with the source sheet. Typically, I start my Data Integrator process by building a spreadsheet with the column headers using the TRIRIGA application. Starting from the Data Integrator interface, reached from Home > Tools > Data Integrator, and using the Create Header action, you can generate a base sheet. It’s as easy as selecting the fields you want to use, and exporting a sheet to begin working with it. You also have the option to simply open Excel and type in the fields you want to use.

A known issue is encountered when copying and pasting from the application into Excel. In fact, this is one of the key points I want to make. Copying data from the TRIRIGA application, or from any other tool, into Excel, will almost invariably introduce formatting into the spreadsheet. This is the most common cause of issues with the upload process. HTML formatting information will cause problems with the upload.

The method I have found that aids in getting around this restriction is to use the Copy/Paste VALUES option when pasting data into the spreadsheet. This removes the formatting tags, and allows for a clean upload. At times, I have experimented with copying and pasting an entire spreadsheet into a new sheet, again using the VALUES option, to clean up an upload sheet prior to saving as a text file. This yields good results and has solved many issues for me.

Another area where I have encountered issues in the past is when trying to make edits to the text file after exporting it from Excel. I strongly recommend that this NOT be done. If any edits are warranted, please make the changes in the spreadsheet and re-export the text file. In fact, I would recommend deleting the original text file, and doing a fresh export each time any edits are made. This eliminates the possibility of bringing in bad data, or merging unexpected edits…

Continue reading

IV87669: Report Builder does not show forms with the same label


If you make a copy of a form that has the same name but a different prefix, and then upgrade, the form is not listed as a form in the Report Builder. But it will be listed, if you go to the Form Builder.

As a temporary fix, change the label of one of those forms and it will show up. We needed to sort the form labels based on lowercase strings and the pair <label, name>, so that identical labels will still be displayed. Moving forward, an issue was resolved in the Report Builder, where forms under the same module and business object, and with the same label but different names, would not be listed. Only one of the forms with the same label would be displayed.

[Admin: This post is related to the 02.24.17 post by Rob Zombron about forms missing from Report Builder.]

Continue reading

Why is the Copy action missing from lease payment schedules?


If you used to work on Real Estate Leases and Generate Payment Schedules before TRIRIGA 3.4.2, you know that every time you needed to copy a Payment Schedule, you would need to open the record, and click “More” > “Copy”.

Since “Copy” was the only action under that “More” button, the Development team made a decision to move this out and place it beside “Save” and “Save & Close”. The issue is that for base TRIRIGA 3.4.2/10.4.2, the “More” button was removed, but the “Copy” button was never placed in the form. It was fixed in TRIRIGA 10.4.2.1, and in the following fix packs.

So, if you are going to test TRIRIGA 10.5 to evaluate an upgrade, the “Copy” action is missing. This was a regression fixed in the most recent 10.5 fix packs.

[Admin: The same article is also posted in the IBM Support Portal. This post is related to the 01.19.16 post about TRIRIGA fix packs.]

Continue reading