The best of both worlds CMS and Cognos Viewer. Each integration type has its strengths and weaknesses but
it does not mean you can only use one or another.Here is a simple example of how to
transition from using CMS to the full Cognos Viewer.
With just two lines of code this can be accomplished. var myURL=objXHR.responseXML.getElementsByTagName("rds:url").firstChild.nodeValue; var newdivtag = "<A HREF=" + myURL + ">Launch Cognos Viewer</a>"; frag.innerHTML =newdivtag ;
The following code is an example that demonstrates
how to provide a hybred approach to utilizing the advantages of BOTH Cognos
Mahsup Service and the Cognos Viewer.It
will first launch a report using CMS then if a user wants more robust
interaction with that chart they can click the “Get C8 Viewer Link”
button to get the cognos viewer for that chart
In this post, Mark and I would like to walk through the technologies available when integrating with IBM Cognos, and give our thoughts on when each might be the right tool in the box. Specifically, we'll talk about the Cognos Software Development Kit (SDK), Cognos Mashup Service (CMS), Cognos Viewer URLs, and Event Studio.
The Cognos SDK provides an RPC/Encoded SOAP interface to the services that make up the Cognos product. With the SDK, you are able to access all the Cognos 8 platform services for integration and automation of tasks. For example, the SDK is often used to automate administration tasks or metadata changes. As well, the SDK can be used to extend the platform, such as adding support for a custom security model.
Where the Cognos SDK is a web service interface to the IBM Cognos product, Cognos Mashup Service is a web service interface to the BI content that you develop with the IBM Cognos product. The reports, ad-hoc queries, analysis, metrics, and other content are implicitly exposed as web services, as soon as they are authored. As well, individual parts of reports are exposed as resources as well (allowing you to reference a single chart, from a complex report, for instance). CMS allows these resources to be accessed as document/literal SOAP web services, or through its REST interface (i.e. simple URL addresses to reports and report parts). The BI can be requested in several formats (e.g. XML, JSON, HTML/HTML fragment), allowing a lot of flexibility in how the BI is consumed and used. CMS also provides alternatives, for different types of integration with
BI, different client environments, different visualization requirements,
Cognos Viewer URLs provide the ability to embed the full Cognos Viewer experience into a web browser container. The documented format of the URLs, allows the viewer to be launched for a specific report, and can be tailored with query parameters to pass in prompt answers, to chose an output format to be shown in the Viewer (e.g. HTML, PDF, etc.), and to allow other customizations. Using the Viewer URLs is the right choice, if your integration calls for the Cognos Viewer experience and look and feel, running in a web browser container (e.g. launching a browser window, running in an IFRAME on an HMTL page with other content, or running in an HTML browser control on a thick client).
Event Studio offers a different integration pattern, than those previously mentioned. While CMS offers a "pull" integration of BI content, Event Studio offers a "push" model. With Event Studio, you can create "agents" to monitor the BI for conditions to occur. When the condition event is detected, your agent can "push" this information from Cognos to outside applications, with a variety of mechanisms ( such as invoking a web service, sending an email, etc.).
So when would you use which API? The following table captures characteristics of each API, as well as some typical integration patterns for which they are used.
Cognos Viewer URLs
- full Cognos Viewer interactivity and features
- Cognos Viewer look and feel, and behavior
- quick to develop, easy integration
- can integrate with just HTML
- integration in HTML browser
- add link to launch Viewer in context of a specific report, prompt values, etc.
- Viewer inside an IFRAME on a page with other content
- Viewer inside a web browser control (e.g. AWT browser) in a thick client
- BI integrated into the look and feel and behavior of the embedding application
- full reports or report parts integrated
- flexibility of how BI integrated
- less viewer interactivity "out of the box", without coding it
- Doc/lit SOAP (WSDL) and REST (i.e. URLs)
- C#, Java, etc with SOAP or REST
- other (e.g. Flex/Flash, Silverlight, etc.)
- enabling some viewer equivalent interactivity requires some coding
- BI data values readily exposed in XML formats for easy use (formatted and unformatted)
- structure of report objects facilitates easy programmatic navigation
- integrate with the BI visually or use it in business logic
- embedding BI in another application
- use Cognos content in mashups
- use in BPM process (use BI in decisions by automation or humans)
- provide alternate visualization of Cognos content
- Very detailed set of services. Provides lots of flexibility and power, but has a higher learning curve.
- C# with provided .dll file
- Java with provided .jar file
- automation (e.g. of admin tasks)
- adding extensions to Cognos (e.g. creating custom security providers)
- creating/using report specifications outside of the Cognos Studios
- information delivered or actions taken automatically, instead of user "checking"
- push model, instead of pulling from Cognos
- invoke web services, send emails, etc.
- notifying users of BI events and conditions
- initiating actions in other products, based on BI events occurring
In upcoming blog posts, we will be exploring ideas, trick and tips in all of these APIs.