CS Package - upgrade existing solutions


For custom solutions implemented in Customer Service we usually create a package to be added to the customers installation. Only we hit an issue when want to upgrading the package, you can't easily do this by uploading a new version and then overwriting the existing scripts etc. We now manually copy over the changes, which is error prone and now something we can automate.. (see online apps, automatically provision the customer)

Ideally it would be great if we could upload a new version of the package (with an increased version number) which will overwrite the existing code, and also have the possiblility for an upgrade script (just like the install script) with the possilbility to get the existing version from a variable (getVariable("currentPackageVersionNumber") so we can create upgrade logic.



RE: CS Package - upgrade existing solutions

Hi David,

Currently only option for "upgrading packages" would require some manual steps.

  1. Uninstall old package (deletes all screens and scripts)
  2. Upload new package
  3. Install all elements

Important to remember

  • ID's of scripts and screen definitions will change if element is deleted and added again, always refer to screen definitions and scripts using idString and includeId.
  • Scripts used thru customer centre with parse/safeParse uses access key, this will also change so implement some function to load key automatically.

Package system is somewhat lacking in this area, please feel free to register a wish highlighting real-life scenarios for usage and requirements.

Von: Michel Krohn-Dale 18. Feb 2020

RE: CS Package - upgrade existing solutions


A wish based from my experience would also to be able to add trigger-scripts to a package. Right now that kind of object is excluded from being able to be added to a package.

I assume this have something with the fact that trigger-scripts technically are stored as "hidden" ScreenChoosers. But as ScreenChoosers per se is a supported object in the package system, it shouldn't be too impossible to be able to add the addition of  being able to add trigger-scritps as well to the package system I think.

Is there any plans on implementing support for that?

Right now I have a best practices where I try to only have an "#include"-part in the trigger script which points to an actual script that contains the trigger handler. This to make sure that as much as possible of the actual solution is possible to be contained in and deployed using a package.

For version handling of trigger scripts I have used a sql-script onsite to export screenchoosers of a specific type to XML-format. The "type" is based on inclusion of screenchoosers that meet a certain name-standard that I use.

So, something like:

FROM crm7.screen_chooser sc
WHERE sc.description like '%trigger%'
for xml auto, elements

But it would be nice to be able to have everything contained in a package. :)



Von: Marcus Svenningsson 27. Feb 2020