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.

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

Feature	Service Data Provider (SDP)	Array Data Provider (ADP)
Data Source	Direct link to a REST Service.	A local Javascript Array.
Pagination	Server-side. Fetches data in chunks.	Client-side. All data must be loaded at once.
Filtering/Sorting	Performed by the REST API (Back-end).	Performed in the browser (Front-end).
Data Manipulation	Difficult; requires service-level changes.	Easy; just update the local array.
Performance	Best 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!