Funktion · Ereignis-Webhooks In Entwicklung
Ihr anderes System erfährt von einer Änderung in Octoserv erst, wenn jemand nachfragt.
In Entwicklung: Ereignis-Webhooks sollen andere Systeme in Echtzeit informieren. Geplant sind Abos auf Ereignisse mit einem Typmuster, signierte Zustellung, Wiederholung bei Fehlern, ein Zustellprotokoll und das Nachholen verpasster Ereignisse. Heute nimmt Octoserv Webhooks entgegen und kann einen Webhook in einem Ablauf senden.
Ein Beispiel: Wird in Octoserv ein Deal gewonnen, soll das Projektwerkzeug des Hauses davon wissen. Heute fragt es regelmäßig nach oder erfährt es zu spät. Fällt es für eine Stunde aus, fehlen ihm ein paar Ereignisse, und niemand merkt es.
Was, wenn Ihre Systeme von selbst erführen, was in Octoserv geschieht?
Octoserv meldet das Ereignis, das andere System nimmt es an, und fällt es aus, wird nachgeholt.
01 Was geplant ist
Webhooks sollen den Ereignisstrom von Octoserv an andere Systeme liefern.
Geplant ist ein Abo mit Typmuster, etwa alles zu Deals. Octoserv liefert jedes Ereignis signiert an die Adresse des Zielsystems aus und wiederholt bei Fehlern. Ein Zustellprotokoll zeigt, was ankam, und verpasste Ereignisse lassen sich nachholen.
02 Der Platz im System
Wie soll sich das einfügen?
Die Ereignisse sind die, die Octoserv heute schon im Journal und in der Ereignisliste führt. Webhooks wären der Weg, sie aktiv nach außen zu geben.
Heute nimmt der Connector Webhooks anderer Systeme entgegen, und ein Ablauf kann einen Webhook senden. Neu wäre das Abonnieren des Ereignisstroms selbst.
Zum Connector03 Was sich ändern soll
Was soll sich für Sie ändern?
Heute
Andere Systeme fragen nach oder erfahren Änderungen verspätet, und Aussagen über das, was verpasst wurde, gibt es nicht.
Geplant
Das Zielsystem bekommt Ereignisse sofort und signiert. Fällt es aus, holt es nach, und das Protokoll belegt, was ankam.
04 Der geplante Ablauf
Wie soll der Ablauf aussehen?
Sie legen ein Abo an: welche Ereignisse, an welche Adresse. Octoserv liefert aus, wiederholt bei Fehlern und führt das Zustellprotokoll. Nach einem Ausfall holt das Zielsystem verpasste Ereignisse nach.
Der Stand der Funktion
Heute gibt es nur eingehende Webhooks und den Schritt „Webhook senden“ in Abläufen. Das Abonnieren von Ereignissen fehlt und steht auf der Umsetzungsliste. Stand: in Entwicklung. Einen Termin nennen wir nicht. Interesse von Kunden beschleunigt den Bau.
Octoserv meldet. Das andere System muss nicht fragen.
05 So könnte es aussehen
So soll das in der Praxis aussehen.
Szenario 01
Ein Deal wird gewonnen, und das Projektwerkzeug des Hauses bekommt das Ereignis in Sekunden.
Szenario 02
Das Zielsystem war eine Stunde nicht erreichbar. Octoserv wiederholt, und was verpasst wurde, holt es nach.
Szenario 03
Das Zustellprotokoll zeigt Ihrer IT, welches Ereignis wann ankam.
06 Häufige Fragen
Häufige Fragen zu den Ereignis-Webhooks.
+Ist die Funktion schon nutzbar?
Nein, sie ist in Entwicklung. Diese Seite beschreibt, was diese Funktion tun wird. Einen Termin nennen wir nicht, denn Interesse von Kunden beschleunigt den Bau.
+Wie kann ich den Bau beschleunigen?
Sprechen Sie mit uns. Wir nehmen Ihren Bedarf in die Planung auf und sagen Ihnen im Gespräch, wo die Funktion steht.
+Was kostet sie?
Das steht noch nicht fest. Wir besprechen es im Gespräch, sobald der Umfang feststeht.
+Was gibt es heute schon?
Der Connector nimmt Webhooks anderer Systeme entgegen und verbindet Octoserv in beide Richtungen mit Ihren Systemen. In einem Ablauf lässt sich ein Webhook senden.
+Für wen ist das?
Für Häuser mit weiteren Systemen, die von Ereignissen in Octoserv erfahren sollen, ohne zu fragen. Ihre IT kann sagen, welche Ereignisse sie braucht.
07 Verwandte Funktionen