In der Regel kommt der Betrieb der SAP Applikationsserver und der Netzwerk-/Firewall-Infrastruktur nicht aus einer Hand. Das kann die Ursachenanalyse für ein Problem erschweren. Gut wenn man als SAP Basis Mitarbeiter ein paar Werkzeuge kennt, um Applikationsprobleme von gestörten oder abgeschotteten Netzwerkverbindungen abgrenzen zu können.

Telnet

Hinweis: Bei neueren Windows-Installationen muss man den Telnet-Client erst nachinstallieren. Unter Linux/Unix ist es im Standardumfang enthalten.

Aufruf:

telnet hostname port

Beispiel:

telnet meinsaprouter.company.com 3299
Wird die Console schwarz und ein Cursor blinkt links oben dann ist die Verbindung erfolgreich hergestellt worden. Die Verbindung beenden kann man mit “CTRL++” und der Eingabe quit.

Blockiert eine Firewall die Verbindung, dann dauert es eine Weile bis schließlich ein Timeout gemeldet wird.

Wird die Verbindung aufgebaut, aber gleich darauf getrennt, ist die Wahrscheinlichkeit hoch, dass es ein saprouter/Dienst-Problem ist.

Niping

Mit niping kann man die Verbindung zu einem Dispatcher oder Gateway testen, inklusive der SAP Router dazwischen. Dies ist ein deutlicher Vorteil gegenüber den direkten Tools wie telnet und netcat.
Tipp: Über den Report RSBDCOS0 kann man das Programm direkt auf dem Applikationsserver ohne Betriebssystemzugriff laufen lassen.
Aufruf:

niping -c -H HOSTNAME oder SAPROUTERSTRING -S PORT

1. Beispiel:

[1]niping -c -H /H/meinsaprouter.company.com -S sapdp99

[1]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99

Sun Aug 21 18:22:07 2011

***LOG Q0I=> NiPConnect2: meinsaprouter.company.com:3299: connect (10061: WSAECONNREFUSED: Connection refused) [nixxi.cpp 3133]

*** ERROR => NiPConnect2: SiPeekPendConn failed for hdl 1/sock 268

(SI_ECONN_REFUSE/10061; I4; ST; meinsaprouter.company.com:3299) [nixxi.cpp 3133]

*** ERROR => NiTClientLoop: NiHandle (rc=-10) [nixxtst.cpp 2529]

2. Beispiel:

[2]niping -c -H /H/meinsaprouter.company.com -S sapdp99

[2]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99

Sun Aug 21 18:25:01 2011

connect to server o.k.

*** ERROR => NiBufIProcMsg: hdl 1 received rc=-93 (NIEROUT_INTERN) from peer [nibuf.cpp 2115]

*** ERROR => NiTClientLoop: NiTReadLoop (rc=-93) [nixxtst.cpp 2529]

Bei dem ersten Beispiel war der SAP Router Dienst nicht gestartet, beim zweiten Beispiel war der Zugriff erfolgreich. Die “*** ERROR” Nachrichten kann man vernachlässigen.

Netcat

Für andere Netzwerkdienste (z.B. Test ob der Mailserver-Port offen ist) kann man neben telnet auch netcat sehr gut einsetzen. Allerdings ist das Programm nur in der Unix/Linux-Welt im Standardumfang verfügbar.
Aufruf:

netcat -w5 -z -v HOSTNAME PORT

-w 5 sekunden warten

-z port scanning only

-v verbose
Beispiel:

[6]netcat -w5 -z -v mail.company.com 25 2>/tmp/test_mailtest.txt

[7]cat /tmp/test_mailtest.txt

mail.company.com [10.0.0.1] 25 (smtp) open
Durch die Parameter im Beispiel läuft netcat nicht-interaktiv und ist damit auch wieder für den SAP Report RSBDCOS0 geeignet.

Gerade im SAP-Umfeld ist es interessant, im produktiven System verfügbare Informationen auch anderen Nicht-SAP-Systemen zugänglich machen zu können. Webservices sind ein effektives Mittel um Systeme ohne große Umwege direkt miteinander kommunizieren zu lassen. Mit SAP NetWeaver 7.0 SP14 steht nun auch die Transaktion SOAMANAGER zur Verfügung, die den Umgang mit Webservices deutlich einfacher macht. Dieses Howto beschreibt anhand eines einfachen Beispiels die Vorgehensweise, um mit ABAP und dem SOAMANAGER einen SAP Webservice zur Verfügung zu stellen.

Überblick

1. Voraussetzungen
2. Einen Funktionsbaustein und Webservice im ABAP anlegen
3. Den Webservice mit soapUI nutzen

Voraussetzungen:

• Eine funktionierende Transaktion SOAMANAGER (ab SAP NetWeaver 7.0 SP14)
• Entwicklerzugriff und ABAP Kenntnisse , Transaktion SE80
• Einen technischen User für den eingeschränkten Zugriff (Benutzertyp Kommunikation)
• Einen Konsumenten, das heißt einen Webservice-Nutzer (zum Testen ist das Webservices-Test-Tool soapUI gut geeignet)

Einen Funktionsbaustein und Webservice im ABAP anlegen

Reihenfolge für das Anlegen eines Webservice im Überblick:

1. RFC-fähigen Funktionsbaustein anlegen
2. Input/Export-Parameter definieren
3. Das Programm
4. Webservice anlegen
5. Service im SOAMANAGER browsen und WSDL-Link speichern

• RFC-fähigen Funktionsbaustein anlegen
  

  Unser Beispiel wird ein Webservice sein, dem zwei Zahlen übergeben werden und der daraufhin die Summe der beiden Zahlen zurück gibt.
  Dafür in der Transaktion SE80 einen Funktionsbaustein anlegen und dabei in den Eigenschaften “Remote fähiger Baustein” anwählen.
  
  

• Input/Export-Parameter definieren
  

  Die Parameter definieren den Webservice, die Verwendung von Tabellen und Changing sind hier nicht vorgesehen.

  Die Import-Parameter bestimmen die Werte, die an den Webservice übergeben werden. In dem Bespiel die beiden Zahlen, die von unserem Programm addiert werden sollen. Die Parameter sollten Optional sein, damit man später das WSDL-Dokument (siehe unten) abrufen kann und als Wert übergeben werden.

  
  

  Der Export-Parameter definiert die Rückgabe.

  
  

  Diese Parameter müssen unbedingt vorher festgelegt werden und sollten sich später auch nicht mehr ändern, da ansonsten sich die ganze Webservice-Definition ändert und somit für Konsumenten nicht mehr nutzbar ist.

• Das Programm
  

  
  

  Das Programm sichern und aktivieren.

• Webservice anlegen
  

  Über einen Rechts-klick auf den Funktionsbaustein kann man einen Web Service Wizard starten.

  
  
  
  
  
  

  
  

  
  

  
  

  Der Webservice ZTH_WS_TESTING ist damit definiert und einsatzbereit.

• Service im SOAMANAGER browsen und WSDL-Link speichern
  

  Bevor der Webservice durch andere Systeme genutzt werden kann, benötigen diese eine Beschreibung, wie und mit welchem Parametern der Webservice funktioniert. Diese Definition steckt in einem WSDL-Dokument und wird zum Konsumieren des Webservices im ABAP und anderen externen System benötigt. Die Transaktion SOAMANAGER öffnet einen Browser für den Zugriff auf das SOA-Management und bietet die Möglichkeit eine Download-URL für das WSDL-Dokument zu ermitteln.

  
  
  Zunächst muss der neue Service selektiert werden.

  
  

  Der markierte Link öffnet das WSDL-Dokument. Hinweis: Das Browserfenster wird unter Umständen im Hintergrund geöffnet.

  
  

  Die URL aus der Adressleiste speichern.

Den Webservice mit soapUI nutzen

Das Webservice Testing Tool soapUI ist als OpenSource-Tool unter http://www.soapui.org/ verfügbar und bietet die Möglichkeit schnell einfacher Webservice Funktionstests durchzuführen. Ideal also, um unseren eben angelegten Webservice zu testen.

“New soapUI Project” auswählen und in dem Dialog die vorher gespeicherten WSDL-URL einfügen.

Technischen User angeben.

Es sollen die Zahlen 200 und 400 addiert werden. Wichtig ist etwaige Kommentare wie z.B. <!–OPTIONAL–> zu entfernen. Diese können beim Aufruf des Webservices Probleme bereiten.

Über den Button “Auth” am unteren Rand müssen die Benutzerdaten für den Aufruf hinterlegt werden.

Auf “Submit Request” links oben gehen. Die Antwort des Webservices (die Summe der beiden Zahlen) erscheint danach auf der rechten Seite. Damit ist der Webservice erfolgreich getestet!