What character set is used by the IBM TRIRIGA integration object?

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

What are the Oracle Database settings for 10.5.2 and 3.5.2?

I wanted to see if anyone has set up the following settings in an Oracle Database for TRIRIGA 10.5.2 and 3.5.2:

• 1. NLS_LENGTH_SEMANTICS: Should this be set to CHAR? In our current production environment, it’s set to BYTE, but the TRIRIGA support documentation says that this can lead to data loss, so they recommend using CHAR.
• 2. NLS_CHARACTERSET: This is set to WE8ISO8859P1 in our current production environment, but the support document says that it must be UTF-8 or UTF-16.
• 3. Block size: This is set to 8k, but the documentation recommends using 16k.

For (1) and (2), if you never want to store multibyte characters, then what you have is fine. But if you do, then you must use what the support documentation suggests.  Once you have your database created, it is difficult and time-consuming to change it, and it needs to be done outside of TRIRIGA. As for (3), I would encourage you to use 16k, since it will allow you better throughput and paging, unless you have a strong reason why you need to stay at 8k.

[Admin: This post is related to the 04.04.16 post about database character settings. NLS refers to National Language Support parameters in Oracle. To see other related posts, use the Multibyte tag, MBCS tag, or NLS tag.]

Having an issue with the database after upgrade to 3.5.3

We are in the process of upgrading to TRIRIGA 10.5.3/3.5.3. We are also importing the triFoodServiceLineItem business object from the modified environment (10.5.0.1/3.5.3) to the new staging environment. But when we import the business objects from the modified environment to the staging environment, we see database errors. Can someone advise us on what the issue could be?

L_TRIFOODSERVICELINEITEM is the language table for the triFoodServiceLineItem business object. For some reason, it sounds like it is unable to create it in the target, most likely because it is already there. I suggest that in the target environment, go to the triFoodServiceLineItem in the Data Modeler, revise the BO, and republish. Hopefully, that will fix it.

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

What is the purpose and impact of the “Localizable” field property?

I’m seeing issues within report results, where if the user profile language is in US English, the results are of one type, but if the user profile language is in German, it is showing some other data. The record while checked is the same for both cases. While opening and checking the record, the ID and name of the record varies from what it showed as a result in the report. While investigating, what we observed is that these fields are marked as “Localizable” in Data Modeler. What is the use and impact of the “Localizable” field property? Any suggestions?

Here is a PDF link to the 3.5.3 Globalization (Localization) user guide. Also, perhaps this technote on localized database storage will help provide some insight.

[Admin: The same question is also posted in the main Application Platform forum. To see other related posts, use the Localization tag or Language tag.]

IV96374: Various non-US English users get “An Error Occurred”

Various existing users with non-US English language profiles are getting the following error when they click on the System tab on each form:

An Error Occurred. Contact your System Administrator. – [MID-3402867005]

When translating object references, the platform needed to catch the “smart object not found” error, and follow the path as if it was non-translated. Moving forward, when invalid data is contained in a reference field (like System Geography), the platform will no longer throw a MID error, and will now show the field as blank, since the referenced record does not exist.

IV95XXX: Multiple APARs on Section 508 compliance for web

IV95219: Section 508 compliance for TRIRIGA login page
Visually impaired users dependent on Section 508 compliance to use TRIRIGA may run into a problem in the login page. They might have difficulty in navigating to enter the ID and Password.

IV95289: Section 508 compliance in Projects page
Keyboard access, style sheet dependence, language, page titles, and images for Section 508 compliance fail test on Projects tab.

IV95290: Section 508 compliance in My Reports page
Keyboard access, web forms have invalid HTML, web links, and user controls. Images have no description in plain text.

[Admin: This post is related to the 10.17.16 post about multiple APARs on Section 508 compliance.]

Why aren’t tasks always showing up in tabular metric reports?

Our client’s tabular metric reports, which are set to show the tasks of service requests, seem to have some issues. Although the tasks are found by the report, they don’t always show up or aren’t displayed on the list.

Here are two examples below: (1) In the first case, 6 tasks are found, but only 2 of them show up. (2) In the second case, 3 tasks are found, but none is displayed. Any ideas on what could be happening?

[Updated 05.03.17]

It seems that the user’s language (set in his profile) and the existence of a contract for the tasks affect their visibility one way or another on the tabular report. Here’s an example below: (1) When the user’s language is set to EN (English), all of the tasks show up fine. (2) When the user’s language is set to FR (French), only tasks which have a contract show up (in this case, only 1) even though all 8 are found…

How are currencies handled in a globalized TRIRIGA environment?

IBM TRIRIGA made vast improvements in the globalization of currencies starting with TRIRIGA Application Platform 3.4.2. If you are on a platform version before 3.4.2, we urge you to upgrade to the most current version to take advantage of these enhancements. For the enhancements to work correctly, you must update your environment after you upgrade your platform. The following discussion highlights globalization areas to review after upgrade:

• User Language: A language is defined in each user’s profile record. The language establishes the locale of the user…
• User Currency: A currency is defined in each user’s profile record. When a user creates a record that includes a currency UOM…
• UOM Value: Currency UOMs are defined in the Unit of Measure (UOM) values, which are found in Tools > Administration > Unit of Measure (UOM) > Values…
• Language Code: Review the language codes in Tools > Administration > Globalization Manager > Language Code to ensure that they are correct for your company…

[Admin: To see other related posts, use the Currency tag or Globalization tag.]

IV93507: Running query executes multiple calls to IBS_SPEC table

Running queries for non-base language users (such as British English) will execute multiple calls to the IBS_SPEC table unnecessarily.

We needed changes in platform to cache many of the frequently-hit items in Classifications and My Profile, so that it reduces pressure on IBS_SPEC. Moving forward, the IBS_SPEC table is no longer queried multiple times when Classifications are included in reports. Classifications are considered metadata and the values will now be cached for a default of 24 hours.

[Admin: This post is related to the 02.20.17 post about a query generating multiple SQL statements when the user is in British English.]

IV93471: Changing language of “System-Help” form breaks help

Changing the language of the “System-Help” form breaks it…

This is because the new language is appended to the end of the publish name. This means that when it looks for the publish name of “System-Help”, it can’t find it. Additionally, changing it back to US English does not resolve the problem, since it appends yet another language name to the publish name.