OXID ERP Modul – Zugriff per SOAP, Hürden und Tipps

OXID stellt für die PE- und EE-Versionen mit dem ERP-Interface seit vielen Jahren bereits eine (allerdings kostenpflichtige) Möglichkeit bereit, Drittsysteme über SOAP mit dem Shop zu verbinden. Da es dennoch nicht allzu viele Tutorials und Updates zu dem Thema gibt und wir bei einem aktuellen Projekt über einige Steine gestolpert sind, finden sich im folgenden einige Tipps und Tricks zur Anbindung.

Installation und einzelne Funktionen werden im mitgelieferten README erläutert. Was jedoch fehlt, sind Beispiel-Aufrufe, um die Schnittstelle z.B. mit „SoapUI“ oder „Postman“ und direkten SOAP-Requests zu testen – daher hier ein Beispiel für ein Login per SOAP.

Hilfreich ist es immer, sich zuerst die WSDL anzusehen, dies geht über die URL (hier kann man die gewünschte Schnittstellen-Version angeben). Eine einfache Liste aller vorhandenen Funktionen erhält man mit

Ein SOAP Login-Request muss seit Version 2.7 des Moduls so aussehen:

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:oxer=“https://www.mein-shop.de/modules/erp/OXERPService“>
<soapenv:Header/>
<soapenv:Body>
<oxer:OXERPLogin>
<oxer:sUserName>admin</oxer:sUserName>
<oxer:sPassword>admin</oxer:sPassword>
<oxer:iShopID>1</oxer:iShopID>
<oxer:iLanguage>0</oxer:iLanguage>
</oxer:OXERPLogin>
</soapenv:Body>
</soapenv:Envelope>

Hier haben wir schon den ersten großen Stolperstein – der XML Namespace in „xmlns:oxer“. Dieser lautete bei Modul-Versionen vor 2.7. noch „OXERPService“, seitdem muss standardmässig die Shop-URL vorne ergänzt werden, ansonsten bekommt man einen Error 500 mit der Meldung: „Procedure ‚OXERPLogin‘ not present“. Leider findet man diesen Hinweis nur im CHANGELOG des Moduls, nicht im README dazu.

In Postman kann man diesen Request so definieren (URL angeben, dann „raw“ und „XML“ auswählen):

Postman OXID ERP/SOAP

Will man den „alten“ Namespace (ohne URL) beibehalten, weil man z.B. noch einen vorhandenen SOAP-Client auf ERP-Seite hat oder weil sich die URL je nach System ja auch ändern kann, kann man dies über eine Variable in der „config.inc.php“ des Shops bewerkstelligen:

Mit

$this->erpTargetNamespace=’OXERPService‘

in der config.inc.php stellt man den alten Namespace wieder her. Hier lauern aber noch zwei kleinere Stolpersteine 🙂

Erstens – der PHP WSDL-Cache. Sofern nicht anders konfiguriert, liegt dieser einfach im „/tmp“-Verzeichis des Servers, hier liegen dann diverse „wsdl-…“-Dateien. Diese müssen gelöscht werden, wenn man die Einstellung geändert hat. Über die „php.ini“-Datei kann der Pfad zum Cache-Verzeichnis auch angepasst werden. Zu Testzwecken kann man WSDL-Caching dort auch komplett deaktivieren („soap.wsdl_cache_enabled=0“), das sollte man aber aus Performancegründen auf keinen Fall auf dem Produktivsystem oder dauerhaft machen.

Zweitens – der OXID „WSDL-Cache“. OXID generiert ebenfalls temporäre WSDL-Dateien für alle angeforderten Versionen und speichert diese im „export/“-Verzeichnis des Shops („generated_oxerpservice_*“). Auch diese müssen gelöscht werden, damit die Änderung des Namespace greift!

Ruft man nun die WSDL über obige URL erneut ab, sollte auch hier der verkürzte Namespace angezeigt werden:

OXID Namespace short

Nun sollte unser Login-Aufruf mit dem alten Namespace funktionieren und wir können die Shop-URL weglassen:

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:oxer=“OXERPService“>
<soapenv:Header/>
<soapenv:Body>
<oxer:OXERPLogin>
<oxer:sUserName>admin</oxer:sUserName>
<oxer:sPassword>admin</oxer:sPassword>
<oxer:iShopID>1</oxer:iShopID>
<oxer:iLanguage>0</oxer:iLanguage>
</oxer:OXERPLogin>
</soapenv:Body>
</soapenv:Envelope>

Die Login-Prozedur liefert übrigens eine Session-ID zurück, die dann für folgende Aufrufe verwendet werden kann:

<?xml version=“1.0″ encoding=“UTF-8″?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:ns1=“OXERPService“>
<SOAP-ENV:Body>
<ns1:OXERPLoginResponse>
<ns1:OXERPLoginResult>
<ns1:blResult>true</ns1:blResult>
<ns1:sMessage>38ji8462v1amovjtvg1sk37reh</ns1:sMessage>
</ns1:OXERPLoginResult>
</ns1:OXERPLoginResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Hier z.B. ein Aufruf, um mit der erhaltenen Session-ID eine Bestellung zu einer sOrderID erhalten:
<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/“ xmlns:oxer=“OXERPService“>
<soapenv:Header/>
<soapenv:Body>
<oxer:OXERPGetOrder>
<oxer:sSessionID>38ji8462v1amovjtvg1sk37reh</oxer:sSessionID>
<oxer:sOrderID>fancyOrderId</oxer:sOrderID>
</oxer:OXERPGetOrder>
</soapenv:Body>
</soapenv:Envelope>

Klappt die Kommunikation an sich, ist es evtl. hilfreich, sich Logausgaben der Schnittstelle ausgeben zu lassen, auch dies ist über „config.inc.php“ einstellbar:

$this->blErpLogging = true;
$this->sErpLogFile = __DIR__ . „/log/erp.log“;

Zum Abschluss noch einige hilfreiche Links zum Thema:

Der Beitrag OXID ERP Modul – Zugriff per SOAP, Hürden und Tipps erschien zuerst auf ProudCommerce.



Start the discussion at OXID forums