Press ESC to close

Handling SFDC Managed Package Namespace Prefix with Web Service Clients !

This post tries to cover a common night mare while developing solutions on top of Salesforce using Partner/Enterprise WSDL web services. So this post can be super helpful for developers working with following technologies with Salesforce Partner/Enterpise WSDLs.

  • Java/J2EE/Spring, .NET, PHP, Perl Clients

  • A Flex application rendered inside a Visualforce page.

  • An Adobe Air desktop application

What is this Web Service issue ?

We (developers) usually develop our Java, PHP, Flex or .NET client code to make web service calls on the development org. But once the product comes close to release, we usually create a “Managed package” for it. Once managed package is created  all the CUSTOM Sobjects, Fields, etc gets a unique “PREFIX”.

From here (after getting the “prefix”) starts the real pain, all your “web service client code” that was working fantastically stable, bursts up on the very first and every consecutive call. Only solution to this problem is the web service client code needs to add the package prefix before every Sobject and Field names. But the equation becomes complex if the same code is running across a scenario where you can work with both prefixed and un-prefixed orgs. For ex.

  • Your development org is not prefixed / un-managed. So everything is available to web service client code un-prefixed. 

  • You push/deploy code(using Eclipse/ANT) to a QA org or STAGING org for testing, that is un-managed. But this org has an org wide prefix “qaorg__”. So this will prefix everything with “qaorg__”. Lets name this org as “QA” 

  • You create a managed package with prefix “mpac__”. This package will of course get  installed to client orgs or managed package testing orgs. So here everything will get prefixed by “mpac__”. Lets name this org as “MANAGED”

  • Now your web service stack has to deal with each of these orgs. So you can get any of these prefixes i.e. “no prefix”, “org prefix” or “managed package prefix”.  

How to crack this PREFIX problem ?

A couple of solutions are possible, please suggest if you have any other ideas.

  1. Create a new release of your web service client app for each package prefix. So

    • Java guys can have some ANT build properties to release an EAR or WAR file for each package prefix. Though maintaining different versions of same application might be hard.

    • Flex/Air/PHP code, it might not be an easy solution, unless you have already TOKENIFY all your .as, .php files to have all SOQL/SObject/Fields some token like “TOKEN__” before Sobject/Field/SOQL access. So for release you can run some file string replacement tool to change tokens and create a build. But this doesn’t sounds good to even me, and it can be super buggy 🙂

    • I will give this solution 2/10 marks.

  2. Using Custom settings to have the package prefix

    • This custom setting will have only a single field like “prefix”

    • This custom setting will be packaged(managed) separately from the main product. So your product can depend or assume that prior installation you have the custom setting managed package installed always.

    • You web service client code will first query for this custom setting to know the right prefix for an Org. Once that prefix is queried, all SOQL, Sobject and field names should be prefixed by that.

    • I will give this solution 3/10 marks.

  3. The 9/10 marks solution: Using “describeGlobal()” call via Partner/Enterprise WSDL to figure out the prefix dynamically and using that for prefixing the SOQL & Sobject Name/Fields. This solution is elaborated in details below. Note : I didn’t gave full marks to this solution, as I want more feedback and better/dynamic ideas if any.

Using “describeGlobal()” to determine the correct package prefix !

describeGlobal() call gives you a list of available objects for an organization. So one can then iterate through this list and use describeSObjects() to obtain metadata about individual objects. So here is the recipe to fetch the correct prefix.

  1. Mark any of your custom Sobject, that is of course part of your product as TOKEN. Lets say my custom object name is “Chatter_Location__c”.

  2. Make a describeGlobal() call to get the org’s describe and then list all available Sobjects in this describe via describeSObjects().

  3. For each available Sobject in iteration try matching TOKEN value with the Sobject name.

  4. For all the 3 SFDC orgs mentioned above, we will receive Sobject names as follows on making describeGlobal() call.

    • DevOrg : Chatter_Location__c

    • QA Org : qaorg__Chatter_Location__c

    • Managed Package Org : mpac__Chatter_Location__c.

  5. On having a match sub-string the prefix, so you will get either

    • “” Empty String > Dev Org

    • “qaorg__” > QA Org

    • “mpac__” > Managed package org.

  6. So, that is it guys. Now we have correct prefix in hand. We can cache this somewhere forever(usually will not change) and prefix the SOQL + Sobject Name/Fields.

Here is the sample code that shows the same recipe as above.

// Assuming  you have the right partner/enterprise binding to make the call.
DescribeGlobalResult describeGlobal = getBinding().describeGlobal();
// Token Sobject Name, this can be any Custom Sobject name from your product.
String TOKEN_SOBJECT_NAME = "Chatter_Location__c";
// Pull the list of Sobjects from the Global Describe
DescribeGlobalSObjectResult[] describeResults = describeGlobal.getSobjects();
int indexOfToken = -1;
// This variable will have the namespace prefix
String namespsacePrefix = null;
for (DescribeGlobalSObjectResult descSobjResult : describeResults) {
    String sobjName = descSobjResult.getName();
    if (sobjName != null) {
        // Try matching each Sobject Name with the TOKEN Sobject
        indexOfToken = sobjName.indexOf(TOKEN_SOBJECT_NAME);
    if (indexOfToken != -1) {
        // If match is success, then substring the namespace prefix
        namespsacePrefix = sobjName.substring(0, indexOfToken);

// Here we go, the final namespace prefix is here.!!!

Have any more ideas thoughts, please share !

Leave a Reply

%d bloggers like this: