Calling WebServices From ABAP Via HTTPS - SAP Blogs
Calling WebServices From ABAP Via HTTPS - SAP Blogs
� �
Login
Thomas Jung
May 13, 2005 6 minute read
Introduction
I have written several times on the topic of WebServices from the ABAP content:
You would think that I would run out of things to write about on WebServices. But it seems like every time we do a
new project using the technology, I learn something new. Maybe that is why I enjoy working with WebServices so
much. Well this week was no different. A college of mine, Chris Cassidy, had a project where he needed to call a
WebService from ABAP. So far so good. However the WebService he was going to be calling (written in .Net) required
HTTPS and Basic Authentication. This was something we had never done before (and I had never written about). We
were able to work though the setup with a few minor problems along the way. Thanks to Chris’s excellent note taking, I
can now share those details and learning’s here today.
wanted to make sure that the data was secure. We also needed the user who authenticated to the WebService to
have its credentials passed through to the SQL Server database. This caused us to have to require SSL (HTTPS) for
the WebService communication. We have an internal Certificate Server at our company. We needed to setup the Root
Certificate for this internal CA on the Web Server that was going to host the WebService. We also needed to go into
IIS for this WebService and force it to require Secure Communications. The following are some screen shots of the
configuration we did in IIS:
I didn’t go into much detail on the WebService setup on the .Net or IIS side. We found plenty of detailed documents on
that other Developers’ Network on the subject. We are all here because we are interested in how to do the ABAP side
of the setup – right? First of all you can following most of the setups detailed in the following weblog: BSP a
Developer’s Journal Part XIV – Consuming WebServices with ABAP. The webservice proxy generation itself isn’t really
any different. When we begin to get differences is in the setup of the Logical Port (Transaction LPCONFIG). All my
examples in the past have used the URL option in the Call Parameters for the Logical Port. This is fine as long as the
connection requires no additional parameters for authentication or security. To go beyond plain HTTP URL
connections, you have to use an RFC Connection of Type G (HTTP Connection to Ext. Server). Before we jump to
SM59 to setup our RFC, I want to show you the area of the Logical Port I am referring to:
I have setup HTTP based RFC connections before. It isn’t too difficult. You supply your Target Host, Path and Port
number (called Service No. in the User Interface) on the Technical Settings Tab. We are going to be using HTTPS to
connect to the IIS WebService, so don’t forget that your Port will not be the default (80). HTTPS defaults to 443.
The next tab (Logon/Security) is where we can setup our requirement for SSL (HTTPS) and that we are wanting to
use Basic Authentication. This is also where we choose the user name and password to use for the Basic
Authentication. Notice that when you choose Basic Authentication combined with SSL the SSL Client Certificate Detail
Drop Down forces in the value for SSL Client (Anonymous). You can not override this value. Remember this Client
Certificate because it becomes very important later on.
The final tab (Special Options) allows you set Compression, Timeout and Cookie options. Now I suggest the following
settings for HTTP Settings (compression). We turned on compression initially. However we were unable to call the
WebService through the ABAP proxy using Compression. We received an error that the first character of the HTML
stream contained an unknown Hex Value. Turning off compression quickly corrected this error. I’m not sure if you
should be able to use compression or not. Perhaps this is just a bug either in .Net or in our WebAS 640 SP10 system.
RFC Setup – Special Options
We thought it would be a good idea to test our RFC HTTP connection from SM59 before we even try to test our
WebService itself. Unfortunately we immediately received an error message. The details from the ICM log were as
follows:
Now I had to clip the right edge of the screen to get an image that conformed to the SDN limits. Don’t worry though,
you aren’t missing much. A few hours of reading documents on SDN, the Service Marketplace, and through the
Internet (gotta love Google) lead us to better understand the nature of SSL Client calls out of the ABAP WebAS. This
is the way I understand it: In order to establish a Secure HTTP communication with a foreign system, SAP must verify
the other party’s server certificate. To do this SAP must have access to the Certificate for the Trusted Root Authority
that signed the foreign Server certificate. This Certificate must then be associated to the profile used during
Anonymous SSL (even though no actual client certificate from the WebAS is required). Remember that certificate
setting from the RFC setup that I told you not to forget? This is where it comes into play.
We will start off by getting our Trusted Root Certificate. Remember that I said early we have our own certificate server
(which is fairly common these days as I understand). Therefore I know that my browser (IE) has this certificate in it as
well. From Tools->Internet Options->Content Tab->Certificates->Trusted Root Certification Authorities Tab, I can
access and download the certificate that I need.
Now I need to load this certificate that I just downloaded into SAP and associate it to the SSL Client (Anonymous)
profile. You can do this work from transaction STRUST.
Now I would like to tell you that after uploading the certificate, the RFC destination connected just fine and we left work
early that day to head over to the local watering hole. Unfortunately that was not the case. The connection continued
to fail with the same error message. In fact we spent another 4 hours playing with settings, reading, and retrying
without any luck. Well past sundown I finally stumbled across an OSS note I wish I had found hours ago. It was OSS
Note 510007. It had detailed instructions on how to setup SSL on the SAP WebAS. However it was the very last line of
this Note that was so important:
Bear in mind that the changes made in the trust manager will only take effect after you restart the application server or
at least the ICM (transaction SMICM, Administration -> ICMAN -> Exit Soft).
Sure enough, we restarted the ICM and everything started working just fine. I would have never guessed that I needed
to restart the ICM just to add a certificate!
Closing
Hopefully I have been able to share another small piece of the very large WebServices puzzle. And maybe if you read
this weblog, you might be able to avoid the very frustrating afternoon that we experienced trying to setup the SSL
connection.
Alert Moderator
Assigned tags
Related Questions
17 Comments
Former Member
Like (0)
Former Member
Like (0)
Former Member
While following ur document for configuring Webservice ADS on ABAP. While testing my ADS connection in SM59 I
am getting ICM_HTTP_SSL_ERROR (only when I use SSL Client Certificate (Default & Anonymus) both.
Later I realized that may be the problem is with my SSL Client (PSE or Cert).
Can you just help us to provide any alternate on the same to resolve the issue.
My ultimate goal to achieve is I need to display Adobe forms in MSS in EP 7.0 with ESS / MSS 1.0 SP8.
Regards,
Nitin Gupta
[email protected]
[email protected]
Like (0)
Like (0)
Former Member
I’m trying to call a external WebService from ABAP via HTTPS without Basic Authentication and I followed all the
steps that you mention on the blog to configure it, except the part that your configure the user and password. The
RFC connection (HTTPS) is just working fine, but (there’s always a but) when I test the proxy client I get the
following error:
– WSDoAllReceiver: Request does not contain required Security header
Thanks in advance.
Alexandre
Like (0)
However all this is just a guess based upon an error message that likely comes from some external system. The
best bet is to talk to the service provider and see what all of their requirements are.
Like (0)
Bhavesh Kantilal
solved a issue that was troubling me for sometime! Its surprising that after loading a cert in STRUST, restart of ICM
process is needed. Coming from the Java World and having used Certs with Visual Admin of XI extensively, I find
this surprising. But hey it works Thanks Again!
Like (0)
Like (0)
Former Member
I can now launch the https://server:port/path/ping service successfully but I get a message back saying my browser
doesn’t trust the issuing authority for the certificate because that authority is my SAP PI server, not the corporate CA
which I used to sign the certificate request. All my keys are marked “self signed”.
Like (0)
Like (0)
Former Member
The import of the certificate response failed with an error saying the response could not be analysed. I found an SAP
Note which said that this may occur if you import from a local file bigger than about 4000bytes. However, copying the
same file from notepad to the clipboard and then pasting it into the import screen with the clipboard button works
(according to the note and in my experience).
Absent some flash of inspiration to the contrary I’ll destroy my PSE tomorrow and try again from scratch now I have
the rest of the methodology seemingly right.
Like (0)
Former Member
Like (0)
Like (0)
Former Member
Like (0)
Former Member
If I got it right, LPCONFIG is as obsolete as WSCONFIG, right? So I would prefer to go with SOAMANAGER instead,
only if it would work…
Any idea?
Thanks, Tom
Like (0)
Former Member
Like (0)
Maricela Valenzuela
Like (0)