Diese Woche werfen wir einen Blick auf die Grundlagen des Cognos Mashup Service. Wir werden es in seine Bestandteile aufschlüsseln, um zu sehen, wie wertvoll es für die Mischung der IBM Cognos-Angebote ist.
Um den Cognos Mashup Service nutzen zu können, müssen die folgenden Mindestanforderungen erfüllt sein:
1. IBM Cognos BI-Server 8.4.1
2. Ein Client, der über HTTP mit SOAP- oder URL-basierten Diensten interagieren kann
Auf Cognos Connection und den Cognos Mashup Service kann über das Cognos-Gateway zugegriffen werden
Anmerkung des Autors: Verwenden Sie die Stimme des Schauspielers R. Lee Ermey (Gunny aus Full Metal Jacket)
Für die nächsten Artikel werde ich Ihr Lehrer sein. Sie dürfen mich „Drill Sergeant“ nennen. Ich werde euch Rekruten in die bescheidenen Sandkörner zerlegen und euch wieder in lasergeätzte Siliziumstücke aufbauen. Sie werden hier mit den Werkzeugen abreisen, die Sie benötigen, um auf dem als Cognos Mashup Service bekannten Schlachtfeld zu überleben. Sie werden in der Lage sein, sich durch gefährliches benutzerdefiniertes Visualisierungsgelände zu codieren. Sie werden in der Lage sein, Freund von Feind zu unterscheiden, wenn es um Designvorstellungen geht. Sie haben vielleicht gedacht, dass Sie von dem Versprechen einfacher REST-Dienste verwöhnt werden. Aber das ist nicht die RUHE deiner Mama. Kann ich einen „JA DRILL SERGEANT!“ bekommen? Jetzt lass mich fallen und gib mir zwanzig!
Ok, lassen Sie mich eine Pause vom Charakter machen, um es Ihnen klar zu sagen. Diese Woche werfen wir einen Blick auf die Grundlagen des Cognos Mashup Service. Wir werden es in seine Bestandteile aufschlüsseln, um zu sehen, wie wertvoll es für die Mischung der IBM Cognos-Angebote ist.
Um den Cognos Mashup Service nutzen zu können, müssen die folgenden Mindestanforderungen erfüllt sein:
1. IBM Cognos BI-Server 8.4.1
2. Ein Client, der über HTTP mit SOAP- oder URL-basierten Diensten interagieren kann
Auf Cognos Connection und den Cognos Mashup Service kann über das Cognos-Gateway zugegriffen werden
Der Cognos Mashup Service besteht aus zwei verschiedenen Teilen, die zusammen arbeiten, um Benutzern zu ermöglichen, Berichtsdaten außerhalb des Berichts-Viewers und in benutzerdefinierte Visualisierungen aufzuteilen. Ein Teil des Dienstes ist die Transportschnittstelle und der andere die Nutzlast. Im folgenden Diagramm können wir die Anfrage als Transport und die Antwort als Nutzlast betrachten.
Die Transportschnittstelle ist das Mittel, mit dem wir Berichte aufrufen können. Für Verbraucher gibt es zwei Möglichkeiten. Eine ist SOAP-basiert und die andere verwendet URLs im REST-Stil. Beide Schnittstellen laufen über HTTP und sind ähnlich aufgebaut. Das heißt, für jede logische Operation in der Schnittstelle im SOAP-Stil gibt es eine passende Operation im REST-Stil. Die genauen Methodenspezifikationen beachten die Eigenheiten des gewählten Aufrufstils. Aber die Quintessenz ist ... die Möglichkeit, sich anzumelden, einen Bericht aufzurufen, die Ausgabe zu erhalten und sich abzumelden, steht beiden Lagern zur Verfügung.
Sie könnten sich also fragen: "Selbst, warum sollte ich das eine dem anderen vorziehen?" Oft ergibt sich die Antwort darauf, wenn man sich Projekttechnik oder Konventionen ansieht. Nehmen Sie das Beispiel eines Verbrauchers, der vollständig auf Kundenseite entwickelt wird. Es verwendet HTML und JavaScript, um mit dem Cognos Mashup Service zu interagieren. In einem Vakuum würde die REST-URL-basierte Schnittstelle eine einfachere Integration ermöglichen. Im Gegensatz dazu kann ein anderes Projekt über vorhandene Cognos SDK-Assets in einem Java-Servlet verfügen. Sie sind an die vom SDK bereitgestellten SOAP-Stubs gewöhnt. Es fühlt sich für diese Situation natürlicher an, ein SOAP-basierter Verbraucher von Mashup-Diensten zu sein. In der Praxis war dies nicht wirklich schwer abzuwägen. Wenn man sich die beiden Auswahlmöglichkeiten ansieht, scheint eine immer besser zu passen, wenn man die Gesamtlösung betrachtet. Versuche, den anderen zu benutzen, fühlen sich gezwungen an.
Die von der Transportschnittstelle angebotenen logischen Operationen ermöglichen es einem Verbraucher, Aufgaben auszuführen, die sich auf die Ausführung von Cognos-Berichten und -Analysen konzentrieren. Der Satz von Optionen ermöglicht es einem Verbraucher, den gesamten Lebenszyklus der Ausführung eines Berichts zu durchlaufen. Das beinhaltet:
• Authentifizierung
• Parametrierung
• Berichtsausführung (synchron und asynchron)
• Bohrverhalten
• Ausgabeabruf
Der Mashup-Dienst bietet sogar einige Extras, die nicht über das SDK verfügbar sind. Wir werden diese Diskussion jedoch für einen bevorstehenden Artikel aufheben, in dem der Mashup-Dienst dem SDK gegenübergestellt und verglichen wird.
Jetzt haben wir die Möglichkeit, Berichte über einen HTTP-basierten Satz von Diensten aufzurufen. Was kommt am anderen Ende raus? Das führt uns zur zweiten Komponente des Mashup-Dienstes. Geben Sie…“Die Nutzlast” ein.
Eine der Optionen, die wir beim Aufrufen eines Berichts über den Mashup-Dienst angeben können, ist das Ausgabeformat. Es gibt eine Reihe von verfügbaren Optionen, darunter HTML Layout Data XML (LDX) und JSON. Es gibt ein paar andere, aber dies deckt das Spektrum in ab . abroad Sinn. HTML ist so ziemlich das, was Sie erwarten würden. Sie sehen sehr ähnlich aus wie aus einem Bericht, der über den Berichts-Viewer in Cognos Connection angezeigt wird. Die vielversprechenderen Formate sind LDX und JSON. Wenn der Cognos Mashup Service einen klaren Hit hat, dann ist es die Einführung dieser beiden Formate.
Beide Formate liefern die Berichtsausgabe in einem präsentationsneutralen Format. Dadurch kann der Consumer der Berichtsausgabe die Informationen in jeder Visualisierung wiedergeben, die JSON oder XML verstehen kann. Nehmen Sie sich einen Moment Zeit, um das noch einmal zu lesen.
Die Berichtsdaten werden jetzt von den Fesseln befreit, die der Cognos Viewer darauf gelegt hat. Daten können jetzt an Orte wandern, die zuvor unpraktisch waren. Rich Internet Applications können beispielsweise Frameworks wie die Google Visualization API oder Ext-JS verwenden, um die Darstellung der Daten aufzupeppen. Die mobile Integration wird viel leichter erreichbar, da die Ausgabe an diese Geräte angepasst werden kann. Cognos-Daten können wirklich mit Daten aus externen Quellen kombiniert werden. Tatsächlich wurden kürzlich Daten von Cognos BI in freier Wildbahn mit Daten aus einem beliebten Content-Management-System im selben Ext-JS-Grid nicht weniger tummeln! Skandalös! Was bedeutet das? In diesem Fall ermöglichte es die Verwaltung beider Datensätze über ihre nativen Tools, ohne dass ein komplexes Verfahren zur Vereinigung im Browser erforderlich wäre.
Unten sehen Sie ein einfaches Low-Fidelity-Mockup, das heterogene Datenquellen veranschaulicht, die dieselbe Seite teilen.
Diese Flexibilität ist mit einigen Kompromissen verbunden. Da wir das Rendern der Daten auf einen anderen Teil der Anwendung verschieben, übertragen wir im Wesentlichen einen Teil der Entwicklung, die traditionell vom Berichtsautor durchgeführt wird, auf einen Experten für Visualisierungstechnologie. Der Aufwand zum Einbinden der Berichtsdaten in die Visualisierung unterscheidet sich im Vergleich zum Erstellen eines pixelperfekten Berichts in den traditionellen Cognos-Studios. Projektplaner müssen die Auswirkungen verstehen, die dies auf die Entwicklungszeitpläne hat. Man wird feststellen, dass Schätzungen genauer sind, wenn diese neue Arbeitsteilung angenommen wird.
Zusammenfassend lässt sich sagen, dass der Cognos Mashup Service eine spannende Ergänzung des Arsenals der verfügbaren Tools ist. Es ermöglicht BI-Daten, über das bloße Stempeln und , die einen Berichts-Viewer enthält, in eine HTML-Seite. Doch die Zeit hat uns gelehrt, dass nichts umsonst ist. Die Flexibilität bei der Präsentation von Daten geht zu Lasten des Einbringens neuer Fähigkeiten in den Lösungssatz. Lassen Sie diese Informationen eine Weile einwirken. In den folgenden Einträgen dieser Serie werden wir detaillierter auf die Verwendung von Mashup eingehen und wie es im Vergleich zu anderen Lösungskandidaten abschneidet.
