The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

Salesforce Managed Packages

with 13 comments

This is one area of the Salesforce.com platform that I’m no fan of.

In short, you code a complex application and it’s beautiful. You marvel at the wonder of the sleek UI, the intelligent complexity of the code, and the comprehensive unit testing you’ve implemented. Now you wish to package your application up, advertise it briefly and have the customers pour in. Not so fast my friend.

Packaging can be a nightmare, and there are certain hurdles to this step that you won’t find officially documented. A few things you may want to consider:

  1. Never, I repeat never hardcode the name of a VisualForce page, class, or custom object anywhere in the code. This one is pretty standard in programming best practices, but it isn’t that obvious on the platform. This is because your code will work PRE-packaging. No checks are performed during packaging, but once(or should I say if) your package is deployed you will be privy to number of buggy areas should you not adhere to this rule. This is a side-effect of managed packaging. Once your code is moved into a managed package all class, objects, and package are automatically prefixed with the package namespace so any hardcoded references to these areas will cause the deployed application to fail.
  2. You must not qualify field names with the object name in SOQL queries otherwise you will receive errors stating that Salesforce does not understand the reference to said object. This is some sort of crazy inconsistent standard in the Salesforce system e.g. Select CObject.name From CObject Where CObject.id=.. will cause a managed packaged apex class to fail. You have to remove the field qualifiers so that the code reads thus, Select name From CObject Where id=.. This makes me a bit unhappy as it is not obvious, can waste a significant amount of time, and can make code less readable.
  3. You want to package what?! You have to pore through the documentation on packaging to find what is and isn’t packageable. The general rule I follow is, if it doesn’t explicitly say it’s packageable, then it probably isn’t. This can be painful, especially for areas such as profiles which are,let’s face it, a pain in the bottom(euphimism) to setup. Oh sure you can ‘map’ them onto an existing profile, but only a bit of them.
  4. Ever seen this exception before: MIXED_DML_OPERATION ? Neither had I until I started packaging. If you’re like me(6″ tall with green eyes) then you probably run all of your unit tests with Eclipse. Thinking my code and testing was flawless I begin the packaging process, and only then did I encounter this error. It seems that it only occurs within the browser testing environment and hotdang is it a pain in the bottom(again, euphimism). The error occurs because you try to perform DML on a ‘setup’ and ‘non-setup’ object in the same ‘context’. This is documented on page 483 201 subsection 6b paragraph 2 of a salesforce document somewhere on the interweb. Well sortof, because the documentation does not tie said error to said solution, and the solution has a bug. Figures. If you do come across this issue, the only real solution can be found on the discussion boards, and boy is it a doozy.
  5. Don’t even get me started on Sites packaging. Bleh.
  6. There is no way to log what happens once a package is installed. I had an experience in which an area of my application was failing only when installed from a managed package and had absolutely no way to tell at which point the code was failing. After some rather helpful communication with Salesforce I was told that there is a bug where in certain cases not all page/class/object references are correctly prefixed with the namespace, causing errors such as mine.

It’s not all gloom and doom ladies and gentlemen. Packaging is a relatively young area of the Salesforce.com offering, and all in all, once you have all the kinks worked out, you can install a package in a matter of hours.. a great improvement on the traditional months of deployment offered by most ERP and CRM systems.

About these ads

Written by Wes

June 6, 2009 at 4:38 pm

13 Responses

Subscribe to comments with RSS.

  1. OMG… we soooo hate mPacks here.

    Less

    September 3, 2009 at 5:39 pm

  2. I am hating this right now…

    MoronGroover

    September 16, 2009 at 10:37 am

  3. Good read! Well said.

    Mark Lapasa

    October 28, 2009 at 9:37 pm

  4. Is it possible to get mpackages to work w/ Sites? Has anyone accomplished this ever?

    d3developer

    March 11, 2010 at 12:42 am

    • It is VERY tricky, and it will require a large amount of your effort for those pulling the package into their Orgs mostly because of packaging limitations; the biggest of these being you cannot package sites grrrr.. so short answer is yes, but with a large amount of post installation configuration e.g. create the site, setup profiles and if you use customer portal then it gets trickier. Good luck.

      Wes

      March 11, 2010 at 10:21 am

      • The one thing I could never figure out how to do is use a separate template in a different org with a page that was part of a managed package. Have you gotten that to work?

        d3developer

        March 11, 2010 at 5:45 pm

      • Never had the situation myself, but if I were to hazard a guess I’d say that the code inside of a package can’t peek out, but code outside the package can peek in. Just a guess though.

        Wes

        March 11, 2010 at 6:33 pm

      • Since I’m back here…

        Solution: use a custom label to refer to the template name.

        d3developer

        July 27, 2010 at 8:49 pm

  5. “I had an experience in which an area of my application was failing only when installed from a managed package and had absolutely no way to tell at which point the code was failing. After some rather helpful communication with Salesforce I was told that there is a bug where in certain cases not all page/class/object references are correctly prefixed with the namespace, causing errors such as mine.”

    I’m hitting the same bug, and I can’t find resolution on the forums… were you able to get this taken care of? I’m ready to go postal at SF headquarters. :)

    Matt

    July 27, 2010 at 7:39 pm

    • That’s still happening? They said they’d fixed it in a release last year some time and that did it for me. I’m afraid you’ll have to push it through your customer relationship person at SF. I feel your pain.

      Wes

      July 27, 2010 at 8:00 pm

      • I’ve got a juicy managed package that gets an internal server error on upload. No other message. Been w/ Tier 3 support for over a week w/ no response….

        Gar!

        d3developer

        July 27, 2010 at 8:03 pm

      • Actually, it appears that it *wasn’t* the same bug. The namespace doesn’t get added to references that aren’t part of apex components, though it seems as if it was working fine before. Perhaps it’s a bug, or just a limitation that I haven’t seen yet in the docs. Either way, the solution for me was to set a public property in the constructor that referenced the StandardController.getRecord(); then I was able to access it from the installed managed package just fine.

        Kudos on a great blog, mate!

        Matt

        July 28, 2010 at 9:57 pm

  6. Good Info,just i want to clear out myself,as i have done managed packaging for my app ,and found many bugs once i installed in the test org.Now i want to change the field-type in the objects,its restricting me soo cant we change the field-type once we are done with the managed packaging.

    Please anyone suggest me the solution to get ride of this error..
    Its an ugent requirement.

    Atif Mohammed

    August 30, 2012 at 12:03 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 2,202 other followers

%d bloggers like this: