Search Results trig_type_date

Overview

AMS_WFTRIG_PVT is a private PL/SQL package body in the Oracle Marketing (AMS) module of Oracle E-Business Suite, owning schema APPS. Its documented purpose is to contain the workflow procedures supporting Continuous Campaigning within Oracle Marketing. The package bridges Oracle Marketing trigger definitions and Oracle Workflow, providing the runtime logic by which campaign triggers are evaluated, scheduled, approved, and executed.

The header comment records a creation date of 22-MAR-2001 and a substantial revision history, including the 2003 trigger redesign, the replacement of direct schedule API execution with a Workflow Business Event in EXECUTE_SCHEDULE (26-SEP-2003), corrections to repeat schedule availability logic, Workflow item owner assignment for trigger workflows, and a monitor history purge concurrent program added in August 2005. A final entry notes fixes for R12, which covers both 12.1.1 and 12.2.2 installations. The package is classified PVT, indicating it is an internal implementation package rather than a public API, and it is referenced by zero other packages.

Key Procedures and Functions

The package exposes 23 documented procedures and functions. Principal among them:

• STARTPROCESS — Entry point that initiates the trigger workflow for a given trigger identifier, extracting process variables from the database at startup.
• INITIALIZE_VAR / FIND_OWNER — FIND_OWNER is a private routine called by Initialize_Var to resolve the user name of the activity owner when the process begins.
• SELECTOR, CHECK_TRIGGER_STATUS, PERFORM_CHECK, RECORD_RESULT — The evaluation cycle: selecting triggers eligible for processing, testing their status, performing the configured check, and persisting the outcome.
• CHECK_REPEAT, GET_AVAL_REPEAT_SCH, GET_AVAL_SCH, CHECK_ACTIVE_SCH, SCHEDULE_TRIG_RUN — Scheduling logic governing repeat and available schedules, active schedule validation, and scheduling of a trigger run.
• TRIG_TYPE_DATE — Supports date-based trigger type determination, relevant to trigger scheduling semantics.
• REQUIRE_APPROVAL, NOTIFY_CHK_MET, ACTION_NOTIFICATION — Approval rule evaluation and notification when a trigger check condition is met.
• EXECUTE_SCHEDULE — Executes a schedule; per the history, target group generation precedes CSCH activation and execution is dispatched through a Workflow Business Event.
• ACTION_EXECUTE, EVENT_CUSTOM_ACTION, EVENT_TRIG_NEXT, ABORTPROCESS — Execution of trigger actions, handling of custom action events, advancement to the next trigger event, and process termination.
• GET_USER_ROLE — Resolves the role associated with a user for workflow routing.

Tables Accessed

The package reads and writes the core Oracle Marketing trigger and campaign tables through APPS synonyms:

• AMS_TRIGGERS, AMS_TRIGGER_ACTIONS, AMS_TRIGGER_CHECKS, AMS_TRIGGER_RESULTS — Trigger definitions, their actions and check conditions, and the results recorded by RECORD_RESULT.
• AMS_CAMPAIGNS_ALL_B, AMS_CAMPAIGN_SCHEDULES_B — Campaign and schedule definitions used during execution and scheduling.
• AMS_ACT_LISTS, AMS_ACT_METRICS_ALL — Activity lists and metrics against which checks are performed.
• AMS_APPROVAL_RULES — Approval rule data consumed by REQUIRE_APPROVAL.
• WF_PARAMETER_LIST_T — Workflow parameter list type used when launching workflow processes and events.
• DBMS_UTILITY — Oracle-supplied utility package used for error formatting and diagnostics.

Usage Notes

Because AMS_WFTRIG_PVT is a private package, it is not intended for direct invocation by customer code or forms; it is called internally by Oracle Marketing and Oracle Workflow when a campaign trigger process runs. Typical invocation paths include the Workflow background engine executing trigger workflows launched via StartProcess, and the concurrent program added in August 2005 that purges monitor history. The use of a Workflow Business Event in EXECUTE_SCHEDULE means schedule execution may be observed through the standard Workflow event and notification infrastructure, including approval notifications generated by the notification procedures. Customizations should target documented public APIs rather than this package, since internal signatures and logic are subject to change between release levels. The behavior is consistent across 12.1.1 and 12.2.2, as the last documented modification was the R12 fix set in August 2005.