Introduction
I have written several times on the topic of WebServices from the ABAP content:
- ABAP WebServices: Logon Language Processing
- WebService Navigator Page for ABAP and Java
- WebServices: A real world implementation experience
- Publishing ABAP WebServices to an External UDDI Server
- Develop a Web Service that sends an Email – in ABAP
- BSP a Developer’s Journal Part XIV – Consuming WebServices with ABAP
- BSP – a Developer’s Journal Part XIII: Developing ABAP WebServices
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.
.Net Side – Setup
I don’t want to focus too much on the development from the .Net Side. I will give you a little background however. We were developing a .Net WebService that would call MSSQL stored procedures in our shop floor MES system. This call would actually be triggered out of our 46C R/3 system from an User Exit in the QM Inspection Lot Maintenance Application. This way when Usage Decisions are made in R/3 we will update the Shop Floor system (by passing through R/3 to our 640 Standalone WebAS system) in real time. Given that this was very important Quality data, we 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:
IIS Configuration – Authentication
IIS Configuration – HTTPS
SAP Side – Setup
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:
Logical Port Setup
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.
RFC Setup – Technical Settings
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.
RFC Setup – Logon/Security
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.
Have been going through your documents. Found them very elloborated and helping.
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
nitingupta.sap@gmail.com
ngupta_satyam@indiabulls.com
First of all, congratulations for your excellent blogs. They are very helpful.
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
This ring’s any bell to you?
What am I doing wrong or what I miss in configuration?
Can you give a direction on this?
Thanks in advance.
Alexandre
My guess, based upon the reference to Security Header, is that this webservice is requiring more than just HTTPS. It is also looking for document level security. You will need to look at adding a security profile to the Logical Port that you use for this service proxy.
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.
The last line at your blog “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). ”
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!
I’ve set up the server PSE and exported the certificate request, signed it and imported the response (there was an issue importing this from a file but saving to a file then pasting the content in worked).
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”.
Have I missed something?
My version of SAP PI STRUST tells me it has notified the ICM after I import certificates so I hadn’t tried to restart it. I did this morning but, with STRUST still telling me my “Own Certificate” is self signed, that didn’t make a difference.
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.
Thanks
well, what described above works for me, as long as I create logical port in LPCONFIG. However when I create logical port via SOAMANAGER, it doesn’t work. Obviously that option to take “anonymous client” (whatever it is) is missing there…
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
Good Blog , Solved a problem quickly which i had spent like hours. 🙂