We have two managed packages. Is there a possibility to let the two packages communicate within one org?

I've seen for example this article, but I was curious if there is any other possibility and a best practice.

Suppose I have a package A that wants to call a method in package B. Package B wants to call a method in package A. Can I for example call the method in B from A with something like Java Reflection? The methods and classes would of course be global. We could also expose the methods as webService. However is there any special limits when you call webServices within the same org? Concerning the same org I only found that there is an unlimited number of callouts. Does the 200 records-per-call limit also apply internally? If there is not big limit, this would be a solution.

Does this make sense at all? Or would you say a common 3rd package with methods to send and receive would be the best alternative? The problem there is that the base package must include all the objects, fields, etc., because otherwise they cannot be passed as parameters via the 3rd package.

Is there a best practice for this case?

Edit: The problem ist that if we have the following architecture: - Package A ---> BasePackage <--- Package B. I can call a BasePackage method from Package A, but how can the BasePackage call a method in Package B then? It does not know any methods from Package B. Is this possible without asynchronous calls?

  • I dont know any other better or possible solution but, you have to have a separate managed package which is installed on both manage package org. That is like a connector. Then it has to have a global interface class. Then you have a chance two communicate between packages. It may be wrong in practice but it looks , it can make it possible May 17 '16 at 16:12
  • FYI Breaking managed package dependencies.
    – Keith C
    May 17 '16 at 20:45
  • Thanks, I found that the blog entry solved my problem the best. The referenced blog entry gave the the idea on how to implement it and now I can communicate between two managed packages in both directions: Apex Calls Between Independent Packages.
    – Florian
    May 19 '16 at 7:54

Here i am sharing my experience with dependent packages.

Generally the approach should be that one will be a parent package and other one will be a dependent package or child package.

Doing development and packaging will be difficult as first you have to install your parent package first in both dev org and packaging org then only you can do development and packaging of dependent package.

In your case if it is possible you can have two independent package and one dependent package.This dependent package will perform the operations which required to have combined inputs from both independent packages.

Edit 1: I overlooked the link you have shared and that seems to have pretty good points from architecture perspective.

Edit 2 Form this doc Callout Limits and Limitations

You can make unlimited concurrent callouts to internal endpoints.

I am collecting more information will share that here.


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.