Breaking managed package dependencies

We have several managed packages with customers sometimes installing just one of them and other times several of them (depending on the set of features they want). Calls can be needed between the packages: global interfaces and classes defined in one package – lets call it B – are called from another package – lets call it A.

But once the direct calls are added and new managed package versions created, A cannot be installed without B first being installed because the platform’s package dependency approach is rigid and enforced at installation time. This dependency (illustrated with UML dependency notation) is not what we want:

Dependencies

So how to allow managed package A to call managed package B without the fixed dependency? The trick is to have no compile-time dependency between A and B but instead to introduce a third entity C (that could be another managed package or non-namespaced local code) that calls are made through where dependency on both A and B is not a problem:

Broken

Here is an example of the pattern. The API used to illustrate the pattern has a single method to send an SMS (text) message.

The implementation (that we want to use from other packages) is in package B:

global interface Sms {
    global void send(String number, String message);
}

global class Factory {
    global static Sms createSms() {...}
}

In package A the interface is duplicated together with a mechanism to register a type that implements the interface. The package A code references only this interface and class:

global interface Sms {
    global void send(String number, String message);
}

global class Factory {
    global static Sms createSms() {
        // Use name of type from custom setting
        String s = ...;
        Type t = Type.forName(s);
        return (Sms) t.newInstance();
    }
    global static void registerSmsType(Type t) {
        // Store name of type in a custom setting
    }
}

...
    Factory.createSms().send('38383', 'PREZ');
...

Then in C, a class is implemented that has the signature defined in A and delegates to B to do the work. At some point this class name must be registered with A. If C is a managed package that could be in an InstallHandler or it could be a manual configuration step:

global class Sms implements A.Sms {
    global void send(String number, String message) [
        B.Factory.createSms().send(number, message);
    }
}

...
    A.Factory.registerSmsType(Sms.class);
....

So A and B remain independent and C is the “glue” that connects then together. A can be installed on its own and so can B. If they are both installed, then adding the C managed package or non-namespaced local code allows the call between the packages to be made.

PS

Stephen Wilcox’s Apex Calls Between Independent Packages describes the same pattern.

Advertisements

One thought on “Breaking managed package dependencies

  1. Pingback: Apex Calls Between Independent Packages | FooBarForce

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