Hi,
I didn't check these details directly because didn't have a need so far.

Assuming your RCU schemas are on an Oracle database, you could enable audit logging for those schemas (just BIPLATFORM should be enough, the other schemas are supposed to be for other things) and you will be able to see what happen when you schedule something and when you execute something.

That's the easiest way to find the answer, because I'm quite sure this isn't something documented. A number of tables in BIPLATFORM have proper foreign keys defined, that should give you the relationships. But looking at the audit logs of your database will give you all the details of every query generated by the product.

That's how I found a number of undocumented answers to my questions in the past.

It's something your DBA should easily be able to help you with.

Dilek, it seems to be quite "messy" with lot of places where things happen…

For example, when I reload a dataset based on a query, what seems to be giving me some useful information is looking in W_ETL_RUN_OBJ by using the object_id column, and from there taking the run_wid column value to query W_ETL_LOG with obj_wid equal the previous run_wid, and there the textfield gives me all the details of the reload. There is also W_ETL_RUN_SOBJ that seem to be related as well, looks like the same thing, no clue what the difference is (welcome to BIPLATFORM, the place where you shouldn't be…).

W_ETL_LOG is a "fun" one because the textfield is updated all the time during the execution of a process appending the new log text to the exist value. Therefore it works better when checking finished jobs to not having a moving value all the time you query it.

There definitely must be a better way to get just the info you look for, because that's what shows on screen when you inspect your dataset. But at the same time there seem to be so many tables involved in everything that it is maybe not really straightforward. Looking for an API is maybe a safer option as it will do the whole job and collect all you need in a single request.

As said, if you want to dig deeper just create an audit policy for all the actions, enable it only for the BIPLATFORM user, and then you filter things when querying the audit logs.

With some observation of the patterns, excluding all the noise you will capture (lot of schedule process running all the time in the background making lot of noise), you will identify the logic of things happening.