Den här veckan kommer vi att titta på grunderna i Cognos Mashup -tjänsten. Vi kommer att dela upp det i dess komponenter för att se hur det ger värde till blandningen av IBM Cognos -erbjudanden.
För att kunna använda Cognos Mashup -tjänsten måste man uppfylla följande minimikrav:
1. IBM Cognos BI Server 8.4.1
2. En klient som kan interagera med SOAP eller URL -baserade tjänster via HTTP
Cognos Connection och Cognos Mashup -tjänsten kan nås via Cognos gateway
Författares anmärkning: Använd rösten till skådespelaren R. Lee Ermey (Gunny från Full Metal Jacket)
För de närmaste artiklarna kommer jag att vara din instruktör. Du kan kalla mig "Drill Sergeant". Jag kommer att bryta ner era rekryter i de låga sandkornen som kom ifrån och bygga er tillbaka till laseretsade bitar av kisel. Du kommer att lämna härifrån med de verktyg du behöver för att överleva på slagfältet som kallas Cognos Mashup Service. Du kommer att kunna koda dig igenom farlig anpassad visualiseringsterräng. Du kommer att kunna skilja vän från fiende när det gäller designföreställningar. Du kanske har trott att du skulle bli förvirrad av löftet om enkla REST -tjänster. Men det här är inte din mammas VIL. Kan jag få en "JA DRILL SERGEANT!"? Släpp nu och ge mig tjugo!
Ok, låt mig ta en paus från karaktären för att ge dig den direkt. Den här veckan kommer vi att titta på grunderna i Cognos Mashup -tjänsten. Vi kommer att dela upp det i dess komponenter för att se hur det ger värde till blandningen av IBM Cognos -erbjudanden.
För att kunna använda Cognos Mashup -tjänsten måste man uppfylla följande minimikrav:
1. IBM Cognos BI Server 8.4.1
2. En klient som kan interagera med SOAP eller URL -baserade tjänster via HTTP
Cognos Connection och Cognos Mashup -tjänsten kan nås via Cognos gateway
Cognos Mashup -tjänsten består av två olika delar som fungerar tillsammans för att låta konsumenter bryta rapportdata utanför rapportvisaren och till anpassade visualiseringar. En del av tjänsten är transportgränssnittet och den andra är nyttolasten. I diagrammet nedan kan vi betrakta begäran som transport och svararen som nyttolast.
Transportgränssnittet är det sätt på vilket vi kan åberopa rapporter. Det finns två alternativ för konsumenterna att använda. Den ena är SOAP -baserad och den andra använder URL -adresser i REST -stil. Båda gränssnitten körs över HTTP och har liknande struktur. Det vill säga för varje logisk operation i SOAP -stilgränssnittet finns en matchande i REST -stil. De exakta metodspecifikationerna observerar särdragen för den valda påkallningsstilen. Men slutresultatet är ... möjligheten att logga in, åberopa en rapport, få utgången och logga ut är tillgänglig för båda lägren.
Så du kan fråga dig själv "själv, varför skulle jag välja det ena framför det andra?" Svaret på detta visar sig ofta när man tittar på projektteknik eller konventioner. Ta exemplet med en konsument som är helt utvecklad på klientsidan. Den använder HTML och JavaScript för att interagera med Cognos Mashup -tjänsten. I ett vakuum skulle det REST URL -baserade gränssnittet möjliggöra en enklare integration. Däremot kan ett annat projekt ha befintliga Cognos SDK -tillgångar i en Java -servlet. De är vana vid de SOAP -stubbar som avslöjats av SDK. Det känns mer naturligt för denna situation att luta sig mot att vara en SÅPE -baserad konsument av mashup -tjänster. I praktiken har detta inte riktigt varit ett svårt val att väga. När man tittar på de två alternativen verkar en alltid passa bättre när man överväger helhetslösningen. Försök att använda den andra känner sig tvingad.
De logiska operationer som erbjuds av transportgränssnittet gör att en konsument kan utföra uppgifter som är inriktade på att köra Cognos -rapporter och analyser. Uppsättningen gör att en konsument kan marschera genom hela livscykeln för att köra en rapport. Detta inkluderar:
• Autentisering
• Parametertilldelning
• Rapportering (synkron och asynkron)
• Borrbeteende
• Utmatningshämtning
Mashup -tjänsten erbjuder till och med några godsaker som inte är tillgängliga via SDK. Vi kommer dock att spara den diskussionen för en kommande artikel som jämför och kontrasterar Mashup -tjänsten mot SDK.
Nu har vi ett sätt att åberopa rapporter via en HTTP -baserad uppsättning tjänster. Vad kommer ut i andra änden? Det leder oss in i den andra komponenten i mashup -tjänsten. Ange… ”Nyttolasten”.
Ett av alternativen som vi kan ange när vi anropar en rapport via mashup -tjänsten är utdataformatet. Det finns ett antal tillgängliga alternativ, inklusive HTML Layout Data XML (LDX) och JSON. Det finns några andra men detta täcker spektrumet i abroad känsla. HTML är i stort sett vad du kan förvänta dig. De ser mycket ut som vad man skulle kunna få från en rapport som ses via rapportvisaren i Cognos Connection. De mer lovande formaten är LDX och JSON. I själva verket om det finns en tydlig smash hit av Cognos Mashup Service är det introduktionen av dessa två format.
Båda dessa format ger rapportutmatningen i ett presentationsneutralt format. Detta gör det möjligt för konsumenten i rapportutmatningen att återge informationen i alla visualiseringar som kan förstå JSON eller XML. Ta en stund att läsa det igen.
Rapportdata befrias nu från de bojor som placerats på den av Cognos Viewer. Data kan nu vandra till platser som tidigare var opraktiska. Till exempel kan Rich Internet Applications använda ramar som Google Visualization API eller Ext-JS för att krydda presentationen av data. Mobil integration blir mycket mer uppnåbar eftersom utdata kan anpassas till dessa enheter. Cognos -data kan verkligen blandas med data från externa källor. Faktum är att data från Cognos BI nyligen sågs, i naturen, kavorterade med data från ett populärt innehållshanteringssystem i samma Ext-JS-rutnät inte mindre! Skandal! Vad betyder det här? I det här fallet gjorde det möjligt att hantera båda uppsättningarna data med sina egna verktyg utan en komplex konstruerad process för att förena dem i webbläsaren.
Nedan är en enkel low fidelity -modell som illustrerar heterogena datakällor som delar samma sida.
Denna flexibilitet kommer med vissa avvägningar. Eftersom vi skjuter upp överföringen av data till en annan del av applikationen överför vi i huvudsak en del av den utveckling som traditionellt utförs av rapportförfattaren till en person som är expert på visualiseringstekniken. Ansträngningen att väva rapportdata i visualiseringen kommer att variera jämfört med att skapa en perfekt pixelrapport i de traditionella Cognos -studiorna. Projektplanerare måste förstå vilken effekt detta har på utvecklingstider. Man kommer att upptäcka att uppskattningar är mer exakta när denna nya arbetsfördelning omfamnas.
För att sammanfatta detta är Cognos Mashup -tjänsten ett spännande tillskott till arsenalen med verktyg som finns tillgängliga för mixen. Det gör att BI -data kan gå längre än att bara stämpla en , som innehåller en rapportvisare, till en HTML -sida. Ändå har tiden lärt oss att ingenting är gratis. Flexibiliteten att presentera data går på bekostnad av att föra nya färdigheter till lösningsuppsättningen. Låt denna information dra ett tag. I de efterföljande posterna i den här serien kommer vi att gå in på mer detaljerad information om användningen av mashup och hur den ställer sig mot andra lösningskandidater.
