Systeme per REST oder SOAP anbinden und Daten abgleichen
Ihre Daten wandern heute von Hand zwischen zwei Systemen, oder ein Partner verlangt eine Schnittstelle? Wir verbinden bestehende Anwendungen über REST oder SOAP, gleichen Daten zwischen ihnen ab und versenden Transaktionsmails und Benachrichtigungen aus Ihren Abläufen.
- Full Stack und DevOps seit 2012
- API-Entwicklung in ColdFusion, Lucee, PHP und Python
- Antwort innerhalb eines Werktags
Wann eine Schnittstelle fällig ist
Daten werden von Hand übertragen
Aufträge, Kundendaten oder Rechnungen werden aus einem System exportiert und im anderen eingetippt. Das kostet Zeit, und Tippfehler fallen erst auf, wenn ein Kunde nachfragt.
Ein Partner verlangt eine Schnittstelle
Ein Kunde, Lieferant oder Dienstleister will Daten automatisch austauschen und schickt die Beschreibung seiner Schnittstelle. Wir implementieren die Schnittstelle in Ihrem System.
Mails und Benachrichtigungen fehlen oder kommen zu spät
Bestätigungen, Rechnungen oder Statusmeldungen aus Ihren Abläufen werden von Hand verschickt oder gar nicht. Wir entwickeln eine API oder binden Ihr System an die API des Dienstleisters an.
Soll ein altes System selbst als Service dienen, damit Neues auf seiner Logik aufbaut, ist Monolith als Web-Service nutzen der passende Einstieg.
Werden Mails zwar versendet, landen aber im Spam, helfen wir auch dabei: E-Mails landen im Spam.
Was wir anbinden
- REST mit JSON: Wir rufen die Schnittstellen anderer Systeme auf oder bauen eine eigene, die andere aufrufen.
- SOAP mit XML: Wir binden Dienste nach ihrer WSDL-Beschreibung an, auch wenn Ihr eigenes System älter ist.
- Datenabgleich: zwischen Anwendungen und Datenbanken, in festen Abständen oder bei jeder Änderung, mit Protokoll der übertragenen Datensätze.
- Transaktionsmails und Benachrichtigungen: aus Ihren Abläufen heraus, mit SPF, DKIM und DMARC, damit sie die Prüfungen der Empfänger bestehen.
Die Technik richtet sich nach Ihrer Umgebung, etwa ColdFusion, Lucee oder PHP. Das sind Beispiele und keine fertigen Module, den Umfang legen wir anhand Ihres Falls fest.
So entsteht eine Schnittstelle: vom Beispiel bis zum Betrieb
-
Fall klären
Sie schildern an einem Beispiel, was hineingeht, was herauskommt, wer die Schnittstelle aufruft und wie oft. Daraus schätzen wir den Aufwand.
-
Beschreibung der Schnittstelle
Wir halten Endpunkte oder Nachrichten, Datenfelder, Fehlercodes und Beispiele für Anfragen und Antworten schriftlich fest. Sie und Ihr Partner stimmen die Beschreibung ab, bevor wir bauen.
-
Umsetzung mit Tests
Wir testen mit fiktiven Daten, auch die Fehlerfälle: Partner nicht erreichbar, doppelte Datensätze, ungültige Werte.
-
Anmeldung und Protokoll
Jeder Aufruf braucht eine Anmeldung und wird protokolliert. Wie die Schnittstelle auf Ausfälle reagiert, steht in der Beschreibung.
-
Inbetriebnahme
Wir nehmen die Schnittstelle zuerst gegen ein Testsystem in Betrieb, wo Ihr Partner eines anbietet, und nach Ihrer Freigabe in der Produktion. Die ersten Durchläufe beobachten wir genau.
-
Übergabe
Sie erhalten Beschreibung, Beispielaufrufe und Tests. Der Code liegt in Ihrem Repository.
Schnittstelle, Datenabgleich oder Altsystem als Service?
| Kriterium | Schnittstelle zwischen Systemen | Regelmäßiger Datenabgleich | Altsystem als Service |
|---|---|---|---|
| Passt, wenn | Zwei Systeme sollen sich gegenseitig aufrufen, etwa bei einer Bestellung oder einer Statusänderung. | Dieselben Daten liegen in zwei Systemen und sollen übereinstimmen, ohne dass jemand sie abtippt. | Ein altes System enthält Logik, die neue Anwendungen nutzen sollen. |
| Was Sie bekommen | Beschriebene Aufrufe in beide Richtungen, mit Anmeldung und Protokoll. | Einen Abgleich in festen Abständen oder bei jeder Änderung, mit Protokoll der Datensätze. | Eine API vor dem alten System und einen Plan, Neues daneben zu bauen. |
Was wir nicht versprechen
- Eine Schnittstelle ist so verlässlich wie die Systeme an beiden Enden. Fällt eines aus, kommen die Daten erst an, wenn es wieder erreichbar ist.
- Fehler in den Quelldaten behebt kein Abgleich. Wir machen sie im Protokoll sichtbar, bereinigen müssen sie Ihre Fachleute.
- Ändert ein Partner seine Schnittstelle ohne Ankündigung, muss die Anbindung nachziehen. Das Protokoll zeigt solche Fehler früh.
Erfahrung unserer Ingenieure mit Schnittstellen, Daten und Mail
- Schnittstellen
- REST mit JSON und SOAP mit XML
- Datenbanken
- MySQL und MariaDB seit 2012, dazu Microsoft SQL Server, PostgreSQL und Oracle
- Transaktionsmail
- Versand aus ColdFusion, Lucee und PHP mit Bounces und Abmeldungen, SPF, DKIM und DMARC
So setzen wir die API um
- Zu Beginn arbeiten wir mit Testzugängen, wo Ihr Partner sie anbietet.
- Code, Zugangsdaten und Dokumentation bleiben bei Ihnen.
- In Betrieb geht die Schnittstelle erst nach Ihrer Freigabe.
- Wir sagen Ihnen auch, wenn sich eine eigene Schnittstelle nicht lohnt, etwa weil ein vorhandener Export genügt.
Und wenn bei uns jemand ausfällt? Die Dokumentation erstellen wir auf Wunsch. Das Repository liegt in der Regel bei Ihnen. Eine Vertretung stellen wir auf Wunsch.
Schnittstellen gehören zu unserer Leistung Entwicklung und Integration.
Fragen zu Schnittstellen und Datenabgleich
Entwickeln und integrieren Sie Schnittstellen (REST, SOAP)?
Ja. Wir entwickeln Schnittstellen und binden Systeme an, mit REST und JSON ebenso wie mit SOAP und XML, einschließlich der Synchronisation von Daten zwischen Anwendungen. Typische Anwendungen beschreiben wir unter Entwicklung und Integration.
Lässt sich auch ein altes System ohne Schnittstelle anbinden?
In vielen Fällen ja. Je nach System lesen wir Daten aus seiner Datenbank, tauschen Dateien aus oder ergänzen im alten Code eine kleine Schnittstelle. Welcher Weg trägt, zeigt ein Blick auf Code und Datenbank.
Soll das alte System dauerhaft als Service für neue Anwendungen dienen, beschreibt die Seite Monolith als Web-Service nutzen den Weg.
Was passiert, wenn ein angebundenes System ausfällt?
Die Schnittstelle wiederholt fehlgeschlagene Aufrufe und hält Daten in einer Warteschlange, bis das andere System wieder erreichbar ist. Jeder Aufruf wird protokolliert, so lässt sich nachvollziehen, was angekommen ist und was nicht.
Wie oft wiederholt wird, wann wer benachrichtigt wird und was danach geschieht, legen wir vorher mit Ihnen fest. Das Verhalten bei Ausfällen ist Teil der schriftlichen Beschreibung.
Können Sie garantieren, dass unsere E-Mails im Posteingang landen?
Eine Zustellgarantie ist technisch nicht möglich, denn der Empfängerserver entscheidet. Wir sorgen für eine technisch korrekte, richtlinienkonforme und überwachte Zustellung. SPF, DKIM und DMARC stimmen, die Reputation Ihrer Absender wird beobachtet, und alle Systeme, die in Ihrem Namen senden, sind erfasst. Danach messen wir das Ergebnis.
Wie hoch ist Ihr Stundensatz?
Das hängt von Umfang, Art der Zusammenarbeit und Dringlichkeit ab. Schildern Sie uns kurz Ihre Situation, dann erhalten Sie nach einem Gespräch ein Angebot. Ein Budget brauchen wir dafür nicht. Feste Preise nennen wir bei den Einstiegsprodukten.
Wann können Sie starten?
Eine erste Antwort erhalten Sie innerhalb eines Werktags. Wann wir mit der Arbeit beginnen, hängt von der aktuellen Auslastung und vom Umfang ab. Das sagen wir Ihnen im Erstgespräch verbindlich. Ist es dringend, beginnt die 48-Stunden-Einschätzung, sobald wir Zugriff auf das System haben.
Welche Systeme sollen miteinander sprechen?
Nennen Sie uns die beteiligten Systeme, was hinein- und herausgehen soll und wer die Schnittstelle aufruft. Wir antworten innerhalb eines Werktags.