Mixed proxy deployment scenario

Document ID : KB000098295
Last Modified Date : 29/05/2018
Show Technical Document Details
Question:
Users have the following scenario :
- Production Developer Portal with 1 tenant with 2 different gateways one Test and one Production 
- Test API Gateway has automatic deployment configuration 
- Prod API Gateway has scripted deployment configuration 
- All the API are created on the TEST Gateway as so published on the Portal 
If we move via GMU the APIs from TEST to PROD env will all the APIs configured in the Portal Application will work with OAuth in PROD (even if the sync in PROD is scripted and the API are not synced) ? 
Or better if an Organisation registered on the Portal create an App selecting the APIs published on the Portal by the TEST Gateway could this Organisation invoke the APIs on Production using the same Portal credential (API key and API Secret) even if from the Portal point of view these APIs are not published on PROD env (because to the scripted deployment)?
Environment:
Portal 4.2
Answer:
All the APIs are created on the TEST Gateway as so published on the Portal 
>> Where is the API created is unclear from this line, and this distinction is important. 
Is the API for example, 1. Created on the Gateway and exposed in the portal? or 
2. Published via Portal and deployed using API sync job to the TEST gateway? 

If we move the APIs via GMU from TEST to PROD env : 
This is where that distinction above regarding where the API was created matters. For gateway published APIs, you can only migrate them between gateways using GMU, but for portal published APIs, we recommend moving them between gateways using one of the deployment modes automatic, on-demand or scripted. , will all the APIs configured in the Portal Application, will work with OAuth in PROD (even if the sync in PROD is scripted and the API are not synced)? 
>> If APIs are not synced/deployed/migrated to the PROD gateway they cannot be consumed in runtime from that gateway. 

Or better if an Organisation registered on the Portal create an App selecting the APIs published on the Portal by the TEST Gateway, could this Organisation invoke the APIs on Production using the same Portal credential (API key and API Secret) even if from the Portal point of view these APIs are not published on PROD env (because to the scripted deployment)? 

>> API cannot be consumed in runtime from the PROD gateway unless it exists on the PROD gateway. However, if you create an App which selects an API, that App/API Key is synced to ALL gateways enrolled with the portal including TEST and PROD. Once the API is synced/deployed to both TEST and PROD gateways the same App creditionals can be used against both gateways to access that API in runtime. This is typically a deal breaker for customers due to bleeding API Keys across environments.. 

The customer needs to use Automatic Deployment; 

Do you know if is it possible to modify the deployment type from Automatic to Scripted (I see on docops this defect: Error when Shifting from Automatic to On-Demand or Scripted Proxy (DE356210)) ? 

>> This issue is still open. The workaround is described in https://docops.ca.com/ca-api-management-saas/en/release-notes-api-management-saas/known-issues-api-management-saas.   From the engineering team’s feedback they are hoping to fix this issue it as part of any changes to API sync work. 

Do you know if is it possible to prevent an Api Owner or an Admin to publish an API on the Portal? 
>> No. 

Do you think if it is possible to ask for an implementation that, on scripted deployment, make possible to publish API from Gateway to Portal? 
>> No. We are moving away from creating APIs directly on the gateway as long term our vision is to not have runtime gateways connected to a policy manager. We’d like to move to having a single source of truth for APIs, right now it can be either the portal or gateway. We have a feature in the backlog that addresses “Advanced Mode” of API publishing where an API on the portal can be published by uploading a RESTMAN bundle which was most likely created on a “design time” gateway. This way we hope address more complex APIs but also prevent customers from creating APIs directly on runtime gateways.