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:
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:
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 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!
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.