adm_hooks_api

Runs the customer PL/SQL registered against a product event. Each hook is a snippet stored in adm_hooks.hook_plsql, executed as dynamic PL/SQL with the event’s parameters bound by name - so a hook is a call to your own procedure, not a procedure body:

my_adm_hooks.after_new_file_upload(
  p_document_id => :p_document_id
, p_version_id  => :p_version_id
);

Hooks are registered in the administration section of the application, which also shows the expected signature and an example for each event. There are exactly three events - AFTER_NEW_FILE_UPLOAD, AFTER_NEW_FILE_VERSION and AFTER_NEW_FOLDER_CREATION - and the c_after_* constants in this spec are their keys.

Two properties decide how a hook behaves:

• It runs inside the caller’s transaction, after the operation is written but before it is committed. A hook that raises therefore ABORTS the operation, which is the supported way to enforce a rule ADM does not have. A hook must never commit or roll back: the transaction is not its own, and committing would persist half of ADM’s work.
• It runs wherever the API does. The same hook fires for an upload from the browser, from a batch script and from a job, inside an APEX session or outside one.

When the hook code fails, the failure is logged with its own message and backtrace and re-raised as adm_error.c_err_hook_failed naming the hook, so the user never sees the customer code’s raw error. Hook code that raises errors of its own must use -20700 .. -20999, the range reserved for customer code.

The run_* procedures are called by the product at the point the event happens; there is nothing here for customer code to call.