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.]
Does anyone have experience in project integration (data transfer) from an external existing project through any IBM TRIRIGA integration module? Our templates and mapping have been identified, but the question is about reproducing the overall standard when a project is created. This seems hard. In order to have this project consistent in TRIRIGA, we think that we need to be consistent with the following:
- Project and direct associations with business objects in perimeter
- Associated purchase orders
- Budget and their associated cost codes
- Financial data and their associated computation
Any help and experience would be great, even if the answer is it’s too hard.
Without detailed knowledge on the user’s part, such as a fundamental knowledge of all of the application functionality, it would really be best to engage IBM Services to implement this integration. It’s not impossible, but it really would need a lot of care.
[Admin: To see other related posts, use the Integration tag.]
We have an issue where sometimes after applying a cost code template to a project, the hierarchy path will not be complete. It will be missing all of the parent path and only shows the name. This issue is only visible in the app by viewing the System Path field inside the form or by using a SQL query, because the system path in the T_TRICOSTCODE table is correct, but the object path field in the IBS_SPEC table is the one that’s not complete. The issue does not have much consequence unless you are using the rollup fields, in which case the corrupt cost code path will cause a posted transaction to fail.
If there are customers who use cost codes heavily, you can try running the following SQL, and if you get any results back, then that means the issue is present at some level in your environment. It is not necessary that you use the Apply Template to create your cost codes, as I have heard of others having the issue where their cost codes are created via an integration. This SQL is for Oracle and may need a tweak for SQL Server. If any customers can run this, and see if they have the issue, it may help us identify how it happens.
select tripathsy, triprojectnamesy, OBJECT_PATH from t_tricostcode T1, IBS_SPEC T2 where T1.spec_id in (select spec_id from ibs_Spec where type_name = ‘triCostCode’ and object_path not like ‘%\Cost Code%’) AND T1.spec_id = T2.spec_id and tripathsy like ‘%\Cost Code%’
[Admin: To see other related posts, use the Cost Code tag or Templates tag.]
In the IBM TRIRIGA Administrator Console, under Performance Monitor > Monitor a Single Value, several monitors are no longer listed.
The following changes were made in the Administrator Console, under Performance Monitor > Monitor a Single Value:
- CRYSTAL_QUEUE_AGENT_RUNNING is renamed to REPORT_QUEUE_AGENT.
- CLEANUP_AGENT_RUNNING is renamed to PLATFORM_MAINTENANCE_SCHEDULER.
- KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING were deprecated in a previous release and are now removed from the Performance Monitor.
Since the CRYSTAL_QUEUE_AGENT_RUNNING and CLEANUP_AGENT_RUNNING monitors are used for integration, only the performance monitor names are changed, not the values or URLs.
[Admin: This post is related to the 07.14.15 post about renaming CleanupAgent (Cleanup Agent) to PlatformMaintenanceScheduler (Platform Maintenance Scheduler). To see other related posts, use the Monitoring tag.]
I am trying to export foreign language data using integration object. Alphanumeric values are exported correctly, but I cannot figure out the character set used for foreign language values, namely Japanese. The Japanese values are displayed correctly when I look at the data from a browser, and the data is stored in UTF-8 in the database. But when I export the value out to a file using the integration object, the value is no longer in UTF-8. Does anyone know what character set the integration object uses? How I can change it to UTF-8?
You are absolutely right that it should use UTF-8, but after talking to a co-working and looking at some code it does not appear that is the case. Submit a PMR and reference RTC 292380 and include that you were referred by me to submit the PMR… This issue is tracked by APAR IJ02452.
[Admin: To see other related posts, use the Integration Object tag or Multibyte 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.]
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.)
[Admin: To see other related posts, use the Best Practices tag.]