Can we connect developer portal to multiple edge organizations?
Is it possible to connect a single drupal instance to connect to multiple edge organizations?
I already have a develoepr portal with one edge organization connected to it. Can we have the ability to connect through multi site installation process in Drupal?
Iam using drupal 7.14 currently
Is it possible to connect a single drupal instance to connect to multiple edge organizations?
I already have a develoepr portal with one edge organization connected to it. Can we have the ability to connect through multi site installation process in Drupal?
Iam using drupal 7.14 currently
Best Answer
@Ramya After looking more closely, it is possible to connect to more than 1 org from DevPortal, but it's not easy.
Using the Edge Management API SDK (located at profiles/apigee/libraries/mgmt-api-php-sdk) you have full control on how to connect to Edge and which orgs to use. However, you would be responsible for making all these extra calls, handling the data returned, and displaying it to the user.
Hi Karl, I am also looking for the same approach and I am new in APIGEE, could you please provide more details on it.
Sure I can go into some more detail.
Generally when the DevPortal is talking to Edge Management API, there's a call to devconnect_default_org_config() to get the edge account credentials. These are the ones you see at /admin/config/devconnect.
So when you make your own Edge Mgmt API calls, you will need to create your own Apigee\Util\OrgConfig object with credentials for the org you would like to use.
For example, in order to generate the org status report, an Org object is created and loaded with information from Edge. You can see this code in action in devconnect_status_edge_report().
// This will load the default org.
$config = devconnect_default_org_config();
$org = new Apigee\ManagementAPI\Organization($config);
$org->load();
// $org is now a fully loaded object, and you can use methods like $org->getName().
// $org is now a fully loaded object, and you can use methods like $org->getName().
to talk to a different org this would change to
// Load a non-default org.
$config = new Apigee\Util\OrgConfig($orgname, $endpoint, $user, $pass, $options);
$org = new Apigee\ManagementAPI\Organization($config);
$org->load();
// $org is now a fully loaded object, and you can use methods like $org->getName().
Thanks for the prompt reply. It actually is presently in Full HTML when I took the screen shot.
I'd caution against trying to map one portal onto multiple orgs. How many various API product sources-of-truth are you willing to query? What happens if a developer gets disabled in one org but not another? How are you going to field analytics reports for developers when that data comes from N orgs?
My recommendation is to be very clear about why you have multiple orgs in the first place and to be sure you're doing that for the right reasons. Is it for the benefit of your admins or your consumer-developers?
As per my understanding Edge has a ability to build multiple organization. but Portal can connect only to one of the organization.
That's why we have asked to fill Organization name and respective credential while configuring.
Is it possible to connect a single drupal instance to connect to multiple edge organizations? No.
Can we have the ability to connect through multi site installation process in Drupal? Yes.
When you're using a multi-site setup, you're sharing the codebase between sites, but each site has its own database. If you set a custom private file directory for each site, then each site can connect to its own Edge instance.
We are running Apigee internally (private) and had the same requirement: to have the Developer Portal support multiple Organizations like Apigee Edge does. Per Apigee at the time we were implementing that was not supported -- Developer Portal only supported a single organization. I am not sure if that limitation has since been addressed. Because of this limitation in Dev Portal we were essentially limited to using a single organization in Edge also (obviously not the preferred choice).
The other option supported by Apigee is to build multiple Dev Portals, one per Organization. We did not want this option as we wanted a single Dev Portal for our enterprise, but wanted orgs in Apigee to provide administrative control. We also did not want to support multiple dev portal instances.
To satisfy our requirement we are using what I consider to be a sub-optimal solution, which is to use multiple environments within a single organization. In this model, environments provide the administrative control that we wanted (and that is provided natively by organizations). The downside is that we have a single organization, so the developer experience is not great. One downside is that the list of API proxies displayed is all proxies in the organization, but developer will only be able to access/update proxies for their environment. We have set up environment specific roles/permission to control access to proxies. Also as the number of proxies grow in a single organization, the API listing display screen becomes very very slow, it takes 30 seconds or more to render.
Below are some other custom (non-Apigee supported) choices we considered. Note that these were just ideas. I am not sure if they are technically possible to implement or how much work they entail:
- Allow multiple organizations in Edge and then create a "super-org" in Edge that aggregates the resources from all of the other organizations. You then point Portal at the super org.
- Configure Dev Portal to point to an API Proxy on Edge that receives all API management requests from Dev Portal and it then calls (proxies) the request to the 'real' organization in Edge using the Apigee management API. This would required naming conventions for objects (proxies, products, etc) so a routing decision can be made to the correct organization
Thanks for taking the time to write up the approaches you considered and why. The root cause, as you've touched on, is because an org is essentially a unit of tenancy, and on the portal side trying to aggregate across tenants is bound to present challenges (and I would not recommend trying to convince one portal to talk to multiple orgs). IMO, using environments is the better way to establish administrative separation without breaking the consumer-developer experience downstream, though I agree that it can complicate the proxy-developer experience as a side effect.
