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.]
Our client is experiencing logout issues when using Perceptive apps on their iPad.
The link to the Perceptive app is passing through a DMZ, and upon initial login, the users are able to navigate the apps on the iPad without issue. But when a new session is started on their desktop, they are logged out of their current session on the iPad. After the users log back in, there are 2 consistent behaviors: (1) the iPad log constantly force-closes the session on the desktop or (2) there is a back and forth between the desktop and iPad sessions.
We’re unsure of how, or if, SSO is playing a part in this, or if we’ve missed a setting that will enable both sessions to stay open for as long as the timeout setting allows. We have attempted to use this solution (IV96586), but have not seen improvement.
When one SSO session is opened, it will log out the user from any other locations. I would ask users to stick with one device and avoid using multiple devices. If they need to use the apps and their desktops simultaneously, then you should provide them with a link to the UX apps for their desktops.
[Admin: This post is related to the 06.10.17 post about the UX session timeout on the iPad. To see other related posts, use the Timeout tag.]
I’m seeing an issue in the Group Move UX app. After application upgrade to 10.5.3, the Group Move application stopped working on “Production Mode”. After activating “Development Mode”, the Group Move worked again. So I think the problem came from the vulcanized code of 10.5.3 OM package. For now, I’ve just vulcanized the Group Move application manually and it works now. Have you seen a similar issue?
We confirmed the defect related to the vulcanized code for the Group Move UX app. It is being addressed for the next full release under APAR IJ01969. Meanwhile, the manual solution you have followed is the workaround. Here are the details:
“The Group Move UX Perceptive application should no longer contain syntax errors and the search feature should work now. Customers who run into this issue on previous app versions can vulcanize the application following the steps outlined on this wiki page. (Tri-IJ01969-5886)”
[Admin: To see other related posts, use the Vulcanize tag.]
We have an issue with duplicate opportunity rows in the building’s Assessment tab. The issue seems tied to the building system class smart section and the underlying table reporting against it, T_TR_DEF_LI_IT_TR_BUI_SY_CL, while in a building record, Assessment tab, when we create a new opportunity, fill in the building system class smart section (not the building system item one), and create draft.
If a user then tries to change the building system class, but then decides to not save and instead just closes the form, the row that is entered into the table T_TR_DEF_LI_IT_TR_BUI_SY_CL for the temp data, is not removed when the record is closed without saving. Which results in the opportunity query on buildings displaying the opportunity twice. This seems to be a general issue with the use of these tables, since it also happens when you do the same steps on a work task and a facility project; an extra row remains in T_TR_WO_TA_TR_FACILIT_PROJ.
Has anyone else encountered this issue and found a way to correct it? Using the steps below, can anyone confirm that the issue happens for them as well?
This issue is being addressed through PMR 12839,082,000 / APAR [IJ00504].
[Admin: To see other related posts, use the Assessment tag.]
We have quite a lot of rows in the extended formula queue that started to back up since Aug 29. At one point, we had over 900K in the queue and the process server is processing it pretty slowly. As of Sep 8, the system is still processing the queue. We are adding daily on average over 125K rows to the EF_QUEUE table.
We tried starting and stopping the Extended Formula Agent and Formula Recalc Agent and tried rebooting the process servers. We swapped the agents to run on different servers. We also ran the segment shrink on the EF_QUEUE table and gathered statistics. It is still extremely slow. We still have over 500K in the queue.
In parallel, we did open the platform logging on the extended formula activity and cache building, and we are working to identify the processes that can be fixed to reduce the multiple calls to the Extended Formula Agent queue. Do you have any recommendations to speed up the process to clear the extended formula queue?
Review the following two APARs. They may need to be applied to your environment to address this issue: (1) Platform: APAR IV87030. (2) Application: APAR IV87104.
[Admin: This post is related to the 07.28.16 post and 05.04.16 post about the Extended Formula (EF) Agent not processing and backing up the queue. To see other related posts, use the Extended Formula tag.]
I’m seeing an issue with report parameters in BIRT. I’ve added a report parameter and bound it to a filter condition. The report runs perfectly in Eclipse. But when I uploaded the same to TRIRIGA, it’s giving me errors while the report is rendering, after entering the parameters. Surprisingly, null checks have been implemented using a script at the table level as well as on the filters, so that optional parameters are dealt with. Here’s the exception trace…
This may be related to a known issue resolved in APAR IV96587. Try the most recent fix pack and see if it resolves the issue. If it does not, I would put in a PMR.
[Admin: This post is related to the 11.13.15 post and 07.03.15 post about having issues with BIRT report parameters. To see other related posts, use the BIRT tag.]
Filtering on a word in a date or date-time column produces unexpected results.
The platform treated any invalid string as “Today’s Date”. Moving forward, for query reports that have filters enabled, a check was added whenever a user attempts to use an invalid filter in a date or date-time field. If a non-date or non-date-time string is used in this filter, then a “No data to display” message is shown to the user in the body of the query results table, and zero results are returned.
[Admin: To see other related posts, use the Date tag or Filter tag.]
We are using IdP-initiated SAML, and we access TRIRIGA via a link that looks something like this: http://idpprovider/applications/Tririga. Can we pass this link in FRONT_END_SERVER in TRIRIGAWEB.properties so that users can click on the link that they get in a work task email, and they can be redirected to TRIRIGA?
SAML does not support basic authentication for non-browser clients. This is a SAML limitation. See the following APAR IV88274 link.
[Admin: For convenience, here are the meanings of the acronyms: Identity Provider (IdP), Security Assertion Markup Language (SAML).]
[Admin: This post is related to the 08.18.16 post about lack of support for non-browser clients. To see other related posts, use the SAML tag.]
When a record is in a read-only state, any form action text links (not a button) on the form no longer run the workflow assigned to the OnClick event for the action. The “busy spinner” comes up and the action is never taken. The only recourse is to close the form window. If the record is editable, the form action text links run their workflows as expected.
[Admin: To see other related posts, use the OnClick tag or OnChange tag.]
If a work task has a calendar and the “Planned End” or “Actual End” date-time field values are updated, the “Working Hours” are not always calculated correctly. The working hours do not seem to factor in the calendar hours.
The working hours were not being calculated correctly. The issue was that the values for the calendar fields (Year, Month, Day, etc.) were not being set correctly. The fix was to set the calendar fields exactly as we do for the other calculation methods. Moving forward, we resolved a work task record and Gantt chart issue, where the Actual Working Hours and Actual Working Days were not being correctly calculated when an Actual End date value was entered.
[Admin: To see other related posts, use the Calendar tag or Gantt tag.]