Integrationen konfigurieren

Regeln für Identitäten, EIS, eSSL, Dokumentendienste und andere Konnektoren.

Publikum: Integrationsanalyst, Implementierer, Identitätsmanager, Zielsystemlieferant
Ergebnis: Jede Bindung hat einen Eigentümer, einen Vertrag, ein Sicherheitsmodell und einen behebbaren Fehlerpfad.

Der Vertrag jeder Anleihe

Quelle und Ziel, Eigentümer beider Parteien und Aufzeichnungssystem
API-Version und unterstützte Kompatibilität
Netzwerkrichtung, DNS, TLS und zugelassene Zertifizierungsstellen
Authentifizierung des technischen Dienstes und Übertragung der Identität des tatsächlichen Benutzers
Timeout-, Wiederholungs-, Backoff-, Idempotenz- und Duplikatschutz
Kontakt für Korrelations-ID, Audit, Überwachung und Eskalation
Datenklassifizierung, Minimierung, Beibehaltung und Protokollmaskierung

SSO über OpenID Connect oder SAML 2.0 konfiguriert die Vertrauensstellung mit IdP/Keycloak entsprechend der jeweiligen Umgebung.
Ein unterstütztes Design kann Microsoft Entra ID, Shibboleth, CAS (Jasig / Apereo), LDAP, NIA oder CAAIS verwenden; die genaue Protokollversion, Ansprüche und der Kontolebenszyklus sind Teil des Integrationsprofils.
Eine Gruppe aus einer Identität ist nicht automatisch eine Prozessrolle; die Zuordnung muss kontrolliert und getestet werden.
In einer unterstützten Identitätsarchitektur werden MFA oder Passkeys erzwungen.
Technische Accounts verfügen über minimale Rechte, rotierte Geheimnisse und separate Auditierung.
Das Entfernen eines Benutzers und das Ändern einer Rolle werden auf die gleiche Weise authentifiziert wie das Anmelden.

Der Fall, die Aufgaben, die Genehmigungen und die Gründe für die Rückgabe werden von OOD/SIFYBOX erfasst; der Buchhaltungsbeleg, die Buchhaltungsnummer und der offizielle Buchungsstatus werden vom Wirtschaftssystem erfasst.
Der interne Buchhalter kann direkt in den Prozess eingreifen. Der externe Buchhalter kann die genehmigten Dokumente in sein System übernehmen. Der Konnektor kann ein Dokument nur in dem Umfang erstellen, der durch die jeweilige Schnittstelle bestätigt wird.
SIFYBOX speichert ausschließlich den Status, den das Wirtschaftssystem tatsächlich zurückgibt: gesendet, technisch empfangen, Dokument erstellt oder veröffentlicht. Diese Status werden nicht kombiniert.
Das verfügbare Budget ist im Finanzsystem maßgeblich, wenn dieses die Information bereitstellt; FS speichert den für die Kontrolle maßgeblichen Snapshot. Lokale Zuweisungen oder Reservierungen sind in FS nur dann maßgeblich, wenn der Integrationsvertrag dies ausdrücklich festlegt.
Lieferanten und Buchhaltungsdimensionen stammen aus einem festgelegten Mastersystem; SIFYBOX verfügt über eine kontrollierte Kopie und eine Quellenkennung.
Die erneute Einreichung verwendet denselben Idempotenzschlüssel. Ein Timeout mit unklarem Ergebnis führt zu einer Bereinigung und nicht zur automatischen Erstellung eines neuen Dokuments.
Der Fehler erzeugt eine Aufgabe für einen bestimmten Solver und bleibt nicht nur im technischen Protokoll protokolliert.

Die Prozessanwendung ersetzt kein zertifiziertes eSSL.
Es übergibt die Komponente, Metadaten und eindeutigen Kennungen über eine bestätigte Schnittstelle gemäß NSeSSS.
Es speichert die zurückgegebenen Registrierungsdaten und den Status, damit der Benutzer nichts überschreibt.
Die Eigentumsverhältnisse der Datei, die Entsorgungsregeln und das maßgebliche Dokument werden vor der Implementierung festgelegt.
Die spezifischen unterstützten eSSLs und Versionen sind in der Release-Integrationsmatrix enthalten.

Nächste Anleitung