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.

5.9 SP3

I have just finished playing with the latest and greatest hot fix for 5.9, and, after been tipped off by one of the posts on http://forums.pivotal.com, can't believe that the smart portals don't work.

Pivotal have, for all my time working with the product, excelled themselves by breaking bits of the application when fixing another part, and this is something that affects all developers, especially with a complicated application that 5.9 surely is. I have been known to do this myself in the past, and I'm pretty good ;)

The only way to prevent this is to ensure your quality assurance processes and people are up to scratch. There should be a set of simple tests that are done for every release, whether it is a Pivotal release or one of your own, which are conducted in all the release versions you make, before they make it in to production and again as the first thing you do after the production release.

If Pivotal haven't got this process in place, haven't got the staff to do the work, what ever the excuse, then what are we paying our maintenance for? Are we in the wrong to expect a release from them not to break other bits of the application?

I know their concentration must be with Sedna now, but there are a lot of people on the 5.X platform that will be staying with it (and paying their maintenance) up to and beyond the date when support stops, surely we should expect some QA process to assist us going forward? Are they just relying on the likes of you and I in doing the testing for them?

The first thing Pivotal says when I come across any problem is to install the latest hot fix. I won't be doing so in the future unless they can prove my issue has been fixed, and it has been QAd effectively.

P.S. There is a fix for the issue with smartportals, coming in HF2 (SP3 less than a month ago), but if you need SP3 before then, there is a workaround documented here

Error handling

Whilst I, like all of you I am sure, never write code which would need an error handler, I am intrigued on how this is approached across the various deployment I have seen.

Some deployments leave errors in the lap of the gods, and to be honest, the error handler in Pivotal meets a lot of peoples needs. Others rely on logging all errors to an external file, even others create a separate error class in the event viewer to show what is going on.

I just have a feeling that all this error handling adds to the complexity of the situation, and can be the majority of the code.

With the essential try...catch in C# I am coming to the conclusion that it is essential to log as much as possible at the lowest level when an error occurs, as the user never gives us the whole picture, certainly not remembering exactly what they did and copying the error message. A vague 'Pivotal is broken' is the usual phone call I get.

New site

It still amazes me how little I know about Pivotal.

I am on a new site, where Pivotal has been running for some time, and seeing how they have customised and developed their solution gives me new ideas and ways of approaching customisation of the system.

It is a 5.9 Rich client system, heavily customised in most areas, and their use of non OOB functionality is great. What it tells me is that you can teach an old dog new tricks and there is more than one way to skin a cat.

The client is planning on moving forward with 6.0, and I hope to be at the forefront of this development.

RSysClient

Following on from my dig at the amount of docuementation available for Pivotal Rich Client and a users question on the official forum about getting the system name, I thought I would document some of the functions / properties I find useful within the RSysClient interface.

First of all, these are all in the 5.9 API Reference, available from eservice / epartner

API Reference

All these functions are called with the UIMaster.RSysClient. prefix

Properties

SystemName - gives you the bit in the middle of the calling URL - Offline / Production / Live etc
ServerName - gives you the name of the Lifecycle Server - may be the same as the webhost, maybe not
UserId - Id of the current user
UserName - Login id of the current user
EmployeeId - Employee Id of current user
InitialUrl - Gives you the web host

Methods

EqualIds(FirstId, SecondId) - returns true if 2 Ids are identical. You can not do if (firstid = secondid). A common one for me is

if UIMaster.RsysClient.EqualIds(rstPrimary.Fields(strFieldName).OriginalValue, rstPrimary.Fields(strFieldName).Value) then

This check to see if an Id field has changed since the form was loaded.

GetClientScript(ScriptName) - use to associate a script with a button / form / event on the fly

GetForm(FormName) - really useful when you want to execute a function on another appserver.
set MyForm = UIMaster.RUICenter.GetForm(FormName)

myform.execute Function, Parameters

They do this to get employee information (onportalloaded within the CMS)

GetTable, SQLSearch - Really usefult to lookup a value, such as putting in a specific employee or support status

with UIMaster.RSysClient

valueIwant = .SQLSearch(.GetTable(TableName).Fields(FieldNametolookin).FieldId, ValuetoLookfor, .GetTable(tablename).Fields(fieldyouwantback).FieldId)

end with

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.

Search Result Lists

One of the great things that was introduced with 5.9 was the ability to use Active Search Results Lists on a form.

This feature really expands the usability of a form to more than one level, allowing you to display, for example, Contacts associated with the parent and child of the record you are on, support incidents on subsidaries and anything else you can create a query on.

I have recently used this to replace the Show Emails / Show LEs on the company / contact forms to 2 SRLs under the activities listing. This was a useful addition for a client.

Sharepoint & Pivotal

Having run out of patience with users filling up the database with documents, a client has requested to link Pivotal with Sharepoint.

This became my first delve into webservices. The project involved creation of a sharepoint folder and subfolders whenever a company was created and displaying the result in a websegment. The issues I faced where mainly not understanding the webservice requirements, but a few days of playing with them got it working.

I then had to do a mass production of folders for the existing companies, by calling the .NET appserver rule via an agent, and seems to work reasonably well.

Things that I still need to include are code when the company changes name (creating a new folder, moving contents of old folder, then deleting the old folder) and security. It may be necessary to prevent certain users adding additional folders and seeing the contents of the folders I have created, but that is for another day.