C^3. C to the power of 3. Cognos. Community. Collaboration.
NickMann 270001QA2W Tags:  burst report+output batching cognos event event+studio email 27 Comments 21,739 Views
Bursting is the process of running a report once and dividing the output into subsets for distribution. Each recipient recieves only the part of the data that is relevant to them.
You can create a sales report that bursts its output by sales territory and usisng Event Studio you can email the appropriate section to each sales manager.
Prompting has undergone some enhancements in CMS 10.1. Over the next couple of blog entries, I'll introduce you to these enhancements.
Passing Prompt answers by REST in CMS 10.1
In previous versions of CMS there were two options to pass prompt parameters in REST. If the prompt answer was a single value, you could pass a value like p_COUNTRY=United States. You could also post an XML form of the prompt answers for more complicated prompting scenarios. However, forming the prompt XML was tedious for REST clients compared to using serialized objects in SOAP.
In 10.1 the simplified prompt format has been enhanced so that all types of prompt answers can be sent to the server.
The following forms are now accepted:
The <![CDATA> modifier can be used to escape the “:” character and any special XML chars that appear in the prompt answer.
These simplified prompts answers can be used to run reports and can also be used to run through the new LDX prompt page API.
LDX prompt pages
In previous versions, the promptDescription resource gave CMS
developers access to an XML description of the prompt controls but
the context of the prompt page was unavailable. The prompt pages could be moved through on a forward only basis, and an XML document needed to be maintained between calls. The new reportPrompts
mechanism replaces this with a much simpler API that allows you to
move back and forth through the prompt pages and get a full LDX
output of the prompt page so that some of the vital context and
layout that isn't contained in the prompt control itself can be
presented to the user. However, 10.1 is completely backwards compatible with 8.4 and 8.4.1 applications, and the older promptDescription mechanism will continue to be supported.
Moving through the prompt pages is easy with the forward,back, reprompt, and finish operations. In the sample above, there is a single drop down prompt control that answers the report parameter cname. To move forward to the next page, simply append /forward?p_cname=Aegis%20Systems to the URL. If it's the final page, you'll be presented with all of the previously selected prompt answers that you can pass directly to the /reportData or /pagedReportData requests via the xmlData parameter.
NickMann 270001QA2W Tags:  integration service intelligence event web cognos actionable studio 8 Comments 17,426 Views
Hi I'm Nick Mann from the Event Management Framework team and I want to talk about something we've been working on recently, a powerful way to integrate Cognos with external applications via web services using Event Studio.
What is Event Studio?
Event Studio is a tool for administrators to design an agent that allows you to conditionally harvest BI data and act on it. One of the actions or tasks that you can perform with the data is calling an external web service.
External web service
First, create a web service or identify a web service that you wish to call. If you want an example and have eclipse, here is a good tutorial. If you are going to reference an external web service remember that the domain has to be in the valid domains list in the configuration tool.
Create an Agent in Event Studio.
The condition filter can be a simple 1=1 and add a web service task and paste in the WSDL URL for the web service. i.e. from the above example http://localhost:5753/axis_test/services/Converter?wsdl. Now internally event studio will use WSIF to parse the WSDL received from the URL and attempt to present the web service arguments to you as a list. At this point you can choose to enter literal data or use the data gathered by the event. Save the agent and then run it and you're done. See the Event Studio User Guide and samples for more guidance.
If your web service takes complex types, for example if the web service is "wrapped", then the complex type information must be available to WSIF. There is a buildws script available in Cognos bin directory that will process the WSDL URL and build the appropriate support classes. See the Event Studio User Guide for more information.
Event Studio help
This example uses the Cognos Mashup Service to display a report in the iGoogle portal.
Here is the link that show how to do this.
iGoogle and CMS
I would like to discuss a simple example that uses IBM Cognos Mashup Service (CMS) to create a Mashup of my IBM Cognos reports, and the ubiquitous web application used in Mashups, Google Maps. This Mashup demonstrates how easy it is to integrate IBM Cognos content into any web application. Mashing up IBM Cognos business intelligence (BI) with other applications can provide a more useful user experience, putting the BI within the context and user interface of another application, right at the “point of impact”, and avoids the need to switch to another application to make fully informed decisions.
Watch the video of the Mashup in action here.
There are a few points worth noting in this demonstration. First, the Mashup uses CMS to access the “Branches” report resource in XML form, so that the data values are readily available to pass to the Google maps API’s for geocoding. This is robust, and avoids fragile, workaround techniques like HTML scraping. The XML format is called layoutDataXML (LDX), and is fully documented in the CMS Developer Guide. Second, the “Branch Details” report resource is requested in HTML fragment form, so CMS transforms the LDX into a HTML fragment, suitable for insertion into a <div> element of an HTML page, before returning the resource. Finally the Mashup uses another resource type, the cognosURL resource to leave the Mashup application and launch another web browser to open the same “Branch Details” report in the full Cognos Viewer user interface.
I like how easy it is to make requests for BI resources to include in the Mashup application. Resources are also available in JSON format from CMS.
In this video, I explain the construction of the REST URL references to IBM Cognos report objects.
I hope that this example helps you to think of ways that your applications can integrate with IBM Cognos to deliver business intelligence right where it is needed most. I look forward to seeing other applications that apply IBM Cognos Mashup Service.
If you would like to see the complete code for this example, you can download the html file with this code here. This sample was created using IBM Cognos 8.4.1. The reports are written using Report Studio with the “Go Data Warehouse (analysis)” sample package.
For information on how to use the Google maps API please visit http://code.google.com/intl/en/apis/maps/
NickMann 270001QA2W Tags:  nc_drop emf db batching notification current pending activities 1 Comment 12,849 Views
IBM Cognos BI supports batch processing for a variety of tasks and objects. A common example would be a scheduled job containing report executions.
The monitor service stores the job and report execution commands in a Task Queue. Commands on the task queue are run as the system has capacity to do so.
There is a balance to be struck between the Cognos installation size and the rate at which background processing occurs, or put another way your installation hardware will have a maximum capacity for background processing that you cannot exceed.
You will notice that if your scheduled execution rate exceeds your system capacity then the Task Queue will start to fill up. If you open the current activities view in Cognos Administration, it will have many Pending report executions.
Stopping the scheduled activities using the upcoming activities view is one way to solve this issue and let the backlog of report be processed.
Another way that some customers have chosen to use is NC_DROP. This involves dropping all of the tables in the notification database that are prefixed NC_ When the system restarts, the tables are rebuilt and repopulated.
This has the drawback however that all of the schedules are re-synchronized to the NC tables which can take some hours on a big system.
A recommended alternative is to stop the server and use the following SQL script to truncate the task queue tables. The schedule data in the NC tables is left alone but the current activities view is now empty on restart. Beware that report executions that were pending will not now execute.
TRUNCATE TABLE NC_TASK_HISTORY_DETAIL;
TRUNCATE TABLE NC_TASK_PROPERTY;
TRUNCATE TABLE NC_TASK_QUEUE;
TRUNCATE TABLE NC_TSE_STATE_MAP;
sql script for current activity queue truncation in cognos 10
This article identifies a possible design option for implementing high availability. The main design goal for implementing high availability is 100% up time which typically requires redundant hardware and software to manage the environment. This article does not take into consideration disaster recovery plans which introduce other complexities about location of the redundant equipment. This article does not address human errors which often contribute to system failures. This article assumes that only two physical servers are available. Additional comment s will be made to discuss what can be done to improve performance if more than two servers are available.
As indicated above one of the most common methods to ensure high availability is to introduce redundancy into the overall architecture of the implementation. Out of the Box Cognos provides high availability within the application servers in the case of failure but in order to provide complete failover other hardware and software capabilities can be introduced to provide additional assurance. Listed below is a description on the various software and hardware components that make up a production ready high availability solution.
This design pattern is based on a modular design. Each physical server in the module is installed with the same software stack. In this example the software components include IBM Cognos BI Server , IBM WebSphere® Application Server, IBM HTTP Server, IBM DB2 Enterprise Server Edition, and IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP).
Each server in the module is installed with the same Cognos components but all of the components will not necessarily be turned on for each server. The following is a review of the cognos components and then a description of how they are implemented for high availability with the concept of nodes.
Gateway: This component receives requests from users, encrypts passwords, gathers the information needed to submit the request to a Cognos server, and passes the request to a dispatcher for processing. For high availability Tivoli SA MP software is used to implement a virtual service IP address that is referenced by users to connect to the gateway on the corporate network. A resource group is created and managed by Tivoli to detect if either the http server or the machine itself is not accessible.
Report service: This service manages report requests and presents output to users through a Web portal called Cognos Connection
Content Manager: This service manages the storage of application data such as security, configuration data, models, metrics, report specifications, and report output. It is needed to publish packages, retrieve or store report specifications, manage scheduling information, and manage the Cognos namespace
For high availability we will introduce the idea of a BI module. I t represents a combination of cognos components, high availability software and or hardware. The BI module must contain one BI type 1 node and one BI type 2 node, and it can contain between zero and either two or four BI extension nodes.
With this design we also have introduced a concept called tier. Tiers are a logical grouping of services. In our case the gateway tier is the http service, application tier is the report processing tier and in this case the database engine as well. The data tier is a high speed network mounted file system that contains the databases used by the application tier.
The three types of nodes in a BI module follow:
BI type 1 node: The primary role of this node is to handle user requests through the Cognos gateway and to process report requests. The number of reports processed is based on the weight associated with the Cognos dispatcher and depends on the number of BI extension nodes in the module. This node also hosts a standby Cognos Content Manager and provides failover support for the content store. Every BI module includes one type 1 node.
BI type 2 node: The primary role of this node is to host the active Cognos Content Manager, to host the content store database and the audit database, and to process report requests. The number of reports processed is based on the weight associated with the Cognos dispatcher and depends on the number of BI extension nodes in the module. The gateway on this node provides failover support for the gateway on the type 1 node. Every BI module includes one type 2 node.
BI extension node: An optional node introduced if higher performance is required. The primary role of this type of node is report processing, and it is configured to have a maximum report processing capacity. The gateway is installed but not used, and the Content Manager is installed but not started. Every BI module includes between zero and either two or four extension nodes. As you add more extension nodes to the module, a higher number of users can generate reports concurrently A mutual failover high availability configuration is implemented for the BI module using native Cognos BI Server functionality to manage the active Cognos Content Manager and Tivoli SA MP to manage high availability resource groups for the Cognos gateway and BI module database resources.
The primary role of the type 1 node is to handle user requests through the Cognos gateway and to process report requests. The resource group for the Cognos gateway is initially assigned to this node, and its Content Manager is in a standby state. If the server fails or becomes unable to connect to the corporate network, the Tivoli SA MP software detects that the type 1 node is unavailable and automatically performs the failover. The failover and subsequent failback follows this sequence of events:
Failover scenarios: A mutual failover high availability configuration is implemented for the BI module using native Cognos BI Server functionality to manage the active Cognos Content Manager andTivoli SA MP is used to manage high availability resource groups for the Cognos gateway and BI module database resources.
If the type 1node fails, the Tivoli SA MP software detects the failure and transfers the Cognos gateway resources to the type 2 node. If the type 2 node fails, the Cognos BI Server application detects the failure and designates the type 1 node as the active Content Manager. Tivoli SA MP also detects the failure and transfers the BI module database resources to the type 1 node. If an extension node fails, no failover is needed because report processing is available in the other servers.
Both file systems mounted in the BI module are located on the external storage allocated to the BI module. The /coghome and /cogfs file systems contain the DB2 instance that manages the Cognos content store and audit databases, and both are mounted on the type 2 node during normal operations. If the type 2 node fails over, the type 1 node mounts the /coghome and /cogfs file systems and manages the active content store and audit databases .
The figure below shows the minimum configuration possible, in which there is one type 1 node, one type 2 node, and no extension nodes. As this diagram shows, the gateway service IP is assigned to the type 1 node, and therefore user requests are routed to the gateway on the type 1 node. The Content Manager on the type 2 node is active. The Content Manager on the type 1 node is in a standby state, and polls the active Content Manager at a regular interval to determine whether the active Content Manager is still available. The report service is active on both nodes.
Design considerations for improving performance
As mentioned above introducing the BI extension node into the architecture will allow for improved performance for the following reasons. Disabling the Report Service on the type 2 node would be a more optimal configuration since the content store process consumes both cpu and memory as the workload increases. The BI extension node could then share report requests with the type 1 node instead of the type 2 node. The fail over scenarios would work the same as above, except for the fact that the BI Extension node will be handling the Report Request if the type 1 node fails.
A hardware load balancer could also be introduced in front of the gateway servers so multiple gateway servers can process the http requests. To obtain better performance the data tier should also include the dbms and the content manager server process as well. Stay tuned for another post on design options for performance. For more details on this topic please refer to links below.
Note: Most of this material was obtained from the IBM Smart Analytics Business Intelligence Module Guide (LC27-3637-00).
For more information on these kinds of architectures please refer to Administration and Security 10.1.0 at http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/index.jsp
And IBM Smart Analytics Business Intelligence Module Guide at:
Wade and Mark have shared some ideas, in earlier blog entries, on using Cognos Mashup Service (CMS) to access report output and to mash it up in various ways. Besides the actual report output, CMS makes other resources related to reports available as well. Included in these, is a set of resources associated with the prompting for the reports.
A common request we’ve seen from several customers, is the desire to be able to share prompt answers, for several reports. The idea is that they have an application which will display several Cognos reports, all of which share a common set of prompts. (“Application”, in this case, could mean a C#/Java client, a SharePoint page, a web page, etc.) A common use of this pattern, is to establish a context that the application user is interested in (such as sales region, and a date range), and to use this context as prompt/filters on all subsequent reporting. Instead of prompting the user several times for each report, the application prompts just once, and then uses these prompt answers to set the context, for subsequent running of all the reports. The CMS resources promptPage and promptAnswers support this pattern, by allowing the application writer to decouple the prompting for a report, from the running of the report(s).
Cognos provides a powerful prompting facility, which include features such as calendar controls, drop down selections, cascading prompts, etc. As well, report authors can further design and customize the prompt pages for their reports. CMS provides access to these prompt pages, independent of actually running the reports, through the promptPage resource. As an example, to get the prompt page for a report at Public Folders > Reports > Inventory Report, the REST URL request for this resource is:
This resource returns an XML document with two elements:
Here’s an example of this prompt page XML document:
The application can now open a browser window (or IFRAME) with the source set to this HTML prompt page url, to ask the user for the prompt response (without immediately having to run the report(s)).
Once the user has specified all the prompt values, and clicked the “Finish” button, the chosen prompt answers are saved on the Cognos server. To retrieve these answers, the application can use the CMS promptAnswers resource (and the promptID from the prompt page XML document):
(Note: the id after “conversationID/” for this resource, is the “promptID” element returned in the prompt page XML document). The promptAnswers resource is an XML document describing all the prompt answers selected:
The application can then use these prompt answers, when running the report, by providing the “xmlData” query parameter, which is set to the value of this promptAnswer XML, on the request:
http://localhost/cognos8/cgi-bin/cognos.cgi/rds/reportData/path/Public%20Folders/Reports/Inventory%20Report?xmlData=<rds:promptAnswers xmlns:rds="http://developer.cognos.com/schemas/rds/types/2"> <rds:promptValues><rds:name>region . . .
Besides the Inventory Report, for which these prompts were originally collected, these same prompt answers can be used for running any of the other reports with the same prompts (using the xmlData query parameter). For example, for the Sales Report:
http://localhost/cognos8/cgi-bin/cognos.cgi/rds/reportData/path/Public%20Folders/Reports/Sales%20Report?xmlData=<rds:promptAnswers xmlns:rds="http://developer.cognos.com/schemas/rds/types/2"> <rds:promptValues><rds:name>region . . .
The decoupled set of prompt-related resources available from CMS, allow flexibility to fit many different application requirements related to prompting. Other variants of this idea include:
The CMS samples which are included in the Cognos SDK installation, include examples of working with promptPage and promptAnswer resources.
This document describes various automation techniques that can be used to create and modify Framework Manager models. These automation scenarios would be common for situations that have dynamic models that change often or, as with OEM organizations, are different for each customer but are based on a common set of modeling operations. Another common situation occurs when a model would require many man hours of repetitive operations to create or modify and automation would free resources to address more specific tasks. Additionally, there may be scenarios where a model needs to be modified in a Unix or Linux environment where the full Framework Manager modeling tool is not available.
The focus on this document is to demonstrate capability with examples. This document should be used in conjunction with in the Framework Manager Developer Guide. This document was based on testing with IBM Cognos 8.2, 8.3, and 8.3 SP1.
As indicated in the Framework Manager Developer Guide, Framework Manager is a data modeling product. It lets users import metadata from one or more data sources and transform it into a business-oriented model for creating reports. The Framework Manager Developer Guide is for developers interested in using the collection of cross-platform Web services, libraries, and programming interfaces provided with the SDK API, to access the full functionality of Framework Manager. You can use the Framework Manager SDK to model metadata and publish packages without the use of the Framework Manager application. For more details on the Framework Manager API and the structure of the log files please refer to the Framework Manager Developer Guide provided with the Cognos documentation.
Detailed White Paper on FM Automation
BMT Script Automation Example
FM Code Using Templates
FM Automation using Templates
The purpose of this document is to identify alternative methods for drilling through another report using the Cognos Mashup Service and HTML Items. Currently the Cognos Mashup Service does provide drill through capability as identified in the documentation and samples provided but it does require some effort on the development side to implement. Individuals who might not have that development expertise or are more comfortable with Cognos Report Studio can quickly use the method provided in this document to achieve drill through capability.
This is a brief overview on how to debug a custom security provider using Eclipse. The techniques used to debug a custom security provider are no different than debugging a normal remote java application. These steps can be found in many sites on the web. The appendix A contains an example of how to do this.
There are a couple of ways to debug any cognos code. One method is to start cognos via the command prompt using startup.bat and then put print messages in your code. As the code gets invoked you will see the results in the command window. Another way is to use an IDE such as eclipse or Intellj to debug the code. There are many advantages of debugging via an IDE but one of the biggest is that you can step through the code one line at a time inspecting any variable vs knowing ahead of time which variable you want to print. This document identifies how this can be done.
Here are the steps necessary to debug using eclipse.
1.) Allow cognos server to be run in debug mode.
The first step is to modify the bootstrap_win32.xml file located in the bin directory to allow for debugging. You will see a section (<!-- uncomment these for debug -->) that needs to be uncommented. Notice the default port in this file is 9091. If you are already using that port or your network is blocking it then you should modify it to a port that is allowed. Once this change is made restart cognos. Note: On windows you must restart cognos via the service mode in order to get this to work.
2.) Create an Eclipse project with your custom security provider code.
Make sure it compiles clean
3.) Create a jar file that contains all the class files for debugging.
In order for your code to be debugged it is convenient to place all the class files in a single jar file which you can point eclipse to when debugging.
4.) Set up debugging in eclipse
Open eclipse and perform the steps identified above in the Appendix A titled: Configuring Eclipse to Debug a Remotely Running Application. For the project pick the project you created in step 2.
5.) Set break points in your source code identified above in step 2
In my case I put break points in the logon method, logout method and the searchobject method of the class file called “SingleTenantProvider” which extends Namespace implements INamespaceAuthenticationProvider2
6.) Logon to cognos, with your browser, picking your csp as namespace
You should then hit a break point if you put one in the logon method or the search method.
You might get an error message indicating cannot find source for class file. If so then configure it to point to the jar file build in step 3.There is more detail provided in the debug_csp_eclipse.pdf document.
How to get a list of folders and reports in Cognos using the Mashup Service.
One very common task to perform often in various business intelligence implementations is to provide a list of folders and reports a user has access to and then to display the report in an iframe. This example uses the cognos cms wsil to implement this.
Here is a screen shot of what it can look like with some simple css formatting.
The code required to implement this is as follows; This is the first call to cognos using the wsil cms rest call. As you continue to navigate the url will be modified as follows. Until finally the report is selected with the following url For a complete example see attached code at: https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/communityview?communityUuid=0a7c97bb-6cf9-4ddb-a918-80994e7b444d#fullpageWidgetId=Wa2f8c8404116_41c8_b1d9_c74fea3113df&file=93f2d095-d203-41f0-ba85-540288e4cdbb
The code required to implement this is as follows;
This is the first call to cognos using the wsil cms rest call.
As you continue to navigate the url will be modified as follows.
Until finally the report is selected with the following url
For a complete example see attached code at:
The syntax for the cms rest call is as follows:
Here is an example of the orgchart and treemap using data from cms.
The treemapcms.html file in the “create” directory contains a treemap and an orgchart using data from c8. It is leveraging the google visualization api with extensions.
This example includes an xml file that can be used as a datasource. It is located in the data directory. The content folder contains a very simple fm model. The content directory contains the reports used in this example. There is a report that uses the included fm model and another one that uses the go sales fm model. The files in the web directory can be placed anywhere but usually best practice to create a virtual directory. This will also work with the gosales data as well.
All of the information needed to perform the drill up/down is available in CMS's layoutDataXML format. A chart object in LDX consists of a URL to the static image, a table with the chart's underlying data, and a section called regions which contains the polygon information to display tooltips and to build an image map to perform actions when a specific area of the chart is clicked.
When we click on a pie slice in our CMS application, we'd like to open up the target report in a pop-up window, and at the same time show the user what they clicked on in the main window.
var reportPart = eval('(' + jsonText + ')');
var chart = reportPart.filterResultSet.filterResult.reportElement.cht;
// The Chart will contain a URL to the chart image, but to make it dynamic we'll also
// construct an Image map to handle drilling down.
var imageHTML = "<IMG border='0' src='" + gateway + chart.url + "' usemap='#chartMap'/>";
imageHTML += "<map name='chartmap'>";
We begin by taking the url property of the chart and creating an HTML image element. However, for the chart to do anything dynamic we also need to create a map. To do this, we need to create an HTML area, that corresponds with the area object of the chart. Chart areas from CMS always correspond to the “poly” type shape in HTML, so we simply append all the x and y coordinates that make up each polygon.
var areas = chart.regions.area;
for (var i=0; i < areas.length; i++)
// If there's no drill through target, don't bother adding it to the map
// Use the "poly" area type, as the shape of the area may be non-rectangular.
imageHTML += "<area shape='poly' coords='";
var coords = areas[i].coord;
for (var j=0; j < coords.length; j++)
if ( j != 0)
imageHTML += ",";
imageHTML += areas[i].coord[j].x;
imageHTML += ",";
imageHTML += areas[i].coord[j].y;
Finally, we need to actually do something when the area is clicked:
var drillDef = areas[i].drills.drill;
drillParam = drillDef.parm.name;
drillValue = drillDef.parm.value;
drillTarget = reportPart.filterResultSet.drillDefinitions.drill.targetPath;
imageHTML += " alt='"
imageHTML += areas[i].label;
imageHTML += "' title='";
imageHTML += areas[i].label;
imageHTML += "'/>";
A drill through is actually running another report while passing parameters from the first report. The drillDefinitions section contains the search path of the target report, while the area contains the parameter(s) that we are answering, and the value(s) that the chart area corresponds to. We now have a complete image map that should respond to our click events, see the full sample here.
With a bit of minor modification, we can also handle drill down events. The code to build up the image map is virtually identical to the above example with a minor exception. Instead of looking at drill definitions, we need to look at drill context:
drillCtx = areas[i].ctx;
if (areas[i].measure && areas[i].member)
drillCtx = areas[i].measure.ctx + ":" + areas[i].member.ctx;
// Finally, need to handle the drill down by defining the link to use our loadReportURL
With the 10.1 version of IBM Cognos, the context value we need is directly under the chart area, but in 8.4.1 we need to put two pieces of information together. Fortunately, we can make this work in both versions of Cognos with the code above. This example hard-codes the direction as DOWN, but it could easily be extended to drill up as well. You can view the complete sample here.
As you can see, making a drillable chart is fairly straight forward, and gives you flexibility in your application to handle drill events as you see fit. Since you know where and what the user is clicking on, you can use this information to update both the Cognos chart, and your own application as well.
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, etc.
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.
In upcoming blog posts, we will be exploring ideas, trick and tips in all of these APIs.