It is common practice to configure a separate brainCloud apps for development vs. production versions of applications and use brainCloud's deployment mechanism to push updates from dev -> production (see article https://help.getbraincloud.com/en/articles/114168-how-do-i-manage-updates-to-live-braincloud-apps).

This can present challenges for apps that need to use separate web service endpoints for development vs. production - because our deployment mechanism always updates the target (i.e. production) app with the latest webservice values from source (i.e. development) app.

This article provides a simple solution to this problem.

---

The solution

The short-summary is simply to:

Define all web service endpoints in the development version of the app - i.e. define both "external_dev" and "external_prod".
Define a Global Property (e.g. "external_service") that scripts will use to choose the correct endpoint. Be sure to enable the "[x] Preserve value during deploy" option on the property so that the value does not get overwritten during subsequent deployments.
Modify your script(s) to use the new global property when making web service calls.
After your initial deploy of the changes to production, be sure update the value of the "external_service" property to the production value (e.g. "external_prod).

The rest of the article will give more details on the steps.

---

Step 1 - Define web service endpoints

Simply define all values of the endpoint that you will need to switch between. We recommend naming them in such a way to group variations of the same endpoint together.

Step 2 - Define the global property

Now define and configure a global property that will be used to select the active endpoint for current application. You can define this value in the development version of the app and let the definition and initial value migrate to the production version during deployment, or you can directly enter it into the production version ahead-of-time. <- Obviously, if you enter it separately, be sure to name it the same!

Note - it is very important to ensure that "[x] Preserve value during deploy" -- that is the key to making this solution work!

Step 3 - Modify your script(s)

Modify the app's scripts to use the Global Property when making HTTPClient calls.

Here is an example:

// Grab the name of the currently configured endpoint  
var externalService = bridge.getGlobalProperty("external_service");

// Configure the request
var path = "v2/request"
var query = {};
var headers = {};
var json = { "arg1": "1234" };

var externalResult = {};
if ( externalService != "disabled" ) {
  externalResult = httpClientProxy.postJsonResponseJson(
    externalService, path, query, headers, json);

} else {
  // Service is disabled. 
  // Return an appropriate place-holder value to the client...
  externalResult.status = 200;
  // add additional no-op customizations here...
}
    
if ( externalResult.status == 200 ) {
  // Success!
        
        
} else {
  // Handle the error!
        
}

Note that in this example, the developer added a "disabled" state that can be used to eliminate or simulate calls to the external web service.

This is considered a best practice - and is handy in the event that your web service starts acting up, and you want to quickly disable it to preserve the health of your app. <- Assuming that your app can operate without the service, of course.

Note - if the global property is set to a web service code that does not exist (other than "disabled", which is compensated for in the example code), the HTTPClient call will return a 400 status response:

{ 
  "status": 400,
  "reason_code": 40443, 
  "status_message": "Processing exception (message): Invalid service code"  
}

Step 4 - Modify the value of the property in production

Remember that after you initially deploy from your development app to another app, you may have to go and adjust the configuration of the "external_service" Global Property... (if you hadn't pre-configured the property that is).

---

We hope that this approach works for you!