Search Results submit_previewed_request




Overview

JTF_FM_REQUEST_GRP is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that anchors the Foundation Message (FM) fulfillment and message-generation infrastructure used across ETRM and CRM modules. Its API classification is GRP (group), indicating that it exposes a cohesive set of related entry points rather than a discrete business entity service. The package is responsible for creating, submitting, tracking, and rendering fulfillment requests — the outbound communications such as e-mail, fax, and print documents that Oracle applications generate for customers and partners.

In Oracle EBS 12.1.1 and 12.2.2, JTF_FM_REQUEST_GRP centralizes request lifecycle management so that numerous AMS, ASO, AST, CS, IES, IEX, and OKL packages do not each implement their own message-dispatch logic. The package depends on FND_API for standard API error-handling and message-stack conventions, and it is referenced by more than thirty sibling packages, confirming its role as a shared utility layer within the fulfillment stack.

Key Procedures and Functions

The package publishes twenty documented procedures and functions that cover the full request lifecycle:

Collectively these entry points give callers uniform control over submission, rendering, cancellation, pause/resume, and error correction without directly manipulating the underlying request tables.

Tables Accessed

The package reads and writes a defined set of APPS-synonym tables that constitute the fulfillment request repository:

Usage Notes

JTF_FM_REQUEST_GRP is not typically invoked directly by end users. It is called programmatically by concurrent programs, Oracle Workflow activities such as JTF_FM_PROCESS_REQUEST_WF, and module packages including IEX_SEND_FFM_PVT, AMS_FULFILL_PVT, OKL_FULFILLMENT_PUB, and OKL_AM_UTIL_PVT. Users searching on OKL_AM_UTIL_PVT will encounter this package because lease and asset-fulfillment routines in the OKL schema delegate message dispatch to JTF_FM_REQUEST_GRP.

Because entry points comply with FND_API conventions, custom code should invoke them rather than perform direct DML on the underlying JTF_FM tables; this preserves queue integrity, auditing, and resubmission handling across 12.1.1 and 12.2.2 environments.