Search Results start_customwf

Overview

IEX_STRY_CUWF_PUB is a public PL/SQL package owned by the APPS schema in Oracle E-Business Suite, associated with the Advanced Collections (IEX) product family and its Strategy (STRY) subsystem. Its documented purpose is to launch and coordinate custom Oracle Workflow processes that run alongside the standard Advanced Collections delinquency strategy workflow. The package is declared AUTHID CURRENT_USER, so all SQL executed within it is resolved against the privileges of the invoking user rather than the definer, a characteristic that carries important implications for grants and synonyms on the referenced tables.

The package is the entry point that allows a delinquency strategy step to hand control to an organization-specific workflow, and then to signal the parent strategy workflow when that custom process completes. It is therefore central to any implementation that extends delivered Collections strategy behavior with bespoke correspondence, escalation, or approval flows.

Key Procedures and Functions

The ETRM metadata documents four procedures. No parameter lists are reproduced here beyond what the source excerpt confirms.

• START_CUSTOMWF — The primary API. It launches a custom workflow defined by the caller. It accepts a record of type CUSTOM_WF_Rec_Type, which carries the strategy identifier, the work item identifier, the custom workflow item type name, and the user, responsibility, and application identifiers to be used as the workflow security context. The procedure follows the standard EBS API convention, exposing an API version, an initialization flag, a commit flag, and the usual x_return_status, x_msg_count, and x_msg_data OUT parameters. This is the procedure behind the search term start_customwf.
• WF_SEND_SIGNAL — Sends a signal to the parent (main) workflow indicating that the custom workflow has finished, and updates the corresponding work item. It is configured as a Workflow function activity with the conventional itemtype, itemkey, actid, funcmode, and result signature.
• START_PROCESS — The standard selector/callback entry point expected by the Oracle Workflow engine. It receives item type, item key, activity identifier, and command, and returns a result, allowing the engine to invoke package logic through a standard interface.
• WAIT_ON_HOLD_SIGNAL — Added under Bug#4506922 (December 2005) for use as the function WAIT_ON_HOLD_SIGNAL within workflow IEXSTRCM. It blocks the strategy workflow until a hold-related signal is received, using the same standard Workflow callback signature.

Tables Accessed

The package operates across the Collections strategy and receivables data model. IEX_STRATEGIES and IEX_STRATEGY_WORK_ITEMS provide the strategy definition and the work item that START_CUSTOMWF launches against and that WF_SEND_SIGNAL later updates. IEX_DELINQUENCIES and IEX_DELINQUENCIES_ALL hold the delinquency records driving the strategy. AR_PAYMENT_SCHEDULES supplies the underlying receivable and payment schedule information. HZ_PARTIES and JTF_RS_RESOURCE_EXTNS identify the customer and the resource or collector associated with the delinquency, supporting assignment and notification decisions. All are referenced through APPS synonyms, consistent with the AUTHID CURRENT_USER declaration.

Usage Notes

IEX_STRY_CUWF_PUB is typically invoked from Oracle Workflow rather than directly by end users. In a standard implementation, a Collections strategy step is configured to call START_CUSTOMWF to spawn an organization-specific workflow; when that workflow ends, WF_SEND_SIGNAL returns control to the parent strategy and updates the work item status. The package is documented as being referenced by one other package, indicating layered use within the Collections workflow framework. Because the API is classified PUB, it may be called from custom PL/SQL and concurrent programs, but callers should supply the security context fields in the custom workflow record so that the spawned process runs under the intended user and responsibility. Behavior is equivalent on EBS 12.1.1 and 12.2.2; the package header dates from 2005 and remains stable across both releases.