Problems with calling webservice after system upgrade.

[former_member186148]

Hello all!

We have some WDJ applications on SAP NW Java 7.3 which uses webservices from SAP backend system (7.01). These webservices developed by us and based on the Function groups.

After upgrade this backend from 7.01 to 7.31 SP 7 we've faced a problem that some of our web-services can't be run anymore. Logs in the Java side sais that there are issues on the service provider side (in our case it's backend system). In the trace files of the backend system we see logs like this:

<?xml version="1.0" encoding="utf-8"?>
<asx:abap version="1.0" xmlns:asx="http://www.sap.com/abapxml">
    <asx:values>
        <TRC_RECS>
            <SRT_MONI_STATUS_TRACE>
                <TS>20130716054915.086702</TS>
                <CLASS_NAME>CL_SOAP_RUNTIME_SERVER</CLASS_NAME>
                <METHOD_NAME>EXECUTE_PROCESSING</METHOD_NAME>
                <PROCESSORID>SOAP_RUNTIME</PROCESSORID>
                <PROCESSORNAME>SOAP Runtime</PROCESSORNAME>
                <TRC_LEVEL>1</TRC_LEVEL>
                <STATUS>E</STATUS>
                <TEXT>A SOAP Runtime Core Exception occurred in method
DETERMINE_OPERATION_NAME of class CL_SRT_WSP_RT_CONFIG
at position id 1 with internal error id 1033 
and error text &lt;no error message available&gt;: 
("Message "ZlibIndReadTblsCommonMass{urn:sap-com:document:sap:soap:functions:mc-style}" 
not supported (interface: "ZLIB_FG_WS" binding key:
"50B1FBB961DA0459E10000000A840FEE")") (fault location is 1  ).</TEXT>
                <ISREQUEST>X</ISREQUEST>
            </SRT_MONI_STATUS_TRACE>
        </TRC_RECS>
    </asx:values>
</asx:abap>  

I tried to find posts with similar problem but found nothing.

How we can fix this issue?

regards,

Lev

[Former Member · Accepted solution]

Hi Lev,

Try to "re-generate" or "re-validate" the connection, because it has a kind of "connection ID" and this lost after the upgrade. I had the same problem back then, after upgrading EhP.

I hope this will help you.

Regards,

Andre

[Former Member · Accepted solution]

Hi Lev,

The "connection ID" is in this case the "Binding Key", after re-generate/re-validate, you will get a new Binding Key, and it should works again.

Regards,

Andre

[former_member186148 · Accepted solution]

Hi Andre!

What do you mean about "re-validate"? Have I go to the transaction SOAMANAGER in the backend system and recreate configuration for web-service?

regards,

Lev

[Former Member · Accepted solution]

Hi Lev,

Yes, you can check the Webservice Administration there, or alternatively use WSADMIN.

You don't have to recreate the configuration but try to "test the connection" from there.

Regards,

Andre

[former_member186148 · Accepted solution]

Well, I can't use WSADMIN since this transaction is obsolete and newly created webservices invisible there. So only SOAMANAGER can be used.

"Test the connection" - like described here - https://wiki.sdn.sap.com/wiki/display/ABAPConn/Web+Service+Testing+Using+the+J2EE+Server+Web+Service... ? Right?

And I still don't understand what does mean "re-generate/re-validate".

Regards,

Lev

[Former Member · Accepted solution]

Hi Lev,

Yes, if you try to start/test your Web Service application from there (point 6 from your link), did you get succeeded? It should "re-generate" a new binding key, tha's what I meant.

Regards,

Andre

[Former Member · Accepted solution]

Hi Lev,

Check this one: http://wiki.sdn.sap.com/wiki/display/ABAPConn/How+to+find+Web+Service+WSDL+in+SOA+Manager

See point 9:

Choose the desired WSDL option from this tray and select Open WSDL document for selected binding or service again to regenerate the WSDL.

Regards,

Andre

[former_member186148 · Accepted solution]

Hi Andre!

I've done test as described in that link and everything was fine. It's strange - from WebServiceNavigator (from Java instance) web-service called without any problems but call from WDJ application led to the error mentioned in my start message.

This error had gone after I recreated web-service configurations in SOAMANAGER and it seems that everything working fine now. But I'm going to perform more tests for our WDJ applications and after that I'll close his thread with points if everyting will be fine.

Regards,

Lev

[Former Member · Accepted solution]

Hi Lev,

I'm glad to hear that your problem is gone now.

As I mentioned before, by doing this "test", it will re-generate a new "binding-key".

It means that every time you upgraded or refreshed your system (new DEV/QAS) or after a system-copy or a migration, you need to perform this procedure again for all your web-services.

Regards,

Andre

[Former Member · Accepted solution]

Hi Lev,

How was your test?

Just want to confirm if my proposed solution was the correct answer to your problem.

Thanks, regards,

Andre

[former_member186148 · Accepted solution]

Hi Andre!

In the DEV system we recreated web-services and recreated configurations for it since only recreation of configuration didn't help us. We transported those recreated web-services to QAS system and recreated configurations there but it didn't solve our problem for some reason. So this method worked in one system and didn't worked in other. It's really strange.

Regards,

Lev

[Former Member · Accepted solution]

Hi Lev,

That's strange indeed, because the same solution should re-generate a new "binding key", and that was the root-cause to your problem, WS having the old binding key.

And you did get the same error prior to transporting to QAS?

>>  and error text <no error message available>:  

     ("Message "ZlibIndReadTblsCommonMass{urn:sap-com:document:sap:soap:functions:mc- style}"  

     not supported (interface: "ZLIB_FG_WS" binding key: 

     "50B1FBB961DA0459E10000000A840FEE")") (fault location is 1  ).</TEXT> 

Another check: Did the transport went OK (RC=0 or 4)? Did all objects activated correctly after the transport? Did you include everything in that transport which needed for those WS?

Regards,

Andre

[former_member186148 · Accepted solution]

Hi Andre.

Sorry for delayed answer.

The transport went OK.

The problem in QAS system was happend since our basis team forgot to recreate WS configurations in SOAMANAGER and I dind't know about that. After configurations were recreated everything became OK.

So the solution for my situation is follow: regenerate web-services and recreate configurations for them in SOMANAGER.

Thank you for your help.