I denne uge tager vi et kig på det grundlæggende i Cognos Mashup -tjenesten. Vi deler det op i dets komponenter for at se, hvordan det giver værdi til blandingen af IBM Cognos -tilbud.
For at kunne bruge Cognos Mashup -tjenesten skal man opfylde følgende minimumskrav:
1. IBM Cognos BI Server 8.4.1
2. En klient, der er i stand til at interagere med SOAP- eller URL -baserede tjenester via HTTP
Cognos Connection og Cognos Mashup Service kan tilgås via Cognos gateway
Forfatteres note: Brug stemmen til skuespilleren R. Lee Ermey (Gunny fra Full Metal Jacket)
I de næste par artikler vil jeg være din instruktør. Du kan kalde mig "Drill Sergeant". Jeg vil bryde jer rekrutter ned i de ydmyge sandkorn, der kom fra og bygge jer tilbage til laser -ætsede stykker silicium. Du forlader her med de værktøjer, du har brug for for at overleve på slagmarken kendt som Cognos Mashup Service. Du vil kunne kode din vej gennem farligt tilpasset visualiseringsterræn. Du vil kunne skelne ven fra fjende, når det kommer til designbegreber. Du har måske troet, at du ville blive forvirret af løftet om nemme REST -tjenester. Men dette er ikke din mors REST. Kan jeg få en “YES DRILL SERGEANT!”? Drop nu og giv mig tyve!
Ok, lad mig tage en pause fra karakteren for at give dig den lige. I denne uge tager vi et kig på det grundlæggende i Cognos Mashup -tjenesten. Vi deler det op i dets komponenter for at se, hvordan det giver værdi til blandingen af IBM Cognos -tilbud.
For at kunne bruge Cognos Mashup -tjenesten skal man opfylde følgende minimumskrav:
1. IBM Cognos BI Server 8.4.1
2. En klient, der er i stand til at interagere med SOAP- eller URL -baserede tjenester via HTTP
Cognos Connection og Cognos Mashup Service kan tilgås via Cognos gateway
Cognos Mashup -tjenesten består af to forskellige dele, der fungerer sammen for at give forbrugerne mulighed for at bryde rapportdata uden for rapportviseren og til tilpassede visualiseringer. En del af tjenesten er transportgrænsefladen og den anden er nyttelasten. I diagrammet herunder kan vi betragte anmodningen som transporten og svareren som nyttelasten.
Transportgrænsefladen er det middel, vi kan påberåbe rapporter til. Der er to muligheder for forbrugere at bruge. Den ene er SOAP -baseret, og den anden bruger URL'er i REST -stil. Begge grænseflader kører via HTTP og er ens i struktur. Det vil sige, at for hver logisk operation i SOAP -stilgrænsefladen er der en matchende i REST -stil. De nøjagtige metodespecifikationer observerer særegenhederne for den valgte påkaldelsesstil. Men bundlinjen er ... muligheden for at logge på, påberåbe sig en rapport, få output og logge af er tilgængelig for begge lejre.
Så du kan spørge dig selv "mig selv, hvorfor skulle jeg vælge det ene frem for det andet?" Ofte viser svaret på dette sig, når man ser på projektteknologi eller konventioner. Tag eksemplet med en forbruger, der er udviklet helt på klientsiden. Det bruger HTML og JavaScript til at interagere med Cognos Mashup -tjenesten. I et vakuum ville den REST URL -baserede grænseflade muliggøre en lettere integration. I modsætning hertil kan et andet projekt have eksisterende Cognos SDK -aktiver i en Java -servlet. De er vant til SOAP -stubbe, der er afsløret af SDK. Det føles mere naturligt, at denne situation hælder til at være en SÅB -baseret forbruger af mashup -tjenester. I praksis har dette ikke rigtig været et svært valg at afveje. Når man ser på de to valg, synes man altid at passe bedre, når man overvejer den samlede løsning. Forsøg på at bruge den anden føler sig tvunget.
De logiske operationer, der tilbydes af transportgrænsefladen, giver en forbruger mulighed for at udføre opgaver centreret om at køre Cognos -rapporter og -analyser. Sættet med muligheder gør det muligt for en forbruger at marchere gennem hele livscyklussen for at køre en rapport. Dette omfatter:
• Godkendelse
• Parametertildeling
• Rapportering (synkron og asynkron)
• Boreadfærd
• Outputhentning
Mashup -tjenesten tilbyder endda nogle godbidder, der ikke er tilgængelige via SDK. Imidlertid gemmer vi den diskussion til en kommende artikel, der sammenligner og kontrasterer Mashup -tjenesten med SDK.
Nu har vi et middel til at påberåbe rapporter gennem et HTTP -baseret sæt tjenester. Hvad kommer ud i den anden ende? Det fører os ind i den anden komponent i mashup -tjenesten. Indtast… ”Nyttelasten”.
En af de muligheder, vi kan angive, når vi påberåber os en rapport via mashup -tjenesten, er outputformatet. Der er en række tilgængelige muligheder, herunder HTML Layout Data XML (LDX) og JSON. Der er et par andre, men dette dækker spektret i abroad følelse. HTML er stort set, hvad du ville forvente. De ligner meget, hvad man ville få fra en rapport set gennem rapportfremviseren inde i Cognos Connection. De mere lovende formater er LDX og JSON. Faktisk, hvis der er et klart smash hit af Cognos Mashup Service, er det introduktionen af disse to formater.
Begge disse formater giver rapportoutput i et præsentationsneutralt format. Dette giver forbrugeren af rapportoutput mulighed for at gengive oplysningerne i enhver visualisering, der kan forstå JSON eller XML. Brug et øjeblik på at læse det igen.
Rapportdataene er nu frigjort fra de lænker, der er anbragt på dem af Cognos Viewer. Data kan nu strejfe ind på steder, der tidligere var upraktiske. For eksempel kan Rich Internet Applications bruge rammer som f.eks. Google Visualization API eller Ext-JS til at krydre præsentationen af dataene. Mobil integration bliver meget mere opnåelig, da output kan tilpasses disse enheder. Cognos -data kan virkelig blandes med data fra eksterne kilder. Faktisk blev data fra Cognos BI for nylig set, i naturen, cavorting med data fra et populært indholdsstyringssystem i det samme Ext-JS-gitter ikke mindre! Skandaløst! Hvad betyder det? I dette tilfælde tillod det, at begge datasæt blev administreret via deres native værktøjer uden en kompleks konstrueret proces for at forene dem i browseren.
Nedenfor er en simpel low fidelity mock up, der illustrerer heterogene datakilder, der deler den samme side.
Denne fleksibilitet kommer med nogle afvejninger. Da vi udsætter gengivelsen af dataene til en anden del af applikationen, overfører vi i det væsentlige noget af den udvikling, der traditionelt udføres af rapportforfatteren, til en person, der er ekspert i visualiseringsteknologien. Indsatsen for at væve rapportdata ind i visualiseringen vil variere i forhold til at skrive en pixel perfekt rapport i de traditionelle Cognos -studier. Projektplanlæggere skal forstå, hvilken effekt dette har på udviklingstider. Man vil opdage, at skøn er mere nøjagtige, når denne nye arbejdsdeling omfavnes.
For at opsummere for dette stykke er Cognos Mashup Service en spændende tilføjelse til det arsenal af værktøjer, der er tilgængelige for blandingen. Det gør det muligt for BI -data at gå ud over bare at stemple en , der indeholder en rapportfremviser, til en HTML -side. Alligevel har tiden lært os, at intet er gratis. Fleksibilitet ved præsentation af data kommer på bekostning af at bringe nye færdighedssæt til løsningssættet. Lad disse oplysninger trække i et stykke tid. I de efterfølgende poster i denne serie kommer vi nærmere ind på brugen af mashup samt hvordan den stabler sig op mod andre løsningskandidater.
