Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

SOAP request to proxy interfaces

Former Member
0 Likes
791


Hi,

We have developed proxy interfaces and generated the WSDL using SOAMANAGER.  This we configured in SOAP UI 5.0.0 for testing.  But nowadays we are facing on challenge.  Once we load the WSDL, it will work fine.  But the same request will give below error after some time.

<env:Text xml:lang="en">Web service processing error; more details in the web service error log on provider side (UTC timestamp 20150311103533; Transaction ID 54FF1844BFE20E40E10080000A300DA3)</env:Text>

When we check t-code SRT_UTIL, it gives the below message.

If we add a new request using the same WSDL, it will work fine again.

Any idea why is this happening?

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
693


The messages are getting expired because of the below reason.

If a Web Service consumer of an SAP system logs on to a
Web service (WS) with message-based authentication such as a UsernameToken, a
SAML token, or an X.509 certificate, the Internet Communication Framework (ICD)
initially performs the logon using the technical user DELAY_L_<SID> that
is stored in the ICF. A direct logon with the authentication data contains in
the SOAP document is not possible, since the ICF cannot access SOAP data.

   

The report WSS_SETUP creates the DELAY_L_<SID>
user, which does not have any authorizations and which I did. The report also
stores the user password in the secure storage. If a WS consumer then accesses
the WS provider, the system first logs on using the user stored in the ICF node.
If the user name and password match, the WS provider performs a user exchange
and logs on the user specified in the UsernameToken.

In short:    

  1. The WS consumer wants to access the WS provider
    and authenticate itself with a UsernameToken.
  2. The ICF cannot evaluate the authentication in
    the document, but rather requires an HTTP authentication. Therefore it uses the
    DELAY_L_<SID> user stored in the ICF and its password for the
    authentication.
  3. The WS provider evaluates the security token
    (such as a UsernameToken). If the user and password match, it replaces the user
    DELAY_L_<SID> with the user specified in the security token.

When we set up the DELAY_L_<SID>, there is an
option to set the time highlighted below.  The maximum time we can give
here is 32767 seconds ( 9 hours).  If we don’t give this value, then it
will take 90 seconds by default.  So after this time, the request will get expired.

Thanks

Vinitha

1 REPLY 1
Read only

Former Member
0 Likes
694


The messages are getting expired because of the below reason.

If a Web Service consumer of an SAP system logs on to a
Web service (WS) with message-based authentication such as a UsernameToken, a
SAML token, or an X.509 certificate, the Internet Communication Framework (ICD)
initially performs the logon using the technical user DELAY_L_<SID> that
is stored in the ICF. A direct logon with the authentication data contains in
the SOAP document is not possible, since the ICF cannot access SOAP data.

   

The report WSS_SETUP creates the DELAY_L_<SID>
user, which does not have any authorizations and which I did. The report also
stores the user password in the secure storage. If a WS consumer then accesses
the WS provider, the system first logs on using the user stored in the ICF node.
If the user name and password match, the WS provider performs a user exchange
and logs on the user specified in the UsernameToken.

In short:    

  1. The WS consumer wants to access the WS provider
    and authenticate itself with a UsernameToken.
  2. The ICF cannot evaluate the authentication in
    the document, but rather requires an HTTP authentication. Therefore it uses the
    DELAY_L_<SID> user stored in the ICF and its password for the
    authentication.
  3. The WS provider evaluates the security token
    (such as a UsernameToken). If the user and password match, it replaces the user
    DELAY_L_<SID> with the user specified in the security token.

When we set up the DELAY_L_<SID>, there is an
option to set the time highlighted below.  The maximum time we can give
here is 32767 seconds ( 9 hours).  If we don’t give this value, then it
will take 90 seconds by default.  So after this time, the request will get expired.

Thanks

Vinitha