What’s new in APEX 26.1: Data Reporter

With the launch of 26.1, Oracle added a lot of exciting new features to APEX that you can read about in our blog post. At RADAPEX we have been getting to grips with the new features and exploring how they have changed the way we work with and build applications.

One feature that was a bit more obscure than the others was the new Data Reporter. During the launch of 26.1 and soon after there were a lot of questions around this feature; how does it interact with your applications? How do end-users interact with it? Who is it for and what does it do?

After getting to grips with it for the last couple of months we have managed to answer those questions and to decipher its real world use cases.

What does it do, and who is it for?

Essentially Data Reporter is another front-end for your business data. It sits within APEX, alongside the App Builder and SQL Workshop, but it isn’t really a part of either. It is a separate app that functions as a standalone from your APEX application. It essentially is a data-sandbox where you can unleash your end-users on a curated set of data and let them create reports and charts to their hearts’ content.

In most business settings, the process for getting a new report in front of a user can be quite prolonged. A ticket is logged, perhaps it goes through an authorisation process internally, a developer is assigned, the work is completed, signed off, released into a test environment and then queued for a deployment release. In some cases this can take weeks, leading to user frustration and data being exported from the app to be managed elsewhere (and all the security nightmares this can cause). 

With Data Reporter you can now give end users the tools to create their own reports and charts without writing any code or contending with the App Builder.

Let's take a look at how it works, and what it can do.

Setting up Data Reporter

To actually use Data Reporter your application needs to be using either SAML, Social Sign-In, or HTTP Header Variable authorisation schemes. The documentation for enabling this can be found here.

Note: As I am using APEX via a Docker image for testing (from this excellent United Codes image) there were a few extra hoops to jump through, essentially I needed to add a small Nginx sidecar that inserts a trusted username header but this is only appropriate for a locally hosted environment.

Creating Datasets

A key part of Data Reporter is curating the data that you make available to the end users, obviously you would never let your users loose on the database, so Datasets are how you compartmentalise their access.

In this picture you can see that it is as simple as selecting the tables you want to grant access to, for extra security in this example we have created views specifically for this purpose.

Creating Data Reporter Applications

Once you have created your datasets you can start building Data Reporter applications.

You can select as many of your created datasets as you require for the application to access:

Once you have created an app you will see a view that is basically a stripped down version of the APEX workspace:

As you can see, from here you can manage users and activity as you normally would for an entire workspace, but limited to just this particular Data Reporter application. This allows users and applications to have fine-grained access, users can be editors of one application and viewers (or have no access at all), in another.

Note: When you are testing Data Reporter in your development environment you do not need to create a user for your workspace account directly, as it will inherit the developer permissions from the workspace account.

User permission breakdown: (chart from Oracle Blog)

Now we have an application and some users set up with permissions we can start creating some reports. As you can see from the chart above, end users can be assigned to create these reports. That is why the ‘manage application’ view for Data Reporter apps looks ‘stripped down’ when compared to the standard APEX back-end; they can access everything from this level down. 

You can also see from here that only workspace admins can create data sets or create the applications, this ensures that although you are granting Data Reporter access to end users, they cannot alter the scope of the data that is available to them.

Creating Reports

Here is one part that definitely looks a bit different from creating a traditional APEX page, there are only 3 options available in Data Reporter; Interactive Report, Faceted Search and Faceted Search with List.

This is streamlined for simplicity and ease of use, it would not really make sense to grant user access to an application if they were going to be raising a support request to actually use the features.

When configuring the reports the options are similarly intuitive; it is not like the APEX page designer with a huge number of settings and options, users here are limited to the columns and how they are displayed.

Once your report is created you have the opportunity to give the fields and facets a check before making them available to the ‘Viewer’ level users - application Editors and workspace administrators are able to see reports in their unpublished state, allowing your team to confirm their new reports before deploying them.

When the report is accepted it can be published, making it available to all users with access to the Data Reporter application.

And now the report is live. But what if there is a problem? As you can see below, the facets have been set, but there haven't been enough columns selected into the results, the users aren’t seeing enough data.

Normally any changes made in APEX would have to be done in a working copy and then merged to prevent active users being affected (presuming an issue was overlooked in your testing phase). But Data Reporter can leverage its ‘Drafts’ report functionality again to make live changes to the applications.

As you can see, simply selecting ‘Edit’ on a live report automatically prompts you to create a draft, you can’t actually make any changes without doing so in a draft, which is a good measure for ensuring the integrity of your applications front end, particularly if you’re granting users the ability to get into these features themselves.

Once you have made the changes you need, you can save the draft and review and preview the new report, before finally publishing the draft to release it to the front end.

As you would expect, this then makes the report changes visible in the front end of the application.

Once a report has been published and is live in the application, the end users have the same options and controls as they would expect in a standard APEX application. They can sort, filter, create charts, private and public reports on the data.

Use Cases

So now you have seen what the data reporter does and how it is managed, what should you actually be using it for?

In situations where reports and data-views are constantly changing and eating up a significant portion of your development time, there will be significant advantages to using Data Reporter. Isolating minimal and in some cases tedious report changes out of the ticket system used for feature and bug-fix releases frees up time and makes the workflows of your production application more efficient.

You can also safely grant agency to end users who need report changes frequently. With a relatively small amount of training they can be given the power to make the changes themselves and manage the reports as they see fit, potentially granting efficiency to other departments in your business.

However there are of course some drawbacks to this, governance is one main concern, it is one thing to grant agency over an application to your users, it is quite another to have any kind of version control or backup history over it. We are also still a bit unsure about how it will play with SQLcl Project, which we are using increasingly for our deployment pipelines.

Access is another one, if a user is mid-workflow in one application working directly with their data, they are unlikely to be willing to switch to another app just to view reports when they are used to them being available in the app they are currently logged into.

We also mentioned the ability to create a draft version of a report, but there does not seem to be a ‘draft history’ accessible, which would be very useful as a stop-gap to any kind of version control (let us know if you find one). You can also only have one draft of a report at once, which is less of a problem, but a disadvantage when compared to working copies, which you can have multiple of at once. Another final surprise we found was that the export for the Data Reporter app doesn’t use the new APEXlang format, and it isn’t available as an option, which seems like a strange oversight given the excitement around APEXlang in the release of 26.1, and its ease of use with things like AI agents and Git diff’s.

Final Thoughts

If you saw the features demoed in the launch of 26.1 for Data Reporter and immediately saw the use case for your business then the good news is that is more or less exactly what Oracle has promised.

The bad news is that it does not really go any further than that, it gives end users the opportunity to manage and create their own reporting applications and screens, no more, no less.

Time will have to tell how the community receives this new APEX feature, but for those teams whose ticket system is constantly full of requests to update and adapt reports and columns it may be exactly what they were looking for.

As with all these new features, the best way to see if this would be useful to your business is to experiment with the Data Reporter and see what it could do for your workflows.