Big uses from a small feature
There’s a little, unnamed feature in Web Intelligence’s Query Panel that often goes unnoticed. OK, it does have a name – it’s called “Change Source”. But that name only shows up in documentation. On the Query Properties pane in the Query Panel, the feature is invoked from a button labeled “…”. This post will show how no-name features can be surprisingly useful, and perhaps point to a completely different usage scenario from its typical use case.
For those unfamiliar with the feature, its usage is critical when you move WebI documents between Development, Test and Production environments that each have different versions of the universes for a particular data source. Here’s how easy it is to use this feature.
- Open the Web Intelligence document
- Click Edit Query
- View Query Properties
- Click the Change Source button to view the “Change Source” dialog
- Ensure that the relevant objects from the source universe are mapped to those in the target universe
- Click Run Query
The report, using the context of the new objects from the newly invoked source universe, maintains the integrity of the report layout, its calculations and variables, the sections, the ranking, conditional formatting (“Alerters”), the input controls, etc.
In step 5 above, note that the objects are automatically mapped between source and target universe by their names.
“Quantity sold” measure from the source universe gets mapped to the “Quantity sold” from the destination universe. Occasionally, the source universe relies on some objects that are named differently than the target universe’s objects. Of course, the user experience suggests the appropriate objects in the target universe based on the names, but if the name doesn’t match between the source and target universes, the dialog suggests that the objects are “ignored” — meaning the report is modified to ignore the existence of those objects in the report based on the new, target source. However, notice the new “…” in this dialog.
The user can define the objects that make sense. As an example, while the object “State”, used in the source universe, is no longer a name used in the target, the user can still point to a relevant object in the target. Simply click on the ellipses to the right of “remove result object” and select, for example, “Country”.
This gives quite a bit of flexibility to the Change Source feature. In fact, it opens up interesting possibilities. Let’s say that the report using that source universe was written for a universe on top of the Sales Database. It’s got a bunch of formatted, aggregate tables and charts, some ranks, and two or three report tabs of details sliced in different ways and sum calculations. In other words, a kind of generic report. But nonetheless a report that involved quite a bit of thought and formatting effort.Now, think about changing from the source universe used to define the report, not to a variant of the source universe (e.g. from eFashion Test to eFashion Production), but to a completely different universe. Why not take that fine-tuned WebI document created for the Customer Database and remap it to the Sales Database? Or the HR database to the marketing database? After all, there are often MANY types of content which are conceptually the same – dealing with geography-related objects, time-related objects, sales measures, etc. Like with DNA in humans, this is a kind of BI content “DNA” that is shared across the many report domains, oftentimes with only minor differences.
Admittedly, instead of remapping a handful of objects because of some name changes, all the objects are different and need to be remapped to the target universe. And true that some from the source universe might no longer be relevant. For example, if the document used “Day of Week” from the source universe, but the destination universe only has the concept of “Month”, then it will have to be “ignored” during the change source.
Keep in mind, however, that the DNA of the reports is often more similar than it is different. Not to mention that there is a lot of work that goes into the layout and formatting. If you have to rework 20% of the report – add in new objects that fill out the context of the new source, change or remove certain calculations, put in a different header/footer, expose prompts a bit differently, etc. – it will often be worth the small updates, rather than starting from a blank slate. It might also provide new insights for new metrics across business domains. A variable from a customer report that is used to measure their “churn rate” for customers can, once mapped to a universe from the HR database, be used to measure “churn rate” for employees. With Change Source, the objects used for the functions just get slotted into the appropriate place. You’d be surprised how many calculations are common between documents serving different domains.
Another use for this feature might be for very fast BI prototyping. The Supplier department wants to get more fact-based information for their decisions, but doesn’t yet know what they want to track? Grab that report for Manufacturing, do a quick mapping of objects to the Supplier universe, and give them a nicely formatted report to solicit their requirements for a more formal report.
Will this always work? Of course not. Moreover, this approach to remapping universe objects between domains will sometimes be completely irrelevant. But next time you embark on a blank slate creation of a report that reminds you of something you’ve already done, find that pre-existing report and see if you can save some time.