Search Results init_user_and_role

Overview

APPS.AHL_WORKORDER_SEARCH_PUB is a public PL/SQL package in the Oracle E-Business Suite 12.1.1 and 12.2.2 environments that supports the Oracle Complex Maintenance, Repair and Overhaul (CMRO) / Enterprise Asset Management "AHL" product family. Its purpose is to expose a controlled search interface over work orders, allowing callers to retrieve work order records based on an incoming search criteria record. The package is classified as a PUB (public) API, meaning it is intended for external invocation by forms, concurrent programs, BPEL processes, and custom code rather than being an internal helper unit.

The package body declares the standard API conventions: a package name constant, debug flag and log prefix, an FND_API-based error handling model, and a hard-coded role key constant (G_BPEL_USER_ROLE_KEY := 'AHL_PRD_TECH_RESP') used for BPEL-driven session initialization. This role key reflects the package's design assumption that search calls may originate from a workflow or BPEL context and require an explicit user/responsibility session before querying work order data.

Key Procedures and Functions

• init_user_and_role — A helper function that accepts a user identifier (typically a user name), resolves the corresponding FND_USER.USER_ID, and resolves the responsibility ID for the role key AHL_PRD_TECH_RESP from FND_RESPONSIBILITY_VL. It then calls FND_GLOBAL.APPS_INITIALIZE using the resolved user, responsibility, and application ID 867, followed by MO_GLOBAL.INIT('AHL') to initialize multi-org context. If the user name is not found, it raises FND_API.G_EXC_UNEXPECTED_ERROR after staging the message AHL_PRD_INV_BPEL_USR with the offending user name as a token. It returns FND_API.G_RET_STS_SUCCESS on success.
• get_wo_search_results — The documented public procedure of the package. It implements the assigned work order query. It receives a work order search criteria record (WORKORDERS_SEARCH_REC_TYPE) and returns a collection of work order results (WORK_ORDERS_TYPE). It follows the standard OAF/FND API signature pattern with API version, initialization message list flag, commit flag, validation level, module type, and an optional user ID, together with the standard outgoing return status, message count, and message data parameters.

Tables Accessed

The package performs its session initialization and validation against two core EBS foundation tables:

• FND_USER — Queried via FND_USER to translate an incoming user name into the numeric USER_ID required by FND_GLOBAL.APPS_INITIALIZE.
• FND_RESPONSIBILITY_VL — Queried by RESPONSIBILITY_KEY to resolve the responsibility ID associated with the constant role key AHL_PRD_TECH_RESP.

Work order data itself is expected to be sourced from AHL and related EAM work order tables referenced inside get_wo_search_results; however, the supplied excerpt does not enumerate those tables, so they are not asserted here beyond the two foundation tables explicitly visible in the code.

Usage Notes

The package is typically invoked from environments where the runtime session has not already been established — most notably BPEL or web service integrations that must impersonate a workload user and responsibility before accessing AHL work order data. A caller would first invoke init_user_and_role to establish the FND and multi-org context, then call get_wo_search_results with a populated search record to obtain matching work orders.

Because the role key is hard-coded to AHL_PRD_TECH_RESP (with the profile lookup commented out in the source), deployers should be aware that the responsibility used is fixed and must exist in the target instance. Custom code and OAF pages that already run under an authenticated session do not need to call the initialization function and can invoke the search procedure directly, respecting the standard API contract of checking x_return_status, consuming messages when x_msg_count is greater than zero, and honoring the commit flag rather than issuing their own commits.