Using Backends, Servers and Application Profiles in Visual Apps

In the previous blog post we saw some basics of backends and servers, their definitions in the catalog.json file and how they work at the Tenant level.  It is worth reminding that the backend setup is only needed if you plan to create Service Connections from the out-of-the-box Service Catalog VB provides (currently supports Oracle Cloud Applications, Integrations and Process backends).  Service Connections created from endpoint or from a specification like Swagger/Open API dont need a backend setup, but the concept of servers for segregation of configuration applies to them as well.  In this blog post, we see some scenarios of backends and servers at the Visual Application level and how to wire them up corresponding to dev, stage or published versions of your app

You can access the backend information for a Visual Application by navigating to (Visual Application) Settings -> Services.  Visual builder developers can access these settings for any Visual Application they have access to.  A snapshot of the Backend settings at application level is shown below

Here, we have two servers for the backend "Integration Applications" (At the app level you can have multiple servers for a backend, unlike the tenant level, where you are restricted to only one server to one backend).  One of the server called "Overridden Integrations Applications Server" is pointing to the tenant backend and derives its URL from there, the other server called "Second Server" has an absolute URL.

Similar to the tenant level, the backend and server settings at the application level are also represented in a catalog.json file at the application level which can be seen from the source editor.  

Let's see the catalog.json behaviour with various cases at the Application level

Backends and Servers at the application level

CASE 1 – No application backends (Tenant backends may be present)

This is the default case for a newly created application.  Navigate to VB application settings and click on the Services tab.  With backends defined at the Tenant level, but no backends at the application level, the screen should look like this

A quick look at the source editor confirms that the catalog.json has no backend entries, which means, whatever backends are shown on the screen are being inherited from the Tenant settings

 

CASE 2 – Full Override of a tenant backend at the application level

Let's override the "ics" backend.  Click the + icon near the backends list, which opens a dialog for choosing the backend type.  On choosing an Integrations type backend, a dialog to add relevant Server details appears.  Add these and click Create.

Now you can see that the Integrations server list reflects the new server details and there is no connection to the Tenant backend at all.  Also there are a couple of things in addition to what we saw in the Tenant backend settings 

• "Override Tenants Settings" switch is in the ON position – this indicates that you have overridden the Tenant settings
• Additional field "Used in profile : Base configuration" is also present.   This tells you what application profile is the Server linked to.  Application profiles are a way to attach different configurations to the same backend ( for e.g. a test instance for Integration connections for testing purposes), so that your application can remain the same, but have different configurations based on which application profile you are using.  There is always a default application profile available in a Visual App (In this case it is called Base configuration).  
• The first server in the server list of a backend is the default server for this backend.  This means that any newly created application profile will automatically be attached to this server (we will see this later on in the blog). 

The catalog.json now has an entry for "ics" with the URL and the other settings specified

Note that there is no mention of an application profile for the https://int.oracle.com server as it is the default.  Therefore all profiles that are not explicitly linked to a server for this backend will automatically be linked to this server.

 

CASE 3 – Partial Override of a tenant backend at the application level

Sometimes, we want the server URL same as that inherited from the Tenant backend, but certain settings need to be overridden. Let's see how this works.

By default, the "Override Tenant Settings" will be off.  Click this switch to enable the override and you will get a changed entry in the server list called "Overridden Integration Applications Server 1"

The difference in this approach is that there is still a link to the tenant's "ics" backend, and you can selectively override the things you want like authentication settings.  

The URL now shown for the server is is vb-catalog://backends.tenant/ics.  The backends.tenant is a special entity to indicate that the URL resolution should happen based on the tenant's backend called "ics".  

Click on the pencil icon to edit the server. 

You can see some extra options available as shown in the above figure, namely

• A checkbox called "Override the configuration inherited from the backend"  which is by default checked- this indicates that the Authentication settings defined in the application's catalog.json take precedence over the Tenant's catalog.json. 
• The authentication from the tenant's backend is simply copied to the overridden server's authentication ("Oracle Cloud Account")
• An extra Connection type called "Inherit from catalog" – this indicates that the Connection type setting is the same as that defined in the server of the Tenant backend.

The catalog.json now looks like below:

There is an x-vb/authentication block, which means though the URL is inherited from the tenant's "ics" backend, the authentication is overridden and whatever is defined at the app level is used.  Currently there is no forceProxy setting (representing the relevant Connection Type) as the option selected is "Inherit from catalog" .  If you change this value, you will start seeing an overridden forceProxy value as well in the catalog.json.

You can now add more servers and link them with different application profiles.

 

CASE 4 – Adding more servers to the Application backend

Now that the Tenant settings are overridden, you can proceed to add more servers.  Lets add another server to the overridden "ics" backend.  For this, click on the + Server button, and fill in the relevant server details as shown below:

You can see that a second server is now added to the list.  The catalog.json looks as below

In our application there was just one application profile defined – Base configuration.  The catalog.json doesnt show any link of Base configuration to any of the servers for ics backend, though the UI shows the Base configuration linked to the first Server, and nothing attached to the second server.  Why is that so?

The answer is, since we designate the first server in the list as the default server for that backend, and this gets attached to any application profile by default (unless the application profile is made to explicitly associate another server for this backend)

Let's see what happens when we create another application profile – TestConfiguration.  For this, go to the Application Settings -> Application Profiles.  The Base configuration currently shows the "Overridden Integration Applications Server 1" for the ics backend.

Duplicate the Base Configuration into the new application profile – TestConfiguration. 

A quick observation of the Test configuration profile shows

Both application profiles have the "Overridden Integration Applications Server 1" as the server, as this is the first server in the list for the "ics" backend.

This can also be checked in the Backend List by navigating to the Services tab as below

For associating the Second Server to TestConfiguration profile, we will edit the "Second Server" and add the relevant profile there as shown below. This will remove the "Overridden Integrations Application Server 1" from the TestConfiguration as well, as there can be at max one server attached to one backend for each profile.  

 

This completes the discussion on application backends and servers.  Let us now see an example of servers and backends usage in an actual application.

Application profiles

Let's say our purpose is to configure our application in such a way that Development  version of the application refers to the first server (https://int.oracle.com) server and Stage refers to the second server (https://secondint.oracle.com) server for the Integrations Cloud backend.  (Note int.oracle.com and secondint.oracle.com are just dummy servers used as way of explanation here, you should connect these to relevant development and test instances).  We already have seen in the previous section how each server for the "ics" backend can be configured to use different servers attached to different application profiles.  Now we need to make the TestConfiguration profile to be used for the staged version of our app.

For this navigate to Visual App -> Settings -> Application Profiles.  The application profiles should show both the ones we have created – namely "Base Configuration" and "TestConfiguration".  Click on Base Configuration and select the option to make it "Development default".  Similarly click on the TestConfiguration and select the option to make it "Stage default".    You show now see both application profiles as below.

With this, the development and stage versions of the application should route to https://int.oracle.com and  https://secondint.oracle.com respectively.

 

Service Connections

Let us now create a Service Connection based on "ics" backend.

Create a new Service Connection, choosing the option of Create from Catalog.  Choose Integrations, and proceed to add any endpoint that is available in Integrations Cloud.  In our example, we have a simple REST resource DEMOBACKEND/getDemo which is deployed on both dev and test Integration servers, but returning a different string based on each of them.  

Go to this newly created Service Connection.  There are different tabs like Service, Servers, Endpoints, Headers, Transforms, Source that give different details about the Service Connection.  Opening the Server tab shows us a Server list complete with the application profile information, that is simply inherited from the application level "ics" backends.  

Note that there is no separate link for the two servers, but both have just one edit link.  This is because both come from the same backend "ics" defined in the application's catalog.json.  Clicking on the pencil icon, we can see that configuration for a Service Connection is similar to that of a backend with some differences

• Instance URL is vb-catalog://backends/ics/ic/api/integration/v1/flows/rest.  This basically resolves the Service Connection URL to the backends entity in current catalog.json (i.e. the application's catalog.json) ,  Depending on the application profile used, this will either be resolved to https://int.oracle.com or https://secondint.oracle.com
• A checkbox called "Override the configuration inherited from the backend"  which is by default unchecked – this indicates that the Authentication and Connection Type settings are inherited from whatever is defined in the backend.  You can choose to override the backend settings and define new ones here if needed.
• Application profile information – All the profiles that are resolved by these servers.

 

It is worth mentioning that you can add servers at the level of service connection too (rather than the backend), and associate them with different application profiles.

This completes all our setup for configuring a Service Connection based on Integrations Cloud backend configured with a different server for development and stage.

Running the application

We can test application profiles by creating a small application which has a button that calls this Integration REST API and see how it behaves in development preview mode and with a staged URL.  The below screens show the output of such an app.

With the preview mode of the application

With the staged version of the application

This blog took the example of an Integrations Cloud backend to show these examples, but the principle is same for other backends like Oracle Cloud Applications backend too.

That completes this two-part blog on servers and backends!  If there are any questions, please leave them in comments.