Wednesday

Oracle Visual Builder Cloud Service: How to Access Application Configuration JSON Files in JavaScript

Introduction

Oracle Visual Builder Cloud Service (VBCS) provides a low-code development environment for building web and mobile applications. In addition to its visual development capabilities, it allows developers to write custom JavaScript code to implement application-specific logic.

In many applications, we need to maintain configuration values such as API endpoints, application settings, feature flags, or other static data. Instead of hardcoding these values directly into JavaScript files, we can store them in custom JSON files under the application's config folder and access them from our code.

In this post, we will explore how to create custom JSON configuration files in Oracle Visual Builder and use them in a page's JavaScript code.

Step 1: Create a JSON Configuration File

First, open your application in Oracle Visual Builder.

Navigate to the application's Sources section and locate the config folder. Create a custom JSON file inside this folder.

For example, let's create a file named appConfig.json with the following content:

{
  "applicationName": "My VBCS Application",
  "apiBaseUrl": "https://api.example.com",
  "enableFeatureX": true,
  "defaultPageSize": 20
}

Here, we have defined a few configuration properties that can be used throughout our application.

The config folder can contain multiple JSON files, allowing us to organize configuration settings based on the requirements of our application.

For example, we might create separate files for API configuration, application preferences, and feature-specific settings.

Step 2: Access the Configuration File in JavaScript

Once the JSON file has been created, the next step is to access its contents from a page's JavaScript code.

In Oracle Visual Builder, the exact method used to load a configuration file depends on the application's structure and how the file is exposed by the application. A JSON file located under config should not automatically be assumed to be available as a JavaScript module or through a particular URL.

If the file is exposed as a static resource at a known URL, we can use JavaScript's fetch() API to retrieve its contents.

For example:

async function loadAppConfig() {
  try {
    const response = await fetch(
      './config/appConfig.json'
    );

    if (!response.ok) {
      throw new Error(
        `Failed to load configuration: ${response.status}`
      );
    }

    const appConfig = await response.json();

    console.log(appConfig.applicationName);
    console.log(appConfig.apiBaseUrl);
    console.log(appConfig.enableFeatureX);
    console.log(appConfig.defaultPageSize);

    return appConfig;
  } catch (error) {
    console.error(
      'Error loading application configuration:',
      error
    );
    throw error;
  }
}

This example demonstrates the general JavaScript approach for loading a JSON resource.

Important: The relative URL ./config/appConfig.json is only an example. In a Visual Builder application, the correct URL depends on the runtime application's base path and how the file is deployed. Verify that the JSON file is accessible at the resulting URL before using this approach.

If the JSON file is not published as a directly accessible static resource, use the appropriate resource-loading mechanism supported by your Visual Builder application.

Step 3: Use the Configuration Values in Page Logic

After loading the JSON file, we can use its values in our page's JavaScript code.

For example, suppose we want to retrieve the API base URL and use it to call a REST endpoint.

async function loadData() {
  try {
    const appConfig = await loadAppConfig();

    const apiUrl =
      `${appConfig.apiBaseUrl}/employees`;

    const response = await fetch(apiUrl);

    if (!response.ok) {
      throw new Error(
        `API request failed: ${response.status}`
      );
    }

    const employees = await response.json();

    console.log('Employees:', employees);

    return employees;
  } catch (error) {
    console.error('Error loading employee data:', error);
    throw error;
  }
}

In this example, the API base URL is read from the configuration file rather than being hardcoded in the page's JavaScript.

This makes the code easier to maintain because configuration values can be managed separately from application logic.

The example assumes that the API supports browser-based requests and that any required authentication, authorization, and cross-origin access settings are configured correctly.

Step 4: Handle Configuration Loading Properly

When working with external JSON configuration files, remember that loading the file is an asynchronous operation.

Therefore, the application should wait for the configuration to load before accessing its properties.

For example:

async function initializePage() {
  const appConfig = await loadAppConfig();

  if (appConfig.enableFeatureX) {
    console.log('Feature X is enabled.');
  } else {
    console.log('Feature X is disabled.');
  }

  console.log(
    'Default page size:',
    appConfig.defaultPageSize
  );
}

Call initializePage() from the appropriate page initialization or lifecycle hook in your Visual Builder application.

You should also decide how the page should behave if the configuration file cannot be loaded. Depending on the application, you might display an error message, use safe defaults, or prevent the page from continuing.

Benefits of Using Application Configuration Files

Using JSON configuration files offers several advantages:

  • Separation of concerns: Configuration values are kept separate from JavaScript business logic.
  • Maintainability: Settings can be updated without modifying every JavaScript function that uses them.
  • Reusability: Multiple functions can consume the same configuration values.
  • Readability: JSON provides a simple, structured format for organizing application settings.
  • Feature management: Boolean properties can be used to control optional functionality.

However, client-side configuration is visible to users who can inspect the application. Do not store passwords, private API keys, client secrets, or other sensitive information in these files.

Conclusion

Oracle Visual Builder Cloud Service allows developers to extend low-code applications with custom JavaScript logic. By organizing configuration values in JSON files under the application's config folder, we can keep application settings separate from our page code and make the application easier to maintain.

The key steps are to create the JSON configuration file, make sure it is accessible through a supported loading mechanism, parse its contents, and use the resulting JavaScript object wherever the configuration is needed.

Note: Before adopting the fetch() approach in a production Visual Builder application, verify the deployed resource URL and confirm that the application's runtime and deployment model support direct access to the JSON file. The folder location alone does not guarantee that the file will be published at a particular URL.

How to Import a Page Between Oracle VBCS Applications Using ZIP Source Import (With Action Chains & JavaScript)

🧭 Introduction

If you are working with Oracle Visual Builder Cloud Service (VBCS), you may already know that it is a powerful low-code platform for building enterprise web applications.

However, one major limitation developers face is:

❌ There is no direct option to import or export a single page between VBCS applications.

While full applications can be exported and imported, moving just a single page with Action Chains, JavaScript, and UI bindings is not officially supported.

In this article, you will learn a practical and tested workaround to migrate a VBCS page from one application to another using a ZIP-based source import approach.


πŸ” Problem Statement: Why Page Migration is Difficult in VBCS

A VBCS page is not just UI—it is a complete structured module consisting of:

  • HTML View Template
  • JSON Page Metadata
  • JavaScript Page Module
  • Action Chains (Event Logic)
  • Variables (Page + Flow level)
  • Service Bindings

Because all these components are tightly coupled, copying a page manually is not straightforward.


πŸ’‘ Solution Overview: ZIP-Based Page Import

The workaround is to package all page-related artifacts into a ZIP file and import it into another application using the Source Import option in VBCS.

This allows VBCS to reconstruct the page as a complete module inside the target application.


🧱 Architecture Flow (Recommended Diagram)



πŸ› ️ Step-by-Step Guide to Import a VBCS Page Using ZIP


πŸ“ Step 1: Collect Page Artifacts from Source Application

Navigate to your source VBCS application and locate the page inside the flow.

You need to gather:

  • .html → UI layout
  • .json → page metadata
  • .js → page module (JavaScript logic)
  • chains/ → action chains folder
  • Optional resources (images, modules, etc.)

πŸ“¦ Step 2: Create a Structured ZIP File

Organize all files into a clean structure:

employee-page.zip
│
├── employee-page.html
├── employee-page.json
├── employee-page.js
├── chains/
│ ├── loadDataChain.json
│ ├── saveDataChain.json
│
└── resources/

⚠️ Best Practices:

  • Keep file names consistent with page name
  • Avoid unnecessary nested folders
  • Ensure all dependencies are included

πŸ“€ Step 3: Import ZIP into Target VBCS Application

Now move to the target application:

  1. Open Oracle Visual Builder Designer
  2. Navigate to the target Flow
  3. Click Import
  4. Select Import From Source
  5. Upload the ZIP file
  6. Confirm import

πŸ”— Step 4: Integrate the Imported Page into Flow

After import, the page will appear in your target flow.

Now complete the integration:

✔ Add Navigation

  • Use Flow Menu OR Action Chain navigation

✔ Verify Action Chains

  • Ensure all events are correctly mapped

✔ Check JavaScript Module

  • Validate all functions and handlers

✔ Reconnect Services

  • REST or Business Objects must be re-linked manually

πŸ§ͺ Step 5: Test the Imported Page

Run the application and validate:

  • UI rendering
  • Action Chain execution
  • API calls
  • Data binding
  • Navigation flow

⚙️ Key Observations

During real-world usage of this method, the following behavior is observed:

  • VBCS successfully reconstructs page structure from ZIP
  • Action chains are restored correctly when included
  • JavaScript modules remain functional
  • Some manual fixing is required for dependencies

πŸ“Š Advantages of ZIP-Based Page Import in VBCS

✔ Enables page-level reuse across applications
✔ Faster than manual recreation
✔ Preserves UI + logic + actions together
✔ Useful for modular enterprise development


⚠️ Limitations

❌ Not an official Oracle-supported feature
❌ Requires manual dependency management
❌ Risk of ID or variable conflicts
❌ Service connections must be recreated


🧠 Best Practices for Oracle VBCS Page Migration

To improve reliability:

  • Maintain consistent naming conventions
  • Document all dependencies (services, variables, chains)
  • Avoid tight coupling with app-level variables
  • Standardize ZIP structure across projects
  • Prefer reusable JavaScript modules for shared logic

πŸ“Œ Conclusion

Although Oracle Visual Builder does not provide a direct way to import individual pages between applications, the ZIP-based source import method is a powerful and practical workaround.

It allows developers to migrate complete pages—including UI, JavaScript logic, and Action Chains—between applications efficiently.

This approach is especially useful in enterprise environments where modular development and reuse are critical.

Tuesday

Understanding SDP vs. ADP in Oracle VBCS: The Ultimate Guide


In Oracle Visual Builder Cloud Service (VBCS), data handling is the backbone of any robust application. If you’ve spent any time in the Designer, you’ve likely encountered two heavy hitters: Service Data Provider (SDP) and Array Data Provider (ADP).

Choosing the wrong one isn't just a technical "oops"—it can lead to sluggish performance, broken pagination, or UI components that refuse to refresh. Let's break down the differences, the use cases, and how to choose the right tool for the job.


What is a Service Data Provider (SDP)?

The Service Data Provider (SDP) is a specialized variable type designed specifically to bind UI components (like Tables or Lists) directly to a REST API. It is "service-aware," meaning it handles the heavy lifting of communication between your front-end and your back-end services.

Key Features of SDP:

  • Automatic Fetching: You don’t need to write a "fetch" action chain. When the page loads, the SDP automatically calls the REST endpoint.

  • Server-Side Logic: It natively supports server-side filtering, sorting, and pagination.

  • Built-in State Management: It tracks the "busy" state, error states, and fetch status automatically.

The SDP Philosophy: "Let the server do the work." Use SDP when you have thousands of records and only want to fetch what the user sees.


What is an Array Data Provider (ADP)?

The Array Data Provider (ADP) is a wrapper for a client-side array. Unlike the SDP, the ADP doesn't care where the data comes from. You could fetch data from a REST API, hardcode it, or calculate it on the fly; once that data is in an array, the ADP makes it "observable" so the UI can display it.

Key Features of ADP:

  • Client-Side Control: You have full control over the data. You can add, remove, or update items in the array locally without calling the server.

  • Manual Management: You are responsible for fetching the data (usually via a "Call REST" action) and assigning it to the ADP variable.

  • Flexibility: Perfect for data that needs to be manipulated (e.g., a shopping cart or a multi-row editable table).


SDP vs. ADP: The Comparison Table

FeatureService Data Provider (SDP)Array Data Provider (ADP)
Data SourceDirect link to a REST Service.A local Javascript Array.
PaginationServer-side. Fetches data in chunks.Client-side. All data must be loaded at once.
Filtering/SortingPerformed by the REST API (Back-end).Performed in the browser (Front-end).
Data ManipulationDifficult; requires service-level changes.Easy; just update the local array.
PerformanceBest for large datasets.Best for small, static, or highly interactive lists.

Real-World Examples

Scenario 1: The "Employee Directory" (Use SDP)

Imagine an HR portal with 10,000 employees. You need a table with searching and sorting.

  • Why SDP? You don't want to download 10,000 records into the user's browser. With SDP, when the user searches for "John," the SDP sends a query to the database, and only the relevant 10-20 results are downloaded.

Scenario 2: The "Expense Report Line Items" (Use ADP)

Imagine a user creating a new expense report. They click "Add Row" to add different expenses before hitting "Submit."

  • Why ADP? The data doesn't exist on the server yet. The user is creating it locally. Using an ADP allows you to add, edit, and delete rows in the UI instantly. Once the user is finished, you can send the entire ADP array to the server in one go.


When to Choose Which?

Choose SDP if:

  1. You are displaying data directly from a REST API.

  2. The dataset is large (over 50–100 records).

  3. You need automatic pagination (infinite scroll).

Choose ADP if:

  1. You need to manipulate the data locally (edit/add/delete) before saving.

  2. You are combining data from multiple sources into one list.

  3. The dataset is small and static (like a list of countries or status codes).

Summary

The SDP is your go-to for read-heavy views with large datasets, while the ADP is the hero of interactive, transactional UI components. Understanding this distinction is the first step toward building high-performance Oracle Visual Builder applications.


Expert Tip: If you ever find yourself needing the best of both worlds—like a large table that is also editable—consider using a Buffering Service Data Provider or managing a "dirty state" alongside your SDP!