DV Parameters - usage/reference in data set definition (reference in physical SQL definition)

Gabby Rubin-Oracle

We will start with this one to improve the 'cooperability' of the workbook experience with the RPD. As for the second one, I assume that a pre-req for that will be Datasets based on physical SQL and not logical SQL, at least for the example that you had before. This is currently not planned, but why not keep these types of use cases in the RPD domain? Subject Areas are our primary data artifact for advanced enterprise use cases; Datasets are not meant to do everything Subject Areas can. Some parameters/variables support for Dataset definition is valuable but will likely remain at the logical SQL level.

Michael Murray

@Gabby Rubin-Oracle Your update is appreciated! Logical SQL is definitely the primary hurdle to overcome with respect to replicating the 'OAC Classic' Report Variable-Session Variable interoperability that's currently lacking in the OAC (i.e. DV interface).

The secondary request --> the ability @Michal Zima references above to reference parameters for dynamic filtering of SQL-based datasets is something we could do in 'Classic' with session variables in the physical layer of the RPD using an 'Opaque View', so technically it could be done in OAC if the primary requested Idea is implemented.

FAW users, or other users without access to the RPD, would not be able to leverage this functionality, though.

Passing parameters to filter the SQL used to generate OAC datasets is useful functionality as well, especially given performance implications of returning large amounts of data to the OAC application stack, rather than optimizing/pruning the SQL prior to sending the physical SQL to the database. This can be especially critical if OAC cannot access the database directly (e.g. due to firewalls, lack of drivers, etc.)

Thanks again for taking this on!

Gabby Rubin-Oracle

Given the differences in the solution architecture, we are trying to see how these types of use cases will be addressed using DV concepts and artifacts, which might differ from how Classic addresses them. We are exploring a project that will allow workbook authors more flexibility along these lines, but it is a bit early to discuss. It goes beyond the use of parameters in the query; the main driver is to allow increased query complexity by the workbook author beyond what the SA/Dataset provides using the basic visualization query generation. Parameters and 'Opaque Views' like concepts will likely be a part of it, but it is still on the drawing board.

Michal Zima

@Gabby Rubin-Oracle Thanks Gabby - looking forward to hear in future where this project, you mentioned, is heading.

And you are right, combination of setting/overwriting session variable from DV UI with RPD model (SQL query, referencing session variables defined in physical layer) would be sufficient option.

Gabby Rubin-Oracle

Happy to announce…

Confirmed for OAS 2025 as well.

Michal Zima

@Gabby Rubin-Oracle Thanks, looking forward to try/test in OAS 2025.

Jayko Paten

@Gabby Rubin-Oracle Does this allow passing a parameter from DV to a classic report?

Gabby Rubin-Oracle

I would not define that in that way; it does allow Workbook parameters to drive the values of request variables, which, in turn, can impact what is presented in classic reports. However, I consider "passing parameters" to be a different type of gesture.