Distribute the golden record: targets, runs, delivery and retry

Die Verteilung gibt den Golden Record an Systeme weiter, die ihn brauchen: ein Verzeichnis, ein Berichtssystem, ein Partnerwerkzeug. Jedes Verteilungsziel hat einen Namen, einen Modus und einen Umfang. Jeder Lauf und jeder Zustellversuch wird protokolliert, damit nachweisbar bleibt, was wann wohin ging. Was überhaupt einfließen darf, legt der Golden-Record-Scope fest.

Die wichtigsten Begriffe

• Modus: Push (Webhook) sendet das Paket an eine Adresse. Abholen (API) hält das Paket zum Abruf bereit. Dateiablage und Ereignisstrom lassen sich anlegen, sind aber noch nicht ausführbar.
• Lauf: ein Versuch, ein Paket für ein Ziel zu bauen und zuzustellen.
• Versuch: eine einzelne Zustellung innerhalb eines Laufs. Scheitert sie, folgen weitere Versuche.
• Tote Zustellung: ein Versuch, der nach fünf Versuchen endgültig gescheitert ist.
• Basisstand: die einmalige, vollständige Lieferung des Bestands nach dem geltenden Scope, mit der ein inkrementelles Ziel startet. Danach folgen nur noch Änderungen.
• Rückstand: Änderungsereignisse, die seit der letzten bestätigten Lieferung aufgelaufen sind und noch nicht ausgeliefert wurden.

Schritt 1: Ein Verteilungsziel anlegen

Öffnen Sie Konfigurationsverwaltung, Datenflüsse, den Reiter Verteilung und darin den Unterreiter Verteilung. Bestehende Ziele stehen oben als Karten, darunter der Kasten Verteilungsziel anlegen:

1. Name: zum Beispiel „Berichtssystem Beispiel“.
2. Modus: Push (Webhook), Abholen (API), Dateiablage oder Ereignisstrom.
3. Ziel-URL: nur bei Push (Webhook), zum Beispiel „https://berichte.beispiel.local/eingang“. Die Adresse muss mit https beginnen.
4. Objektart: Konfigurationselement, Anwendung, Service oder Geschäftsprozess.
5. Klasse (optional): nur bei Konfigurationselementen. Ohne Auswahl gilt „alle Klassen“.
6. Attribut-Liste des Ziels (keine Auswahl = alle im Scope stehenden Attribute): eine Liste mit Kontrollkästchen, kein Freitext. Sie zeigt die Attribute, die das Klassenmodell für die gewählte Objektart (und Klasse) führt, mit Maskenbezeichnung und dem Zusatz „Schlüssel: seriennummer“. Haken Sie an, was das Ziel höchstens bekommen soll. Darunter steht: „Personenbezogene Attribute verlassen das System nur, wenn Sie sie hier ausdrücklich auswählen.“ Wechseln Sie Objektart oder Klasse, wird die Auswahl geleert. Beim Laden steht „Attribute werden geladen“, scheitert es „Die Attribute ließen sich nicht laden.“ mit Erneut versuchen.
7. Ziel-System (optional, Id einer Integration für die Anmeldung): Die Id einer vorhandenen Integration Ihres Mandanten. Dann sendet knooing deren Zugangstoken als Bearer-Token mit. Ohne Treffer sendet es ohne Anmeldekopf.
8. inkrementell vorgesehen: ab Werk eingeschaltet, aber nur bei der Objektart Konfigurationselement möglich. Bei jeder anderen Objektart ist der Schalter gesperrt und aus.

Klicken Sie auf Anlegen. Danach erscheint „Verteilungsziel angelegt.“ und das Ziel steht als Karte in der Liste. Der Knopf Anlegen bleibt gesperrt, solange der Name fehlt. Der Server prüft die Auswahl der Attribut-Liste: Ein Schlüssel, den das Klassenmodell nicht kennt, wird abgelehnt (siehe „Wenn etwas nicht klappt“).

Warum Attribut-Liste und Scope? Der Scope legt zentral fest, was verteilt werden darf. Die Attribut-Liste grenzt je Ziel weiter ein. Personenbezogene Attribute verlassen das System nur, wenn sie ausdrücklich in der Attribut-Liste stehen.

Was „inkrementell“ bedeutet: Ein Ziel für Konfigurationselement mit inkrementell vorgesehen startet mit einem einmaligen Basisstand (der vollständige Bestand nach dem geltenden Scope, auch Objekte, die nie geändert wurden) und liefert danach nur Änderungen, genauer die Ereignisse seit dem letzten bestätigten Stand. Die Karte zeigt zuerst die Marke Basisstand ausstehend, dann Delta: aktuell oder Delta: Rückstand n. Alle anderen Ziele liefern bei jedem Lauf den vollständigen Abzug, höchstens 2000 Objekte je Lauf. Auch inkrementelle Ziele prüfen jedes Ereignis gegen Scope, Klasse und Attribut-Liste (Schritt 4). Inkrementell liefern kann nur ein Ziel für Konfigurationselemente; für jede andere Objektart lehnt der Server es ab (siehe „Wenn etwas nicht klappt“).

Beispiel: Julia Beispiel legt „Berichtssystem Beispiel“ mit Push (Webhook), der Ziel-URL „https://berichte.beispiel.local/eingang“, der Objektart Konfigurationselement, der Klasse „Server“ und der Attribut-Liste mit dem Haken bei „seriennummer“ an und lässt inkrementell vorgesehen eingeschaltet. Der erste Lauf liefert den Basisstand aller Server, jeder weitere nur Änderungen.

Schritt 2: Die Zustellung signieren

Die Karte eines Push-Ziels trägt die Marke unsigniert oder signiert. Klicken Sie auf Secret verwalten. Der Dialog heißt „Webhook-Secret: „Berichtssystem Beispiel““ und erklärt: „Mit einem Secret werden Zustellungen an dieses Ziel signiert (X-Knooing-Signature, HMAC-SHA256). Das Ziel kann so prüfen, dass die Nachricht wirklich von hier stammt. Ohne Secret bleibt die Zustellung unsigniert. Das Secret selbst wird verschlüsselt gespeichert und nie wieder angezeigt.“

Tragen Sie bei Neues Secret einen langen, zufälligen Wert ein und klicken Sie auf Setzen. Danach erscheint „Secret gesetzt. Künftige Zustellungen dieses Ziels werden signiert.“ Hat das Ziel schon ein Secret, heißt das Feld Neues Secret (ersetzt das bestehende) und der Knopf Rotieren. Entfernen löscht das Secret: „Secret entfernt. Zustellungen dieses Ziels gehen wieder unsigniert hinaus.“ Schließen verwirft die Eingabe.

Warum signieren? Das Empfängersystem kann so prüfen, dass das Paket von knooing stammt und unterwegs nicht verändert wurde. Der Wert wird nie wieder angezeigt, notieren Sie ihn vor dem Setzen im Tresor Ihres Empfängers.

Beispiel: Julia Beispiel setzt ein Secret und hinterlegt denselben Wert im Berichtssystem. Die Karte zeigt jetzt signiert.

Schritt 3: Einen Lauf starten

• Push (Webhook): Klicken Sie auf Jetzt ausführen. Die Meldung lautet „Lauf gestartet und zugestellt.“ oder „Lauf gestartet, Zustellung fehlgeschlagen. Siehe Verlauf.“ Gibt es nichts zu übertragen, steht dort „Keine Objekte im Scope - nichts zu übertragen.“ Ein Lauf ohne neue Ereignisse in einem inkrementellen Ziel zählt als gewöhnlicher Erfolg. Hat das Ziel einen Rückstand von mehr als 2000 Ereignissen oder einen Basisstand von mehr als 2000 Objekten, braucht es mehrere Läufe: Jeder Lauf liefert höchstens 2000 Ereignisse beziehungsweise Objekte (eine Charge). Klicken Sie so oft auf Jetzt ausführen, bis die Marke Delta: aktuell erscheint. Kann der Fortschritt nicht gespeichert werden, weil ein anderer Lauf schneller war oder der Scope sich geändert hat, steht dort „Der Delta-Cursor konnte nicht fortgeschrieben werden - ein anderer Lauf war schneller oder der Scope wurde geändert. Der nächste Lauf holt die Zeitspanne bzw. den Basisstand erneut ab.“
• Abholen (API): Das Empfängersystem ruft das aktuelle Paket selbst ab. Mit Abrufen (Vorschau) sehen Sie vorab, wie viele Objekte aktuell bereitstehen: „Abruf liefert aktuell n Objekte.“ Ein Abruf ist kein Zustellversuch und steht deshalb nicht im Verlauf.

Beide Knöpfe erscheinen nur bei aktiven Zielen. In der Oberfläche starten Sie jeden Lauf selbst. Ein Zeitplan je Ziel, der Läufe von allein anstößt, ist hier nicht vorgesehen; von allein wiederholt knooing nur gescheiterte Zustellungen (Schritt 6).

Warum ein Vorschau-Abruf? So prüfen Sie Umfang und Scope, ohne dass etwas das Haus verlässt.

Beispiel: Julia Beispiel klickt auf Jetzt ausführen und liest „Lauf gestartet und zugestellt.“

Schritt 4: Das Paket des Empfängers verstehen

Was beim Empfängersystem ankommt, hängt von der Lieferart ab. Jedes Paket trägt im Umschlag unter anderem runId, publicationId, generatedAt und signed.

• Vollständiger Abzug (mode: snapshot, Feld items): alle Objekte im Scope, höchstens 2000 je Lauf.
• Basisstand eines inkrementellen Ziels (mode: snapshot, baseline: true, Felder items und relations): der vollständige Bestand nach dem geltenden Scope, bei großen Beständen seitenweise zu je 2000 Objekten (baselinePage, baselineComplete). Behandeln Sie ihn im Zielsystem als vollständigen Ersatz Ihres Bestands. Ereignisse, die während der Seiten entstehen, folgen danach als Änderungen.
• Änderungen (mode: delta, Feld events, dazu fromSeq, toSeq, truncated): Ereignisse aus dem Journal. Der Umschlag trägt scopeApplied: true: Jedes Ereignis wurde vorher gegen Objektart, Klasse, Attribute des Scopes und die Attribut-Liste des Ziels geprüft.

Was bei Änderungen gilt:

• Objekt verlässt den Scope (zum Beispiel durch einen Klassenwechsel): das Ziel bekommt einmalig ein Ereignis deleted mit dem Feldnamen scope, ohne die neue Klasse zu nennen. Auch die Beziehungen des Objekts zu Objekten im Scope werden als gelöscht gemeldet. Ein archiviertes Objekt wird als gelöscht gemeldet. Das endgültige Löschen eines Objekts hält das Journal nicht fest.
• Objekt tritt in den Scope ein (Klassenwechsel hinein, Reaktivierung): das Ziel bekommt ein Ereignis created mit dem vollen aktuellen Zustand (Kernfelder und erlaubte Attribute) und seine bestehenden Beziehungen als created.
• Beziehungen werden nur geliefert, wenn beide Enden Konfigurationselemente im Scope sind, und nur mit den freigegebenen Feldern. Bei Änderungen an einer Beziehung (typeId, propagatesImpact, critical) steht relationRows im Ereignis: die aktuellen Beziehungszeilen mit dem neuen Wert. Das Journal führt keine Beziehungs-Id; ist die Zuordnung mehrdeutig, stehen mehrere Zeilen darin und das Ziel gleicht über die Id ab.
• Interne Vorgänge wie Herkunft, Zusammenführung oder Qualitätsprüfung werden nicht geliefert.

Wann kommt wieder ein Basisstand? Beim Umstellen auf inkrementell, beim Wiederaktivieren mit der Wahl Basisstand statt Rückstand liefern (Schritt 8), wenn der Scope des Ziels (Objektart oder Klasse) geändert wird, wenn Sie die Attribut-Liste des Ziels erweitern und wenn der Golden-Record-Scope etwas neu einschließt. Die Karte zeigt bis dahin Basisstand ausstehend, bei einem mehrseitigen Basisstand „Basisstand läuft: n Seite(n) geliefert“.

Warum? Ein Delta liefert nur, was nach der letzten Position im Journal steht. Eine neu eingeschlossene Angabe betrifft aber bestehende Objekte, die nie ein Ereignis auslösen. Der Basisstand gleicht das Zielsystem aus.

Beispiel: Ein Server wechselt von der Klasse „Server“ in die Klasse „Arbeitsplatz“. Das Ziel für „Server“ bekommt ein Ereignis deleted mit dem Feld scope und räumt den Eintrag ab.

Schritt 5: Den Verlauf lesen

Klicken Sie bei einem Ziel auf Verlauf (oder auf den Namen). Der Bereich Läufe zeigt jeden Lauf mit Zeitpunkt, Status und der Zahl der Objekte. Der Status heißt läuft, erfolgreich, teilweise fehlgeschlagen, fehlgeschlagen oder abgebrochen. Darunter stehen die Versuche: „Versuch 1 · Zeitpunkt · HTTP 200“ mit dem Status ausstehend, gesendet, bestätigt, fehlgeschlagen oder endgültig gescheitert und, falls vorhanden, der Antwort des Empfängers. Noch kein Lauf: „Noch kein Lauf.“ Zuklappen schließt den Bereich.

Warum der Verlauf? Er ist der Nachweis, was wann an wen ging und was der Empfänger geantwortet hat.

Beispiel: Der Verlauf zeigt einen Lauf mit „Versuch 1 · HTTP 200“ und dem Status gesendet.

Schritt 6: Gescheiterte Zustellungen wiederholen

knooing wiederholt gescheiterte Zustellungen selbst. Ein Hintergrundlauf prüft in kurzem Takt (Standard: alle 5 Minuten), ob Versuche fällig sind. Die Wartezeit verdoppelt sich von Versuch zu Versuch: 15 Minuten nach dem ersten, 30 nach dem zweiten, 60 nach dem dritten, 120 nach dem vierten. Nach dem fünften gescheiterten Versuch wird der Versuch zur toten Zustellung. Auch tote Zustellungen holt der Hintergrundlauf mit wachsender Wartezeit nach (zuerst nach 4 Stunden), solange das Ziel aktiv ist. Wer nicht warten will, greift von Hand ein:

• Erneut versuchen am gescheiterten Versuch im Verlauf. Es gibt den Knopf nur am jüngsten Versuch eines Laufs mit dem Status fehlgeschlagen. Danach erscheint „Erneuter Versuch zugestellt.“ oder „Erneuter Versuch wieder fehlgeschlagen. Siehe Verlauf.“
• Erneut versuchen bei den Toten Zustellungen unter der Zielliste. Jede Karte nennt Ziel, Zeitpunkt, Zahl der Versuche und den letzten Fehler. Danach erscheint „Erneuter Versuch aus der toten Zustellung zugestellt.“ oder „Erneuter Versuch ist wieder fehlgeschlagen.“ Ohne offene Fälle steht dort „Keine offene tote Zustellung.“

Ein Ziel, das inzwischen deaktiviert wurde, wird nicht mehr beliefert, auch nicht von Hand: Aktivieren Sie es zuerst wieder (Schritt 8). Offene Wiederholungen setzt das System nach dem Aktivieren innerhalb einer Stunde fort.

Warum die Wiederholung mit wachsender Wartezeit? Ein Empfänger, der gerade ausfällt, wird nicht mit Anfragen überrollt, und kurze Störungen heilen von selbst. Wer die Ursache beseitigt hat, muss nicht bis zum nächsten Takt warten.

Beispiel: Das Berichtssystem war nachts nicht erreichbar. Julia Beispiel sieht am Morgen im Verlauf drei gescheiterte Versuche, behebt die Ursache und klickt auf Erneut versuchen.

Schritt 7: Die Lieferart ändern

Sie können bei einem bestehenden Ziel nachträglich zwischen vollständigem Abzug und inkrementeller Lieferung wechseln. Klicken Sie auf der Karte des Ziels auf Lieferart. Der Dialog „Lieferart - „Berichtssystem Beispiel““ erklärt je nach Stellung des Schalters Inkrementell liefern (nur Änderungen), was dann gilt. Schalten Sie ein oder aus und klicken Sie auf Speichern (gesperrt, solange Sie nichts geändert haben; Abbrechen verwirft).

• Einschalten: Es erscheint der Hinweis „Beim Umstellen auf inkrementell liefert der nächste Lauf zuerst einen Basisstand (vollständiger Bestand im Scope, bei großen Beständen seitenweise zu je 2000 Objekten), danach nur noch Änderungen. Das Zielsystem sollte den Basisstand (Feld „baseline“) als vollständigen Ersatz behandeln.“ Nach dem Speichern steht „Lieferart geändert. Der nächste Lauf liefert einen Basisstand.“
• Ausschalten: Jeder Lauf liefert wieder den vollständigen Bestand im Scope. Nach dem Speichern steht „Lieferart geändert.“

Inkrementell liefern kann nur ein Ziel für Konfigurationselement. Bei jeder anderen Objektart steht im Dialog „Für diese Objektart wird immer vollständig geliefert. Die Einstellung wirkt erst bei Konfigurationselementen.“, und der Server lehnt das Einschalten ab. Jede Umstellung wird im Journal festgehalten. Schalten zwei Personen gleichzeitig um, gewinnt die erste; die zweite sieht „Das Ziel wurde zwischenzeitlich geändert. Laden Sie die Ansicht neu und versuchen Sie es erneut.“

Warum? Wer vom Abzug auf Änderungen wechselt, soll nicht von vorn anlegen müssen. Der Basisstand sorgt dafür, dass das Zielsystem danach vollständig und aktuell ist.

Beispiel: Das Berichtssystem kann nun Änderungsereignisse verarbeiten. Julia Beispiel klickt bei „Berichtssystem Beispiel“ auf Lieferart, schaltet Inkrementell liefern (nur Änderungen) ein und klickt auf Speichern.

Schritt 8: Ein Ziel deaktivieren und wieder aktivieren

Klicken Sie bei einem Ziel auf Deaktivieren. Es erscheint „Ziel deaktiviert. Lauf- und Zustellhistorie bleiben erhalten.“ Die Karte trägt die Marke deaktiviert, die Knöpfe Jetzt ausführen, Abrufen (Vorschau) und Deaktivieren verschwinden. Gelöscht wird nichts: Läufe und Versuche bleiben als Nachweis. Ein deaktiviertes Ziel wird nicht beliefert und lässt sich nicht ausführen.

Um es wieder zu beliefern, klicken Sie bei der Karte auf Aktivieren. Es öffnet sich der Dialog Verteilungsziel aktivieren: „„Berichtssystem Beispiel“ wird wieder beliefert. Die Lauf- und Zustellhistorie ist erhalten. Bei einem inkrementellen Ziel liefert der nächste Lauf den Rückstand seit der letzten bestätigten Lieferung, in Chargen zu höchstens 2000 Ereignissen je Lauf. Ein großer Rückstand braucht deshalb mehrere Läufe. Alternativ liefern Sie einen Basisstand und überspringen den Rückstand. Offene Wiederholungen setzt das System innerhalb einer Stunde fort. Die Aktivierung wird im Verlauf festgehalten.“

Bei einem inkrementellen Ziel für Konfigurationselemente gibt es im Dialog den Schalter Basisstand statt Rückstand liefern: „Der nächste Lauf liefert den vollständigen Bestand im Scope, danach wieder nur Änderungen. Ereignisse aus der Zeit der Deaktivierung werden nicht einzeln nachgeliefert: Das Zielsystem ersetzt seinen Bestand.“ Klicken Sie auf Jetzt aktivieren. Danach steht „Ziel aktiviert. Die Lieferung läuft ab dem nächsten Lauf wieder.“, bei eingeschaltetem Schalter „Ziel aktiviert. Der nächste Lauf liefert einen Basisstand.“ Scheitert die Aktivierung, steht die Meldung im Dialog, und er bleibt offen. Abbrechen schließt ihn.

Warum deaktivieren statt löschen? Die Zustellhistorie ist ein Nachweis. Ein Löschen würde sie mit entfernen. Und weil nichts gelöscht wird, lässt sich ein Ziel später mit seiner Historie wieder in Betrieb nehmen.

Warum die Wahl zwischen Rückstand und Basisstand? War das Ziel lange aus, ist der Rückstand groß. Ein Basisstand ist dann oft schneller und liefert garantiert einen vollständigen Stand. Der Rückstand dagegen ist lückenlos, braucht aber mehrere Läufe.

Beispiel: Das Berichtssystem war drei Wochen in Wartung. Julia Beispiel klickt auf Aktivieren, schaltet Basisstand statt Rückstand liefern ein und klickt auf Jetzt aktivieren.

Änderungen am Ziel im Konfigurationsprotokoll

Das Anlegen eines Verteilungsziels und jede Änderung von Adresse, Auswahl der Attribute, Zielsystem, Scope und Secret stehen im Konfigurationsprotokoll der Konfigurationsverwaltung, mit Vorher und Nachher. Die Adresse steht dort ohne Pfadgeheimnisse. Das Secret steht nur als Zustand („gesetzt“, „ersetzt“, „entfernt“), nie mit seinem Wert. Die Fortschrittsmarke eines inkrementellen Ziels (die Position im Ereignisstrom) ist keine Einstellung und steht nicht im Protokoll.

Warum? Ein Verteilungsziel entscheidet, welche Daten das Haus verlassen. Wer später fragt, ab wann ein Ziel welche Attribute bekam, findet die Antwort im Protokoll.

Die Dialoge Verteilungsziel aktivieren und Lieferart lassen sich nicht schließen, solange sie speichern: Escape, ein Klick daneben und Abbrechen wirken dann nicht. So geht eine Fehlermeldung nicht verloren.

Wenn etwas nicht klappt

• „Verteilungsziele sind der Verwaltung vorbehalten.“ Ihnen fehlt das Recht der Verwaltung der Konfigurationsverwaltung.
• „Zum Auslösen einer Verteilung brauchen Sie Schreibrecht auf die Konfigurationsverwaltung.“ Ihnen fehlt das Bearbeitungsrecht. Bitten Sie eine Person damit, den Lauf zu starten.
• „Ein Name ist Pflicht.“ Das Feld Name war leer.
• „Ein Push-Ziel braucht eine Ziel-URL.“ Tragen Sie bei Push (Webhook) eine Ziel-URL ein.
• „SSRF-Schutz: Nur HTTPS-Ziel-URLs sind zulässig.“ Verwenden Sie eine Adresse mit https. Adressen, die nicht öffentlich erreichbar sind, lehnt knooing ebenfalls ab.
• „Der Scope braucht mindestens eine gültige Objektart.“ Wählen Sie eine Objektart.
• „Dieses Ziel ist deaktiviert.“ Lauf, Abruf oder Wiederholung sind bei einem deaktivierten Ziel nicht möglich. Klicken Sie bei der Karte auf Aktivieren (Schritt 8). Ein neues Ziel brauchen Sie nicht.
• „Dieses Ziel ist bereits aktiv.“ oder „Dieses Ziel ist bereits aktiv oder wurde zwischenzeitlich geändert.“ Jemand hat es schon aktiviert. Laden Sie die Ansicht neu.
• „Dieses Ziel lässt sich nicht aktivieren: …“ Der Scope des Ziels ist nicht lesbar (zum Beispiel fehlt die Objektart oder die Klasse gibt es nicht mehr). Der Text nennt den Grund.
• „Zum Aktivieren eines deaktivierten Ziels nutzen Sie „Aktivieren“ (POST .../activate), nicht diese Änderung.“ Nur bei der Schnittstelle: Das Setzen von active: true an einem deaktivierten Ziel wird abgelehnt. Das Aktivieren geht nur über Aktivieren beziehungsweise POST .../activate.
• „Das Ziel wurde zwischenzeitlich geändert. Laden Sie die Ansicht neu und versuchen Sie es erneut.“ Zwei Änderungen am selben Ziel trafen gleichzeitig ein.
• „Die inkrementelle Lieferung gibt es nur für Konfigurationselemente. Für diese Objektart geht jeder Lauf als vollständiger Abzug hinaus: schalten Sie „inkrementell“ aus.“ Inkrementell gilt nur bei der Objektart Konfigurationselement.
• „Das Attribut „…“ gibt es im Klassenmodell für diese Objektart (und Klasse) nicht. Bitte wählen Sie vorhandene Attribute aus.“ Ein Schlüssel der Attribut-Liste ist unbekannt. Haken Sie nur Einträge der Liste an. (Weitere Prüfungen: „Die Attribut-Allowlist muss eine Liste von Attributschlüsseln sein.“, „Die Attribut-Allowlist darf höchstens 200 Schlüssel enthalten.“, „Diese Klasse gibt es im Klassenmodell nicht.“)
• „Dieses Ziel hat den Modus „Abholen“ (pull_api) - es liefert auf Anfrage über GET .../pull, kein Push-Lauf.“ Bei einem Abhol-Ziel gibt es keinen Lauf, nur den Abruf.
• „Der Modus „file_drop“ ist in dieser Oberfläche anlegbar, aber noch nicht ausführbar.“ (entsprechend „event_stream“) Wechseln Sie auf Push (Webhook) oder Abholen (API).
• „Es gibt bereits einen neueren Versuch für diesen Lauf.“ Ein anderer Versuch war schneller. Laden Sie den Verlauf neu.
• „Dieser Versuch ist endgültig gescheitert. Nutzen Sie „Erneut versuchen“ bei der toten Zustellung.“ Der Versuch steht bei Tote Zustellungen. Wiederholen Sie ihn dort.
• „Diese tote Zustellung ist bereits bearbeitet.“ Eine andere Person oder der Hintergrundlauf war schneller.
• Der Lauf meldet „Keine Objekte im Scope - nichts zu übertragen.“ Prüfen Sie im Scope, ob die Objektart ausgeschlossen ist, und ob es Objekte der gewählten Klasse gibt.
• Das Empfängersystem lehnt die Signatur ab. Prüfen Sie, ob in beiden Systemen derselbe Wert hinterlegt ist, und rotieren Sie das Secret bei Bedarf.

Wie geht es weiter?

• Golden-Record-Scope festlegen
• Quellen eintragen und Rangfolge einstellen
• Alle Anleitungen zu diesem Thema: /de/docs/suche?q=A4-07