Cognos 10 provides a powerful new feature to engage business users in controling BI workflow: MyInbox.
First I'm going to create an agent in event studio that checks for stores with low sales and then creates a human task in My Inbox with a report context that allows the designated user to select to notify a group of users or call a webservice.
Heres the agent in event studio. You can see the condition for sales quantity and the tasks to run if the condition is met.
For the human task definition in event studio make sure that the task owner action is set to specify which remaining tasks to run.
When I run the agent manually, you can see the tasks that will execute in sequence.
In reality scheduling the agent would be better.
Here is a view of the agent workflow state from cognos administration. we see the human task is waiting and blocking the workflow.
This is my inbox for the relevant user The low store sales task is waiting for completion.
Lets view the human task details in my inbox. if we select to distribute the report and submit our task the agent carrys on to execute the selected task.
Lets view the agent workflow state again, the agent has succeeded
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.