Deze week kijken we naar de basisprincipes van de Cognos Mashup Service. We zullen het opsplitsen in zijn samenstellende delen om te zien hoe het waarde toevoegt aan de mix van IBM Cognos-aanbiedingen.
Om gebruik te kunnen maken van de Cognos Mashup Service moet men aan de volgende minimumvereisten voldoen:
1. IBM Cognos BI-server 8.4.1
2. Een client die via HTTP kan communiceren met SOAP- of URL-gebaseerde services
Cognos Connection en de Cognos Mashup Service zijn toegankelijk via de Cognos-gateway
Auteurs Opmerking: Gebruik de stem van acteur R. Lee Ermey (Gunny uit Full Metal Jacket)
Voor de volgende artikelen zal ik je instructeur zijn. Je mag me "Drill Sergeant" noemen. Ik zal jullie rekruten breken in de lage zandkorrels waar vandaan kwam en jullie weer opbouwen tot lasergeëtste stukjes silicium. Je vertrekt hier met de tools die je nodig hebt om te overleven op het slagveld dat bekend staat als de Cognos Mashup Service. Je zult in staat zijn om je een weg te banen door gevaarlijk, aangepast visualisatieterrein. Je zult vriend van vijand kunnen onderscheiden als het gaat om ontwerpconcepten. Je had misschien gedacht dat je verwend zou worden door de belofte van gemakkelijke REST-services. Maar dit is niet de RUST van je moeder. Kan ik een "JA BOORSERGEANT!" krijgen? Laat vallen en geef me twintig!
Oké, laat me een pauze nemen van karakter om het je duidelijk te maken. Deze week kijken we naar de basisprincipes van de Cognos Mashup Service. We zullen het opsplitsen in zijn samenstellende delen om te zien hoe het waarde toevoegt aan de mix van IBM Cognos-aanbiedingen.
Om gebruik te kunnen maken van de Cognos Mashup Service moet men aan de volgende minimumvereisten voldoen:
1. IBM Cognos BI-server 8.4.1
2. Een client die via HTTP kan communiceren met SOAP- of URL-gebaseerde services
Cognos Connection en de Cognos Mashup Service zijn toegankelijk via de Cognos-gateway
De Cognos Mashup-service bestaat uit twee afzonderlijke delen die samenwerken om consumenten in staat te stellen rapportgegevens buiten de rapportviewer om te splitsen in aangepaste visualisaties. Een deel van de service is de transportinterface en het andere is de payload. In onderstaand schema kunnen we de request als het transport beschouwen en de response als de payload.
De transportinterface is het middel waarmee we rapporten kunnen oproepen. Er zijn twee opties voor consumenten om te gebruiken. De ene is gebaseerd op SOAP en de andere maakt gebruik van URL's in REST-stijl. Beide interfaces lopen over HTTP en zijn qua structuur vergelijkbaar. Dat wil zeggen, voor elke logische bewerking in de SOAP-stijlinterface is er een bijpassende in de REST-stijl. De exacte methodespecificaties houden rekening met de eigenaardigheden van de gekozen aanroepstijl. Maar het komt erop neer dat de mogelijkheid om in te loggen, een rapport op te roepen, de uitvoer te krijgen en uit te loggen beschikbaar is voor beide kampen.
Dus je zou jezelf kunnen afvragen "zelf, waarom zou ik de ene boven de andere verkiezen?" Vaak komt het antwoord hierop naar voren als we kijken naar projecttechnologie of conventies. Neem het voorbeeld van een consument die volledig aan de klantzijde is ontwikkeld. Het gebruikt HTML en JavaScript om te communiceren met de Cognos Mashup Service. In een vacuüm zou de op REST URL gebaseerde interface zorgen voor een eenvoudigere integratie. Een ander project kan daarentegen bestaande Cognos SDK-assets in een Java-servlet hebben. Ze zijn gewend aan de SOAP-stubs die door de SDK worden weergegeven. Het voelt natuurlijker voor deze situatie om te neigen naar een SOAP-gebaseerde consument van mashup-services. In de praktijk is dit niet echt een moeilijke keuze geweest om af te wegen. Als we naar de twee keuzes kijken, lijkt er altijd een beter te passen bij het overwegen van de totale oplossing. Pogingen om de ander te gebruiken voelen geforceerd aan.
Dankzij de logische bewerkingen die de transportinterface biedt, kan een consument taken uitvoeren die zijn gericht op het uitvoeren van Cognos-rapporten en -analyses. Met de reeks opties kan een consument de volledige levenscyclus van het uitvoeren van een rapport doorlopen. Dit bevat:
• Authenticatie
• Parametertoewijzing
• Rapportuitvoering (synchroon en asynchroon)
• Boorgedrag
• Uitvoer ophalen
De mashup-service biedt zelfs enkele goodies die niet beschikbaar zijn via de SDK. We bewaren die discussie echter voor een volgend artikel waarin de Mashup-service wordt vergeleken en vergeleken met de SDK.
Nu hebben we een manier om rapporten op te roepen via een op HTTP gebaseerde reeks services. Wat komt er aan de andere kant uit? Dat leidt ons naar het tweede onderdeel van de mashup-service. Voer ... "De Payload".
Een van de opties die we kunnen specificeren bij het aanroepen van een rapport via de mashup-service is het uitvoerformaat. Er zijn een aantal beschikbare opties, waaronder HTML Layout Data XML (LDX) en JSON. Er zijn er nog een paar, maar dit bestrijkt het spectrum in abroad gevoel. HTML is ongeveer wat je zou verwachten. Ze lijken erg op wat men zou krijgen van een rapport dat wordt bekeken via de rapportviewer in Cognos Connection. De meer veelbelovende formaten zijn LDX en JSON. Als er een duidelijke hit is door de Cognos Mashup Service, dan is het de introductie van deze twee formaten.
Beide formaten leveren de rapportoutput op in een presentatie-neutraal formaat. Hierdoor kan de consument van de rapportuitvoer de informatie weergeven in elke visualisatie die JSON of XML kan begrijpen. Neem even de tijd om dat nog eens te lezen.
De rapportgegevens zijn nu bevrijd van de boeien die de Cognos Viewer erop heeft gezet. Gegevens kunnen nu zwerven naar plaatsen die voorheen onpraktisch waren. Rich Internet Applications kunnen bijvoorbeeld frameworks zoals de Google Visualization API of Ext-JS gebruiken om de presentatie van de gegevens op te fleuren. Mobiele integratie wordt veel haalbaarder omdat de output kan worden aangepast aan deze apparaten. Cognos-gegevens kunnen echt worden vermengd met gegevens van externe bronnen. In feite werden gegevens van Cognos BI onlangs in het wild gezien met gegevens van een populair contentbeheersysteem in hetzelfde Ext-JS-raster! Schandalig! Wat betekent dit? In dit geval konden beide gegevenssets worden beheerd via hun eigen tools zonder een ingewikkeld gekunsteld proces om ze in de browser te verenigen.
Hieronder ziet u een eenvoudige low-fidelity-mock-up die heterogene gegevensbronnen illustreert die dezelfde pagina delen.
Deze flexibiliteit komt met een aantal afwegingen. Aangezien we de weergave van de gegevens uitstellen naar een ander deel van de applicatie, dragen we in wezen een deel van de ontwikkeling die traditioneel door de auteur van het rapport wordt gedaan, over aan een persoon die een expert is in de visualisatietechnologie. De inspanning om de rapportgegevens in de visualisatie te weven, zal variëren in vergelijking met het schrijven van een pixelperfect rapport in de traditionele Cognos-studio's. Projectplanners moeten het effect begrijpen dat dit heeft op ontwikkelingstijdlijnen. Men zal ontdekken dat schattingen nauwkeuriger zijn wanneer deze nieuwe taakverdeling wordt omarmd.
Samenvattend voor dit stuk, de Cognos Mashup Service is een opwindende toevoeging aan het arsenaal aan tools die beschikbaar zijn voor de mix. Het stelt BI-gegevens in staat om verder te gaan dan alleen het stempelen van een , met daarin een rapportviewer, in een HTML-pagina. Toch heeft de tijd ons geleerd dat niets gratis is. Flexibiliteit bij het presenteren van gegevens gaat ten koste van het toevoegen van nieuwe vaardigheden aan de oplossingsset. Laat deze informatie even intrekken. In de volgende artikelen in deze serie gaan we dieper in op het gebruik van mashup en hoe het zich verhoudt tot andere kandidaten voor oplossingen.
