Search Results get_custom_wf_process

Overview

WSH_WF_STD is the Shipping Execution workflow integration package in Oracle E-Business Suite, owned by APPS and classified as an OTHER API. It provides the programmatic bridge between Oracle Shipping (WSH) transactional entities — trips and deliveries — and the Oracle Workflow engine. Its primary business purpose is to select, validate eligibility for, and launch tracking and "Ship to Deliver" (SCPOD) workflow processes against trips and deliveries, and to record the launched process name back on the shipping transaction records. The package is defined with AUTHID CURRENT_USER and declares a package-level global, G_RESET_APPS_CONTEXT (default FALSE), which governs whether workflow item attributes are used to reset the application context during workflow execution. The header identifies the entity types handled as 'TRIP' and 'DELIVERY', keyed by TRIP_ID or DELIVERY_ID together with an organization identifier. The package is a foundational integration point: it is referenced by 19 other packages within the EBS application schema.

Key Procedures and Functions

The ETRM metadata documents 17 procedures and functions. The central entry point is START_WF_PROCESS, which starts a tracking workflow process for an entity after confirming eligibility (no process already exists for the entity, and global and shipping parameters admit the entity), then updates the shipping record with the process name launched. START_SCPOD_C_PROCESS starts the "Ship to Deliver" controlling workflow process for a delivery, with the entity always being a delivery. CONFIRM_START_WF_PROCESS supports confirmation of process initiation, while PROCESS_SELECTOR determines which workflow process applies to a given entity. CHECK_WF_EXISTS and WF_EXISTS provide existence verification for workflow instances, and GET_CUSTOM_WF_PROCESS retrieves a customer-defined workflow process. RAISE_EVENT raises a workflow business event. PURGE_ENTITY removes workflow data associated with an entity. LOG_WF_EXCEPTION records workflow error conditions. INSTANCE_DEFAULT_RULE — the object matching the user's search term — supplies the default rule logic associated with a workflow instance, and RESET_APPS_CONTEXT_ON / RESET_APPS_CONTEXT_OFF toggle the context-reset behavior controlled by G_RESET_APPS_CONTEXT. Carrier-related processing is handled by GET_CARRIER, HANDLE_TRIP_CARRIERS, and ASSIGN_UNASSIGN_CARRIER. GET_DELIVERIES retrieves delivery records, supporting workflow decision and routing logic. Return and status conventions follow WSH_UTIL_CORE.G_RET_STS_SUCCESS for success signaling.

Tables Accessed

The package operates against several documented tables accessed through APPS synonyms. WSH_NEW_DELIVERIES and WSH_TRIPS are read and updated to verify eligibility and to persist the launched workflow process name for deliveries and trips respectively. WSH_DELIVERY_DETAILS supplies delivery line-level detail. MTL_PARAMETERS provides organization-level inventory parameters, consistent with the organization-scoped parameters of the start procedures. HZ_CUST_ACCOUNTS and HZ_PARTIES supply customer and party information used in carrier and delivery resolution. WF_EVENT_T and WF_PARAMETER_LIST_T are Workflow engine tables used for event raising and parameter passing, and PLITBLM is the standard PL/SQL integer table type used for list-based parameter handling.

Usage Notes

WSH_WF_STD is not a form-level API in the conventional sense; it is invoked from shipping forms, concurrent programs, and custom PL/SQL when a trip or delivery must enter or be evaluated against a Workflow process. Typical invocation patterns include calling START_WF_PROCESS or START_SCPOD_C_PROCESS after a delivery or trip is created or confirmed, checking WF_EXISTS or CHECK_WF_EXISTS before initiating a process to avoid duplicate instances, and using RAISE_EVENT with LOG_WF_EXCEPTION for event-driven and error-handling flows. Because the package is referenced by 19 other packages, customizations should treat it as a shared dependency. The G_RESET_APPS_CONTEXT global, together with RESET_APPS_CONTEXT_ON and RESET_APPS_CONTEXT_OFF, should be set explicitly in custom code that invokes workflow from contexts requiring deterministic application context behavior.