Search Results get_wf_item_type




Overview

The APPS.JTF_UM_ENROLLMENT_CREDENTIALS package body is a member of the Oracle E-Business Suite User Management (UM) infrastructure, part of the JTF (Java Technology Foundation) schema family. Its purpose is to manage the provisioning and de-provisioning of user enrollment credentials — the security entitlements expressed as responsibilities, roles, and subscription registrations — that are granted to or withdrawn from an EBS user as a result of an enrollment or self-service registration event. In practical terms, it provides the PL/SQL layer that translates a user enrollment decision into concrete assignments against the FND security model, and that revokes those assignments when an enrollment is terminated or rejected.

The header identifies the module as JTF.UM.PLSQL.JTF_UM_ENROLLMENT_CREDENTIALS and shows the last source revision as version 120.2, dated 2005/10/29. The package participates in the ETRM 12.2.2 repository under owner APPS with an API classification of OTHER, and it is referenced by one other package.

Key Procedures and Functions

The documented interface exposes seven procedures and functions:

  • ASSIGN_ENROLLMENT_CREDENTIALS — the principal entry point that grants the set of credentials associated with an enrollment to a user. It coordinates the individual assignment steps against the subscription and responsibility models.
  • ASSIGN_RESPONSIBILITY — overloaded to assign a responsibility to a user, either by numeric responsibility identifier combined with an application identifier, or by a responsibility key (name) resolved through FND_RESPONSIBILITY_VL. Internally it delegates to Fnd_User_Resp_Groups_Api.Upload_Assignment with an open-ended (null) end date.
  • REVOKE_RESPONSIBILITY — removes a responsibility from a user. It first verifies the assignment exists via Fnd_User_Resp_Groups_Api.Assignment_Exists, then calls Upload_Assignment with both start and end dates set to SYSDATE to terminate the assignment. The source comments confirm that a legacy direct UPDATE against FND_USER_RESP_GROUPS was replaced by the API because that object is no longer a base table.
  • ASSIGN_USER_ENROLLMENT — records the enrollment of a user, linking the user to the subscription definition that governs which credentials are provisioned.
  • REJECT_ENROLL_DEL_PEND_USER — handles the rejection path for a pending enrollment, including deletion or cleanup of the pending user record.

Tables Accessed

The package operates against the following APPS synonyms:

  • FND_USER — the EBS user account record that is the subject of enrollment and credential assignment.
  • JTF_UM_APPROVALS_B — approval metadata for user management requests, used to drive the pending-approval and rejection logic.
  • JTF_UM_SUBSCRIPTION_REG — the registration of a subscriber to a subscription, linking users to the access they have requested.
  • JTF_UM_SUBSCRIPTION_RESP — the mapping between a subscription and the responsibilities it entitles the subscriber to; drives responsibility assignment on enrollment.
  • JTF_UM_SUBSCRIPTION_ROLE — the equivalent mapping for roles granted through a subscription.
  • JTF_UM_USERTYPE_REG — registration of user types used to classify subscribers and determine provisioning behavior.

In addition, the responsibility overloads query FND_RESPONSIBILITY_VL to resolve a responsibility key to its identifier, and all assignment and revocation work is routed through FND_USER_RESP_GROUPS_API rather than direct DML.

Usage Notes

This package is not a user-facing API. It is invoked programmatically by the User Management enrollment and approval flows, and by the forms and concurrent processes that submit or act upon enrollment requests. The presence of l_is_debug_parameter_on, initialized from JTF_DEBUG_PUB.IS_LOG_PARAMETERS_ON(MODULE_NAME), indicates that the package supports FND debug logging and can be traced by enabling the corresponding profile option.

Custom code should not call the internal procedures directly where a supported enrollment API exists, but where integration requires direct responsibility provisioning or revocation, the documented ASSIGN_RESPONSIBILITY and REVOKE_RESPONSIBILITY procedures offer a thin, API-based wrapper around FND_USER_RESP_GROUPS_API. Note that the user's search term get_wf_item_type does not correspond to any documented procedure in this package; that name belongs to a different User Management or workflow utility and should be searched separately. Callers should also be aware that responsibility assignments take effect through the standard FND security model and may require a concurrent request to propagate to the user's active session.