The following blog is written by Quincy Anderson – Senior Education Consultant in the North America SAP Education Delivery Organization since 1999 and is the first in a three part series dealing with Web Services from an ABAP perspective. Quincy specializes in the areas of ABAP, JAVA, Workflow, and Portal. Quincy holds both associate and professional level certifications for both ABAP and JAVA development and also an associate level certification for Portal development. You can contact Quincy via email at firstname.lastname@example.org.
Recently, one of my colleagues forwarded me a student email to solicit my thoughts:
“A quick question for you – do you have any experience with calling an External Web Service from an ECC 6.0 system WITHOUT using NetWeaver PI? I would like to find a way to call our SaaS services directly from SAP, but can’t use PI because it logs card numbers and security codes which is a no-no for the PCI-DSS requirements. Any good ideas?”
Now normally of course, I would suggest to a student that they should use PI as it’s a fantastic middleware product but sometimes as technical purists we can forget that in the real world other considerations come onto play that affect technical decisions. Sometimes those other considerations are business process or regulatory in nature. Put another way, when someone asks “Is this possible?” the answer may be “Technologically possible but legally prohibited.”
Fortunately for the student in this case, a solution was available namely generating a “Web Service Client Proxy” (hereafter proxy) using transaction code SE80. Before we look at the specifics of creating a proxy first; a little background information. Web Services are self contained functional entities that are capable of being called (by the client) and delivering a result (to the client). Creating a web service will be the subject of a future blog (think of the creation of the web service as the server side of the equation). For now we will look at the client side of the equation which is generating a proxy which can be used to call a web service and receive the results of that call.
The only prerequisite to a generating a proxy is a web service (which as noted above will be the subject of a future blog).
To get started from our transport package we create an “Enterprise Service” as depicted in Figure 1 below.
From the second screen of the wizard (Figure 2 below), we choose the second option since we have the WSDL URL available. All web services have a WSDL file available which was created when the web service was originally developed (irregardless of the tool used to create the web service) and a URL to retrieve that WSDL file was also created at the same time. It is this URL that we will copy and paste hence we choose option 2. The WSDL file that the URL points to is an XML based file containing the specifics of a web service (i.e., location, methods that can be called and their corresponding parameters, etc.). The first option in the screen (“Enterprise Service Repository”) would normally be used to call a web service located in PI but as noted above by the student, business and legal considerations preclude that option in this particular case. The third option (“Local File”) is used if you happen to have the WSDL file available on your local machine (or maybe on a shared network drive). A file browser will pop up to select it from its location.
On the third screen of the wizard we do a straight copy and paste of the WSDL URL (Figure 3 below).
On the next to last screen (Figure 4 below), we assign our package, proxy prefix, and change request. The prefix is for the various programming objects about to be created (we will see the prefix in each name in a few moments). The package and change request are for transport purposes.
Finally, we choose “Complete” in the final screen of the wizard (Figure 5 below) to conclude the creation of our proxy.
In Figure 6 below, we now see what (and this is very important) the wizard is *about* to create. But it does not actually create anything until we *activate*.
Here we have the result of our efforts namely a proxy that can be used to call a web service directly (Figure 7 below). Note the various subobjects created. They all have “ZFLIGHTPROXY” as a prefix. These subobjects, taken as a whole, form a complete solution to call a web service. As the cliché goes: “The whole is greater than the sum of its parts”.
In our next blog, we will look at how to actually code against this proxy to call our web service (thus finishing up the client side of the equation) and in a third future blog, we will look at how to create a web service based off of an ABAP function module (thus concluding the server side of the equation).
We offer a wide variety of courses through SAP Training dealing with Web Services and other technical topics. Be sure to check out the entire NetWeaver training curriculum online at https://training.sap.com/us/en/courses-and-curricula/netweaver. You can also contact our Customer Interaction Center at 1-888-777-1727 or email them at email@example.com.