Hier finden Sie allgemeingültige, technische Tipps zur Verwendung der Webservice-API von Speed4Trade CONNECT. Die Liste ist dynamisch und wird sukzessive erweitert.

Maximale Größe eines Requests

Ihre Requests sollten in der Regel 2 MB Datengröße nicht überschreiten. Dies kann beispielsweise dann der Fall sein, wenn Bilder als Base64-kodierte Zeichenketten oder wenn sehr viele Kompatibilitäten zu einem Artikel übertragen werden. Ein größerer Grenzwert kann durch den Speed4Trade Support bei Bedarf in Einzelfällen konfiguriert werden, was aber zu Performance Problemen führen kann und nicht empfohlen wird. Der bessere Weg ist, die Daten auf mehrere Requests zu verteilen.

Ein Tipp zur kurzfristigen Reduktion der Größe eines Requests: Verzichten Sie auf sogenannte "pretty-print" Formatierungen. Entfernen Sie vor der Übergabe Einrückungen, unnötige Leerzeilen und Ähnliches. Dadurch können bei XML-Dateien schnell 30-40% der Größe eingespart werden.

Performanceprobleme durch Timeouts

Sollen viele Daten übertragen werden und wurde die maximale Größe des Requests bereits erreicht, dann können die Daten in mehrere, kleinere Requests aufgeteilt werden. Die Abarbeitung der Requests kann unterschiedlich lange dauern, je nachdem, wie viele Informationen zu den einzelnen Datensätzen enthalten sind. Dabei kann es vorkommen, dass auf der Seite des aufrufenden Partners Timeouts auftreten, wenn die Speed4Trade-CONNECT-API nicht rechtzeitig antwortet. Diese Timeouts sind keine Einstellung auf Seiten von Speed4Trade CONNECT, sondern der Aufrufende legt selbst in seiner Software fest, wie lange gewartet wird. D.h. Sie müssen diesen Wert bei sich einstellen. (Ausnahmen: UpdateItems, UpdateStockCount und UpdatePrices haben jeweils einen konfigurierbaren Process-Timeout.)

In der Regel ist es sogar so, dass die Speed4Trade-CONNECT-API im Hintergrund den Request komplett abarbeitet, aber die Response aufgrund des Timeouts beim Aufrufenden nicht mehr ankommt, weil dessen Prozess nicht so lange gewartet hat. Im schlechtesten Fall wird sogar der gleiche Request nochmal geschickt in der Hoffnung, dass die Verarbeitung dieses Mal eine Antwort in der eingestellten Zeit zurückgibt. Dadurch werden die gleichen Datensätze allerdings nochmal aktualisiert und verarbeitet, obwohl das nicht sein müsste.

Gegen dieses Verhalten der beteiligten Programme gibt es immer die gleichen Lösungsansätze:

•Wartezeit bis zum Timeout beim Aufrufer der Speed4Trade-CONNECT-API verlängern oder

•Requests kleiner machen, um die Datensätze innerhalb des Zeitfensters zu verarbeiten und eine Response zu erhalten oder

•Schnellere Hardware und/oder einen größerer Speicher für Speed4Trade CONNECT zur Verfügung stellen.

Wie lange die Wartezeit bis zum Timeout eingestellt werden soll, kann nicht allgemein beantwortet werden, da diese Information stark von der anzusprechenden Schnittstelle und den zu übertragenden Daten abhängt. So kann es auch sein, dass es für unterschiedliche Requests unterschiedliche Timeouteinstellungen bedarf, ob die maximale Performance aus der Schnittstelle herauszuholen.

Sicherheit

Wir sind aus gesetzlichen Gründen verpflichtet, unsere Software aktuell zu halten und Sicherheitslücken zu schließen (IT-Sicherheitsgesetz). Dies tun wir regelmäßig. Dazu gehören nicht nur Speed4Trade CONNECT selbst, sondern auch die darunter liegende Systemsoftware, wie z.B. der Windows Server oder Java. Diese Komponenten stellen den Support bspw. für ältere, nicht mehr sichere Verbindungsverfahren ein.  Wir möchten unsere Partner darauf hinweisen, dass es auf beiden Seiten zur Pflicht führt, die Umgebung und Softwarebestandteile zu warten und aktuell zu halten und unsichere Verfahren gegen sichere in der eigenen Software / Schnittstelle auszutauschen.

Hinweis-Meldung im Vorfeld von geplanten Updates und Systemneustarts von Speed4Trade CONNECT

Ist eine Aktualisierung von Speed4Trade CONNECT geplant oder über die Oberfläche angestoßen, dann werden frühestens fünf Minuten vor der Beendigung des Dienstes keine neuen Webserviceanfragen mehr angenommen. Requests, die innerhalb dieser Zeit an die Speed4Trade-CONNECT-API gesendet werden, erhalten unten stehende Response zurück. Sobald das Update oder der Systemneustart durchgeführt ist und Speed4Trade CONNECT danach wieder läuft, können Webserviceanfragen normal verarbeitet werden.

Empfehlungen für das Verhalten von angebundenen Systemen bei der Nichtereichbarkeit der Speed4Trade-CONNECT-API

Damit die Daten zwischen ERP-System und Speed4Trade CONNECT synchron gehalten werden, empfehlen wir folgende Vorgehensweisen:

1) Um der Dynamik im Online-Umfeld sowie der angeschlossenen Marktplätze gerecht zu werden und um Funktionserweiterungen schnell nutzen zu können, stehen für Speed4Trade CONNECT wöchentlich neue Versionen zur Verfügung. Wenn möglich sollte ein Zeitfenster für Updates von Speed4Trade CONNECT geschaffen werden, in welchem keine API-Zugriffe per SOAP erfolgen. Das Zeitfenster sollte ca. 15 Minuten groß sein, um ausreichend Zeit bereitzustellen, falls bei den Updates von Speed4Trade CONNECT Datenmigrationen notwendig sind. Die Updates sollten so geplant werden, dass sie in diesem Zeitfenster durchgeführt werden. Dazu ist eine Abstimmung mit dem Kunden notwendig.

2) Nichtereichbarkeit der Speed4Trade-CONNECT-API während lesender Zugriffe:

a) Hintergrundprozesse im ERP-System:

Sollte aufgrund einer Downtime oder einer Störung Speed4Trade CONNECT nicht erreichbar sein während ein lesender Zugriffsversuch durch Hintergrundjobs stattfindet (z.B. Abholung von neuen Aufträgen), sind diese Zugriffe nach einer Wartezeit zu wiederholen. Es wird eine Wartezeit von ca. 15 Minuten empfohlen. Lesende Jobs sollten so gestaltet werden, dass sie ansatzlos fortfahren können.

b) Frontend-Interaktion im angebundenen ERP-System:

Bei User-Interaktionen, die eine direkte Verbindung zu Speed4Trade CONNECT haben, sollte eine Meldung angezeigt werden, dass die angeforderten Informationen aktuell nicht verfügbar sind. Hier ist keine automatische Wiederholung nach einer Wartezeit notwendig.

3) Downtime der Speed4Trade-CONNECT-API während schreibender Zugriffe:

a) Hintergrundprozesse im ERP-System:

Kann ein schreibender Zugriff während eines Hintergrund-Prozesses (z.B. UpdateItems) nicht durchgeführt werden, so sollten diese Requests zu einem späteren Zeitpunkt wiederholt werden. Es wird auch hier eine Wartezeit von ca. 15 Minuten empfohlen. Falls die Wiederholungen mehrmals direkt hintereinander fehlschlagen, sollte dies protokolliert und die Störung zur manuellen Lösungsfindung weitergeleitet werden, z.B. Meldung an einen Systembetreuer.

b) Frontend-Interaktion im angebundenen ERP-System:

Erfolgt der schreibende Zugriff aufgrund einer Nutzer-Interaktion, so ist das sendende System verantwortlich einen konsistenten Zustand der Daten aufrecht zu erhalten und ggf. dem User eine Handlungsempfehlung anzuzeigen. Die Konsistenz kann alternativ durch Wiederholung des Requests zu einem späteren Zeitpunkt wiederhergestellt werden wobei hier ein Verfahren implementiert werden muss, welches zu häufige Wiederholungsversuche verhindert und in diesem Fall eine Meldung zur Nachbearbeitung an den Systembetreuer weiterleitet.

Die genannten Punkte haben keinen Anspruch auf Vollständigkeit es kann sein, dass spezielle Use-Cases nicht durch dieses Schema abgedeckt sind, aber sie sind eine Empfehlung die Schnittstelle stabiler und ausfallsicherer zu machen.

Generell sollten Schnittstellen so konzipiert werden, dass sich Fehler nicht fortpflanzen, sondern mit der Zeit wieder verschwinden (eventual consistency). Beispielsweise können Bestandsänderungen täglich mehrmals als Delta-Update übergeben und einmal wöchentlich mit einem Vollimport synchronisiert werden.