Triggers are widely used across many Cognos environments, particularly larger ones where reports are often scheduled based on one or more dependent events being completed. These events are typically things external to Cognos but required by it to complete a scheduled event. An example would be to run reports based on the successful update of the data warehouse. If the reports were simply run on a time schedule it’s possible that the reports could kick off before the data warehouse update was completed rendering the reports useless and requiring a rerun. Tying report execution to a successful update of the data warehouse insures that they will only be run once for a given cycle.
Creating triggers is reasonably easy once the Cognos environment has been enabled for this and the trigger has been created and tested within the warehouse server. It only needs to be given a name and entered into the schedule for one or more reports on Cognos. This is a great feature since it enables things to be done much more efficiently within Cognos while at the same time tying in external events for operational effectiveness.
What often happens over time as things change is that triggers accumulate and get created with a multitude of different names. And since there is no way of easily identifying objects using triggers within Cognos, or the names of the triggers, or where the same triggers is used multiple times, this can be a real problem when changes occur.
To successfully deal with this we created the capability within our NetVisn product to better manage triggers across the Cognos environment. We wanted the ability to manage triggers in a manner that gives the NetVisn user the flexibility to easily get the information they need at any given time and at the same time get this information output in a way that best meets their needs.
Thus, in figure 1 we have the ability to choose what we want and how we want it organized. We can select all triggers or specific triggers that exist in our environment. We also have the ability to determine if we want the output organized by location, trigger name, package, etc.
We also have the ability to get a total count of triggers, a count by trigger name, etc. Additional detail data such as creation date, enabled/disabled, etc. can also be selected. In an environment with a large number of triggers having the ability to get the specific data needed on triggers is critical.
Figure 2 shows the analysis options we’ve selected along with a total count for all triggers in our environment.
Finally, in figure 3 we see eight of the triggers organized by trigger name along with along with other information on location, creation date, package name and its status. Note that one of the triggers is currently disabled.
Triggers are one of the most useful things that exist for managing events in any Cognos environment. In fact, without them many things currently being done would not be possible. But since change is part of every environment, triggers need to be managed effectively and that requires an ability to access them quickly, easily and selectively whenever needed. Having the right tool with which to do this makes it virtually painless.
© Envisn, Inc. – 2019 – All Rights Reserved.