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 https://www.mein-shop.de/modules/erp/oxerpservice.php?wsdl&version=2.15.0 (hier kann man die gewünschte Schnittstellen-Version angeben). Eine einfache Liste aller vorhandenen Funktionen erhält man mit https://www.mein-shop.de/modules/erp/oxerpservice.php?functions&version=2.15.0

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 bzw. der Dokumentation dazu. Ausserdem ist man im ersten Moment natürlich ziemlich ratlos bezüglich der Ursache des Fehlers.

In Postman kann man diesen Request so definieren (POST-URL angeben, dann „raw“ und „XML“ auswählen und obiges XML einfügen und anpassen):

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 im „/tmp“-Verzeichis des Servers, hier finden sich 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 nun auch hier der verkürzte Namespace (ohne Shop-URL) angezeigt werden:

Nun sollte unser Login-Aufruf mit dem „alten“, kurzen Namespace funktionieren und wir können die Shop-URL im Namespace 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 nachfolgende 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:

Das könnte Dich auch interessieren