When a record name is changed in the record itself within TRIRIGA, the new name is reflected, but when querying the record via an integration URL for an XML output (e.g. f=xml url parameter), the specId is still referring to the record with the original name. This happens with localized users…
When a record name is changed, it is not being reflected when requested via web services. The issue was that integration query URLs were not returning localized values when the response is in XML format. The fix adds two new URL parameters that can be used to localize XML results. They are f=xml-loc and f=pxml-loc…
When you run a query expecting JSON results, via the integration object external URL functionality, the modified names of the roles are not being reflected. That is, the original name is displayed in the result query. This happens for localized users only. Meanwhile, US English (US_en) users observe the proper changes when refreshing the query results…
As I’ve understood it, both the integration object and DataConnect allow you to import localized data (except business key fields, I think). In addition, we have another option to use the Globalization Manager to import traditional data. I found it’s pretty cool. We will only deal with the localized data, with less impact for the non-localized data. Before going forward with an option, I’d like to know what’s the best option for you guys?
Importing by using the Globalization Manager updates the L_ tables directly. If your data does not include localized values that need to be concatenated, for example in a formula, the Globalization Manager import is your best option.
However, if your data includes localized values that need to be concatenated through a formula, or if your data needs to be processed by workflow before it is added to the TRIRIGA tables, then you should use either the integration object or DataConnect.
[Admin: This post is related to the 03.02.16 post about best practices for integration optimization.]
If a parent building has been renamed, a localized user cannot find that parent building in the lease by searching for it. You may test directly in Portfolio > Locations and may be able to find that for a localized user, the name of the building is modified. But that change does not flow to the column named “Building”. That is ultimately the building name used in the query inside the Lease record…
The root cause is that the query that displays the list in Portfolio > Locations is “Location – Manager Query – Manage By Hierarchy”. The field that is displayed in the column labeled “Building” is triParentBuildingTX. In the Data Modeler for Location > triBuilding, the Localizable property for triParentBuildingTX field is not selected.
Launching a record by clicking the link for a record in the tabular section of a metric report throws an error. This was reported for the French language and might impact other localized users and non-localized users.
In the user’s home page, click on the “Indicateurs” link in the second portal section on the left. In the metric scorecard, click on the first (note there are 2, you want the first) “Nombre de demandes” link. Then click on any of the records returned in the table format on the lower right. The system opens a window, but throws an error…
In the Attachments tab, this package contains the untranslated labels and data delivered in IBM TRIRIGA Platform 3.5.2 and Application 10.5.2. These will be translated in the future release. You can use the files inside this package to provide translations for your supported languages, then import them into your environments.