If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Multiple packages in Cognos Analytics?

Started by Michael75, 23 Aug 2016 09:35:29 AM

Previous topic - Next topic

Michael75

Hi All,

In a new position for a couple of months now, I find myself in a challenging situation. The implementation of a new ERP was started a couple of years ago, and the development of the Cognos BI reporting solution, based on C10.2.1 & Netezza EDW & DMs, started at the same time.

Take a minute to digest that one! It means, in our case:
1. There was no knowledge of what data would be available, only DB schemas from the supplier, showing columns which now (the ERP has been running in very limited mode since March 2016) turn out more often than not to be always null.
2. Based on the above, "user requirements" (report requests) were written, in the form of a mock-up containing a list of columns (often null), and few or no business rules at all.
3. The DM structure was designed from a purely "data driven" point of view, meaning that now, during report development, we discover that the DMs are far from optimal.
4. An arbitrary decision was taken, apparently based on achieving deliverables of a manageable size, to produce 12 FM packages, each covering a different subject area, from the (single) FM project.

Point #4 would have been acceptable had the subject areas been discrete. But of course, they are not. It's only natural in an ERP. As of today, we have maybe 30 reports in production or in final validation. And there are maybe 20 more which need to be entirely reworked or have not even been started. In the latter case, one of the main hold-ups is that the report needs to traverse two or more packages. Hard-coded SQL, although I've used it in a couple of exploratory reports, is not an option in production reports to access the query subjects which are "out of reach".

BTW No recriminations are possible! There's been high staff turnover on this project, and not only are the guilty parties long-departed, they can't even be identified. So the objective now is to make the best of this situation.

I'd say that the only positive factor in this is that my predecessors at least stuck with a single FM project. Given that fact, three remedial solutions come to mind, which I'll list in increasing order of effort required:
1. Extend the number of objects included in the packages concerned. This will obviously lead to many overlaps (think Venn diagrams), by which I mean the same objects appearing in two or more packages.
2. Re-analyse the reporting requirements, and create a much smaller number of new packages. Gut feeling tells me that this number would be three or four.
3. Put everything, absolutely everything, in a single package.

Looking at this list, solution #1 has the advantage of not needing to remap the existing reports. I've done this exercise before, and it is not as simple as doing a series of Find/Replace in one's favourite text editor. But I dont't know if there are drawbacks in having these overlaps. Maybe somebody has already been there, and can advise? And (yet again thinking as I type), I'd say that while solution #2 would be easier than #3 from the FM point of view, it doesn't necessarily cater for future requirements, whereas #3 is "future-proof".

(../..)

I mentioned that we run on C10.2.1. We also have a C10.2.2 instance that's under evaluation, and there's a lot of interest here in Cognos Analytics, from the self-service reporting point of view. We really could be an early adopter. And that's why I've chosen to post on this board.

Can anyone shed any light on this New Feature in Cognos Analytics?

    Reports support multiple packages
    When you are authoring a report, you can add data items from multiple packages that use the dynamic query mode, or from a single package that uses the compatible query mode.

    http://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.ca_new.doc/c_ca_nf_11_0_x.html?cp=SSEP7J_11.0.0

My understanding is that report specs are compatible between C10 and Cognos Analytics. And in a C10 report spec, the package on which the report is based is defined in the <modelPath> . . . </modelPath> string.

So is a report authored in Cognos Analytics and based on a DQM data source able to allow <modelPath1>, <modelPath2> etc? And if not, how is this new functionality achieved? I also have difficulty visualising how this would be presented in the new report authoring environment.

Sorry for this long and rambling post, and TIA for any advice on any of the points above.

Michael

bdbits

It is always tough to walk into a half-finished effort. It can be very satisfying to right the ship, though, so hang in there. Keep looking forward.

So it sounds like you have conformed dimensions and a reasonable underlying data model (data quality aside), and a single FM model with multiple packages - essentially data marts built off a single model. This is a good thing. I should think the core problem is how to move forward without breaking what is in place.

Your option 1, it seems to me, is only extending the problem by putting a band-aid on it. Options 2 and 3 are not necessarily mutually exclusive. I think it depends on who will be consuming the packages. If it is end users (self-service orientation), a single package could be overwhelming, confusing, and worst of all lead to incorrect reporting unless they understand working with data and data warehouses quite well. Data marts done well can be a good solution for users, though 12 does seem it might be excessive (or maybe not, depends on the data complexities). On the other hand if IT is doing the reports, a single package can be very efficient.

Keep in mind if you put out new packages, you could just leave the old ones out there for the reports that need them. Make your new packages so compelling no one will *want* to use the old ones. You can catch more flies with honey.   ;)

I am not very up to speed on v11 so I will defer to those who are. I do think you should bring up a test instance of it to play with, rather than trying to imagine how it will work. There are a lot of pieces that seem unfinished to me, but only you can determine if that has impact for your organization.

Michael75

Thank you very much for such a considered and helpful reply!

QuoteSo it sounds like you have conformed dimensions and a reasonable underlying data model (data quality aside), and a single FM model with multiple packages - essentially data marts built off a single model. This is a good thing. I should think the core problem is how to move forward without breaking what is in place.

Yes, this is generally the case, and I should have been clearer about it in my original post. For one of the "bundles" (as we call them), both the DM (and obviously the corresponding FM) have had to be completely reworked, and the same will have to be done for one other. But basically, the right building blocks are in place. It's a question of finding the right way(s) to assemble them.

QuoteOptions 2 and 3 are not necessarily mutually exclusive. I think it depends on who will be consuming the packages. If it is end users (self-service orientation), a single package could be overwhelming, confusing, and worst of all lead to incorrect reporting unless they understand working with data and data warehouses quite well. Data marts done well can be a good solution for users

The original idea was for IT to provide a large number of canned, multi-prompt reports. But because the whole project has gone over budget, the number of these reports has been reduced, and self-service reporting has become much more of a priority. Hence our interest in Cognos Analytics.

QuoteKeep in mind if you put out new packages, you could just leave the old ones out there for the reports that need them.
Indeed, there is no need to remap existing reports. Thanks for pointing this out.

QuoteMake your new packages so compelling no one will *want* to use the old ones.
I can assure you that the Cognos developers don't like working with them :)

(../..)

If anybody is able to shed any light on my final point, the multi-package capability in Cognos Analytics, I'd be very grateful.

Michael

cognostechie

As much as I understand , there is a difference in 'Data Items in a Report' and 'Data Items in a Query' when they talk about a report using multiple packages in Cognos Analytics.

What it means to me is that one query can only use one package (till release 3 of ver 11 which is 11.0.3) but it is possible to use data items from multiple packages in one report.  Just imagine that you have four different queries in the same report showing the data from four different angles or even showing data from four modules.
Query 1 can use only one package but Query 2 can use another package. Ex: If you have separate packages for Sales and PO then you can see both Sales and PO data in one report by using different queries.


   

MFGF

Quote from: Michael75 on 24 Aug 2016 10:33:00 AM
If anybody is able to shed any light on my final point, the multi-package capability in Cognos Analytics, I'd be very grateful.

From CA 11 Release 3 you can add more than one package when defining the source for your report to use. The limitation is that a reporting container (chart/crosstab/list etc) can only be based on one package - you can't mix data from multiple packages with (for example) an item from one package in the rows of your crosstab and an item from a different package in the columns. YOu can have two containers on the same page based on different packages though. My personal take on this is that it's a move towards introducing the multi-package support you get in Cognos Workspace where you can assemble report components from different packages on the same page.

Cheers!

MF.
Meep!

cognostechie

I thought that's exactly what I said  ;)