The New Year

Apologies for taking a time to post again, been a busy month for my family and I, and work has not been too good for taking a break as usual ;)

What are my hopes for Pivotal in the New Year?

Well I hope Sedna is as good as it promises and is not too buggy. I am expecting lots of little things that will only come to light when someone develops in the environment in anger. Lots of 'I can do this in 5.X, but can not seem to be able to do the same in Sedna', which happened for me moving from 3 to 5 to 5.9.

I am looking forward to working with Sedna, and hoping (a bit of a desperate hope I admit) that the documentation is up to scratch. Just a quick 'This is the stuff that is new, look at the one I made earlier' would be good, as in point the developer to OOB scripts that use the functions that you are documenting. It is so much easier to see a line of code in 'action' rather than making sure you are using the right object, have instantiated it properly etc etc.

From my previous rants, you will know that I want Pivotal to market themselves more effectively. I have invested a lot of my time and career in this product, and I want it to evolve and have more installations. Stagnation will happen if the thing doesn't sell.

I am hoping to have a play with the Pivotal AppServer Rule Conversion Tool (PACT) recently announced in the next couple of weeks, but don't hold out much hope. I am finally comfortable with .NET ASRs and know how different a VB6 one is. It may be converted, but it certainly won't produce streamlined code.

Ho Ho Ho

Hope everyone has a good break, whether they celebrate Xmas or not.

Here's to a great 2008, and hope it is a succesful and happy one for you and yours.

Piv Dev

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

Sedna Webcast Part 3

Having watched the Sedna webcast yesterday, I was disappointed.

Firstly, I was expecting some more insight into how the development was progressing, and got very little. This was more than likely because my expectations were not met. The first line in the invite was New Capabilities in Sedna Drop 5. Not sure I saw anything I did not know before.

What the webcast (Webinar was the word they used, but I hate this word with a passion. The Americans have a lot to answer for the words that they have introduced to our vocabulary, leveraging is another word that I can not stand.) did focus on was Migration strategies, and this bored me to death.

I think the simple strategy for WAM customers is 'Don't migrate'. They kept mentioning their 'Inexpensive' off-shore professional service which would convert your WAM customisations to Smart Clients, but I can not see this working for many customers. I would rather manage this transition myself with all the heart ache and cost it would involve.

Rich Client customers - there is a point. Hopefully being able to re-use some of your VB 6 code will assist in this process, but there is still a lot to do. Pivotal showed us the Active Form to Smart Client form conversion, but the end result was hideous. I think that businesses will use this as a starting point, but I think they will have to redesign the forms significantly to make the users think they have got something from the effort they have put into upgrading.

Another point they emphasised is the difference between conversion and migration. Conversion being a re-write, migration being re-using your business logic in the new Smart Client. Both methods fill me with dread, and will be expensive, particularly in the regression testing that will be required. The tweaks they stated would be needed for a migration will be more than a simple tweak, if you don't want the end application looking hideous.

I think the 2 days migration time they quoted for a system that has had minimal customisation is a joke. For any of my customers this would be a significant project, taking months of effort to test and deploy.

Don't get me wrong, the deploy and wait for mobiles / satellites PBS is a good idea, and one that I fully support, as well as the ED migration tools and Agent explorer, but I will wait until I get my hands on it before passing judgement.

I am not sure that any user will be upgrading in February. I certainly won't recommend taking this leap until SP1 is out. But I am also hoping that new customers will be willing to go to Sedna rather than 5.9 early in the new year as from the previous webcasts it looks good.

Role on February (more likely March or April!)

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.

A Thanks and documentation

Thanks to Mr Kwiecinski for posting a link on his excellent forum (see link to right) to my lowly blog. I am astounded that a little mention such as this has resulted in people viewing my diatribe from as far away as Japan and New Zealand.

Also, a quick comment on his comment on my last post - heartily agree. As a partner, I get to see more that is coming from professional services than ordinary users, but this should be shared more. Allow users to play with bits, but have a one off charge to send them the code. This way the PS development can be charged for. The resources and examples out there are huge, but you need to know what to ask for and have a friendly Pivotal contact.

Last thing - when are Pivotal going to sort their documentation out? Don't get me wrong, the documentation is a lot better than back in the AA3 days, but there are still things that are not documented. How about a code sample in the API Reference for each function? What about ensuring the fields that are passed are explicitly labeled within the API?

Rant over, back to work.

Small World

Even though the Pivotal product is not widely used, it still surprises me how small a world is, well in the UK anyway. I often here about developers / consultants moving between companies, companies moving between consultancies but there still is not a lot of new customers (to my knowledge).

This is a worry, for a consultant like myself, with the knowledge that your key skill has a limited number of clients. I have always been critical of Pivotal's marketing strategy. Pivotal should be capitalising on it's key selling points - flexibility and stability. When Pivotal is installed at a customer site, the clients I have spoken to love it. It can do all they want, with the ability to expand to all they will need. Can you say that about MS CRM / Siebel etc?

I think Pivotal have missed a trick here, and hope (selfishly) that they start getting more clients soon. I know Sedna will hopefully be a huge step forward but please Pivotal, open the purse for some decent marketing.