Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Clean Core & Integration
Lesen ohne Schreiben: die sicherste Art, IFS Cloud zu überwachen
Auf einen Blick
- Eine nur lesende OData-Anbindung beobachtet Bestellstatus, Liefertermine und Bestände über die eigenen Projections von IFS Cloud. Im Kern entsteht dabei kein einziges eigenes Objekt.
- Jeder Schreibpfad, den Sie einem Überwachungswerkzeug mitgeben, müssen Sie beim nächsten R1 oder R2 testen, patchen und verteidigen. Ein Konto mit reinem Leserecht verlangt das nie.
- Eine nur lesende Anbindung kann weder Daten beschädigen noch eine Geschäftsregel verletzen, weil sie die Schreibseite von IFS Cloud nie berührt.
- Es wird nichts installiert, also bleibt nichts zu deinstallieren und nichts, was beim nächsten Release leise bricht. Die Überwachung bleibt vollständig innerhalb von Clean Core.
Eine nur lesende OData-Anbindung überwacht Bestellstatus, Liefertermine und Bestände in IFS Cloud, ohne eine einzige Zeile zurückzuschreiben. Sie besteht aus einem eigenen Konto, einem eng begrenzten Satz von Standard-Projections und einer Überwachungsschicht, die diese Daten genauso abfragt wie jeder IFS-Cloud-Client. In der Datenbank wird nichts installiert, im Kern landet kein eigenes Objekt, und endet das Projekt, gibt es nichts zu deinstallieren. Sobald ein Überwachungswerkzeug Daten ändert, und sei es nur in kleinem, gut gemeintem Rahmen, wird aus etwas, das Sie beobachten, etwas, das Sie bei jedem Release testen, patchen und verteidigen müssen. Dieser Artikel zeigt, wie der Schreibpfad sich einschleicht, was er kostet und wie Sie die Alternative sauber aufbauen.
1.Wie Überwachungswerkzeuge in IFS Cloud zum Schreiben kommen
Der Schreibzugriff beginnt klein: Ein Werkzeug meldet eine überfällige Bestellung, und jemand fragt, ob es die Meldung auch als quittiert markieren kann, damit die Liste nicht mit Rauschen vollläuft. Dieses eine Schreibfeld wirkt harmlos. Es ist eine Spalte, ein Statuskennzeichen, eine kleine Erleichterung für den, der die Ausgabe prüft.
IFS Cloud kennt kein harmloses Schreiben. Jeder Schreibpfad berührt ein Geschäftsobjekt mit eigener Validierung, eigenem Zustandsautomaten und Regeln, die sich von Release zu Release ändern. Ein Feld, das in einer Version jeden Wert annahm, kann in der nächsten eine neue Pflichtabhängigkeit tragen. Was als Komfort für das Überwachungswerkzeug begann, wird zur Anpassung, die das Upgrade-Team finden, verstehen und neu qualifizieren muss, womöglich ohne von ihr zu wissen, weil niemand sie als Integration dokumentiert hat.
2.Was ein Schreibpfad tatsächlich kostet
Die Kosten fallen nicht an dem Tag an, an dem Sie das Schreiben hinzufügen. Sie zeigen sich zwei oder drei Upgrades später, verteilt auf vier Stellen:
- Regressionstest. Jeder Schreibpfad ist eine Anpassungsfläche, die die Qualitätssicherung bei jedem R1 und R2 neu finden und neu prüfen muss, ob sich jemand an den Bau erinnert oder nicht.
- Upgrade-Anfälligkeit. Ein Schreibzugriff, der gegen die Geschäftslogik des Vorjahres sauber lief, kann eine Regel verletzen, die das nächste Release verschärft. Der Fehler kann im ungünstigsten Moment auftreten: mitten im Upgrade, in Produktion.
- Erhöhte Rechte. Bei einem Überwachungskonto mit Schreibrecht ist das Angriffsziel größer und der Schaden weitreichender, wenn die Zugangsdaten abfließen oder das Werkzeug fehlerhaft arbeitet.
- Laufende Pflege. Jedes Rückschreiben braucht eine eigene Fehlerbehandlung, eigene Wiederholversuche und jemanden, der verantwortet, was passiert, wenn es um drei Uhr nachts unbemerkt fehlschlägt.
Am billigsten bleibt die Integration, die IFS Cloud nie um Vertrauen für einen Schreibzugriff gebeten hat.
3.So bauen Sie die lesende Variante in IFS Cloud
IFS Cloud stellt die Daten, die eine Überwachung braucht, bereits über die eigenen OData-Projections bereit: Bestellstatus, Bestätigungsstatus, Liefertermin und Bestandsmenge. Es sind dieselben Projections, die der Standard-Client nutzt. Sie legen ein eigenes Integrationskonto an und hängen ein Permission Set daran, das Lesezugriff genau auf die Projections im Umfang gewährt und auf nichts sonst. Es entsteht keine eigene Entität, keine neue Tabelle und kein PL/SQL-Paket in der Datenbank, das beim nächsten Upgrade auf seine Entdeckung wartet.
Von dort fragt das Überwachungswerkzeug nach Zeitplan ab, filtert auf die Zustände, die zählen, und löst den Alarm oder die Dashboard-Aktualisierung aus, die der Fachbereich braucht, und zwar vollständig außerhalb von IFS Cloud. Geschrieben wird, falls überhaupt, in einem E-Mail-System, einem Teams-Kanal oder einem Ticketsystem, nie zurück in das ERP. IFS Cloud bleibt so sauber, wie es vor der Überwachung war.
4.Integration mit Rückschreiben und lesende Überwachung im Vergleich
Beide Ansätze unterscheiden sich im Risikoprofil und in der Zeit, die sie Upgrade für Upgrade unbemerkt binden.
| Integration mit Rückschreiben | Lesende Überwachung | |
|---|---|---|
| Upgrade-Aufwand | Jeder Schreibpfad wird bei jedem Release neu getestet | Nichts nachzutesten: Die Projection ist Standard |
| Benötigte Rechte | Schreibzugriff auf Kern-Geschäftsobjekte | Nur Lesen, begrenzt auf die Projections im Umfang |
| Was bei R1/R2 bricht | Eigene Schreiblogik gegen geänderte Regeln | Nichts: Sie lesen dieselben Daten, die IFS ausliefert |
| Audit-Fläche | Jeder Schreibvorgang ist eine Änderung, die jemand nachvollziehen muss | Keine: Das Werkzeug hinterlässt keine Spur im System |
| Schlimmster Fehlerfall | Stille Datenbeschädigung oder ein blockiertes Release | Ein veralteter Lesewert, nie eine zerstörte Transaktion |
Das heißt nicht, dass Rückschreib-Integrationen grundsätzlich falsch sind. Es gibt Prozesse, die tatsächlich einen Status in IFS Cloud ändern müssen. Eine Überwachungs- und Alarmschicht gehört nicht dazu. Wer sie von Anfang an als nur lesend behandelt, nimmt eine ganze Kategorie von Upgrade-Risiko weg, bevor sie sich aufbauen kann.
5.Sicher ausrollen
Der lesende Aufbau ist der leichte Teil. Der Rollout braucht Disziplin, damit kein zweites Problem entsteht: ein Integrationskonto mit weitreichenderen Rechten als nötig.
- Projections eingrenzen. Listen Sie genau auf, welche Entitäten (Bestellstatus, Bestätigung, Liefertermin, Bestand) die Überwachung braucht, und nichts darüber hinaus.
- Eigenes Konto nur mit Leserecht anlegen. Ein benannter Integrationsbenutzer mit einem Permission Set, das ausschließlich Lesezugriff gewährt, nie Schreibrechte, auch wenn Schreibzugriff bequem aussieht.
- Zuerst gegen eine Nicht-Produktionsumgebung testen. Richten Sie die lesende Schicht auf einen Test- oder UAT-Mandanten, bevor sie Echtdaten berührt.
- Abfragetakt begrenzen. Fragen Sie nach einem Zeitplan ab, der die Leistungsgrenzen von IFS Cloud respektiert, und nicht bei jedem denkbaren Auslöser.
- Das Konto nach jedem Upgrade prüfen. Eine Rechteprüfung von fünf Minuten pro R1- oder R2-Zyklus ist der gesamte laufende Pflegeaufwand.
Weil das Konto nur liest, muss das IFS Extensibility Framework hier nichts abfangen: keine Änderung am Kern, kein eigenes Objekt, kein Schreibpfad, den das nächste Release brechen könnte. Update-sicher ist die Lösung durch ihren Aufbau, nicht durch eine Disziplin, an die Sie jedes Mal denken müssen.
Technisches 30-Minuten-Gespräch buchen SCM Automation Pack ansehen
6.Fragen und Antworten
Braucht eine nur lesende OData-Anbindung eine Eigenentwicklung in IFS Cloud?
Nein. Sie nutzt die Standard-OData-Projections, die IFS Cloud ohnehin bereitstellt, über ein eigenes Integrationskonto mit einem Permission Set, das nur liest. In IFS Cloud selbst ist nichts zu bauen.
Was kann eine nur lesende Integration in IFS Cloud sehen?
Sie sieht genau das, was das Permission Set gewährt, und nichts darüber hinaus. Für die hier beschriebene Überwachung genügen Bestellstatus, Bestätigungsstatus, Liefertermine und Bestände: ein kleiner, klar umrissener Ausschnitt der Daten, die IFS Cloud ohnehin hält.
Kann eine nur lesende Integration trotzdem Alarme senden und Aktionen auslösen?
Ja. Das Lesen löst den Alarm aus, die Aktion (eine E-Mail, eine Teams-Nachricht, ein Ticket) findet außerhalb von IFS Cloud statt. Es wird nichts in das ERP zurückgeschrieben, daher wird die Aktion nie zu einer Anpassung, die Sie pflegen müssen.
Passt eine nur lesende Integration zu Clean Core?
Ja, unmittelbar. Eine nur lesende Integration installiert nichts in der Datenbank, ändert kein Kernobjekt und hinterlässt keine Spur, die ein Upgrade brechen könnte. Sie ist einer der einfachsten Wege, eine Überwachung zu ergänzen, ohne die Clean-Core-Position von IFS Cloud anzutasten.
7.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote tätig in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Ausgewählte Kunden: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Überwachen, ohne Upgrade-Aufwand zu erzeugen
Schreibt Ihre Überwachung bereits in IFS Cloud zurück, ist der Umbau auf reines Lesen womöglich kleiner, als er klingt. In einem 30-Minuten-Gespräch kläre ich mit Ihnen, was Ihre Alarme tatsächlich lesen müssen und was aus dem Schreibpfad komplett entfallen kann (Festpreis, Probelauf (Dry-run), bevor sich etwas ändert).
