Custom Environments do not appear at most places in the Edge UI

Former Community Member
Not applicable

We have a custom environment called "portal" provisioned in the organization.

I know that the environment exists because a call to https://api.enterprise.apigee.com/v1/o/{orgName}/environments

returns

[ "prod", "dev", "portal", "test" ]

Also some of the sample proxies created by accounts_apigee_admin@google.com when I got the environment were deployed on all these 4 environments.

Now the issue is that i do not get to see this environment at most places on the Edge UI. For instance:

  1. The proxy hello world that came pre-deplyed on "portal" environment does not show "portal" in the depoyments dropdown on the overview page. However, on the same page, the deployments section does show portal in the table under column Environment
  2. The Admin>Environments section also does not show up "portal" in the environment dropdown. However when I edit the URL in the browser to https://apigee.com/platform/bat/environments/portal/caches then I do get to access the portal environment
  3. If I need to deploy a proxy to portal environment, I use the Apigee Maven deployment tool. I cam make API calls to the portal endpoint after deploying a proxy, however, on the overview page of this proxy, the portal environment neither shows up on the Deployments table nor in the dropdown.

We even have another environment called "dev" which is available in all the usual places in Edge UI (the way prod and test environments are available). What can be the reason for portal to behave differently?

Note1: I believe, all these 4 environments were created by Apigee when the org was setup and handed over to us.

Note2: There is a slight difference in the response of /environment/{environmentName} for Portal and other environments. Portal has an additional property "features.isDevPortalEnvironment" which is set to true.

Solved Solved
0 2 144
1 ACCEPTED SOLUTION

robert
Participant V

Hi @Anshul Aggarwal, as far as I know, the Portal environment is used for the integrated portal and configuration of virtual hosts and TLS for any portal you create. Do not use it for api traffic. Again, the portal environment is there to set up your integrated portals. Stuff like adding a custom domains, etc.. Can you use it for API traffic? Perhaps. Should you? I wouldn't recommend it. You've already described some issue with using it that way.

It sounds like you have other environments. Just use those as they are there for API traffic and to build proxies. It also sounds like you are on a paid org so using dev, test, and prod should be fine. If you need more environments to support your development lifecycle, just connect with your Apigee sales team or the support team to request additional environments. Please note, there may be a fee involved in adding extra environments.

Hope this answer helps? If so, please click accept.

View solution in original post

2 REPLIES 2

robert
Participant V

Hi @Anshul Aggarwal, as far as I know, the Portal environment is used for the integrated portal and configuration of virtual hosts and TLS for any portal you create. Do not use it for api traffic. Again, the portal environment is there to set up your integrated portals. Stuff like adding a custom domains, etc.. Can you use it for API traffic? Perhaps. Should you? I wouldn't recommend it. You've already described some issue with using it that way.

It sounds like you have other environments. Just use those as they are there for API traffic and to build proxies. It also sounds like you are on a paid org so using dev, test, and prod should be fine. If you need more environments to support your development lifecycle, just connect with your Apigee sales team or the support team to request additional environments. Please note, there may be a fee involved in adding extra environments.

Hope this answer helps? If so, please click accept.

Former Community Member
Not applicable

Thanks @Robert Johnson for the response. I now understand that portal is not for managing API traffic and definitely not the right use case for Mocking.

I came across http://apistudio.io from one of the other community questions and that helped me configure another mocked backed based on a header condition within existing environments.

Accepting the answer.