Oracle BICC: What It Is and Where Data Extraction Gets Complex

If you’re looking for a way to extract data from Oracle Fusion Cloud, you’ve probably come across BICC, or Business Intelligence Cloud Connector.

BICC is Oracle’s tool for bulk data extraction, moving data out of Oracle Fusion applications to external storage. The data can then be loaded into a data warehouse or another data platform, where it can be used by BI systems like Power BI or Tableau for reporting and analytics.

For many organizations, BICC is a good starting point. It is a tool provided by Oracle, supports both full and incremental extracts, and can handle large-scale data extraction.

But extracting the data is only part of the job.

You still need to find the right Oracle Fusion data stores, deal with View Objects and PVOs, set up your extracts, manage the files BICC generates, and build out the rest of the pipeline that moves that data into your warehouse or analytics platform.

Before deciding whether BICC is the right choice, it’s better to understand exactly how it works and where the complexity begins.

What Is BICC in Oracle Fusion?

BICC is Oracle’s bulk data extraction tool that exports data from Oracle Fusion Cloud applications to external storage, where it is then retrieved for BI consumption and enterprise analytics.

BICC is included with Oracle Applications Cloud subscriptions, but users must have the right roles and access to use it.

A couple of things to understand upfront are that:

• BICC does not provide a direct connection to the Oracle Fusion database. 
• Oracle does not give customers direct access to the underlying transactional database. Instead, BICC enables you to extract data through the data stores and View Objects that Oracle exposes. 

What is a PVO in BICC?

A Public View Object (PVO) is a read-only view provided by Oracle that exposes Oracle Fusion application data for extraction and integration.

Imagine you’re building a procurement or finance data pipeline. You may need details of suppliers, invoices, payments, purchase orders, and a whole host of other data points. With BICC, your team must identify which available PVOs have those attributes and how they map to the data model you are building.

Oracle has documentation to assist you with this. But when you have hundreds of fields across ERP, HCM, SCM, or other Fusion modules, it still can take time to find and map the right data.

This is one of the areas where having people on your team who understand the Oracle Fusion data model becomes particularly valuable.

Once you’ve identified the PVOs and data you need, BICC lets you configure how that data is extracted and delivered. You can:

• Run full or incremental extracts.
• Schedule extraction jobs. 
• Filter the data you want to extract.
• Send the output to a configured storage location, such as Oracle Universal Content Management (UCM) or supported external cloud storage.

If you need to pull large volumes of Fusion data on a schedule, this approach works well. But the bigger question is what happens before and after that extraction.

How to Extract Data From Oracle Fusion with BICC? A Step-By-Step Approach

A typical BICC data extraction workflow has four stages:

1. Extract raw transactional and master data from Oracle Fusion

The first step is to select the Oracle Fusion data you want to extract. BICC uses Oracle-provided data stores based on View Objects (VOs), such as Public View Objects (PVOs), to provide access to Fusion application data for extraction.

You can configure BICC to perform full extracts, or for supported data stores, incremental extracts that pull in data changed since a previous extraction. You can run extraction jobs on demand or schedule them to run automatically at intervals that meet your data refresh requirements.

2. Store the extracted files

BICC writes the extracted data to a configured storage location like Oracle Universal Content Management (UCM) or supported external cloud storage. You can create BICC extracts as compressed data files and a manifest file describing the files created in each extract batch.

At this point, the data is out of Oracle Fusion, but it isn’t necessarily ready for reporting. If you want to load Fusion data into a data warehouse, you will need a downstream integration process to grab the extracted files and load the data into your target platform.

3. Load and transform the data

Then, a data integration or orchestration tool, such as Azure Data Factory or Oracle AI Data Platform Workbench, picks up the BICC extracts and loads the data into the destination. That destination might be a data lake, lakehouse, or data warehouse such as Snowflake, Databricks, Azure SQL, Microsoft Fabric, or Oracle Autonomous Data Warehouse, depending on your architecture.

Data engineers can then clean, join, model, and transform the extracted Fusion data as per the organization’s analytics requirements. That may involve building fact and dimension tables for a dimensional model, but the actual transformation and modeling process depends on how the organization has architected its data platform.

4. Use the data in Power BI or Tableau

Once the Fusion data is in the data warehouse, BI tools like Power BI and Tableau can connect to it for reporting and visualization.

The complete workflow might look like this:

Oracle Fusion → BICC data stores/View Objects → BICC extract → UCM or external cloud storage → data integration pipeline → data warehouse → Power BI/Tableau

This is an important point to keep in mind when evaluating BICC. BICC is responsible for pulling data from Oracle Fusion, but it does not handle the entire process of moving that data from Fusion to your BI dashboards. Your team still needs to build and maintain the storage, ingest the data into the destination, and handle whatever loading and transformation logic your architecture requires. 

What Are the Limitations of Oracle BICC?

BICC does what it is supposed to do: bulk extraction of Oracle Fusion data.

The challenges usually become visible when you start to think beyond the extract and look at the entire journey from Oracle Fusion into your data warehouse, BI platform, or analytics environment.

Here are the limitations of BICC to be aware of before building your data pipeline around it.

1. Finding the data you need isn’t always straightforward

One of the first questions your data team will have is:

Where is the data we actually need?

With BICC, answering that question means getting the right data stores and View Objects, and then finding the attributes you need inside of them.

That might be doable for a relatively simple extraction. But it gets more complicated when you’re pulling data across multiple Fusion modules or building data sets that require dozens or hundreds of fields.

Your team may need to work through questions such as:

• Which PVO contains this particular field?
• Which attributes correspond to the business fields our analysts asked for?
• Do we need data from multiple PVOs?
• How does this data map to the tables we’re creating in the warehouse?

Oracle provides documentation and lineage information, but you still need people who can understand the Fusion data model and translate a business requirement into the right BICC data stores.

That’s a learning curve to consider in your implementation timeline.

2. Getting data out of Fusion isn’t the same as getting it into your warehouse

BICC pulls your Fusion data to a storage area. It does not just open a direct connection from Oracle Fusion to Microsoft Fabric, Azure SQL, Snowflake, Databricks, or any other warehouse and populate your tables.

Once the files are extracted, a data orchestration tool like ADF should pick them up, clean, ingest, and transform the data, and move it to its final destination.

So your actual architecture may look like this:

Oracle Fusion → BICC → external storage → ingestion process → data warehouse

If your organization has the infrastructure and engineering resources to execute those steps, BICC may be a good fit for your existing architecture.

But if your goal is simply to get Oracle Fusion data into the data platform your team already uses, the additional moving parts are worth looking at. You’re not just building BICC. You also build and maintain everything that surrounds it.

3. You can’t simply write SQL against Oracle Fusion through BICC

If you’re a data engineer who is used to working directly with databases, it is important to understand that BICC doesn’t give you a SQL endpoint to the underlying Oracle Fusion transactional database. 

You work with the data stores and View Objects that Oracle has made available to extract from. This approach can be limiting if your requirement is very specific.

For example, your team may want only a specific set of columns, or you may already know exactly which Oracle Fusion tables contain the data you need. You might want to write SQL, define your joins and filters, and impose granular control over what goes into your pipeline.

Whether that matters to you depends on the flexibility your data team needs and how comfortable they are with Oracle’s BICC framework.

4. Incremental extraction solves only one part of the pipeline

BICC supports incremental extraction, and that’s an important capability when you’re dealing with large amounts of Fusion data.

If the selected data store supports incremental extraction, after the initial load you can avoid having to extract the entire data set each time and can instead retrieve changes since the last extraction.

But your pipeline doesn’t end when BICC creates the extract.

You still need to work out how those files are going to move from storage to your destination. You must decide how you will handle the loading logic, process updates, track failures, and ensure that the most recent data reaches the consuming systems.

So, when evaluating BICC, don’t focus solely on how the extraction job works. Consider the entire pipeline your team will need to build around it.

5. Your data is only as fresh as the entire pipeline

BICC works well for scheduled bulk extraction, but it does not provide a live connection to the Oracle Fusion transactional database. Your data’s freshness is determined by factors other than your BICC schedule.

You need to consider:

•  When the extract runs,
•  How long it takes to complete, 
•  When your downstream pipeline picks up the files, and 
•  How long it takes to load and process them in the destination.

That is totally acceptable for a lot of reporting and analytics workloads. Maybe all you need is a scheduled or daily batch process.

However, rather than focusing only on the BICC extraction schedule, you should take into account the latency throughout the entire pipeline if your company anticipates data availability more frequently.

6. The architecture becomes harder to manage as you scale

One thing is setting up an extract. Another is handling hundreds of data sets in different Oracle Fusion modules. As your requirements increase, so does the number of PVOs, extracts, schedules, files, warehouse tables, and downstream processes your team has to manage.

Then there are the daily operational questions.

What happens if the extraction job fails? How do you track the pipeline? How quickly can you add a new Fusion data set when the business requests it? Who maintains the mappings between the Fusion source and destination?

These challenges do not mean BICC is the wrong tool. But they do mean that the total effort of using BICC is bigger than configuring the extraction itself.

When Is Oracle BICC a Good Choice?

BICC is a good option if your company needs Oracle’s native way to extract large amounts of data from Oracle Fusion and already has the infrastructure to support the rest of the data pipeline.

It’s particularly well suited for organizations that:

• Prefer to use Oracle’s native data extraction framework.
• Require scheduled full or incremental data extracts from Oracle Fusion.
• Understand Oracle Fusion’s View Objects (VOs) and Public View Objects (PVOs).
• Have an existing setup for loading BICC extracts into a data warehouse or other analytics platform.
• Are comfortable building and maintaining the storage, ingestion, and transformation layers around BICC.
• Don’t require real-time data and are comfortable with scheduled batch refreshes.

In these scenarios, BICC fits seamlessly into a larger enterprise data architecture and can be used as the first step in transferring Oracle Fusion data to downstream analytics systems.

Starting from scratch makes the decision more difficult. If you don’t already have storage, ingestion, and pipeline infrastructure in place, you’ll need to build and maintain them in addition to configuring BICC.

When Should You Consider an Alternative to BICC?

An alternative may make more sense if your end goal is not simply to get Oracle Fusion to external storage but to solve a broader data integration or analytics problem.

For example: “We need Oracle Fusion ERP data in Microsoft Fabric.” “We need to build a pipeline from Fusion to Snowflake.” “Our Power BI team needs access to Oracle Fusion data.”

In these cases, BICC can handle the initial data extraction, but you will still need to build and manage the additional steps required to move that data from external storage to its final destination.  

You may also want to consider an alternative if your answer is yes to any of the following questions:

• Do you want more control over the Fusion data you extract?
• Does your team prefer to use SQL to access Fusion data?
• Would you prefer to avoid building a file-based ingestion architecture?
• Do you want to reduce the Oracle-specific work involved in getting Fusion data into your existing data stack? 

Lastly, if your organization has already standardized on tools like Microsoft Fabric or Azure Data Factory, you may prefer an Oracle Fusion-specific connectivity layer that fits into your existing data platform rather than building a separate extraction and file-handling process.

How Does BI Connector Simplify Oracle Fusion Data Extraction?

BI Connector simplifies the Oracle Fusion part of data extraction and gets Fusion data to the tools your team already uses.

For example, Microsoft Fabric and Azure Data Factory are designed to move and orchestrate data, but there is still a need to access Oracle Fusion data. BI Connector serves as the bridge, managing Fusion-specific connectivity so your data engineers can continue using their existing data stack.

Depending on your use case, there are two ways BI Connector fits into the architecture:

For enterprise data pipelines:

Oracle Fusion → BI Connector → Microsoft Fabric/ADF → Data warehouse 

• BI Connector exposes Oracle Fusion data directly to your existing Microsoft Fabric or Azure Data Factory pipelines, eliminating the need to extract Fusion data as files and then build processes to read, parse, and ingest those files.
• BI Connector also provides prebuilt pipeline templates for Fabric and ADF that take care of a lot of the data-loading logic, such as initial full loads, incremental loads, fetching data in chunks, and upserts. 
• Your team doesn’t need to create this Oracle Fusion-specific extraction and ingestion logic from scratch.

From there, you can load Fusion data into Fabric SQL, Azure SQL, Snowflake, Databricks, or other destinations and use your existing data stack for any additional transformation, data quality, or modeling requirements.

Simply put, the BI Connector makes it easier to move from Oracle Fusion to your data warehouse, but your existing data platform still does the analytics and transformation work it was built to do.

For BI reporting without a data warehouse:

Oracle Fusion → BI Connector → Power BI/Tableau

• If your goal is simply to get Oracle Fusion data into Power BI or Tableau, you don’t need a data warehouse in between. 
• BI Connector supports native OTBI reports and BI Publisher data models for direct connection to these BI tools, as well as custom SQL-based data sets.

Your team can also leverage BI Connector Developer Edition, which offers an Oracle Fusion SQL editor, to develop Fusion SQL queries that access Oracle Fusion data. 

Use the Oracle Fusion Query Vault to access prebuilt queries for common reporting use cases.

To summarize, BI Connector does not replace Fabric, ADF, your data warehouse, Power BI, or Tableau. It abstracts the complexity of the Oracle Fusion connectivity and extraction layer, allowing your team to continue using the data and analytical tools they already know.

Oracle BICC vs. BI Connector: Which One Should You Choose?

The right choice is determined by your goals and the data architecture you currently have in place.

BICC may be a good fit if:	BI Connector may be a better fit if:
You prefer Oracle’s native bulk extraction framework.	You want to simplify getting Oracle Fusion data into your existing data stack.
Your team is comfortable working with BICC data stores, View Objects, and PVOs.	Your team prefers a more SQL-driven approach to accessing Fusion data.
You already have the infrastructure to process staged extract files.	You want to avoid building a file-based extraction and ingestion process.
Scheduled batch extraction meets your data freshness requirements.	You want to connect Fusion with Fabric, ADF, Power BI, Tableau, or a downstream data warehouse.
Your team can build and maintain the downstream pipeline around BICC.	You want to reduce the Oracle Fusion-specific extraction work your data engineering team has to manage.

Then consider a few practical questions: 

How many components will your team need to build and maintain? 

How much Oracle Fusion expertise will the process require? 

How quickly can you add new data sets? 

And how much ongoing maintenance will your data team own?

If reducing the Oracle Fusion-specific engineering work is a priority, BI Connector may be the better fit, particularly if your organization already uses Power BI, Tableau, Microsoft Fabric, or Azure Data Factory. 

For a more detailed breakdown of how the two options compare across data extraction, architecture, setup, and ongoing maintenance, read our BI Connector vs. Oracle BICC comparison. 

Conclusion

When organizations need to extract large volumes of data from Oracle Fusion, BICC is often one of the first options considered, and for good reason. 

But the important thing is to know what BICC does and what it doesn’t. BICC can move your data out of Fusion to external storage. From there, your team may still have to construct and maintain the processes that move that data into your warehouse or analytics platform.

That could work well if your organization already has that infrastructure and the Oracle Fusion expertise to work with BICC data stores and PVOs.

If you are looking for a simpler way to connect Oracle Fusion to your existing data and analytics stack, whether it’s Power BI, Tableau, Microsoft Fabric, Azure Data Factory, Snowflake, or Databricks, then it makes sense to evaluate alternatives like BI Connector before committing to an architecture.

The goal, after all, isn’t just to get data out of Oracle Fusion. The goal is to provide the right Fusion data where your teams actually need it, without turning the extraction layer into another system that they have to spend their time maintaining.

Want to see how BI Connector fits perfectly into your Oracle Fusion data architecture? 

Start your free BI Connector trial and explore a simpler way to bring Fusion data into the BI and data platforms your team already uses.