Search Results jtf_fm_request_grp_w




Overview
Explore in AI Chat

Overview

APPS.JTF_FM_REQUEST_GRP_W is a public wrapper package that fronts the internal logic of the JTF (Oracle Applications Foundation / CRM Technology Foundation) Foundation Manager request infrastructure. Its primary business function is to build, submit, and manage document-generation requests that the Foundation Manager framework records, queues, and dispatches to physical or electronic output destinations — printers, e-mail, fax, and file paths. In the Oracle EBS 12.1.1 and 12.2.2 releases the package provides the PL/SQL entry point through which application modules ask the Foundation Manager to render content (typically XML-based documents) and to create the corresponding request rows in the JTF request tables. The _W suffix indicates this is the callable wrapper layer exposed to APPS, while the underlying procedural logic and package-level types reside in the matching base package, JTF_FM_REQUEST_GRP, to which this wrapper delegates. The package is declared AUTHID CURRENT_USER, so it executes under the privileges of the calling schema, and callers rely on APPS synonyms for any underlying tables. The object carries the header identifier jtfgfmws.pls 120.2, a lineage consistent with the mid-2000s Foundation Manager code line still shipped in current EBS releases.

Key Procedures and Functions

The package exposes thirteen documented entry points, which fall into three functional groups.

  • Request submission. SUBMIT_BATCH_REQUEST builds and submits a single Foundation Manager request that can carry multiple content items and processing options in one call. It is the procedure associated with the search term and is the primary supported path for applications that must generate a batch of documents or outputs together.
  • Mass submission. SUBMIT_MASS_REQUEST provides the higher-volume variant, submitting many requests or a mass content set in a single invocation.
  • Content XML generation. GET_CONTENT_XML assembles the XML representation of a single content item, accepting document, media, destination, and bind-variable information. GET_MULTIPLE_CONTENT_XML performs the same assembly across several content items in one call.
  • Request cancellation. CANCEL_REQUEST cancels an existing request, NEW_CANCEL_REQUEST is the corresponding newer-generation cancellation entry point, and CORRECT_MALFORMED and RESUBMIT_MALFORMED handle request rows that failed the initial submission or validation, allowing them to be repaired and resubmitted.
  • Rosetta table conversion utilities. ROSETTA_TABLE_COPY_IN_P3, ROSETTA_TABLE_COPY_OUT_P3, ROSETTA_TABLE_COPY_IN_P5, and ROSETTA_TABLE_COPY_OUT_P5 convert PL/SQL collection types between the wrapper's generic types and the Foundation Manager base package's g_varchar_tbl_type and g_number_tbl_type. They support the bind-variable arrays used by the content XML procedures and are not intended for direct application use.

Tables Accessed

The documented table reference is PLITBLM, reached through an APPS synonym. PLITBLM is the standard Oracle EBS repository for persistent temporary and batch data and is used here to hold intermediate values generated while assembling and submitting Foundation Manager requests, particularly the bind-variable collections and content sets associated with batch and mass submissions. Because the metadata documents only this table, request and content rows written by the package should be understood to be managed through the underlying JTF_FM_REQUEST_GRP base package rather than through direct DML in the wrapper.

Usage Notes

JTF_FM_REQUEST_GRP_W is normally invoked from application code rather than from a general-purpose concurrent program. In EBS 12.1.1 and 12.2.2, it is called by forms-based and OAF-based Oracle Applications modules, and it is referenced by two other packages in the APPS schema that act as consumers of the Foundation Manager API. Custom code should call SUBMIT_BATCH_REQUEST with an initialized message list, the requested commit and validation levels, and the content and destination parameters; callers must then inspect x_return_status and the message count and data outputs before assuming success. All submission and cancellation procedures require a commit decision from the caller, and the Rosetta conversion routines must be used only with the collection types they were defined for. Because the object is a wrapper, functional behaviour and error semantics are ultimately determined by JTF_FM_REQUEST_GRP, and the wrapper should always be referenced through APPS rather than by schema-qualified direct calls.