I am using the below mentioned flow steps to decode an encoded string.But in the 2nd step(bytesToString) step,I am getting no output after conversion from byte to string.It seems base64Decode step is not creating proper object as expected .I am facing this issue in webMethods 8.2.But the same steps are working fine for the same input data in webMethods 6.5.
I tried with the below sequence of services, and found the output to be fine… I am running on 8.2.2 with IS Core Fix 8. As you said, this is executing fine in 6.5, I am assuming it is a different environment. In such case, are you sure the data that you are passing is base 64 encoded format?
Thanks for the reply.
Sorry for not elaborating the issue properly.
There are two issues related to the above scenario.
1)Not getting output for byteToString service for a particular encoded data .
2)In the third step, a java service is called which encodes the string with the customized charset value.
We are getting the below error in this step for the encoding charset(begins with WM_) used in 8.2.But the same encoding charset is used in webMethods6.5 environment and the same service is working fine.
After analysing, I came to know that only “UTF-8” default encoding is being accepted in our webMethods8.2 environment .
So it seems we need to do some server side configuration to accept other charsets. Could you please let me know what changes we should make to resolve this issue.
Error-Unsupported Encoding Exception
RMG/Senthil-Thanks for your reply. I will check on Monday and let you know about the fixes applied in webMethods 8.2 env.
Thanks rmg for your suggestion.Our integration architect has already raised a ticket in software ag.If any resolution is provided,I will update in the forum.
When you invoke bytesToString service, you could see an input parameter ‘encoding’. You can set this to specific value or ‘autoDetect’.
You had also mentioned that, it worked in 6.5 whereas not in 8.2. May I know what Operating System you had in 6.5 and what you have now in 8.2? It actually depends on encoding supported by the specific Jvm used by that OS.