Rückschreibefunktion als Extension – Fortschritte bei KI für Cognos-Entwicklung

Erinnert ihr euch noch? Eines der ersten bekannten Beispiele von Cognos Product Manager Paul Mendelson rund um ChatGPT war damals die Frage: „Wie kann man in Cognos Reporting eine Rückschreibefunktion in einen Bericht bauen?“

Die Antwort von ChatGPT war damals komplett halluziniert. Das Modell behauptete unter anderem, man könne einfach ein entsprechendes Objekt aus der Cognos Toolbox in die Abfrage ziehen und damit direkt in eine Datenbank zurückschreiben. Wer mit Cognos Reporting gearbeitet hat, wusste natürlich sofort: so funktioniert das nicht.

Interessant war aber die eigentliche Erkenntnis dahinter. Denn die fachliche Anforderung selbst war absolut realistisch. Kommentare, Freigaben, Rückmeldungen oder kleine Eingaben direkt im Bericht sind seit Jahren ein typischer Wunsch in vielen BI-Projekten.

Die gute Nachricht: auch wenn Cognos Reporting selbst primär lesend arbeitet, lässt sich so ein Szenario mit überschaubarem Aufwand trotzdem sauber umsetzen. Zumindest für einfache Anwendungsfälle

Warum Cognos Reports nicht direkt schreiben

IBM Cognos Analytics Reports sind grundsätzlich für die Darstellung und Analyse von Daten konzipiert. Das klassische Reporting besitzt daher keine native Writeback-Funktion für eigene Datenbanktabellen.

Das bedeutet: ein Benutzer kann zwar Parameter eingeben oder Prompts verwenden, aber diese Werte werden normalerweise nicht dauerhaft in einer Datenbank gespeichert.

Für echtes Writeback benötigt man deshalb eine zusätzliche technische Komponente zwischen Report und Datenbank.

Typische Architektur für Kommentare oder Rückmeldungen

Cognos Report
    ?
Custom Control mit Eingabefeld
    ?
REST API / Webservice
    ?
Stored Procedure oder INSERT
    ?
Kommentar-Tabelle in der Datenbank

Der Report selbst enthält dabei beispielsweise ein Eingabefeld für einen Kommentar und einen Button zum Speichern. Technisch umgesetzt wird das meist über ein Custom Control mit JavaScript.

Das Custom Control ruft anschließend einen kleinen REST-Service oder Webservice auf, der den eigentlichen Datenbankzugriff übernimmt.

Beispiel für eine Kommentar-Tabelle

CREATE TABLE report_comment (
    comment_id      BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    report_key      VARCHAR(200) NOT NULL,
    object_key      VARCHAR(200) NOT NULL,
    comment_text    VARCHAR(4000) NOT NULL,
    created_by      VARCHAR(200) NOT NULL,
    created_at      TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Über die Felder report_key und object_key kann später eindeutig bestimmt werden, zu welchem Report oder Datensatz der Kommentar gehört.

Typische Schlüssel sind dabei:

• Report-Name oder Report-ID
• Kunde oder Kostenstelle
• Periode oder Szenario
• Produkt oder Projekt
• Benutzername
• Zeitstempel

Beispiel für einen einfachen REST-Aufruf

const payload = {
  reportKey: "Sales_Report",
  objectKey: "Customer_1001_2025",
  comment: document.getElementById("commentBox").value
};

fetch("/api/cognos-comments", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify(payload)
});

Der eigentliche INSERT oder UPDATE erfolgt anschließend serverseitig über eine Stored Procedure oder Backend-Logik.

Wichtiger Sicherheitsaspekt

Direkte SQL-Statements aus JavaScript oder dem Browser heraus sind keine gute Idee. Berechtigungen, Benutzerinformationen und Validierungen sollten immer serverseitig verarbeitet werden.

Ein kleiner REST-Service bietet hier deutlich mehr Sicherheit und Kontrolle.

Kommentare anzeigen

Die gespeicherten Kommentare können anschließend wieder ganz normal über ein Datenmodul oder ein Framework-Manager-Package in Cognos eingebunden werden.

Dadurch entsteht ein recht eleganter Kreislauf aus:

• Analyse im Report
• Kommentar oder Eingabe
• Speicherung in der Datenbank
• erneute Anzeige im Bericht

Wann eine Speziallösung sinnvoller ist

Für einzelne Kommentare oder kleinere Rückmeldungen funktioniert dieser Ansatz sehr gut. Sobald die Anforderungen aber komplexer werden, steigt auch der technische Aufwand deutlich an.

Typische Beispiele dafür sind:

• mehrstufige Freigabeprozesse
• Workflows
• Datenerfassung
• Versionierung
• Planungsprozesse
• Schreibrechte auf Datenebene
• Auditierung
• Benutzer- und Rollensteuerung

Genau an diesem Punkt wird häufig klar, warum spezialisierte Lösungen wie Apparo Fast Edit entstanden sind. Denn viele dieser Funktionen müssen sonst individuell entwickelt und dauerhaft gepflegt werden.

Für einfache Kommentarfunktionen reicht ein Custom-Control-Ansatz oft aus. Für größere Writeback-, Workflow- oder Datenerfassungsszenarien ist eine dedizierte Lösung in vielen Projekten langfristig deutlich wartbarer und wirtschaftlicher.