Search Results start_servereq_workflow

Overview

The APPS.CS_WORKFLOW_PKG package is a core Oracle Service (CS) database component in Oracle E-Business Suite 12.1.1 and 12.2.2 that governs the lifecycle of Oracle Workflow processes associated with service requests and service request actions. It provides the server-side logic used to determine whether a service request item or an action item remains active, to retrieve the display name of a workflow associated with a service request, and to initiate or abort the corresponding workflow instances.

The package resides in the APPS schema and carries a VALID status in both releases. Under the ETRM classification it is documented as an OTHER API rather than a public, formally supported open interface. Its principal design intent is to bridge the Service Request data model—incident types, statuses, and incident records—with the Oracle Workflow engine, ensuring that workflow activity stays consistent with the state of the underlying service request. It is referenced by seven other packages, including CS_SERVICEREQUEST_PVT, CS_WF_EVENT_PKG, CS_WORKFLOW_PUB, and itself, and is exposed to several Service views such as CS_INCIDENT_ACTIONS_V, CS_INCIDENT_ACTION_AUDIT_V, and CS_INCIDENT_TYPES_RG_V, which confirms its role as a shared, low-level utility for the Service module.

Key Procedures and Functions

Nine procedures and functions are documented for this package. Their purposes are as follows:

• IS_SERVEREQ_ITEM_ACTIVE — Determines whether the Workflow item associated with a given service request is still active, allowing callers to avoid duplicate workflow starts.
• IS_ACTION_ITEM_ACTIVE — Performs the equivalent check for a service request action item's workflow instance.
• GET_WORKFLOW_DISP_NAME — Returns the display name of the workflow configured for a service request, used for presentation and logging.
• START_SERVEREQ_WORKFLOW — Initiates the workflow process for a service request, typically when the request is created or transitions into a workflow-driven status.
• ABORT_SERVEREQ_WORKFLOW — Terminates an in-flight service request workflow, invoked when a request is cancelled or otherwise closed prematurely.
• START_ACTION_WORKFLOW — Launches the workflow associated with an individual service request action, such as an approval or task action.
• ABORT_ACTION_WORKFLOW — Aborts the workflow instance tied to a specific action item.

The remaining documented entries follow the same naming conventions and support the internal orchestration of these operations. No parameter lists are published in the metadata, and the package header and body are both valid.

Tables Accessed

The package reads and writes the following objects through APPS synonyms:

• CS_INCIDENTS_ALL_B — The base service request (incident) table, used to identify the request and its organizational context.
• CS_INCIDENT_STATUSES and CS_INCIDENT_TYPES — Provide status and type attributes that determine whether a workflow applies and how it should behave.
• CS_WF_PROCESS_ID_S — The sequence used to generate workflow process identifiers for Service requests.
• WF_ITEMS, WF_ACTIVITIES, and WF_PARAMETER_LIST_T — Workflow engine tables used to check item activity, resolve activity definitions, and pass parameters into started processes.
• HZ_LOCATIONS and HZ_PARTY_SITES — TCA tables supplying party site and location context for the request.
• DUAL — Used for scalar function evaluation. SYS.STANDARD is referenced for standard PL/SQL types.

Usage Notes

CS_WORKFLOW_PKG is not intended for direct end-user invocation. It is called programmatically from the Service Request business logic—most notably CS_SERVICEREQUEST_PVT—and from event handlers such as CS_WF_EVENT_PKG and CS_WORKFLOW_PUB, as well as by the Service views that expose workflow state. Consequently, workflow starts and aborts occur implicitly when a Service Request form saves a new or modified request, when a concurrent program processes service request activity, or when workflow business events fire.

Because the package is classified as OTHER and is not a published open API, customizations should avoid calling it directly. Where extensions are required, the supported approach is to use the documented Service Request public APIs and workflow event subscriptions, which in turn invoke CS_WORKFLOW_PKG internally. Direct calls risk bypassing validation performed in the surrounding private layer and may be affected by changes between 12.1.1 and 12.2.2. Developers should also note that the package depends on the Workflow schema, so the Workflow services must be installed and running for its procedures to function correctly.