Web App Services Part 2 EMconvt

8/8/2019 Web App Services Part 2 EMconvt

1/27


2/27

How to Develop Web Services in WebASPart 2:Design your own Web serviceswith ABAP HTTP Extensions

Consulting Web Services from SAP and Anywhere

Accessing SAP from Any Web ServerNowadays, the SAP ERP suite is the omnipresent software solution for enterprise computing.Many companies rely on SAP to manage their important finance and asset management issues,as well as their sales and distribution process, just to name a couple of the functional areas thatSAP encompasses. A commonand definitely not very newdesire of users of informationtechnology is to access the data stored in a centralized ERP system from anywhere in the world;especially now, since we have a feature-rich Internet browser client stored on every computer,including small pervasive devices like the palm-top computers. Under this premise, it appears asa natural choice to access your centralized SAP system via HTTP, the protocol your browseruses. Once you start talking about managing business processes remotely via the Internet, you'retalking about the emerging technology that we call Web services.

Somewhere in the Internet/Intranet

SAP R/3

RFC Function Modules BAPI

HTTP Client Application

(can be another R/3 system, too)

RFC

RFC

RFC

RFC

COM

HTTP

HTTP Communication Interface

Understands both HTTP and RFC

SAP WebAS ICMInternet Communication Manager

Any HTTPServer

Accessing SAP ERP via HTTP

Figure 1: Accessing an ERP System HTTP

Web services are designed to be accessed from another program, although they can generally beconsulted from a Web browser as well. The calling program can be any program that understandsHTTP, including SAP R/3 starting with release 3.0E. Before we go into details, lets first learnmore about Web services by example.

Copyright 2003 by Klee Associates, Inc. Page 2

www.SAPtips.com


3/27


Example of a Web Service

Let's look at what a typical Web service might look like. The principle of our example is very

simple:

You send an HTTP request to the Web service provider.

You receive an XML document with the result.

To visualize this, we shall have a look at Amazon.com, which allows XML-based inquiries to theirbookstore through automated Web services. You can test this easily by entering the HTTPrequest shown in Figure 2 in your Web browser:

http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-t=D2H30000000000&AsinSearch=3528057297&type=lite&f=xml.

Figure 2: Calling the Amazon.com Web Service

To make the request string a little better readable, we insert some line breaks after each part ofthe URL (Figure 3). However, the URL above must be entered as one string without any spacesas shown in Figure 2.

http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-t=D2H30000000000&AsinSearch=3528057297&type=lite&f=xml.

Figure 3: The Amazon.com Web Service Request URL Formatted for Better Readability

This request (which asks Amazon.com to list the books authored by someone in my company,

logosworld.com), returns a plain XML document with the requested information included. SeeFigure 4 below.


www.SAPtips.com
http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-http://xml.amazon.com/onca/xml2http://xml.amazon.com/onca/xml2http://xml.amazon.com/onca/xml2?t=webservices-20&tag=logosworldcom&dev-


4/27


3528057297The SAP R/3 Guide to EDI and

Interfaces

Axel AngeliUlrich StreitRobi Gonfalonieri

Friedrick Vieweg & Son$50.95

Tree representation of above XMLProductInfo

Details Asin 3528057297 ProductName The SAP R/3 Guide to EDI and Interfaces Authors Author Axel Angeli

Ulrich Streit Robi Gonfalonieri OurPrice

$50.95

Figure 4: XML-Response from Amazon.com

About URLs, URIs and Points of Content

In the theory of electronic communication, the partners at either end of a communication line arecalled end points. End points are also known as terminals, but this is a very ambiguousexpression, so we better avoid it. Typically, a communication consists of two partners. At one endis a client, orrequester, and at the other end is apoint of contentlocated on a server. In simple

cases, the point of content is a file.

In order to locate a point of content, the requester needs to specify sufficient information aboutthe requested content, so that the Internet framework can route the request to a listener that runson a server and is able to retrieve the content from the point of content.

Typically, the requester specifies three items:


www.SAPtips.com
http://www.w3.org/2001/XMLSchema-instancehttp://xml.amazon.com/schemas2/dev-lite.xsdhttp://xml.amazon.com/schemas2/dev-lite.xsdhttp://www.w3.org/2001/XMLSchema-instance


5/27


The public name of the server and the domain; alternately, it can specify the servers uniqueIP address.

The name of the resource in a format that it is understood by the listening port on the server

Optionally, parameters to pass further details about the request are provided.

The assembly of these three information items is called a URI Uniform Resource Indicator. Incases of Web pages, they are also known as URL Uniform Resource Locator, where a URL isgenerally recognized as a subset or special variant of a URI. So we can say that a reference to ageneral point of content within the Internet is called a URI, a Uniform Resource Identifier, whileURL is reserved to address a Web page. Figure 5 shows how a URI is constructed.

Traditionally, a URL references a file on a specific server. Nowadays a URL may point to any kindof electronic resource that can be reached via HTTP. In these cases, the Web server capturesthe URL, and instead of returning a simple file, it calls a program to return a computed result.

Parts of a URI

Resource type

Resource address Resource parameters

Protoc

ol

Serve

rNam

e

Doma

inpat

h&file

name

CGI-P

arame

ter

http: //www. logosworld.de /asp/testdrive.htm ?user=micky&pass=mausi

Resource address

Ressource type

http: HyperText Transfer Protocol

ftp: File Transfer Protocol

smtp: Simple Mail Transfer ProtocolMost important protocol for eMail distribution.

Protocol specially for file transfers.

Tells the server that the requester (i.e., the browser) wants to receive

general Unicode-coded documents (e.g., HTML).

This is an identifying name of the requested ressource. Usually, this is simply the

filename of the requested document, but it can be any string that is understoodby the server. Usually the server tells from the suffix (e.g., .htm, .txt, .asp, .php,

.cgi).

Tells the server which protocol to use. There are a wide variety of protocols. The

most important protocols are the following ones:

Figure 5: Elements of a URI


www.SAPtips.com
http://www.logosworld.de/asp/testdrive.htm?user=micky&pass=mausihttp://www.logosworld.de/asp/testdrive.htm?user=micky&pass=mausi


6/27


7/27


One great feature of the human readable XML format is that it usually allows an easy discoveryof its contents and the document structure without the need for external documentation. As apoint of comparison, many EDI projects failed primarily because the chosen formats wereproprietary and had been disclosed only to a pre-selected, exclusive audience (E.G. EDIFACTdocumentation is only accessible by paying dues to the organization).

2. Web services should be easily adaptable to a range of clients and operating systems.

The Alpha and Omega of Web services is compatibility through convention. No matter thecontent, Web services look largely the same. With the use of XML, it is possible to parsedocuments for necessary information, instead of mapping to a strict, inflexible format. Given thisflexibility, a handler program can react smoothly on changes and additions in the sent documents.

Characteristics of a Web Service

From what is offered as Web services today, we can generally characterize Web services ashaving the following attributes:

Web services are invoked via an HTTP request.

HTTP and the sister protocolslike the secure HTTPS optionare the undisputed standard asInternet protocol, and the only Internet protocol that is understood by all modern computers.

Web services deliver their results as an XML data stream.

XML has become the de facto standard for Internet data exchange. XML documents havebecome so ubiquitous that it is an easy bet to say that XML will be the exclusive data exchangeformat for any kind of online, automated document-distribution system. Many documentprocessing applications are transitioning from proprietary formats to storing data as XML data, oradding XML interfaces for external programs, e.g., the next version of Microsoft Office (Word,PowerPoint, etc.) will be XML-enabled, as will Adobe Framemaker. It is already obvious that theEDI world will soon be dominated by XML. Sooner or later all those acknowledged EDI standards

like EDIFACT/UN or ANSI X.12 will go the way of the dinosaurs. Web services results are structured datadata that can be easily interpreted by another

program.

This is an important characteristic that defines the essential difference between a classic Webpage and a Web service. Web services are designed to be consulted primarily by other programs.Due to the text-based nature of XML documents, the results are naturally readable as wellanother helpful XML feature. However, the response data must provide sufficient information sothat a program can formally derive the requested information with as little effort as possible.

Web service results are either called by:

passing the requested data to an agent as an XML document, or

passing parameters as part of the URI, using the canonical URL as introduced by the CGI.

(We'll elaborate on canonical URLs on the next page.)

Web services via the SOAP-XML Standard

As the request itself becomes more complicated, the URI(URL) used to issue the request wouldbecome lengthy. Therefore, the request can also be handed over to HTTP as a data block; this is


www.SAPtips.com


8/27


then called an HTTP Post request. There are many uses of HTTP Post requests, e.g., an HTTPPost request is sent to a server if you fill out an online HTML form in your browser and submit theform data. Amazon.com accepts requests from an HTTP Post as well and, in this case, it usesthe SOAP protocol standard.

SOAP is the acronym for the Simple Object Access Protocol and is itself an XML document. Inaddition to having the same features as a plain XML document, SOAP defines restrictions onhow the document must be structured and how the XML tags have to be named. SOAP wasdesigned out of the simple need to provide a standard format for the multiple ways you couldstructure a response with respect to naming your tags and laying out your response tree. SOAPhas been designed to be used out of programs; therefore it is not that easy to test this variant inyour browser, but in Figure 6, we show what a SOAP request might look like.

3528057297logosworldcomlite12345678901234

Tree representation of above XMLAsinSearchRequest

asin 3528057297

tag logosworldcom type lite dev-tag

12345678901234

Figure 6: SOAP Request for Amazon.com

SAP as Web Client

So far, we have seen how a Web service works in principle. The typical client of a Web service,however, is not an individual user, but another program, e.g., a program within SAP R/3. Let'stake a closer look at how Web services function within various SAP releases.

While the WebAS (SAP 4.7 and higher) can act generically as an HTTP client, the older releasesmake use of an SAP-provided utility called SAPHTTP, which is found both in the /bin/exedirectory of the SAP application server (/usr/sap/SID/SYS/bin/exe) and as SAPHTTP.EXE aspart of the SAPGUI installation package. Before you can use SAPHTTP, a valid RFC destination


www.SAPtips.com


9/27


must be defined with transaction SM59 in SAP (Figure 8), pointing to SAPHTTP either on theserver or on the PC that has SAPGUI on. In the latter case, SAPHTTP will be called via theSAPGUI on the workstation.

Using SAPHTTP, you call the following function modules:

function HTTP_GET, and

function HTTP_POST

with the destination of SAPHTTP. See Figure 7 for an example of accessing Web services inSAP, using our Amazon.com book query example.

DATA: ABSOLUTE_URI(128) type c.data: response_headers(80) occurs 0 with header line.data: RESPONSE_ENTITY_BODY(120) occurs 0 with header line.ABSOLUTE_URI ='http://xml.amazon.com/onca/xml2?t=webservices-20' &

'&tag=logosworldcom&dev-t=D2H30000000000' &'&AsinSearch=3528057297&type=lite&f=xml'.CALL FUNCTION 'HTTP_GET'EXPORTINGABSOLUTE_URI = ABSOLUTE_URIRFC_DESTINATION = 'SAPHTTPA'PROXY = '192.168.69.64:8080'TABLES* REQUEST_ENTITY_BODY =RESPONSE_ENTITY_BODY = RESPONSE_ENTITY_BODYRESPONSE_HEADERS = RESPONSE_HEADERS

* REQUEST_HEADERS =EXCEPTIONS

OTHERS = 8.LOOP AT response_entity_body.WRITE: / response_entity_body.

ENDLOOP.

Figure 7: SAP as Web Service Client with ABAP via SAPHTTP Utility


www.SAPtips.com
http://xml.amazon.com/onca/xml2?t=webservices-20%27http://xml.amazon.com/onca/xml2?t=webservices-20%27


10/27


Figure 8: Definition of RFC Destination SAPHTTP in Transaction SM59

Calling a Web Services with the SAP WebAS HTTP Extension Class

WebAS, with its generic HTTP interface, proposes to use the IF_HTTP_CLIENT interface classinstead. Standard SAP WebAS distribution includes the report SXSLT_TEST, whose formLOAD_HTTP gives an example of how to request an HTTP page. In Figure 9 we constructedanother example to demonstrate the essential.

Intermezzo (and key SAP RFC tip):

I recommend continuing to use the traditional method via the RFC destination to SAPHTTPwhenever possible. Not only will it keep your development backward-compatible with older SAPreleases, but the new access method, via the ABAP Object syntax, is still in a state of evolution,and cannot currently satisfy the needs of a modern developer. Unfortunately, ABAP Workbench,


www.SAPtips.com


11/27


the traditional SAP development environment, only has very basic support for ABAP/Objects. Thecore tool of every modern development workbench, the debugger, does not allow the display ofessential information about ABAP/Objects and the current setting of attributes. The ABAP editordoes also not support ABAP/Objects in a convenient way. Editing aids, like Intellisense, whichdisplays methods and attributes for an object while you type, are either completely missing orawkward to use. With respect to the HTTP classes that ship with WebAS, it must be said that alarge part of the coding is realized on the kernel level, which makes it nearly impossible to debugthere. I am aware that a large community of developers, who dedicate their time, ambition, and

professional obsession to object oriented development will heavily object, but from anexperienced software architects and software auditors point of view, this way in which HTTPservices are currently implemented in WebAS cannot be endorsed at this time.

The only advantage of the HTTP classes over the traditional SAPHTTP is the directimplementation of all HTTP features, as opposed to SAPHTTP, which basically does HTTPforwarding to your proxy. But when you take into account that real life implementations of Webclients from SAP will forcibly access the Internet via a proxy anyway, this is not much of an

advantage. Therefore, I decidedly state that, as of this writing, the best practice is to ignorethe HTTP classes of WebAS, while continuing to use SAPHTTP for outbound Internetaccess and BSP for inbound HTTP calls. I will keep an eye on the evolving ABAP/Objectsand HTTP classes of WebAS, and at the point where these new technologies surpass thetraditional SAP HTTP protocols, I will author an update to SAPtips readers. For a detailedlook at the WebAS HTTP client classes, see Figure 9below, which submits a query to

Amazon.com.


www.SAPtips.com


12/27


REPORT ZAXXTEST_CLHTTP. .CLASS cl_ixml DEFINITION LOAD.DATA: response TYPE string.DATA: g_ixml TYPE REF TO if_ixml.DATA: g_stream_factory TYPE REF TO if_ixml_stream_factory.DATA: headfields TYPE tihttpnvp.DATA: client TYPE REF TO if_http_client,

host TYPE string, port TYPE string,proxy_host TYPE string, proxy_port TYPE string,path TYPE string, scheme TYPE i.

During program load we create factory (helper) classes for XML handlingLOAD-OF-PROGRAM.g_ixml = cl_ixml=>create( ).g_stream_factory = g_ixml->create_stream_factory( ).

START-OF-SELECTION.

Setting the parameters needed by the objecthost = 'http://xml.amazon.com'.port = '80'.path ='/onca/xml2?t=webservices-20' &'&tag=logosworldcom&dev-t=D2H30000000000' &'&AsinSearch=3528057297&type=lite&f=xml'.proxy_host = '192.168.69.64'.proxy_port = '8080'.scheme = 1. "1=HTTP 2=HTTPS

* Create HTTP client object

CALL METHOD cl_http_client=>createEXPORTINGhost = hostservice = portproxy_host = proxy_hostproxy_service = proxy_portscheme = scheme

IMPORTINGclient = client.

* Create HTTP client object, send & receiveclient->request->set_header_field( name = '~request_uri'

value = path ).client->request->set_header_field( name = '~request_method'

value = 'GET' ).

* send & receiveclient->send( ).client->receive( ).

* Capture the result dataresponse = client->response->get_cdata( ).


www.SAPtips.com
http://xml.amazon.com%27/http://xml.amazon.com%27/


13/27


* Capture the header fields from the resultCALL METHOD client->response->get_header_fieldsCHANGING

fields = headfields.WRITE: / response COLOR COL_NEGATIVE.

Figure 9: WebAS as HTTP Client

Discovering a Web Service with WSDL and UDDI

While the previous examples are certainly clear enough to understand the idea behind sendingWeb service requests and interpreting the responses, it is not clear how to find out how the SOAPrequests need to be formatted. To do this, we need some sort of documentation. The requireddocumentation for the form of a Web service can in turn be easily represented as a formal XMLdocument.

These formal descriptions of SOAP requests are done in a language called WSDL, the Web

Services Description Language. The WSDL tells you how the tags of the request and responsehave to be named and what tree layout the XML documents will have. The WSDL format forAmazon.com is illustrated in Figure 10.

If your Web service is to be accessed by many foreign sources, the next step is to publish theWSDL in a public directory, just as you publish a telephone number in the yellow pages. One ofthe popular Web service directories is the UDDI (Universal Description, Discovery andIntegration), which is upheld by a consortium mainly driven by IBM. However, like the yellowpages, these directories are of interest only for a certain niche group of clients, as the directoriesdo not indicate anything about the quality of a service. In practice, the use of a Web service is nottypically established on an ad hoc basis. Rather, in advance, you would know exactly what kind ofservice you wanted to use, and you would already know the information you needed to access it,including the WSDL, without having to consult the UDDI.

This key point should not go unmentioned: if you search for WSDL in SAPs Interface Repository(http://ifr.sap.com), you may not find what you expect. SAP has not yet committed itself to anystandards like WSDL. WSDL is mainly driven by IBM and Microsoft and it already has the statusof a recommendation by the W3C (World Wide Web Consortium). Instead of WDSL, SAP hasaffiliated itself with a competing standard called the Web Service Choreography Interface (WSCI),an initiative mainly driven by SUN Microsystems and BEA. There appear to be some politicalissues in play here, because while WSCI may not be worse than WSDL, it isn't better either.Needless to say, competing Web services standards only slow down the corporate acceptance ofWeb services, so we can only hope that the political issues will be set aside in the interests ofuniversal interoperability.


www.SAPtips.com
http://ifr.sap.com/http://ifr.sap.com/


14/27


Figure 10: WSDL-Definition of an Amazon Search by Article Number (ASIN)

Implementing Your Own Web Services

Now that we have seen how we can make use of other peoples Web services, what we really

want to see is how we can implement our own services. Let us explore this by showing how it isdone in Java, WebAS, and Microsoft.NET.

There are basically two different approaches to outline here. In both cases, our goal will be tocreate an XML result page. One option is to create the page by defining a template page thatoutlines the structure of the response document and by generating some code that evaluates theresponse data.

The alternative is to set up a program that is called directly by the URL through an interface shimand returns the resulting data stream. Such a program is known as a servlet. The way thatservlets are called and parameters are passed to them is derived from the old CGI standard,which allowed for the calling of executable programs from a Web server. While the concept ofserver pages, with its predefined templates, is nearly identical for all Web servers, the servletconcept differs in some essential ways, which we'll explore shortly.

Web Services Through a BSP

Let us start by taking the example of a Business Server Page (BSP) from the previous article Iwrote on WebAS, and manipulate it to return an XML document instead of an HTML page. In theprevious article, we defined a BSP that calls the BAPI to return the actual currency exchangerates as they are stored in the SAP system. The result was inserted within HTML tags to displayan HTML table.


www.SAPtips.com


15/27


Well now vary this example by inserting some useful XML tags to represent a proper requestresponse (see Figure 11). The format of the resulting XML document is taken from the templatedefined in the interface repository http://ifr.sap.com. As another variation, we could also enhancethe template from the IFR and easily construct a SOAP document, which differs only in somenamed tags. We'll do this later in this paper.

Figure 11: XML Service Defined Through a BSP


www.SAPtips.com
http://ifr.sap.com/http://ifr.sap.com/


16/27


Passing Parameters to the Web Service

The previous example shown in Figure 11 is missing an important feature, the passing of

parameters to the Web service. While ASP.NET or Java servlets resolve the parametersimmediately into the request object, they are accessed through header variables in WebAS.Because this feature is poorly documented in the current WebAS release, we demonstrate theiruse in Figure 12.


www.SAPtips.com


17/27


get_header_fieldsCHANGING fields = tfields.

**** This one reads the query_string explicitely ********CALL METHOD request->get_header_fieldEXPORTING name = '~query_string'RECEIVING value = querystring.

*********** URI Helper Class *************************************** Initialize the helper class to better deal with query strings URI* need a dummy prefix to make the class work properlyCONCATENATE 'dummy?' querystring INTO querystring.CALL METHOD cl_swlwp_uri=>create_from_stringEXPORTING im_string = querystringIMPORTING ex_uri = query.

*********** Extract a single parameter ****************parm-name = 'ASIN'.CALL METHOD query->get_query_parameterEXPORTING im_name = parm-nameIMPORTING ex_value = parm-value.

**** Here we better call a function module to do our service.* CALL FUNCTION 'Z_AXX_XML_BOOKSTORE'* EXPORTING querystring = querystring* IMPORTING XML = XML.*******************************************************%>

Simulation of AMAZON Web Services through BSPQueryString:
PARAM: Name=Value=RC=


www.SAPtips.com


18/27


Figure 12: Catching the Query String Parameters to Simulate the Amazon Service

In Figure 13 we show the way to simulate the Amazon.com article number search. The examplereturns an XML data stream in the way it is done by Amazon.com. Since there is no bookstoreavailable in the WebAS basic version, we simply echo the received parameters in the resultstring, assuming that this is sufficient guidance to add the necessary code to return the desiredresult data in the resulting XML stream.

Figure 13: Returning the Query String Data as XML Stream in the Amazon Fashion

WebAS Servlets Through HTTP Extensions

The previous WebAS examples returned the both HTML and XML result through a BusinessServer Page. Another way to produce the result string from the WebAS is through the use of theHTTP extensions, which we will call WebAS servlets, as they use an approach similar to the Java

servlets. While Java servlets extend the baseclass javax.servlet.*, the WebAS

extends

3

the ABAP class IF_HTTP_EXTENSION(the prefix IF stands forinterface). Extendingthe class is also known as inheritingthe class. In the case of Web services, the newly developedclass inherits theIF_HTTP_EXTENSIONand overwrites one distinct method:

HANDLE_REQUEST (). The request handler itself can access the HTTP objects through a

3 Extending a class is also known as inheriting a class, depending on which terminology of object

oriented programming is used


www.SAPtips.com
http://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance


19/27


series of helper classes, e.g.,IF_HTTP_RESPONSEand IF_HTTP_REQUEST, which are

inherited via the parent class IF_HTTP_EXTENSION.

As a simple first example, for an HTTP service we shall inspect the predefined classCL_HTTP_EXT_PING, which can be reviewed with the class builder(SE24). The class has

been mapped with transactionSICFto the service namepingservice. Hence, with an up andrunning WebAS, you could call the service by entering a URL like the one below in your browser,wherelinux:8080is the HTTP address of the WebAS.

http://linux:8080/pingservice

Figure 14: Sample URL to Call a Web Service of the WebAS

Request Handling with Method IF_HTTP_EXTENSION~HANDLE_REQUEST

When the HTTP service request is received by the WebAS, it calls themethodHANDLE_REQUEST() of the named class. In our example,pingserviceis the public namethat has been assigned to the implementing class in transaction SICF. The implementing class

should be an extension of the default handler classIF_HTTP_EXTENSION,and it should

implement a method with the fixed nameHANDLE_REQUEST().

The IF_HTTP_EXTENSIONclass implements all important methods and attributes that areneeded for handling the response and request parts of an HTTP communication. See Figure 15.

method IF_HTTP_EXTENSION~HANDLE_REQUEST.data: result type string.server->response->set_header_field(name = 'Content-Type'value = 'text/html' ).

result = ''(001) &'Connection to server successful'(101) &'SystemID: &SYSID&'(102) &'


20/27


server->response->set_header_field

accordingly totext/html and the result data block is set to the response data with method

server->response->set_cdata( data = ) .

In addition to returning the data, we need to set the HTTP header information, which issometimes mandatory and sometimes only useful. Typically, the header would at least provideinformation about the content of the document data that is sent in the document body. In ourcase, we tell the receiver of the document that the body contains HTML data. The valid contentdescriptors are defined by the W3C MIME recommendation.

server->response->set_header_field(name = 'Content-Type'value = 'text/html' ).

As a next step, we build the result string, which actually can be an arbitrary text. As a bestpractice rule, you would insert a call to a function module that returns the final result data string.This is best practice because it reduces the amount of code within an interface handler to a

minimum. Doing so, the request handler is used as a wrapper for the application and as ajumping board to call the actual processing only:

result = ''(001) &'Connection to server successful'(101) &'SystemID: &SYSID&'(102) &'


21/27


Every method will be called exclusively from the matching context, and the response of eachmethod is a string that is returned in the body of HTTP response. Before we can use the servlet,the servlet class must be deployed in the Web servers servlet container. When this issuccessfully done, it can be called via an HTTP Get or HTTP Post request by specifying nothingmore than the class name in the URL. If the class requires parameter information, it can beappended to the URL separated by a question mark (?) to build a canonical URI, which we arealready familiar with. See Figure 16.

public class HelloJSP {

public static void doGet(String[] args) {System.out.println("Hello World from

JSP");}

public static void main(String[] args) {System.out.println("Welcome to Hello World forJSP");}

}

Figure 16: Implementation of Servlet Class HelloWorldExample in Java

SAP XML and SOAP Utilities

SAP also provides for a number of helper classes to allow for easier (I don't dare say easy)creation of the resulting XML documents, e.g., creating a proper SOAP response document. InFigure 17, there is an example that is also found in a similar fashion in the demo section of theWebAS, and is called the info service. The example may look cryptic at the first glance. The key

thing to understand is that themethod soapdoc->add_parameter converts the givenABAP data structure into a SOAP-compliant XML sub tree.


www.SAPtips.com


22/27


method if_http_extension~handle_request.* parameters:* [in] if_http_server& server* Call through browser: http://linux:8080/sap/public/info

data: l_rfcsi type rfcsi.data: soapdoc type ref to CSoapDocument.data: isoapdoc type ref to ISoapSerialize.data: exUsage type ref to CSoapExceptionUsage.data: exResrc type ref to CSoapExceptionResource.data: exIntrn type ref to CSoapExceptionInternal.data: dref type ref to data.data: xdata type xstring.data: data type string.

call function 'RFC_SYSTEM_INFO'

importingrfcsi_export = l_rfcsi.

clear xdata.create object soapdoc.if not soapdoc is initial.try.call method soapdoc->set_methodexporting name = 'RFC_SYSTEM_INFO.Response'

nsprefix = 'rfc'nsvalue = CSoapConstants=>sc_rfc_function_ns.

get reference of l_rfcsi into dref.call method soapdoc->add_parameterexporting name = 'RFCSI'

value = drefdirection = CSoapConstants=>ic_param_in.

isoapdoc = soapdoc.call method isoapdoc->serializechanging document = xdata.

* -- set header fieldcall method server->response->set_header_field(name = 'Content-Type' "#EC NOTEXTvalue = 'text/xml' ).

catch CSoapExceptionUsage into exUsage."-- don't careclear xdata.

catch CSoapExceptionResource into exResrc.

clear xdata.catch CSoapExceptionInternal into exIntrn.clear xdata.

endtry.endif.

if xdata is initial.call method server->response->set_header_field(


www.SAPtips.com
http://linux:8080/sap/public/infohttp://linux:8080/sap/public/info


23/27


name = 'Content-Type' "#EC NOTEXTvalue = 'text/html' ).

* Bild an HTML framework to properly display it in a browser

concatenate '' '' l_rfcsi '' ''into data.

call method server->response->set_cdata( data = data ).else.call method server->response->set_data( data = xdata ).

endif.endmethod.

Figure 17: Producing a SOAP Document Out of a Function Call Result

In my system, the resulting SOAP document looks as follows in Figure 18. If you look closer, youwill find that the SOAP document is nearly identical with the template provided by the SAP

interface repository, but with one small enhancement: the template is embraced by the SOAP-ENV envelope tags.


www.SAPtips.com


24/27


Figure 18: SOAP Document Produced with Aid of the Soapdocadd_parameter Method

Do You Need WebAS or SAP Enterprise for Web Services?

Calling SAP via RFC or via HTTP

From what we have seen so far, it is certainly clear that there is no need to upgrade to WebAS orSAP Enterprise (4.7) for the sole purpose of integrating your SAP system with the Web. If youwant to give your HTTP-based SAP clients real-time access to all the wealth of data inside of

SAP, you can use any modern Web server, and access your SAP ERP system via RFC callsfrom Java or Windows DCOM calls.

Realistically, if you designed a solution that delivered information from your ERP system to anInternet requester, you would not even think of plugging in your Internet connection directly toyour SAP box, for the simple reason of security. Exposing your ERP system directly to theInternet would be like depositing the safe with the Queens crown jewels in the garden ofBuckingham palace.


www.SAPtips.com


25/27


However, there are other arguments for upgrading your SAP ERP system to SAP Enterprise 4.7:

SAP Enterprise will allow you to easily design browser access to SAP for Intranet solutions.

These solutions are becoming more and more popular, because they don't involve deployingSAPGUI on every workstation.

Secondly, having SAP function like any HTTP server, as it does in SAP Enterprise, allows asmoother communication with other internal TCP/IP applications, including your own InternetWeb server.

Smooth HTTP interaction can provoke a nominal return of investment when you have a complexheterogeneous server landscape. Whereas having RFC access means deploying the necessarydrivers on the client computer, calling dedicated libraries, and being dependent on SAP-providedutilities and documentation during development, the use of WebAS allows you to access yourSAP ERP system in the same manner and use the same utilities as you would to access anyother online location or Web server.

Although programming RFC access is relatively easy, and it's available for most common

operating platforms (including Windows, Java on Windows, Linux, and UNIX), deploying an RFCapplication requires that the client computer has the necessary RFC drivers installed.

Installing drivers on a productive machine is always critical. You have to consider:

deployment and registering of the drivers

rebooting the box after installation

allowing for the proper security mechanisms

hat testing your application may interfere with existing applications and even bring themdown.

When you decide to activate HTTP communication with SAP, you will benefit from the already-installed TCP/IP tools that are universally installed on every modern computer from mainframesdown to pervasive palm-top clients. This allows access to SAP from every computer within reachof your network, without any special preparation of the client.

Another benefit of SAP HTTP: your development and deployment team will also avoid endlessdiscussions with the Basis and security administration team. Every proprietary standard used inyour server landscape will likely explode your training and planning costs. What may look like aneasy five-minute task to your development team suddenly turns out to become an elaborateceremony requiring weeks of planning. Once your SAP talks HTTP, it is only up to whoever ishandling the firewall to open or deny the access to your SAP ERP system. This takes thediscussion away from technical complexities and allows for a more strategic focus.

So, based on the strengths of the WebAS and Enterprise 4.7, what is my final assessment interms of the best approach to Web services? My current recommendation, as of this writing, isthat WebAS and Enterprise 4.7 is the ideal platform for SAP Web services, for all the reasons I've

outlined in this paper. But, keep in mind, that specifically when submitting a SOAP request to theSAP system, I recommend continuing to use SAP HTTP and RFC, not the HTTP classes ofWebAS, until the HTTP classes and ABAP/Objects technologies mature. Even if you're runningon WebAS, you can still continue to use SAP HTTP and traditional RFC methods. And, best ofall, you do not need to be running WebAS or 4.7 to start using Web services in your applicationenvironment.


www.SAPtips.com


26/27


SAP As the Universal Development Platform

It is already pretty obvious that SAP, with the addition of HTTP service to its kernel, has matured

into one of the leading competitors in the enterprise application server market. From now on, wewill have to clearly distinguish between the SAP ERP suitewhich is a class of its own anywayand the SAP kernel technology, currently marketed as the NetWeaver WebAS.

Thanks to the strong transaction management, the database integration, the fully integrateddevelopment workbench, and sophisticated change and deployment management, SAP WebAShas already become a serious contender to the established virtual machine frameworks forenterprise application servers. In the next white paper, I shall assess the strengths andweaknesses of the three major development and runtime environments, namely WebSphereJ2EE, Microsoft.NET, and SAP WebAS, and explain why the Clash of the Frameworks willend in favor of the newcomer SAP WebAS and ABAPat least for SAP users.


www.SAPtips.com


27/27

Copyright 2003 by Klee Associates Inc Page 27


Axel Angeli is a senior SAP and EAI advisor and principal of logosworld.com, a German-

based enterprise specializing in coaching SAP and EAI project teams and advising ITmanagement on implementation issues. Axel has been in the IT business since 1984, andthroughout his career, he has always worked with cutting edge technologies. Axel's SAPexperience stems back from the good old R/2 days and he is an expert on SAPs NetWeavertechnology and any kind of ABAP development. A speaker of several languages, Axelspecializes in coaching and leading large multi-national teams on complex projects withheterogeneous platforms and international rollouts. Known for his intensive and successfultrouble-shooting experience, Axel has been nicknamed by his colleagues as the Red Adairof SAP projects. He is the author of the best-selling tutorial The SAP R/3 Guide to EDI, IDocs,

ALE and Interfaces.

The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned byKlee Associates, Inc.

NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracyor use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensureaccuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc.reserves the right to make changes without prior notice.

NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AGsoftware referenced on this site is furnished under license agreements between SAP AG and its customers and can beused only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG.

All other company and product names used herein may be trademarks or registered trademarks of their respectiveowners.

Documents

Web App Services Part 2 EMconvt