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.

Data Importing

Just been working for a client on a data import. The import had to read a flat file but produce a primary and several secondary records depending on the data involved.

I toyed with an agent firstly, but this is really restrictive when it comes to adding secondary data, without having the initial load of the data into a temporary table, and then having the agent go through the temporary table and complete the secondary tasks.

My solution was to use a pivotal agent to call a method on a c# appserver rule. The main dll is not transaction dependent. The code reads in the file into a data table (thanks to Andreas Knab's blog, this is childs play) then for each row gets together the information for a new or update to the main table. The code then calls another ASR which is within a transaction and returns the new or updated record id, which is then used to create secondary records using the same principle. Errors are collated in an arraylist.

At the end, the errors arraylist is written to a file to check the import, and we are done.

What impresses me is the speed of adding / processing records within c# compared to similar code within an agent. The c# code takes minutes to update / create 1000+ records. An agent would take considerably longer on the same specification machine.

One thing I have learnt is the use of transactions. I originally started with one appserver, which would fall over when the number of records added reached 200+. This was due to the transaction not being able to be expanded, and hence at this point all the modifications were rolled back. By creating a wrapper around the transactional appserver, the transaction is only around one update / insert. If the code does fall over, the records before are all saved and you don't have to start again.

My offline task now is to create a more generic update. Use a config file to determine which file to import, what the columns map to as well as any linking required / conditions. This seems simple enough, but I think it will be down to the syntax and flexibility of the import configuration whether it is a real benefit.

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.

First Post

My first post.

Thought I would share a few things about myself.

I am a Pivotal Consultant / Developer who has worked mainly with Rich Client since Active Access 3.1. Have a good understanding of all client / server development, including integrations and other things.

Worked originally on the client side, as a developer / system admin, but moved to a consultancy, 4 years ago now, have just moved again to another consultancy.