Troubleshooting
Problem
For example, when the operation name of a workflow Partnerlink contains the German special character 'ß' at runtime character 'ß' is unexpectedly transformed into 'ß' and the wrong, non-existant, Web Services operation name gets called.
Symptom
For example, the Web Services operation name StartKampAbschließen is interpreted as StartKampAbschließen resulting in a schema validation error. The workflow is unable to process the call due to the incorrect Web Services operation name.
Malfunction: [FNRPE2131090122E]Received an unhandled fault in an Invoke: "filenet.vw.api.VWException: aixserver1(192.168.xxx.yyy) filenet.vw.api.VWException [soapAddress:http://<cpeservername>:8080/ibmccepo/WSBroker/wscppstage/wc/] Exception: Schema Validator Result: for StartKampAbschließenSchema Ids=http://www.filenet.com/ns/fnpe/2006/06/po/schema/fn/basichttp://www.filenet.com/ns/fnp e/2006/06/po/schema/m011_crmkampagne_abschliessenIS INVALID. Errors: 0 : [Schema Error] null: line 3, column 72, s4s-att-invalid-value: Invalid attribute value for 'name' in element 'complexType'. Recorded reason: cvc-datatype-valid.1.2.1: 'KampAbschlStartKampAbschließenInputType0' is not a valid value for 'NCName'.
The workitems are then routed to Malfunction queue.
Cause
The problem is caused by an incompatible character encoding setting on the CPE server host machine.
Environment
The customer, in this example, has a CPE server on AIX, with Windows client machines, with CPE 5.5.4.
The customer has the following locale settings
-bash-4.4$ locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=
-bash-4.4$ locale charmap
ISO8859-1
ISO8859-1
The important setting is the character encoding, shown on AIX by the output of the "locale charmap" command.
Notice that the character encoding on the CPE server is ISO8859-1. ISO8859-1 is a single-byte character encoding, but the 'ß' character in the web service WSDL is encoded in UTF8, which is a multi-byte character encoding.
Absent any JVM specific encoding setting, the JVM defaults to the Operating System character encoding setting, and incorrectly interprets the UTF-8 encoded WSDL file as if it were encoded in ISO8859-1.
Diagnosing The Problem
The Unicode character “ß” https://www.compart.com/en/unicode/U+00DF
“ß” UTF-8 Encoding: 0xC3 0x9F
“ß” UTF-8 Encoding: 0xC3 0x9F
The Error in the XML being reported in this case, is that the XML contains two characters "Ã" and "Ÿ", where "ß" is expected.
Look at the Windows 1252 page on Wikipedia
https://en.wikipedia.org/wiki/Windows-1252
https://en.wikipedia.org/wiki/Windows-1252
See that is 0xc3 "Ã", and 0x9f is "Ÿ"
The UTF8 encoding of "ß" is correct (0xC3 0x9F),
But it is being interpreted as 2 separate characters, 0xc3 "Ã" and 0x9f "Ÿ"
The UTF8 encoding of "ß" is correct (0xC3 0x9F),
But it is being interpreted as 2 separate characters, 0xc3 "Ã" and 0x9f "Ÿ"
Resolving The Problem
To fix the problem, override the JVM encoding settings forcing the JVM to read and interpret the
characters as UTF-8.
characters as UTF-8.
For example, on WebShpere Application Server, via Application servers > server1 > Process Definition > Java Virtual Machine > Generic JVM arguments, add the following -D options and then restart the server.
-Dfile.encoding=UTF-8 -Dclient.encoding.override=UTF-8 -Ddefault.client.encoding=UTF-8 -Djava.nio.charset.Charset=UTF-8
Document Location
Worldwide
[{"Type":"SW","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSNW2F","label":"FileNet P8 Platform"},"ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]
Was this topic helpful?
Document Information
More support for:
FileNet P8 Platform
Software version:
All Version(s)
Document number:
6441917
Modified date:
14 April 2021
UID
ibm16441917