The Problem
Pulling ad-hoc data out of Oracle Fusion usually means writing a query inside a BI Publisher data model. That works, but it has two annoying limitations:
- Every query change means editing the data model. There's no way to just type a new query and run it.
- XML output caps out at 200 rows. Anything larger requires generating a full report from the data model instead of a quick preview.
This post walks through a small custom app that removes both restrictions: a VBCS front end where you type any SQL query, run it, and see the results in a table — with no data model edits and no row limit — via a BI Publisher data model + report that accepts the query dynamically, and an OIC integration that glues the two together.
Architecture at a Glance
| Component | Role |
|---|---|
| BIP Data Model | Accepts a Base64-encoded SQL string, decodes it, opens a ref cursor, and returns the result set |
| BIP Report | Wraps the data model so it can be run as a proper report (no row cap) |
| OIC Integration | Receives the encoded query from VBCS, runs the BIP report, and returns the report bytes |
| VBCS App | UI for entering a query, triggering the integration, and rendering the results as a table (with CSV export) |
1. BI Publisher Data Model
The core trick is a data model built on a PL/SQL block that decodes a Base64 string into a query and opens it as a ref cursor:
The data model needs two parameters:
query1— a string parameter that holds the Base64-encoded SQL query. String parameters cap out at 32,767 characters; 32,000 is used here to leave some headroom.xdo_cursor— the ref cursor returned by the PL/SQL block.
Why Base64? Passing a raw SQL string as a data model parameter tends to error out (special characters, quotes, line breaks, etc. all cause problems). Encoding it sidesteps all of that.
The data model query block is:
DECLARE
TYPE refcursor IS REF CURSOR;
xdo_cursor refcursor;
var VARCHAR2(32000);
BEGIN
var := utl_raw.cast_to_varchar2(utl_encode.base64_decode(utl_raw.cast_to_raw(:query1)));
OPEN :xdo_cursor FOR var;
END;
Testing it
Now lets run a query and save the sample data so that we can use the saved sample data to create report.
Lets write a simple query(There should not be any semicolon at the end):
select invoice_id, invoice_num from ap_invoices_all
Now we need to convert this to base64 because if we pass the query directly then it will give error.
We can use any text editor or use online tool to convert to base64.
The encoded string for above query is:
c2VsZWN0IGludm9pY2VfaWQsIGludm9pY2VfbnVtIGZyb20gYXBfaW52b2ljZXNfYWxs
Now lets pass this in our datamodel query1 parameter and click on view:
We will get the output like below:
Save this as sample data.
Now lets create a report.
2). A BIP report.
Select the data model for report:
No need to have a layout as it will give data XMl as output. We can create template and give output type as well.
Save the report and then view report.
We can export this report as Data xml.
3). An OIC integration to run report and provide output to VBCS app
We will create a simple OIC integration which will accept the base64 encoded query from VBCS ,runs the BIP report and returns base64 report bytes to VBCS.
Now call BIP report using a soap adapter:
Give attributeFormat as xml
Finally send the response back to VBCS:
4). A VBCS app to provide UI for running query and seeing results.
This is the start and end of the whole process.
In the sample app we have given a text area to enter the query ad then a run icon.
There is a progress bar, to display the progress of steps in query execution, a table to display the results and an export button to export the result in csv.
The UI looks like below:
Now lets run a query:
The Result will look like below:
We can export this output to csv.
Another query example with commenting the previous one:
We need to do below things in VBCS:
- From the text area whatever query we are having , we need to encode that to base64 through javascript:
Sample Function:
- Call rest endpoint(the OIC integration) by passing this base64 string
- The response from integration will be base64 report byte . We need to decode that using JS.
- This will return the xml, we need to parse this xml and convert to json.
- We will use fxp(fast-xml-parser) library.
- Place the library in our
resources/jsfolder.
Make an entry in index.html as follows : <script src="resources/js/fxp.min.js"></script>
The sample js function to convert xml to json will be:
ConvertXmlToJson(arg1) {
Similarly we need to do for data in table.
Note:- We can combine some funtions together which we saw above, to reduce total number of functions.
This is a simple app which explains flow of how we can query dynamically from VBCS , present the data in tabular form after parsing and also providing option to download data in csv( We need to seacrh and install export data component from components).
The mapping for export data will look like below:
We can Enhance this application to have features like
- Format Query
- Query history - Store the executed queries in ATP with env, query,user, unique id and status
- Rerunning the past queries - Fetch the query from ATP and allow to rerun
- Running queries for different Fusion Environments from the same page - Create OIC connection for diff ENV and have branches in the int for each env. Have LOV in VBCS page and accordingly pass to integration.
- Having links for fusion tables etc - This will help making easy to find the Fusion tables, We can give OER link for each module tables.
as shown in below screenshots.
Before Formatting:
After Formatting:
Get the past run queries, Which we stored in ATP
Select the Query which we want to rerun and click on highlighted rerun button
Run queries in Different Fusion Environments , from single page without needing to open BIP of each env.
Link for Oracle OER tables for Different Modules
No comments:
Post a Comment