nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

OAS 7.0: Efficient way to delete user's 'My Folders' and Agents after the user leaves

Analytics_User

OAS 7.0 (OBIA 7.6.4, EBS 12.2): Hi, is there a way to delete a user's "My Folders" and Agents when the user leaves. We are having difficulty with recurring agents set up by users who are not with the company anymore. Any input to clean up these agents is highly appreciated.

Find more posts tagged with

Accepted answers

Gianni Ceresa

What Steve said is important: changing things in the scheduler table also require, in an ideal situation, to update the agent in the catalog to match the config of the scheduler table. It isn't ideal, but should break (this is actually what OAS uses to detect that you have agents that should be enabled but aren't currently in the scheduler as enabled and therefore OAS will try to enable them again when you use this feature in "Monitor Deliveries").

I don't remember right now what flags to set (I generate just delete everything :D ).

What you can do is to create an agent yourself and enable it. Go in the scheduler tables and look at how it does look like. Then disable that agent and check what did change in the scheduler tables. At this point you will know how to disable them, but you will have a conflicting information between the scheduler and the agents.

That's why I would say that, if the final result is to delete those objects fully from the catalog, test that as well. Delete the agent you just created and check what the scheduler tables show (it is possible that the config stays in the scheduler tables!).

The first time you do that, just for safety reasons, you could stop your OAS first, take a backup of the scheduler tables you are going to change, do the job, restart your OAS.

When OAS is down, you can't generate conflicts, OAS will discover the new scheduler config when it will start. But the keyword is backup: take a snapshot and export the BAR, backup the database objects you are going to change, change database tables with your OAS down. That's the safest approach as you have various ways to recover in case something goes badly… (it isn't extremely complex, it just require to be careful, think twice and execute once and not the opposite, till you get a bit more comfortable with the operation).

All comments

Sumanth V -Oracle

@User_SI7HK - We can use the Catalog Manager Command Line Interface to delete the objects from catalog. Please refer the below documentation for more details on usage.

https://docs.oracle.com/en/middleware/bi/analytics-server/administer-oas/use-catalog-manager-command-line-interface.html

TSoracco-Oracle

Hi — Please see the following note —> How To Retrieve Agent Information Using Catalog Manager (Doc ID 2732776.1). This note provides the steps to do exactly what you are looking for. Let me know if it helps.

Gianni Ceresa

Not sure if Catalog Manager will really be able to do much, "my folder" has a very strict (private) security and Catalog Manager in OAS is only "online", meaning that you have the security of the account you use to login applied. Before OAS, that task was easily done in Catalog Manager in "offline" mode, where no security was enforced.

From the first OAS release, that kind of management and administration tasks where ignored and no real tool existed.

I believe the idea to solve those issues is now in the DV console tools "Content" and "Monitor Deliveries". I just don't remember what they were like in OAS 7.0, they maybe weren't even there, or just partially there…

What matter the most for you is probably to stop the scheduled agent in the private "my folder" of a user who left the company. You could use "act as" to impersonate the user and then disable any active agent.

My way to handle this kind of situation is quite simple: delete any active agent scheduled from the scheduler tables in the BIPLATFORM schema, and the same for the catalog objects, deleting all the records of those objects. Clean and simple. This approach is not officially supported, but if done correctly, there is no way to know it was done (because there is nothing left behind to even say it has been done). The risk is that you can also corrupt your catalog or scheduler tables if not done correctly. (You better be extremely sure of what you are doing when manipulating tables in BIPLATFORM, and always take a backup first.)

Steve F-2

Agree with @Gianni Ceresa

The best method is to transfer ownership, then managed the content.

You can do that here: Manage Content

Analytics_User

Thanks Gianni, I will have this approach with changing ownership, tested out and let you know.

Analytics_User

Thanks Gianni, DV>Content Management and Change ownership method won't be efficient for us as we have over 7k users which are no longer with company, so we are going updating BIPLATFORM table route. As it is unsupported activity, what would be the safest way to stop these obsolete agent from running ?

Set the 'DELET_FLG' column to 'Y' or 'DISABLE_FLG' to 'Y'
Set the 'NEXT_RUNTIME_TS' column to null

in S_NQ_JOB table for the agents owned by obsolete employees ?

Please advise.

Steve F-2

Siraj ( @User_SI7HK ),

Multi-selection is available in Change Ownership and Monitor Deliveries . You can use shift+select (command+shift) if MacOS) to select multiple agents, or control/command + select for specific agents, then right+click to bring up a menu to delete, enable, disable, resume, suspend.

I do understand that 7K is a lot.

If you go the unsupported route, make sure you then go and delete them in the catalog, as the schemas and catalog statuses will be out of sync.

Gianni Ceresa

I don't remember right now what flags to set (I generate just delete everything :D ).

The first time you do that, just for safety reasons, you could stop your OAS first, take a backup of the scheduler tables you are going to change, do the job, restart your OAS.

Analytics_User

Thanks Gianni, we will examine the schedular tables by creating a test agent and make changes to it to see the effects on the tables and accordingly rehears the updates in lower environment after taking backups, BAR export, OAS shutdown. Thanks again, much appreciated.