Mismatch between AWI field validation and AE DB storage for IntAccount field.
Article ID: 367043
Updated On: 11-13-2024
Products
Issue/Introduction
AWI v24.0.0 allows the user to enter up to UTF8-64 bytes worth of characters in the Internal Account (IntAccount) field, but when the object is saved, only characters completely encoded by the first 16 bytes are saved to the database.
The problem is only noticeable when using multi-byte characters (for example 😀'' coded by '\uD83D')
The AWI, for example, will allow entry of the string "\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00" (16 smiley face emoji characters) in the Internal Account field, and will display a field validation error message only upon entry of an additional character (e.g., a single letter A). However, when the user saves the object, only the string "\uD83D\uDE00\uD83D\uDE00" will be saved to the database.
So, using the AE REST API POST​/{client_id}​/objects, it is possible to import an object with an Internal Account with greater than 16 bytes.
{
"total" : 1,
"data" : {
"scri" : {
"metadata" : {
"version" : "24.0.0"
},
"general_attributes" : {
"type" : "SCRI",
"name" : "XXX.XXXXX.XXX.XXX.XXXX.SCRI",
"description" : "\uD83D\uDE00",
"max_parallel_action" : 1,
"archive_key1" : "\uD83D\uDE00",
"archive_key2" : "\uD83D\uDE00",
"mrt_time" : "000000",
"inherit_output_filter" : "N",
"queue" : "QUEUE",
"auto_deactivation" : "A",
"minimum_ae_version" : "11.2"
},
"documentation" : \[ {
"Docu" : \[ "Script for testing UTF-8 capabilities of AE v24" \]
} \],
"rollback_definitions" : { },
"scripts" : {
"process" : \[ ":SET &VARIABLE1#=\uD83D\uDE00", ":P &VARIABLE1#" \]
},
"script_attributes" : {
"account" : "\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00\uD83D\uDE00"
}
}
},
"path" : "APPS/EBM",
"client" : 1,
"hasmore" : false
}
In the above example, the account field contains 5 4-byte characters (\uD83D again), for a total of 20 bytes. The AE accepts this and writes the information to the DB (ORA.ORA_INTACCOUNT).
However, this causes problems for the AE when the user then attempts to work with the object in the AWI. Attempts to open, rename, or export the object cause WPs to repeatedly crash and write forced traces.
20240304/163348.287 - U00015006 System forced memory trace dump.
20240304/163348.287 - U00003631 Dump caused by:
20240304/163348.287 - U00003590 UCUDB - DB error: 'OCIStmtFetch', 'ERROR', '', 'ORA-01406: fetched column value was truncated'
20240304/163348.287 - U00011801 Error in Server routine 'UCDS_R', Server: 'YYYYY#WP0XX' AE system: 'YYYYY'.
Eventually, the AWI will report another error:
Request timed out during XRequest com.uc4.webui.communication.requests.OpenObjectAdapter specifies a timeout for the AE calls in the configuration.properties file. It is possible to resolve the problem by re-importing a version of the object with only 4 4-byte characters (16 total bytes) in the Internal Account field.
Environment
Oracle 19c
AE 24.0.0
Customer's database specifications:
20240227/085740.198 - U00003535 DB INFO: 'NLS_LENGTH_SEMANTICS = BYTE'
Cause
This is due to 2 defects in the Automation Engine
- Content check in the API checks for code units and not bytes. Because of this, there is no error message returned on "save" - but the value truncated afterward by UCUDB32
- REST API also allows the storage of more data than UCUDB32 can read.
Resolution
This is partially fixed in v24.2.0 (available): It is no longer possible to store invalid information in the database.
A second fix is underway as part of a general improvement: The field IntAccount will be extended to 200 characters (up from 16). This improvement will also fix the live field validation in AWI. In other words, before saving it will show a warning message if the content is not accepted.
Additional Information
Bug ID: AE-36575
Bug Title: Mismatch between AWI field validation and AE DB storage for IntAccount field.
Feedback
