What Are Backends?
Simply put, a backend describes the server that hosts a system you want to connect to. For example, the "Oracle Cloud Applications" backend represents the details of the Oracle Cloud Applications system, including the URL, authentication method, and so on, all of which are needed to gain access to that system's REST APIs.
All new service connections require a backend. If a backend doesn't exist, you'll be prompted to create one. You'll know when services are "derived" from a backend because you’ll see something like this:
Click the backend link to open the Backends editor, where you can view the backend’s details.
You can create your own backends to represent the systems you want to connect to. Creating backends for commonly used systems helps keep the information in one place, rather than duplicating it across various service connections. For example, instead of having multiple service connections for your company's LinkedIn account, each with the same URL, authentication method, and so on, you could define the details in one backend, perhaps called the “LinkedIn Backend”.
- An in-source server definition provides a backend’s details for use during both development and deployment. Its details live in an extension's source code (specifically in the
catalog.jsonfile) and is therefore packaged up as part of the extension itself. This means that the backend always points to the same URL and authentication method, irrespective of where you deploy the extension. - A local server definition provides a backend’s details for use during development only. Because its details aren't stored in an extension's source code, you can go beyond the limitations of an in-source server by defining the URL and authentication method for the particular instance you're deploying to. Typically, a local server is used in conjunction with a runtime configuration, specified in the Oracle Cloud Applications instance, which provides the backend’s details for the deployed extension (see Provide a Backend's Runtime Server Details). You can also use a local server with an in-source server to override its details during development, although this is far less common.
In VB Studio, a local server’s details are used by the Page Designer's Live mode, while the server details provided by the runtime configuration and in-source server are used by the Preview action.
For example, suppose that during the development phase you want to use a mock URL. While testing you want to use a different URL, located in the test instance, and when you finally deploy you want to use the actual URL. You can achieve this using local servers, but not with in-source servers. The caveat is that local servers must be supplemented with a runtime configuration on the Oracle Cloud Application instance you are deploying to. The relationship between potential servers is shown here: 
Description of the illustration servcon-full-diagram.png
In addition to defining your own backends, you can also add another extension as a dependency and gain access to its backends as well (so long as those extensions have been marked as accessible to other extensions). Your extension also has automatic access to some out-of-the-box backends, like Oracle Cloud Applications and its child backends. These backends are provided by the Unified Application, as shown here: 
Note:
At the moment, you can't add an extension as a dependency with the intent to use the extension's backends to create service connections. Until this is resolved, you must create service connections in the same extension as their associated backends.These backends are provided so that you can use them to quickly create service connections to the REST APIs exposed by Oracle Cloud Applications. You'll need these service connections so you'll have data for things like configuring a dynamic container, or adding other components to the page that require a data source.
Note:
If you don't see the Unified Application as a dependency, contact your administrator to confirm that you have the proper credentials and that your user role is authorized.| Tab | Description |
|---|---|
| Overview | Displays the name and type of the backend, which can be Oracle Cloud Applications or a custom backend.
You can use the + Service Connection button to create a service connection based on the backend. If any service connections have been defined for the backend, they'll be listed below the + Service Connection button:
If you have the backend configured with a local server, you might also see a section that shows the runtime configuration on the Oracle Cloud Application instance you're deploying to. See What Are Local Servers? for more on this. |
| Servers | Displays the server, including the instance URL, associated with the backend. You can display details for a backend server that comes from a dependency, but you can't edit it. You can edit the details for a backend server that you defined for your extension.
The server can be either an in-source server, which is packaged within the extension, or a local server. Local servers are indicated by a Local server definition tag. |
| Headers | Add and edit static headers, which pass information to the service, for the backend at the server level. |
| Source | Displays the backend's description, which is stored in the catalog.json file of the extension or dependency that the backend is defined in. For backends that you define, the location is services/self/catalog.json, and the entries are editable.
Local server details are not stored in the source code. |
The artifact that stores all the backend definitions for the extension is an OpenAPI-compliant file called catalog.json, which contains the list of backends and their details. If you want a backend to be usable by other extensions (that is, extensions who have added your extension as a dependency), the backend must be marked as "Accessible to application extensions" on the backend's Overview tab. The complete service catalog for your extension is a combination of all the backends that you have defined in your extension, plus any backends exposed by dependencies.
If your App UI needs access to a particular Oracle Cloud Applications instance—say, one that’s running a different version of Human Capital Management—use your project’s Environment's tab to add that instance to your Oracle Cloud Applications environment, then use Switch Environment to point your workspace to that environment (or just create a new workspace): 
Description of the illustration switch-environment.jpg