It really happens that I get questions from customers who own/develop their own application - asking on what the developers can do to actually make transaction identification under APM CE easier.
To understand the working of the TIM, let's take a simple example. Imagine you have a web-site, and on the website the developers have decided to have all application groups and actions defined as below:
- mod: Every sub-function will be define by the module name. Example: faq, blog, content, budget etc.
- op: Main operation this sub-function will have to deal with. That would be save, edit, display, view
- addon tags: They add specific functionality, usually to define the a function like print, popup, expand to show all content etc.
Now - every time one of these modules will be executed - this application will show what is being called by these tags.
For simplicity, we are using QUERY variable tags. POST variable tags can also be used. It does not matter.
Example:
- module "FAQ", Operation "List" will result in a URL with at least: '?mod=faq&op=list'
- module "blog", Operation "view", tag "expand" will result in a URL with at least:
'?mod=blog&op=view&expand=set'
In the APM world, we as admins would configure in the transaction discovery the Query parameters mod, op and the addon-tags to be optional entries - to be detected like expand, popup and print.
By choosing this combination - the transaction discovery would detect all transactions with existing query parameters matching mod and op and the optional parameters which are added. it will then create a transaction name which will look like: "mod=faq&op=list&expand=set". If one had filtered the traffic, one other parameter would show up in front - and the more complex this transaction is, the longer the generated name will be and with its complexity increasing become unreadable
Note that transaction definition names names are limited to 50 characters! Once that limit reached, the name is trimmed to that length. Transaction names which have differences after the 50th character can't be distinguish anymore.
So - this to understand how CEM/TIM works and how the system identifies a transaction. But keep in mind that usually it takes us Admins a while to first identify the transaction identifying parameters. And then to applying these to the configuration can become quite tricky because sometimes we need to use a combination of various parameters and regular expressions which identify this transaction call uniquely.
The easiest way developers can help us CEM Admins is by actually just adding one specific header to the HTTP response - the "page identifier". It actually is quite easy to actually do that.
Just add one HTTP header tag called: pageID (Or any other name), and on every page call add the page identifier to it.
For the previous 2 examples, you would have respectively
- "pageID=faq_list"
- "pageID=blog_view_expand"
These would be 2 page identifiers - and every time the combination of example 1 or 2 is being called, it will be detected.
If now the customer wants to also identify the server it has been executed on, they can also add a Server Tag - Like Serv1 or Serv2 into the associated variable, making the Page ID look like: "pageID=Serv2_blog_view_expand"
Note that as this will result in very simple transaction definitions, it will also save a lot of resources and enable the TIM to monitor even more traffic. And in the long run make managing the CEM transaction configuration a very easy task.