Axis sender adapter UTF-8 encoding issue

[former_member560382]

Hi guys,

I am facing an issue with sender Axis adapter when sending german character. Despite the encoding is UTF-8, the characters get 'demaged'. For a comparison I tried the same message with HTTP sender adapter, and there was all good. Therefore I assume there is some bug with the encoding.

Do you have any suggestion or experience with this?

when message posted via HTTP adapter, looks in the monitor like this

<ns0:Order xmlns:ns0="sometestns">

   <Query>

     <SalesOrderID>Außewölf</SalesOrderID>

   </Query>

</ns0:Order>

using Axis adapter looks like this

<ns0:Order xmlns:ns0="sometestns">

   <Query>

      <SalesOrderID>Au&#xC3;&#x192;&#xC5;&#xB8;ew&#xC3;&#x192;&#xC2;&#xB6;lf</SalesOrderID>

   </Query>

</ns0:Order>

And basically the main problem is, when the message from Axis gets to CRM, it is malformed.

Any hints?

I am on

Make Release	NW731EXT_17_REL
SP Stack Number	17
JDK Version	jdk16

Thanks, Peter

[Former Member]

Hello Peter,

check SAP Note #1802147 and try to execute the request with defining explicitly the charset. Maybe it will help.

Regards,
Vadym

[bhavesh_kantilal]

Hello Vadym,

I am on PI 7.31 SP 06 and hence this note does seem applicable and something that should sort the issue.

Unfortunately for me , a SP upgrade to SP 08 or higher where this patch should be available is not a possibility and hence cannot confirm if implementing this fixes the issue. Hopefully someone on a greater version of PI can confirm that this issue does not occur on their end to help validate this!

Regards,

Bhavesh

[former_member560382]

and one more update..  The problem is (and probably bug in Axis), when using "rest" parameter. In that case the nonASCII characters don't get HTML encoded properly and are corrupted

[engswee]

It doesn't seem like anyone else is responding to this issue, so it might be no one else is aware of this HTML encoding issue or knows of a way to fix it.

As such, if you want to get it fixed, then opening a call to SAP is the most likely way to go.

Otherwise, since you mentioned that it's not a problem when a message mapping is used, then you might want to add that into the scenario - not ideal if you were hoping for a passthrough scenario, but there's not much options left from the looks of it.

PS: Stating up front that this is already a live interface and German characters are a new addition would have been very crucial information. This would have prevented some of us trying to force the REST design down your throat!

[former_member190293]

Hi Eng Swee!

I've honestly tried to find workaround for this issue with some Java libraries, but due to lack of knowledge in UTF encoding and HTML entities I was not successfull.

Regards, Evgeniy.

[bhavesh_kantilal]

Hello Peter,

I just tried this and was able to replicate the issue. Sorry took me sometime to get off the blocks on this one This definitely seems like a bug!

I tried setting a Message Mapping but even when I have a mapping, the same results occur,i.e, the output of my mapping remains the same. Are you sure having a mapping in the middle ( a 1:1 mapping ) means PI decodes the text?

Regards

Bhavesh

[Former Member]

Hi Peter,

         Try using the MessageTransform bean and Text codepage conversion beam in the module. Please find below screenshot for reference;

- Muru

[former_member560382]

Hi guys,

so after latest tests we had some more results.

(Just regarding changing the adapter - that is not possible, this solution is live for some time and nowwe are only starting using german chars. Changing the adapter type would have huge regressive impact. Impossible to do now).

So let's focus on sender Axis.

So what it does is it HTML encodes non ASCII characters. This is not a problem if you use a standard message mapping, because during this the message gets HTML decoded and all these characters are then sent to receiver adapter as UTF-8, so no problem. Problem occurs, when you either don't use any mapping at all and just pass through the message, or if you use some java mapping, which doesn't deal with this.

So the options are either to sent Axis sender not to translate chars to HTML encoding or to use java to revert them back.

[bhavesh_kantilal]

Hi Peter,

Does it make sense to remove the custom handler temporarily and check if the message still gets corrupted? Will help eliminate an additional Point of failure.

Also, do you mind sharing your Axis configuration screen shot? Dont mind trying this on my end and seeing what happens just as a reference point.

Regards

Bhavesh

[former_member560382]

Hi Bhavesh, we tested it. It gets corrupted as well.

[former_member560382]

so if you try only a standard setting, you should get the same result.

[engswee]

Hi Peter

Do you actually mean receiver adapter since it's sending from PI to CRM?

Also, any particular reason for using Axis? You are on quite a high SP level which also supports the REST adapter.

Regards

Eng Swee

[former_member560382]

Hi guys,

no no, I am talking about sender adapter. I send a message from a client app and when that goes through the Axis adapter and I check it in monitor, it looks like i wrote. Which is strange considering it is supposed to support UTF-8.

We used axis because we wanted to avoid mandatory authorization requirements for other adapters and didnt want to switch off authoraization on the whole server. Additionally there is implemented a custom handler which responses to senders.

Yes, now there are better option to implement this, but it is not achievable from the project prospective. (timelines, budget.. you know guys

But it definetely seems to be some bug with handling UTF on the Axis.

[former_member194786]

Hi Peter,

I agree with Eng Swee here and would also suggest to use the REST adapter. Regarding the authorization and custom response, you can achieve both using REST adapter itself. For not using authorization, select the option "Allow public access(no authorization required)" in channel Selection tab of REST channel and for sending back custom response back, you can handle using Error handling tab Result handler, where your Source will be "Always", Action would be Custom Result and then you can provide a response as you want.

Coming back to your query, you can try performing encoding on the message in a UDF and see if that changes the message in the format that you expect.

Regards,

Sanjeev.

[engswee]

Sanjeev mentioned exactly what I had in mind - your requirement can be easier to achieve with the REST adapter standard functionality without going the Axis route.

Just to add on, these functionality are delivered on 7.4 SP13 - refer the answer by Vadim in the following thread as well as the link to the SAP library there which provides more info on both the functionality that Sanjeev mentioned above.

How to disable basic authentication for sender ... | SCN

Since you are on 7.31 SP17 which shares the same Java package as 7.4 SP13, these functionality are readily available to you as well.

Of course, I understand that project timelines will affect these considerations. However, from the symptom you have described above, there might be a bug in the Axis adapter. I don't think that can be resolved via UDF since the Axis adapter at the sender side already encodes it incorrectly when it reached the messaging system. This might require you to open a call with SAP Support, which most likely will result in a ping-pong match - if you are lucky, there might be an existing bug fix for it, but if you are not, then this will drag on longer than you or your project may like.

So in the meantime, it might be a good idea to explore an alternative design.

Just my two cents.

[former_member190293]

Hi Peter!

I'm not much experienced in Axis adapter, therefore just could try to suggest using java UDF in mapping where you could try to convert your string to correct encoding.

Regards, Evgeniy.