Subiekt GT mit einer Webanwendung verbinden: Was sollten Sie vorab klären?
Wenn Ihr Team Bestellungen aus einer Webanwendung manuell in Subiekt GT übertragen muss, klären Sie zuerst, welche Daten zwischen den Systemen ausgetauscht werden sollen, wer sie ändern darf und woran Mitarbeitende erkennen, dass ein Vorgang erfolgreich abgeschlossen wurde. Auf dieser Grundlage können Sie eine fertige Schnittstellenlösung auswählen oder den Aufwand für eine individuelle Anbindung schätzen lassen. Dass eine Bestellung übertragen wurde, bedeutet noch nicht, dass der richtige Beleg angelegt ist und die Bearbeitung beginnen kann.
Vor der Umsetzung brauchen Sie auch Regeln für Verbindungsunterbrechungen. Ein Shop oder Portal kann weiterhin Bestellungen annehmen, während die für Subiekt zuständige Komponente nicht erreichbar ist. Dafür muss feststehen, wo ausstehende Vorgänge gespeichert werden und wie das Team Verzögerungen erkennt. Diese Entscheidungen betreffen auch die Organisation Ihres Vertriebs.
Hat Subiekt GT eine API für Webanwendungen?
InsERT bietet Sfera für Subiekt GT an. Mit diesem Zusatz lassen sich Erweiterungen entwickeln, die Funktionen des Programms nutzen, etwa zur Verarbeitung von Bestellungen aus einem Onlineshop. Sfera ermöglicht den Zugriff auf Subiekt-Funktionen, ist aber kein fertiger Webdienst, an den eine Webanwendung einfach eine Anfrage aus dem Browser senden kann.
Die technische Dokumentation von InsERT nennt COM und OLE Automation. Diese Mechanismen ermöglichen es einem anderen Programm, Funktionen von Subiekt aufzurufen. Für die Anbindung einer Webanwendung benötigen Sie deshalb eine Komponente, die mit Sfera arbeitet, und einen Kommunikationsweg zu dieser Komponente. Die Web-API kann eine fertige Schnittstellenlösung oder individuell entwickelte Software bereitstellen. Aus dem Angebot sollte klar hervorgehen, wer diese Komponente liefert und für ihre Aktualisierung verantwortlich ist.
Für Subiekt GT Sfera gelten Systemanforderungen an Windows und Microsoft SQL Server. Die Webanwendung kann in einer anderen Umgebung laufen. Der Betrieb der mit Subiekt verbundenen Komponente muss dennoch eingeplant werden. Klären Sie, auf welchem Rechner oder Server sie läuft, wann sie verfügbar sein muss und wer sie nach einem Ausfall wieder in Betrieb nimmt.
Welche Daten werden gemeinsam genutzt, und welches System darf sie ändern?
Beschreiben Sie einen vollständigen Bestellablauf, statt pauschal „alles synchronisieren“ zu lassen. Wo entsteht die Bestellung, wann wird sie bestätigt, welcher Beleg soll in Subiekt erscheinen und welche Information geht an die Anwendung zurück? Legen Sie gesondert fest, was bei Mengenänderungen, Stornierungen und Retouren geschieht. Mit der Übertragung einer neuen Bestellung ist deren weitere Bearbeitung noch nicht abgedeckt.
Für jede Datengruppe muss feststehen, welches System die maßgebliche Quelle ist. Wenn das Team Preise in Subiekt pflegt, Produktbeschreibungen aber im Shop entstehen, sollte die Integration diese Aufteilung berücksichtigen. Können Personen dasselbe Feld unabhängig in beiden Systemen ändern, braucht es eine Regel zur Konfliktlösung oder eine Prüfung durch Mitarbeitende. Einfach den Wert mit dem neueren Zeitstempel zu übernehmen, kann eine bewusste Entscheidung einer anderen Person überschreiben.
Klären Sie auch Produkt- und Kundenkennungen, Verkaufseinheiten, Lager, Rabatte sowie die Übertragung von Beträgen und Steuersätzen. Beispielsweise kann eine Verpackungseinheit in der Anwendung mehreren Einzelstücken im Lager entsprechen. Prüfen Sie diesen Fall mit Testdaten, bevor die Integration automatisch Belege anlegt.
Definieren Sie gesondert, was der im Shop angezeigte Bestand aussagt. Ist es die Menge im Lager, die Menge nach Abzug von Reservierungen oder ein anderer Wert für die verkaufbare Menge? Legen Sie fest, welche Verzögerung bei der Aktualisierung zulässig ist und was bei fehlenden aktuellen Daten geschieht. Der regelmäßige Abruf von Beständen allein verhindert nicht, dass mehrere Kunden das letzte verfügbare Stück bestellen.
Was passiert, wenn die Bestellung gespeichert wurde, aber die Bestätigung ausbleibt?
Dieser Fall gehört zur Abnahme: Subiekt hat den Beleg gespeichert, danach bricht die Verbindung ab. Die Anwendung erhält keine Antwort und versucht, die Bestellung erneut zu senden. Erkennt die Integration den früheren Vorgang nicht, kann ein Duplikat entstehen.
Lassen Sie sich zeigen, wie die Lösung einen erneuten Versuch erkennt und das Ergebnis des vorherigen Speichervorgangs ermittelt. Eine gleichbleibende Vorgangskennung ist ein Bestandteil einer solchen Lösung. Das Prinzip erläutert AWS in einem Beitrag zur sicheren Wiederholung von Anfragen. Die Bestellnummer lediglich im Protokoll zu speichern, reicht nicht aus. Es braucht ein geprüftes Verfahren, um sie dem Beleg zuzuordnen und einen unklaren Ausgang zu klären.
Unterscheiden Sie außerdem zwischen einem kurzen Verbindungsausfall und fehlerhaften Daten, etwa einem unbekannten Produkt. Die Empfehlungen von Microsoft zu Wiederholungsversuchen sehen Wiederholungen bei vorübergehenden Problemen vor, mit begrenzter Anzahl und angemessenen Abständen. Fehlerhafte Daten müssen korrigiert werden. Das Team sollte sehen können, welche Bestellung wartet, warum sie wartet und wer sich darum kümmern muss.
Erfasst jemand während eines Ausfalls eine Bestellung manuell, muss das Verfahren zur Wiederaufnahme der Synchronisierung dies berücksichtigen. Andernfalls kann die Integration nach Wiederherstellung der Verbindung bereits erledigte Arbeit erneut ausführen. Vereinbaren Sie, wie solche Fälle gekennzeichnet und ausstehende Vorgänge abgeglichen werden.
Fertige Schnittstellenlösung oder individuelle Anbindung?
Prüfen Sie ein fertiges Produkt anhand Ihres konkreten Bestellablaufs. Lassen Sie sich die Verarbeitung für Ihr Lager, Ihre Belegarten, Änderungen und Retouren sowie das Verhalten bei Verbindungsunterbrechungen zeigen. Eine Liste unterstützter Systeme sagt noch nicht, ob die Lösung zu den Arbeitsabläufen Ihres Unternehmens passt.
Eine individuelle Anbindung ist sinnvoll, wenn verfügbare Produkte den benötigten Ablauf nicht abdecken oder ihre Einschränkungen erhebliche manuelle Arbeit verursachen. Die Kalkulation sollte auch Tests, Fehlerbehandlung, Dokumentation und Wartung enthalten. Die Verantwortung dafür endet nicht mit der Inbetriebnahme.
Prüfen Sie vor dem Angebotsvergleich Ihre Subiekt-Version und die Lizenzbedingungen. InsERT beschreibt Sfera für Subiekt GT als erweiterbare Einzelplatzlizenz. Der Anbieter sollte bestätigen, welche Lizenzen für die geplante Installation benötigt werden. Berücksichtigen Sie neben den Umsetzungskosten auch den Betrieb der Umgebung, gegebenenfalls Gebühren für die Schnittstellenlösung und Kompatibilitätsprüfungen nach Updates.
Beim Anlegen von Belegen sollten Funktionen des Programms genutzt werden, die dessen Geschäftsregeln berücksichtigen. Sieht ein Angebot direkte Datenbankoperationen vor, sollte der Anbieter deren Umfang, die Auswirkungen auf die Datenkonsistenz und die Wartung bei Versionswechseln erläutern. Das Lesen von Daten für einen Bericht und das Schreiben eines Verkaufsbelegs müssen getrennt bewertet werden.
Wie prüfen Sie die Integration vor der Inbetriebnahme?
Verfolgen Sie in einer Testumgebung eine Bestellung von der Webanwendung bis zum Beleg in Subiekt und zur Bestätigung für das Team. Vergleichen Sie Produkt, Menge, Preis, Rabatt, Lager und die vereinbarten Auswirkungen des Vorgangs. Zur Abnahme gehören auch das erneute Senden derselben Bestellung, ein fehlendes Produkt, eine geänderte Bestellung und eine Verbindungsunterbrechung. Halten Sie für jeden Fall das erwartete Ergebnis fest.
Prüfen Sie außerdem die Wiederaufnahme nach einem Neustart der Integrationskomponente, die Verarbeitung aufgelaufener Vorgänge und das Verhalten bei der erwarteten Bestellspitze. Zeitvorgaben sollten sich auf den Abschluss des benötigten Vorgangs beziehen, nicht allein auf die Aufnahme in eine Warteschlange zur Übertragung. Beziehen Sie die Person ein, die sich im Alltag um Ausnahmefälle kümmern wird.
Der Zugriff auf die Webschnittstelle sollte eine Authentifizierung und Berechtigungen für die jeweiligen Vorgänge voraussetzen. Die OWASP-Empfehlungen zur Sicherheit von REST-Diensten behandeln unter anderem HTTPS und den Schutz von Zugangsdaten. Zugangsdaten zu Subiekt und vertrauliche Schlüssel der Integration gehören auf den Server, nicht in Browsercode oder URLs. Protokolle müssen Vorgänge nachvollziehbar machen, ohne unnötig Kundendaten zu kopieren.
Wer ist nach der Inbetriebnahme verantwortlich?
Vereinbaren Sie einen zentralen Meldeweg für Probleme, auch wenn verschiedene Unternehmen den Shop, Subiekt und die Anbindung betreuen. Es muss klar sein, wer Fehler untersucht, Daten korrigiert, einen Vorgang erneut auslösen darf und die vollständige Bearbeitung ausstehender Vorgänge bestätigt. Legen Sie auch den Supportumfang und die Tests nach Updates von Subiekt, der Schnittstellenlösung oder der Webanwendung fest.
Stellen Sie für eine Aufwandsschätzung die Subiekt-Version, Angaben zum Betrieb, eine Beschreibung der verwendeten Belege sowie Beispiele für eine normale Bestellung und Ausnahmefälle zusammen. Als erster Schritt einer System- und API-Integration lassen sich Datenflüsse, Einschränkungen und Abnahmekriterien klären. So können Sie Angebote danach vergleichen, wie sie die Bestellbearbeitung verbessern und Ihrem Team helfen, bei Problemen gezielt einzugreifen.
