When should you write a trigger?

triggers

#1

When should you write a trigger? When do you have to write a trigger? Valid questions, worth some discussion. I don’t pretend to know all of the scenarios, but here are a few off the top of my head. Some other folks out there will surely have more.

Here’s a pop quiz:

  1. You want to graph a particular URI’s transaction rates over time. Do you need a trigger for this?

  2. You want to show the full Database query and how long it took to respond. Do you need a trigger?

  3. You want to define an application.

ANSWERS: 1) Nope - a custom page can do this easily. 2) Yes. 3) Yes, but it’s really trivial.

The first part of knowing when to write a trigger is figuring out your use case and then doing it with native functionality, like #1 above. Sometimes you’ll need to use a trigger, often times not.

A general rule is this: if there is a custom view that you want in a chart, chances are high you can do it without a trigger. Just make a custom page, drop in your charts and you’re done.

The flip side is this: When you want a custom metric, application, or protocol you’ll need a trigger.

I’ll walk through an example of each to try and gel the idea:

– A custom metric is, say, combining Citrix web login times with a published application’s load time. You’ve got two independent things, but you want to create something particular from them. Trigger, all the way.

– An application requires a trigger because we allow you to define an app from, well, sort of anything in a flow. A great example is a basic web app. You’ve got some FQDN or path that you want to carve out into an app. Easy as pie - it’s a one-line trigger. But a more creative example is the “trouble DNS” bundle that of our smart folks rolled together. It’s really clever, but also simple: create a list of DNS queries that tend to be problematic and create an application from them. It’s its own reporting object in our UI now…

– Custom protocols: By far the best example I can think of with this is the CICS bundle that one of our SEs (Kanen) put together. Many things use HTTP for layer 7 transport these days, and CICS is one of them. So he essentially created a new protocol parser, right inside of triggers. (PS: If you’ve got a custom app protocol that uses HTTP for transport, let us know. Chances are extremely high we can write a quick trigger and get you visibility and insights you’ve never had before).

I hope this helps. Please chime in with better examples - I’m positive that this post can be improved upon :slight_smile:


#2

You can also do #1 – graph a particular URI’s transaction rates – with a dashboard and drilldown by URI.