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

Continue reading

Advertisements

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

Continue reading

IV87787: Integration object HTTP post can’t send UTF-8 characters


The TRIRIGA integration object’s XML post type requests are not correctly encoding UTF-8 characters. As a result, double-byte characters, although they appear correctly in the server.log when the integration object’s “Debug” is clicked, are seen by the receiver as “??”.

The issue was that XML post type requests were not correctly handling UTF-8 characters. The fix is to include UTF-8 content binding when the entity is being added to the request. Moving forward, we resolved an integration object HTTP post scheme issue, where multibyte characters were not being correctly handled in the outgoing HTTP request. Please note with this fix, if for some reason your integration object HTTP post scheme configuration leaves the Content-Type field blank, and the Content-Type is not defined in the Headers field, then the Content-Type of the HTTP request will default to: “Content-Type: text/plain; charset=UTF-8”. On prior releases, it defaulted to: “Content-Type: null”.

Continue reading

IV80364: Document with a Korean file name fails to upload properly


A document with a file name in Korean fails to upload, view, or download properly.

We needed to (1) add an onError method in upload.js to close the window and refresh the document list, (2) use StringEscapeUtils to escape the document content, and (3) add UTF-8 to the content disposition so the file name can be unescaped by all browsers.

An issue was fixed where uploading a document with multibyte characters in the file name would not close the upload popup window after clicking the submit button. Also, another issue was resolved in Document Manager where viewing or downloading a file with a multibyte character file name (such as Korean) would show encoded characters instead.

Continue reading

IV79986: State family label header not being translated to Korean


On the top left label of the sub-actions in the State Family screen, where in English you can read the text “SubAction Label Details”, it is not being translated correctly to Korean. Instead of Korean characters, the equivalent UTF-8 code is showing up.

We fixed an issue where the SubAction Details section label header would not display various language characters correctly.

Continue reading