What Are Local Servers?
A local server lets you override an in-source server's details, so that you can provide a URL and authentication type that are more applicable during development, without those details going into the extension's source code.
Note:
To use local servers in conjunction with runtime server configurations, make sure your Oracle Cloud Applications instance is on 25A and that you've completed the check described in Work With Services (Limited Availability).If a service connection's backend has a local server defined, it will be used when interacting with the Designer during development, like when you use the layout editor or the Page Designer's Live/Design mode. When you deploy or preview your App UI, however, the local server is not used. Instead, the URL and authentication method defined in the runtime server configuration are used. More about this later.
Note:
Service connection endpoints based on local servers currently only work in the Page Designer if they are GET-based and have the connection type Always Use Proxy in the local server definition.You can tell that a local server has been defined for a backend because it has the Local server definition tag on the backend's Servers tab, like this:
Description of the illustration servcon-lsdtag.png
You'll also see that the Local server definition check box has been checked if you click the Edit Server icon:
Description of the illustration servcon-lsdcheckbox.png
If you navigate to the Source tab in the Designer, you won't see any important details about the server because they aren't stored as part of the extension:
"oicBackend": {
"description": "Backend representing OIC",
"servers": [
]
}
Local servers are stored within a given VB Studio environment. So, if you switch your workspace to a new environment, you may have to define the local server again for the new environment.
When a backend has a local server, you must also supply a runtime server configuration on the Oracle Cloud Application instance to which you plan to deploy or preview the extension. You can do this on the Manage Backends in Visual Builder screen, available from the Setup and Maintenance menu on the relevant Oracle Cloud Applications instance. This completes the entire definition for the server: you have the URL and authentication method for the server while it's being used in development (as set on the VB Studio Create/Edit Server screen), and a different URL and authentication method when the extension is deployed or previewed (as set on Manage Backends in Visual Builder).
Note:
After you enter your credentials on Manage Backends in Visual Builder, it can take up to five minutes for them to take effect. Keep this in mind if you try to preview or deploy your extension before this time period has elapsed.This diagram shows how a local server in VB Studio works in tandem with the runtime server configuration on an Oracle Cloud Applications:
Description of the illustration servcon-localserv-oac.png
In this image, myBackend
has a local server. Within VB Studio, then, myBackend
resolves to the URL https://devcloud
with Basic Auth credentials. But when the App UI is served from Oracle Cloud Applications, either through the Preview action or after it is deployed, myBackend
will resolve to https://actual cloud
and OAuth 2.0 Client credentials.
Note:
You can't use runtime server configurations in government installations, although this support is being introduced gradually beginning in 2025.If the runtime server configuration is missing for a backend, you'll see a warning message on the backend's Overview tab. Assuming you have the necessary privileges, you can click Edit Configuration to supply the runtime details on the Oracle Cloud Applications instance. If you don't have the right privileges, you'll have to ask an administrator to do this for you. This process must be completed for each Oracle Cloud Application instance to which you plan to deploy. See Provide a Backend's Runtime Server Details.
- Change the URL and authentication method for a backend for different environments (VB Studio, an Oracle Cloud Application test or prod instance, and so on).
- Use mock REST APIs with a different set of credentials only during the development cycle, switching to different set during deployment.
- Override an in-source server during development. While less common than the first two scenarios, this situation can arise occasionally.
To see an example of using a local server and a runtime server to access third-party data (in this case, Oracle Process Automation), see Connect to OCI Process Automation Services - Example.
If you change the details of a local server or runtime configuration after deploying your extension, your changes take effect immediately; redeploying is not required. (Changes to in-source servers, on the other hand, require you to redeploy the extension in order to implement the update.)