SOAP Axis - XML encoding

[Former Member]

Hi,

I have used SOAP Axis adapter for consuming a third party web service. One method requires name surname as input parameters. But when i used Turkish characters (e.g. Ğ, İ, Ş, Ç ) i am getting error "(400)Bad Request".

I checked Integration Engine messages in message monitoring. the payload is always correct as below.

" is incorrect.

I changed the SOAP version as 1.2 and i got below error

com.sap.engine.interfaces.messaging.api.exception.MessagingException: org.xml.sax.SAXParseException: Premature end of file.

Is there any idea why it happened? could it be a bug? if so which art of PI?

System information: PI 7.1 EHP1 SP04

Kind regards,

Altuğ Bayram

[sunil_singh13]

Hi,

Try to send the payload in CDATA(can be easly achieved using XSLT or JAVA mapping) formate, it avaoids the xml validation/modification to the payload. You can remove the CDATA formate while mapping logic and then send it as it is just before calling the Web Service.

Thanks,

Sunil

[Former Member]

Hi SUnil,

Thanks for help. I will try it.

Kind regards,

Altuğ Bayram

[stefan_grube]

Make sure that the web service does accept UTF-8. I know a lot of web services which are not complient to standard and expect a specific format.

Check also web service log, of the message has reached the server and why it was denied.

[Former Member]

Hi Stefan,

I am using other methods of the web service and there is no problem. It is accepting UTF-8. I am also getting results correctly in UTF-8 which contains turkish characters.

I am not sure it is delivered but should be because there is no problem with other WS methods.

I was below error in log viewer

Message: Message 4c8cd507-2a9d-006f-e100-80000aa6001c(INBOUND): was not delivered due to com.sap.engine.interfaces.messaging.api.exception.MessagingException: (400)Bad Request

Date: 2010-09-13

Time: 18:41:24:505

Category: com.sap.aii.adapter.xi.ms.XIEventHandler

Location: com.sap.aii.adapter.xi.ms.XIEventHandler.onRequest(Services, TransportMessage)

Application: sap.com/com.sap.aii.af.ms.app

Thread: Thread[HTTP Worker [@1594130585],5,Dedicated_Application_Thread]

Data Source: j2ee/cluster/server0/log/defaultTrace_00.trc

Arguments:

DSR Transaction: 57a173f0bf4d11df9454001a64bb2238

Message Code:

Session: 306

Transaction:

User: PIISUSER

Time Zone: +0300

CSN Component: BC-XI-CON-AFW

DC Component: com.sap.aii.af.lib

Correlation ID: 504436150000000004

DSR Root Context ID: 57A173F0BF4D11DF9454001A64BB2238

DSR Connection: 57a173f0bf4d11df9454001a64bb2238

DSR Counter: 0

Log ID: 001A64BB22380317000000010011C0F2

Host: bepid0

System: BPD

Instance: DVEBMGS50

Node: server0

**********************************

Message: Caught exception com.sap.engine.interfaces.messaging.api.exception.MessagingException from application code with msgKey: 4c8cd507-2a9d-006f-e100-80000aa6001c(INBOUND)

Date: 2010-09-13

Time: 18:41:24:494

Category: com.sap.engine.messaging.impl.spi.ServicesImpl

Location: com.sap.engine.messaging.impl.spi.ServicesImpl.deliver(Message)

Application:

Thread: MS Queue Worker [SOAP_http://sap.com/xi/XI/SystemRqst]

Data Source: j2ee/cluster/server0/log/defaultTrace_00.trc

Arguments:

DSR Transaction: 57a173f0bf4d11df9454001a64bb2238

Message Code:

Session: 0

Transaction:

User: J2EE_GUEST

Time Zone: +0300

CSN Component: BC-XI-CON-MSG

DC Component: com.sap.aii.af.ms.svc

Correlation ID: 504436150000000004

DSR Root Context ID: 57A173F0BF4D11DF9454001A64BB2238

DSR Connection: 57a173f0bf4d11df9454001a64bb2238

DSR Counter: 0

Log ID: 001A64BB22380318000000010011C0F2

Host: bepid0

System: BPD

Instance: DVEBMGS50

Node: server0

**********************************************

Message: header HopList is an unexpected type null

Date: 2010-09-13

Time: 18:41:24:152

Category: com.sap.aii.axis.xi.XI30BaseHandler

Location: com.sap.aii.axis.xi.XI30BaseHandler

Application: sap.com/com.sap.aii.axis.app

Thread: MS Queue Worker [SOAP_http://sap.com/xi/XI/SystemRqst]

Data Source: j2ee/cluster/server0/log/defaultTrace_00.trc

Arguments:

DSR Transaction: 57a173f0bf4d11df9454001a64bb2238

Message Code:

Session: 0

Transaction:

User: J2EE_GUEST

Time Zone: +0300

CSN Component: BC-XI-CON-AFW-TAD

DC Component: com.sap.aii.af.axis.lib

Correlation ID: 504436150000000004

DSR Root Context ID: 57A173F0BF4D11DF9454001A64BB2238

DSR Connection: 57a173f0bf4d11df9454001a64bb2238

DSR Counter: 0

Log ID: 001A64BB22380318000000000011C0F2

Host: bepid0

System: BPD

Instance: DVEBMGS50

Node: server0

Kind regards,

Altuğ Bayram

[markangelo_dihiansan]

Hello Altuğ Bayram,

Can you try using UTF-16 as your encoding scheme? If this does not work, I suggest you try the steps below:

1. Create a MessageType that looks like your SOAP Envelope.

2. Use JavaMapping to add the SOAP Envelope tags and namespaces.

3. Use the PLAIN_HTTP_ADAPTER to connect to the external system.

I have had trouble with the Axis Receiver using SOAP, so I decided to try the steps above and it worked for me.

Regards,

Mark

[Former Member]

Hi Mark,

Thanks for advice. How can i change the encoding scheme as UTF-16?

Kind regards,

Altuğ Bayram

[markangelo_dihiansan]

Hi,

You could try using XLST or Java Mapping to override the UTF-8 Encoding Scheme. Just to be sure, can you use a third-party software like SOAP UI to test the WebService?Just to rule out that the WebService is not supporting UTF encoding like Stefan mentioned. Let us know of the results.

Regards,

Mark

[Former Member]

Hi,

I had a demo client application from the WS provider. It was written in Java and used Swing library and axis2. It was using another method which is not sending any turkish character as input. But i added a code for trying the method. Put the same input but got the below exception.

Error in extracting message properties

...Error in converting SOAP Envelope to Document; nested exception is: org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character ((CTRL-CHAR, code 30)) at [row,col {unknown-source}]: [4,1109]

......com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character ((CTRL-CHAR, code 30)) at [row,col {unknown-source}]: [4,1109]

.........Illegal character ((CTRL-CHAR, code 30)) at [row,col {unknown-source}]: [4,1109]

Kind regards,

Altuğ Bayram

[Former Member]

Hi,

I have spend time and debugged the demo application in NW developer studio. I found that it has a bug about in UTF8Writer class. But it is part fo axis2. We are using axis 1.4 in PI. It should be similar bug in the axis 1.4 but dont know. How can i debug the axis adapter? Is it possible? or should i send a message to SAP?

Kind regards,

Altuğ Bayram

This is the buggy code is doing a kind of convertion

   public void write(int c)
        throws IOException
    {
        // First; do we have a left over surrogate?
        if (mSurrogate > 0) {
            c = convertSurrogate(c);
            // If not, do we start with a surrogate?
        } else if (c >= SURR1_FIRST && c <= SURR2_LAST) {
            // Illegal to get second part without first:
            if (c > SURR1_LAST) {
                throwIllegal(c);
            }
            // First part just needs to be held for now
            mSurrogate = c;
            return;
        }

        if (mOutPtr >= mOutBufferLast) { // let's require enough room, first
            mOut.write(mOutBuffer, 0, mOutPtr);
            mOutPtr = 0;
        }

        if (c < 0x80) { // ascii
            mOutBuffer[mOutPtr++] = (byte) c;
        } else {
            int ptr = mOutPtr;
            if (c < 0x800) { // 2-byte
                mOutBuffer[ptr++] = (byte) (0xc0 | (c >> 6));
                mOutBuffer[ptr++] = (byte) (0x80 | (c & 0x3f));
            } else if (c <= 0xFFFF) { // 3 bytes
                mOutBuffer[ptr++] = (byte) (0xe0 | (c >> 12));
                mOutBuffer[ptr++] = (byte) (0x80 | ((c >> 6) & 0x3f));
                mOutBuffer[ptr++] = (byte) (0x80 | (c & 0x3f));
            } else { // 4 bytes
                if (c > 0x10FFFF) { // illegal, as per RFC 3629
                    throwIllegal(c);
                }
                mOutBuffer[ptr++] = (byte) (0xf0 | (c >> 18));
                mOutBuffer[ptr++] = (byte) (0x80 | ((c >> 12) & 0x3f));
                mOutBuffer[ptr++] = (byte) (0x80 | ((c >> 6) & 0x3f));
                mOutBuffer[ptr++] = (byte) (0x80 | (c & 0x3f));
            }
            mOutPtr = ptr;
        }
    }

[markangelo_dihiansan]

Hi,

You could try viewing SAP Note 1039369 regarding the FAQ about Axis Adapters. If this did not help, you can write directly to SAP regarding this issue. The reason why I did not use the SOAP Axis Adapter is that it is giving me a very strange error. We are getting a 500 internal error even though we don't have firewall restrictions and the URL is working. Checking the deployment did not help because it is okay. Pressed for time, I changed the adapter to Plain HTTP and it worked.

Hope this helps,

[stefan_grube]

When the demo app has wrong code, I assume that the web service has the same wrong code.

You shoud not wast your time by searching the issue in SOAP/Axis adapter. This adapter works in many customer scenarios perfect. The web service is defitively the source of the issue.

[Former Member]

Hi Stefan,

Today, I have created a simple client application in .NET. It worked very well. It is certain that axis and other apache libraries have a bug. It is working very well with ASCII texts but not for turkish characters.

I have also told my previous post that i found the bug in the Axis 2. It is doing char -> byte -> char conversion but it has a bug. That should be corrected.

When i have a time i will debug axis 1.4 and will find the bug.

Kind regards,

Altuğ Bayram

[Former Member]

Hi,

I have informed SAP with an OSS message. After a long investigation by Development Support the reason was found.

I have used xmlsec-1.4.0.jar because the SAP note was referring to use 1.4.0. I didnt check newer releases of xmlsec. When OSS was indicated that 1.3.0 doesnt have this issue. I have checked xmlsec web site and found below explanation.

-

---

Version 1.4.1 Released

Version 1.4.1 of the Java library has been released. This is a bugfix release that contains a major bugfix to the canonicalization engine introduced in the 1.4 release. It is recommended that 1.4 users upgrade to the new version as signatures containing non ascii characters created by this library are not according to the standard, and will be only validated by 1.4 library.

-

---

Anyway, i have updated the SDA with xmlsec-1.4.3 and related jars. Deployed to our systems and tested successfully.

If anyone needs to use axis and xml security for non-ascii characters, should stay away from xmlsec-1.4.0.

Kind regards,

Altuğ Bayram

[Former Member]

Hi Altuğ Bayram,

I have informed SAP with an OSS message. After a long investigation by Development Support the reason was found.

I have used xmlsec-1.4.0.jar because the SAP note was referring to use 1.4.0. I didnt check newer releases of xmlsec. When OSS was indicated that 1.3.0 doesnt have this issue. I have checked xmlsec web site and found below explanation.

Can you please tell me which note was talking about this specific scenario? Also where to replace xmlsec jar file? is it in Axis eployment jar or else where.

thanks in advacne.

thanks,

Venkat