Activity Usage Monitor

A positive post, for a change.

I have just watched the recorded webex from Pivotal on Activity usage, available on the link below

http://cdcsoftware-marketing.com/mk/get/WE-CM-ACTIVITY-USAGE-MONITOR-NOV-11-LONG

This is the stuff I wished there was more off. Yes, it is an add-on that you have to pay Pivotal a bit of hard earned profits for but it gives you an idea of what is possible within Pivotal 6.

The Activity Usage functionality, I presume, adds code to the events when certain things happen in your system – ReportRequest, SearchLoaded etc, and then stores in a table what, where & when so you can make some pretty pictures from the data added to the tables. I am sure there is a lot more to it than that, Pivotal have to earn the cost of the add-on for something. I am also positive that a good developer will be able to create this functionality, and add more detail, with ease.

Often I see client & server side logging of information, mostly for debugging and error capture, but this takes it one step further. Want to know when the last time a piece of functionality was used? Bring up a graph and take a look. Users complaining that a report or search is taking too long? You now have the figures to prove it is not the system, it is the fact that they are using search conditions that make the search take an age (wild card searches for example in a large memo field). It also gives you an insight into where to improve performance, adding indexes to tables or search terms that are frequently used. You can now make informed decisions where to spend your development budget from the areas that are constantly hit, rather than who kicks up the most fuss.

I just hope that it is coded in such a way that performance is not degraded significantly to make the use of the tool a detriment to the users. Have Pivotal produced figures to show the change in performance by using this tool?

It is a lovely piece of functionality. Do I encourage anyone to buy it? Depends on the cost (something that is not apparent in the Webex), if it is less than 3 man days of developer time, then no. That is the time I would estimate to do this in Pivotal 5.9 or 6 on my current system, it may take more or less time on your system, but this is a good ball park figure for anyone.

To Customise CMS or Not

I have seen a lot of discussion recently on whether to customise the Out-Of-The-Box (OOB) functionality directly or not.

What I mean by this is whether, as a customiser, you should edit what is given by Pivotal (in terms of Client scripts / App server rules / table fields / queries) or should you create your own, using the base as a reference or even referencing them directly with an additional layer (for Appserver rules). There are Pros and Cons for each method, which I hope to summarise below, so you can make your own decision.

Direct Editing of OOB

• PRO: Quicker turn around for any code changes (as you don't have to create anything you don't have to)
  
• PRO: No additional dlls to cause issues
• PRO: Speedier performance as not calling 2 dlls to do the same function
  
• CON: Upgrades are more difficult, as you need to be careful not to replace any customised code
• CON: Difficult (unless properly documented) to know what is your customisations and what is OOB when something is wrong.
  

Adding to OOB

• PRO: Only use the bits of OOB that you need : if you don't want to use the OOB method for delete contact, implement your own.
• PRO: Distinction between what is your customisations and what is OOB
• PRO: Upgrades / CMS Hotfixes are easier to implement as you have not touched the OOB.
• PRO: Ability to use .NET Appserver rules for customisation even though the OOB is VB6.
  
• CON: Why alter things that are not broken? If you need to change the save form call in an Appserver, you will also have to provide functionality (or at least pass to the OOB) for Add / New / Delete / Execute etc.
• CON: Slower execute time as you are calling 2 dlls to do the same functionality that can be achieved by one. This is a negligible one now adays, but worth considering if you are doing frequent calls to an Appserver.
  

I admit that I am firmly in the Adding to OOB camp, as I believe the benefits far out way the negatives. This is also the Pivotal method. Not saying this is correct, but I always take guidance when it comes to the customisation of an application from the writer where I can. The time taken to create a pass through Appserver rule in .NET or VB6 is negligible, and I would rather do this than comment out huge chunks of code that I don't want.

I also apply this rule to Client Scripts / Queries / Forms etc. The first thing I usually do when customising for a client is take a copy of the Contact form, save it as Company Name Contact, and update security so the new form is the default. Same with the Form script and any scripts I need to alter that are referenced by the form. The Appserver, I will create a Company Name Contact .NET project and pass through to the original for all the methods (SaveForm, AddForm etc).

Hope this helps with any new people starting up in Pivotal development.