Meldungen vom letzten Jahr sollten keinen Abruf kosten

Fragen Sie einen in Joule Studio erstellten Agenten, an welchen Pumpen eines Bereichs in diesem Quartal Dichtungsschäden gemeldet wurden und was die Instandhalter dazu geschrieben haben. Er durchsucht die Meldungen, öffnet die Langtexte, die infrage kommen, und prüft zu jeder Meldung das genannte Equipment: ein Aufruf ans Backend für jeden Schritt.

Wo ein Aufruf bezahlt wird, hängt von seinem Weg ab. Die ausgelieferten Joule-Skills rufen, sofern Ihre Edition und Ihr Vertrag sie umfassen, die OData-Services des Backends direkt auf, mit den Berechtigungen des Benutzers und nicht über Cloud Integration; in der Private Edition gehen sie über den Cloud Connector. Eigene Skills und Agenten rufen auf, worauf ihre Destinationen zeigen, etwa einen Integrationsfluss in Cloud Integration (CPI) oder einen Proxy in API Management.

Die Integrationsschicht zählt, was sie zustellt. In der Private Edition wird Cloud Integration je Kilobyte bezahlt: Ein Langtext kostet mehr als ein Status, und jedes Kilobyte, das eine Frage über einen Integrationsfluss holt, wird abgerechnet. Wo jede Schnittstelle hinter API Management liegt oder ein eigener Skill an einen Integrationsfluss angebunden wurde, bezahlt jede Frage alles, was ihre Aufrufe transportieren.

Ein Aufruf an der Integrationsschicht vorbei ist keine Nachricht – umsonst ist er trotzdem nicht. Die Schritte eines Agenten können in eigenen Einheiten gezählt werden, je nach Ihrem Vertrag; jeder Aufruf ist Last im Backend, während Planer darin arbeiten; jeder Langtext, den ein Modell zu lesen bekommt, kostet Tokens.

Keiner dieser Posten hängt davon ab, ob sich vor Ort etwas geändert hat, seit zuletzt jemand gefragt hat. Das Modell beantwortet weiterhin jede Frage; verlagern lässt sich der Abruf aus dem Backend.

In den letzten beiden Zeilen sammeln sich die Aufrufe. Eine Frage nach Häufungen liest viele Meldungen, um eine einzige Aussage zu treffen, und fast alle wurden schon beim letzten Mal gelesen. Angenommen, eine Meldung wurde letztes Jahr abgeschlossen: Jede Frage zu dieser Maschine holt sie erneut, bezahlt sie erneut und bekommt dieselbe Antwort.

Zu wählen ist also nicht zwischen live und repliziert. Zu entscheiden ist, welche Fragen einen Abruf kosten dürfen.

Konsolidieren Sie dort, wo die Daten liegen: im Backend, in CDS-Views im Kundennamensraum (Z oder Y), die auf freigegebenen Standard-Views aufsetzen.

Auf dem Standard aufsetzen, nicht in seine Tabellen greifen. Ein eigener View über einem freigegebenen View hängt nur von dem ab, was der Hersteller als stabil zugesagt hat. Ein View direkt auf den Datenbanktabellen lässt sich in ABAP Cloud nicht aktivieren; in klassischem ABAP schon, und beim nächsten Upgrade sehen Sie, was sich verschoben hat.

Nehmen Sie in die Views alles auf, was eine Antwort ohne zweiten Abruf braucht: Meldungsart, Status, Datumsfelder, Bezugsobjekt (Technischer Platz und Equipment), Instandhaltungswerk, Planungswerk, Planergruppe, die Codes der Positionen und Ursachen und die Stichwörter aus dem Langtext. Halten Sie jeden View in der Granularität seiner Daten, eine Zeile je Meldung oder je Position, und lassen Sie den Integrationsfluss einen Eintrag je Meldung bilden: Ein View, der Positionen verdichtet, kann kein Delta per Change Data Capture liefern.

Prüfen Sie, was Ihr Release mitbringt. Die neuesten Releases der Private Edition und von On-Premise enthalten freigegebene Extraktions-Views für Kopf, Positionen, Ursachen, Aktionen und Maßnahmen einer Meldung; ältere Releases und die Public Edition nicht, und die Liste der extraktionsfähigen Views Ihres Systems (I_DataExtractionEnabledView) zeigt, welche es bei Ihnen gibt. Wo es sie gibt, beschränken Sie Ihre eigene Arbeit auf das, was der Standard nicht liefern kann: den Langtext. Wo nicht, tragen Ihre eigenen Views auch den Rest, und das Delta dafür richten Sie selbst ein.

Das Folgende setzt die Private Edition oder ein On-Premise-System voraus. In der Public Edition stehen Ihnen die klassischen Text-Funktionsbausteine, Change Data Capture auf einem eigenen View und ein selbst angelegter Extraktionsservice womöglich nicht zur Verfügung; prüfen Sie alle drei auf Ihrem Release.

Der Langtext einer Meldung steht in keiner Spalte. Er ist komprimiert als Cluster gespeichert; klassisches ABAP liest ihn mit READ_TEXT oder, für viele Texte in einem Aufruf, mit READ_TEXT_TABLE, und ein CDS-View kann den Cluster weder entpacken noch einen Funktionsbaustein aufrufen. Ein View über der Textkopftabelle sieht, dass ein Text existiert und wann er zuletzt geändert wurde, aber nur in klassischem ABAP, denn diese Tabelle ist nicht freigegeben; prüfen Sie jeden solchen Zugriff vor einem Upgrade.

Was im Text steht, sieht kein eigener View. Ihr Release hält aber womöglich schon eine Kopie im Klartext für Enterprise Search, lesbar über I_TextObjectPlainLongText. Dieser View ist weder freigegeben noch für die Extraktion aktiviert; prüfen Sie also, ob Ihr System ihn für Meldungen füllt. Wenn ja, liest der Job unten die Kopie, statt READ_TEXT aufzurufen.

Die Verschlagwortung ist also ein eigener Schritt, und der View liest ihr Ergebnis. Ein Hintergrundjob wählt nach Datum und Uhrzeit des Textkopfs die Texte aus, die sich seit seinem letzten Lauf geändert haben, liest nur diese, leitet die Stichwörter ab und schreibt sie in eine kundeneigene Tabelle. Setzen Sie den Beginn der Auswahl jedes Laufs etwas vor den Startzeitpunkt des vorigen Laufs: Der Textkopf speichert ein Datum und eine Uhrzeit, keinen Zeitstempel, und ein Text kann gesichert werden, während der Job läuft. Nehmen Sie die Texte zu Positionen, Ursachen, Maßnahmen und Aktionen dazu, wenn in Ihrem Betrieb dort geschrieben wird; jede davon hat ein eigenes Textobjekt.

READ_TEXT ist als klassische API eingestuft und die Textkopftabelle nicht freigegeben, der Job ist also klassisches ABAP. In ABAP Cloud lässt er sich nur entwickeln, wenn die freigegebene API oder das freigegebene Geschäftsobjekt der Meldung auf Ihrem Release den Langtext liefert, und dazu ein Datum, das sich mit dem Text ändert.

Eine Meldung trägt bereits strukturierte Stichwörter. Die Positionen der Meldung nennen Objektteil und Schaden, deren Ursachen die Ursache, jeweils als Code aus dem Katalog. Den Code hat eine Person gewählt, aus einer Liste, die Ihr Betrieb pflegt. Das Stichwort hat ein Programm nachträglich aus dem Text gelesen.

Führen Sie beide in getrennten Feldern und weisen Sie in keiner Auswertung das eine als das andere aus. Ein Stichwort macht alten Freitext für einen Assistenten auffindbar. So zählbar wie ein Code wird er dadurch nicht, denn niemand hat das Stichwort gewählt und niemand hat es geprüft.

Leiten Sie die Stichwörter aus Regeln ab, einer Liste von Begriffen, die Ihren Katalogcodes zugeordnet sind, oder aus einem Modell, das Freitext besser liest und je geändertem Text einmal Tokens kostet. Geben Sie einem Modell die Begriffsliste vor, statt es Begriffe erfinden zu lassen, und schreiben Sie eine Stichwortzeile nur, wenn sich ihr Inhalt ändert: Ein Modell antwortet auf dieselbe Frage nicht immer gleich, und jede neu geschriebene Zeile ist eine Änderung, die das Delta überträgt. Halten Sie die Begriffsliste kurz und legen Sie fest, wer sie verantwortet.

Aktivieren Sie für den Stichwort-View ein Delta per Change Data Capture, wo Ihr Release das für eigene Views anbietet. Das Verfahren protokolliert jedes Einfügen, Ändern und Löschen über Trigger auf den Tabellen, die der View liest – hier eine einzige kleine, kundeneigene Tabelle, nicht die Meldungstabellen, in die Planer schreiben –, also sieht das Delta nur Textänderungen.

Eine Meldung, die abgeschlossen, umcodiert oder auf ein anderes Equipment umgehängt wird, ohne dass sich ein Wort im Text ändert, oder die keinen Langtext hat, braucht ein eigenes Delta: aus den Standard-Extraktions-Views, wo Ihr Release sie hat, aus Ihren eigenen Views, wo nicht. Führen Sie beide Deltas in der Ablage über die Meldungsnummer zusammen. Holen Sie nicht jede geänderte Meldung mit einem eigenen Aufruf; über die Integrationsschicht ist jeder Aufruf eine Nachricht.

Change Data Capture sieht eine gelöschte Zeile nur in der Tabelle, die es überwacht, und eine Meldung wird selten direkt gelöscht: Sie erhält eine Löschvormerkung und wird später archiviert. Übernehmen Sie ihren Status in die Ablage und filtern Sie danach. Die Archivierung ist eine eigene Entscheidung: Eine archivierte Meldung hat die Datenbank verlassen, nicht die Historie Ihres Betriebs; klären Sie mit dem, der die Aufbewahrung verantwortet, ob die Ablage sie behält. Lassen Sie den Job die Stichwortzeilen jedes Textes entfernen, den es nicht mehr gibt, und jeder Meldung, die gelöscht oder nach Ihren Aufbewahrungsregeln gesperrt ist – sonst gibt die Ablage weiter Auskunft über sie.

Cloud Integration liest das Delta zeitgesteuert, ob jemand fragt oder nicht, über das Extraktions-Framework (ODP), bereitgestellt als OData-Service, und folgt dabei von Lauf zu Lauf einem Delta-Link. Speichern Sie den neuen Link erst, wenn die Ablage das Paket angenommen hat, und schreiben Sie mit der Meldungsnummer als Schlüssel: ersetzen statt anhängen. So richtet ein doppelt geliefertes Paket keinen Schaden an.

Joule hat keine Eingangsschnittstelle für Ihre Daten, also landet das Delta in einer Ablage, die ein Joule-Agent durchsuchen kann: in einer Grounding-Collection, einem Vektorspeicher, einem Datenprodukt. Was Sie auch wählen, muss nach Feldern filtern können, nicht nur ähnliche Texte finden. Eine Ähnlichkeitssuche liefert die wenigen Einträge, die der Frage am nächsten kommen, nicht alle Treffer. Eine Frage, die auflistet oder zählt, wird deshalb aus den Codes beantwortet, über einen Filter auf Feldern – Datum, Instandhaltungswerk, Equipment, Code –, den der Agent als Werkzeug aufruft; eine Grounding-Collection, die nicht filtern kann, braucht eine Tabelle daneben, die es kann.

Senden Sie so wenig, wie die Antwort braucht. Wo Cloud Integration je Kilobyte bezahlt wird, wie in der Private Edition, liegt die Ersparnis in dem, was der Integrationsfluss transportiert: Stichwörter statt ganzer Langtexte und ein Delta statt einer Vollladung. Auch die Ablage kostet: Jeder geänderte Eintrag wird einmal indexiert, und jede Frage durchsucht sie weiterhin. Was nicht mehr mit den Fragen wächst, ist der Abruf aus dem Backend über die Schnittstelle.

• Welchen Weg die Aufrufe Ihres Assistenten heute nehmen und was auf jedem Weg gezählt wird.
• Wo das Delta landet. Deckt ein Datenprodukt, das es bei Ihnen schon gibt, Meldungen ab, prüfen Sie, ob es den Langtext mitführt; wenn ja, ersetzt es den größten Teil Ihres eigenen Codes.
• Wer was sehen darf. Ein Aufruf unter der Identität des Benutzers prüft dessen Berechtigungen; ein Integrationsfluss, der als technischer Benutzer aufruft, tut das nicht. Die Ablage prüft nichts, solange nicht jeder Eintrag Meldungsart, Instandhaltungswerk, Planungswerk, Planergruppe und, wo Sie sie nutzen, die Berechtigungsgruppe des technischen Objekts trägt und die Suche nach den Werten filtert, die die Rollen des fragenden Benutzers gewähren, bevor der Agent ein Ergebnis sieht. Lesen Sie diese Werte einmal je Sitzung oder replizieren Sie sie mit einem eigenen Delta. Überlassen Sie diesen Filter nicht dem Agenten.
• Was das System verlässt. Wo die Langtextsteuerung jedem Langtexteintrag eine Protokollzeile mit Datum, Uhrzeit und Benutzer voranstellt, entfernen Sie diese Zeilen, die Benutzerkennungen und von Hand eingegebene Namen, bevor ein Modell oder eine Ablage den Text sieht.
• Wie alt eine Antwort sein darf. Eine Antwort aus der Ablage ist so alt wie der letzte Lauf; weisen Sie überall darauf hin, wo sie gelesen wird.

Entscheidend ist nicht, ob der Assistent antworten kann, sondern ob die nächste Frage zu den Ausfällen des letzten Jahres beantwortet wird, ohne eine einzige Meldung aus dem Backend zu holen.