Der folgende ABAP-Code stellt ein vereinfachtes Beispiel dar, es handelt sich nicht um eine Vorlage für die professionelle Anwendung.
Das folgende ABAP-Programm führt einen HTTP-Request aus. Zu Testzwecken richtet sich der Aufruf an das sendende System selbst, d.h. der Application Server ABAP wird sowohl in der Client- als auch in der Serverrolle verwendet:
report HTTP_Test. * data declarations data: client type ref to if_http_client. … |
Folgende Parameter müssen eingegeben werden:
Wird nichts angegeben, werden Defaultwerte verwendet: Host (Defaultwert: der aktuelle Host), Service (Defaultwert: Port 80 für HTTP und 443 für HTTPS), Protokoll (Default HTTP/1.0), Pfad zu dem gewünschten Service, wie in Abschnitt Implementierung beschrieben (Default /sap/public/ping).
Wird bei der Erzeugung des Client-Objekts die Verbindung über die Destination (SM59) benutzt, müssen diese Parameter in der Destination gepflegt werden.
data: host type string value = ‘host.wdf.sap-ag.de’, service type string value = ‘8080’, path type string value = '/sap/public/ping', errortext type string. "used for error handling |
Nun wird das Objekt vom Typ CL_HTTP_CLIENT erzeugt. Hierzu gibt es 2 mögliche Vorgehensweisen:
● Im einen Fall wird die create-Methode aufgerufen; hier müssen gewünschter Host und Port angegeben werden, des weiteren kann die Proxy-Einstellung festgelegt werden. Diese übersteuert eine eventuell in der Transaktion SICF vorgenommene Konfiguration (vgl. Proxy konfigurieren).
● Im anderen Fall wird eine in der Transaktion SM59 gepflegte Destination verwendet (Methode create_by_destination). Hier müssen nur der Name der Destination sowie der Mandant angegeben werden. In beiden Fällen müssen Exceptions definiert werden (hier nicht gezeigt) und der letzte Fehlercode abgefragt werden.
SAP empfiehlt die Verwendung einer festen Destination, da sich hierdurch der Aufwand für Konfiguration der Kommunikationsparameter verringert.
Anschließend kann über das Objekt Client auf alle Daten (Request, Response, Header-Felder, etc) zugegriffen werden.
Das Scheme bestimmt, ob HTTP oder HTTPS verwendet wird.
* create HTTP client object(s) |
|
call method cl_http_client=>create exporting host = host_str service = service_str proxy_host = proxy_host proxy_service = proxy_service scheme = scheme importing client = client exceptions argument_not_found = 1 internal_error = 2 plugin_not_active = 3 others = 4. |
call method cl_http_client=>create_by_destination exporting destination = dest importing client = client exceptions destination_not_found = 1 internal_error = 2 argument_not_found = 3 destination_no_authority = 4 plugin_not_active = 5 others = 6. |
if sy-subrc <>0. write: / ‘Create failed, subrc = ', sy-subrc. exit. endif. |
Danach werden Header-Felder des Requests gesetzt. Das Setzen der HTTP-Request-Methode auf GET ist optional.
Wird dieses Feld nicht gesetzt, nimmt das System GET für den Fall, dass der HTTP-Request keinen Body enthält, ansonsten POST.
Das Setzen des Request-URI ist erforderlich, es sei denn, es wurde über die Destination (SM59) der gesamte Pfad als Pfad-Präfix angegeben. Hierzu verwenden Sie die Methode set_request_uri der Klasse cl_http_utility:
* set http method GET call method client->request->set_method( if_http_request=>co_request_method_get ). * set protocol version if protocol = 'HTTP/1.0'. client->request->set_version( if_http_request=>co_protocol_version_1_0 ). else. client->request->set_version( if_http_request=>co_protocol_version_1_1 ). endif. * set request uri (/<path>[?<querystring>]) cl_http_utility=>set_request_uri( request = client->request uri = uri ). |
Im Anschluss können beliebige Felder des Client-Kontrollblocks gefüllt werden.
Weitere Optionen
● Sie können die Attribute PROPERTYTYPE_LOGON_POPUP, PROPERTYTYPE_REDIRECT und PROPERTYTYPE_ACCEPT_COMPRESS die im Default den Wert CO_ENABLED haben, deaktivieren (auf CO_DISABLED setzen).
● Sie können PROPERTYTYPE_ACCEPT_COOKIE auf andere Werte setzen. Der Defaultwert ist CO_DISABLED, es stehen aber auch die Werte CO_ENABLED(Cookies immer akzeptieren), CO_PROMPT (beim Empfang des Cookies ein Popup senden, ob das Cookie akzeptiert werden soll) sowie CO_EVENT (Cookiebehandlung über das Ereignis EVENTKIND_HANDLE_COOKIE des Interfaces IF_HTTP_CLIENT) zur Verfügung.
● Sie können PROPERTYTYPE_ACCEPT_COMPRESS auf den Wert CO_DISABLED setzen, damit der Partner seine Daten unkomprimiert sendet.
● Es besteht auch die Möglichkeit, vor dem Senden des Requests die notwendigen Anmeldedaten durch Verwendung der AUTHENTICATE()-Methode des Interfaces IF_HTTP_CLIENT einzugeben.
Nun wird der Request versendet:
* Send call method client->send exporting timeout = timeout exceptions http_communication_failure = 1 http_invalid_state = 2 http_processing_failed = 3 others = 4. if sy-subrc <> 0. call method client->get_last_error importing code = subrc message = errortext. write: / 'communication_error( send )', / 'code: ', subrc, 'message: ', dummy. exit. endif. |
Hier muss wieder mit client->get_last_error der letzte Fehler abgefragt werden.
Nun wird die Antwort empfangen, die Responsedaten in das Client-Objekt gefüllt.
* receive call method client->receive exceptions http_communication_failure = 1 http_invalid_state = 2 http_processing_failed = 3 others = 4. if sy-subrc <> 0. call method client->get_last_error importing code = subrc message = errortext. write: / 'communication_error( receive )', / 'code: ', subrc, 'message: ', dummy. exit. endif. |
Auch hier müssen wieder Exceptions und Fehlerabfragen eingefügt werden.
Wenn die Verbindung nicht mehr verwendet wird, muss sowohl das Client-Objekt als auch die Verbindung abgebaut werden:
* close call method client->close exceptions http_invalid_state = 1 others = 2. |
Um den erfolgreichen Test zu dokumentieren, wird nun die Ausgaberoutine aufgerufen.
* output perform write_document. |