2

while playing around with push upgrades I also investigating how to deal nice with "manual" upgrades.

Background: I found it difficult in the past, to get the feature PUSH-MAJOR-Upgrades (https://developer.salesforce.com/releases/release/Winter13/PUSH+Major+Upgrade?language=en) enabled before passing security review... But I need it especially in development phase, BEFORE passing the review, to keep the testers up to date without annoying them. And even if PUSH-MAJOR is enabled, in some scenarios manual upgrades are better. BUT there is a problem: clients won't be notified when you publish a new version. So I thought it should be easy to check and provide a hint in the app. Like most desktop apps do it: check for updates. Not easy in SF... (or I did not found it)

My goal is:

  • A: dynamically get the current installed version of a package
  • B: dynamically get the most recent version (details-tab @ appexchange-listing)
  • C: if(installed version < most recent version) offer clients to make an update

actually all but C seems hard in SF... so even A seems not to be supported out ouf the box. Being sad, I found a hackish solution I can live with for a while:

PageReference p = new PageReference('/0A3');
String html = p.getContent().toString();

I parse the html and I got it in the end. If you are interested in the full code: I'll happy to provide, but its not beautiful. If anyone has a better solution for that, it would be very welcome!

But B seems to be harder... I am looking for a way to determine the most recent available package displayed at the Details-Tab https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B5SYEEA3 A clean way using an API I was not able to find. Very sad and going hackish again, it is not possible to reuse the trick form A, because the Detail-Tab will be loaded by AJAX here. Now way to get it with getContent() Sniffed also a bit into the POST of the ajax call. They use Viewstate :-( to submit params and wierd A4J.AJAX.Submit() calls to get the tab. Also the use Sarissa (abiss.gr) which I have no experience with. But the response of the ajax contains exactly what I need...

So is there a better approach to get info about package versions? If not, anyone crunched it the hard way?

Or has (in the end) anyone experience in how to convince Salesforce to enable PUSH-MAJOR before passed security review?

Thanks Uwe

Improve this question

1 Answer 1

Reset to default
3

On A, System.requestVersion called from code contained in your managed package gives you the version number of the managed package.

On B, assuming you are using the License Management App (LMA), the managed package versions are all represented in there. (PPS But not the patch part. So if you need that you will have to say manually set a static variable in an Apex to the patch number as part of the patch creation process.)

For a different purpose than this, we added a Force.com Site to our LMA org to provide no authentication access to a single REST GET API that our application calls. This is just 50 lines of code using @RestResource, plus a similar amount of HttpRequest code at the client-side (your app). You also have to add a Remote Site to your app to allow the access.

You could add an API in the same way to provide the latest managed package version number of your app - PackageVersion is a child of Package - see e.g. License Management App 2.1 Administration and User Guide.

PS Uwe correctly points out that the page version value shown by the LMA is the manually assigned version - Salersforce's example would be "Summer '14". We already include SVN version numbers in that field, and while manually adding the major.minor.patch number there too (inside some easily parsed delimiters) is a bit annoying it would make those numbers available.

Improve this answer
9
  • On A) System.requestVersion() brings only [Major].[Minor] but better would be [Major].[Minor].[Patch] and if present [Beta (Number)]. At least the PageReference('/0A3').getContent() provides it ALL - even if it is such a shame to use it the dirty way...
    – Uwe Heim
    Jun 29, 2014 at 11:59
  • On B) also at sfLma__Package_Version__c there are only sfLma__Version_ID__c and sfLma__Version__c. The ID is not usable, and the sfLma__Version__c is not in the [Major].[Minor] format. It contains only the marketing-name, like "Summer'13" - which is not very useful and not compatible with A. Here again [Major].[Minor].[Patch] [Beta(Number)] would be the perfekt - [Major].[Minor].[Patch] without beta would be usable.
    – Uwe Heim
    Jun 29, 2014 at 12:05
  • The approach via Site is very cool. Even if at the current stage it does not solve the version dilemma, it is a great approach for other things I have in mind ;-) thank you very much for that trick!!
    – Uwe Heim
    Jun 29, 2014 at 12:09
  • @UweHeim On A) I assume that the patch number would be included (if there was a patch number). Do you have evidence it wouldn't be? On B) good point. But as the version string is anything you want it to be you could impose your own convention and include something like "(Major.Minor.Page.Beta)" that you could easily parse out.
    – Keith C
    Jun 29, 2014 at 12:13
  • a) I verified the absence of the patch in my patchOrg - its really missing :-( Also in the manual you see "Returns a two-part version that contains the major and minor version numbers of a package." so it is really only Major.Minor - sad but true...
    – Uwe Heim
    Jun 29, 2014 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.