Search Results start_fulfillment_request




Overview
Explore in AI Chat

Overview

APPS.JTF_FM_PROCESS_REQUEST_WF is a PL/SQL package body that serves as the workflow-facing integration layer for the Oracle E-Business Suite fulfillment request framework. Its central purpose is to receive a fulfillment request, publish its attributes into the Oracle Workflow engine, and drive the resulting business event toward an external or downstream fulfillment provider. The package is the counterpart to the request submission API: whereas the submission routine stages the request data, JTF_FM_PROCESS_REQUEST_WF executes the workflow item and manages the subsequent exchange with the provider.

Because the package encapsulates the mechanics of WF_ENGINE item attribute assignment and workflow initiation, callers are insulated from the internal item type and attribute naming conventions. This is consistent with the ETRM classification of the object as OTHER, indicating it is an internal infrastructure component rather than a public business API. The package is present in both the 12.1.1 and 12.2.2 code lines; the header comment references script jtffmwfb.pls version 120.0, confirming its status as a long-standing seeded component of the fulfillment management module.

Key Procedures and Functions

  • START_FULFILLMENT_REQUEST — The principal entry point. It accepts the workflow item type and item key together with a broad set of request attributes, including content XML, content identifier, request identifier, template, subject, party information, priority, source code, object type and identifier, order and document references, server and queue response settings, and extended header data. Parameter declarations follow the standard EBS API convention with p_api_version, p_init_msg_list, p_commit, and p_validation_level input arguments and x_result, x_msg_count, x_msg_data, and x_return_status output arguments. Internally it sets the item user key and writes item attributes such as CONTENT_XML and API_VERSION through wf_engine.SetItemAttrText before launching the workflow.
  • SUBMIT_FULFILLMENT_REQUEST — Handles submission of the fulfillment request once workflow attributes have been established, acting as the bridge between the staged item and the fulfillment engine.
  • CHECK_REQUEST_RESULT — Evaluates the outcome returned by the fulfillment provider and determines whether the request completed successfully or requires further handling.
  • SCHEDULE_CALLBACK — Arranges the callback activity used to poll or re-enter the workflow when the provider processes the request asynchronously.
  • CHECK_IF_CALLBACK_REQUIRED — The routine corresponding to the common search term. It determines whether the fulfillment request configuration demands a follow-up callback to the provider, allowing the workflow to branch between synchronous completion and deferred polling.
  • VERIFY_EXTERNAL — Performs verification against the external fulfillment system to confirm the request was received and is being processed.
  • VERIFICATION_FAILED — Handles the failure path when external verification does not succeed, permitting the workflow to record the error and route to exception handling.

Tables Accessed

The ETRM metadata does not document specific base tables referenced through APPS synonyms for this package. The package relies principally on Oracle Workflow runtime tables (WF_ITEMS, WF_ITEM_ATTRIBUTES) when setting item attributes and item user keys, and on fulfillment request tables to persist request state. Because no table list is published, customizations should not assume access to any particular base table.

Usage Notes

JTF_FM_PROCESS_REQUEST_WF is invoked indirectly. The ETRM metadata records zero referencing packages, which indicates it is not called from other PL/SQL units within the documented scope. Instead it is driven by the fulfillment workflow itself — the seeded item type calls these procedures as function activities as the request progresses from submission through verification to completion or callback. Direct invocation from a form or concurrent program is atypical; the correct integration point for custom code is the fulfillment submission API, which in turn launches the workflow that reaches this package. Developers extending the fulfillment flow should treat the procedure signatures as internal and avoid calling them directly, since the workflow engine supplies item type, item key, and attribute values at runtime.