Skip Headers

Oracle Credit Management User Guide
Release 12.1
Part Number E13502-04
Go to Table of Contents
Go to previous page
Go to next page

Credit Request Business Events

This appendix describes business events that you can use with Oracle Credit Management.

This appendix covers the following topics:

Credit Request Business Events

Oracle Credit Management leverages the Business Events System available in Oracle Workflow Release 2.6 to create business events during the life cycle of a credit request. This lets customers/consumer products perform custom processing.

Note: Credit request events are raised by the Credit Request processing workflow engine; users should not manually raise them.


The Event Subscription

  1. Log on to Oracle Applications with the System Administrator responsibility.

  2. Navigate Workflow > Add subscription to Event.

  3. Every Credit Request event follows the same naming convention:


For example, if you want to subscribe your business process (such as custom recommendations) to the implementation of the default recommendations for a credit request, then you should subscribe your routine or custom program (also known as the rule function) to the event.

Deferred Subscriptions

The Workflow Release 2.6 Business Event System allows subscriptions to be executed in deferred mode so that no overhead is added to the process raising the event. For Credit Request business events, it is recommended that user subscriptions be executed in the deferred mode.

One of the mechanisms to defer a subscription would be by setting the phase number of a user-defined subscription to greater than 99. For additional details on different mechanisms for deferring a subscription, see: Event Subscriptions, Oracle Workflow Developer's Guide.

When the credit request processing flow raises an event for a deferred subscription, the event message is sent to the deferred queue.

Subscriptions will be executed when the "Workflow Agent Listener" with the parameter "WF_DEFERRED" is executed. When this concurrent program is executed, every subscription from every instance of events in the DEFERRED queue at that moment will be executed.

This concurrent program is seeded in the request group of the System Administrator responsibility.

Coding a Subscription

How to subscribe

Per Oracle Workflow coding standards, two kinds of subscriptions exist for use:

For information about the standards for the event subscription rule function, see: Standard API for an Event Subscription Rule Function, Oracle Workflow Developer's Guide.

The parameters provided by events

Oracle Workflow uses the object type WF_EVENT_T to store event messages. WF_EVENT_T defines the event message structure that the Business Event System and the Workflow Engine use to represent a business event.

For more information about this Event Message structure, see: Event Message Structure, Oracle Workflow API Reference.

As part of the event message, the raised event can pass a number of parameters to the subscription rule function in a named varying array WF_PARAMETER_LIST_T. The credit request event passes 13 parameters, listed in the following table:

Parameter Name Description
CREDIT_REQUEST_ID The unique identifier of the credit request
USER_ID The user ID of the initial session that had initiated the credit request
RESP_ID The responsibility ID of the initial session that had initiated the credit request
RESP_APPL_ID The application responsibility ID of the initial session that had initiated the credit request
SECURITY_GROUP_ID The security group ID of the initial session that had initiated the credit request
ORG_ID The Operating Unit ID of the initial session that had initiated the credit request
SOURCE_NAME The source name on the credit request, which is used to identify the source product that initiated the credit request
SOURCE_COLUMN1 The unique identifier of the entity for which the credit request was created
SOURCE_COLUMN2 The unique identifier of the entity for which the credit request was created
SOURCE_COLUMN3 The unique identifier of the entity for which the credit request was created

The org_id, user_id, resp_id, resp_appl_id, and security_group_id parameters let users re-create the application environment at the moment the credit request was raised. This is useful if your business logic depends on some application context parameters, such as for a multi-organization environment.

You can use FND_GLOBAL.APPS_INITIALIZE(<USER_ID>, <RESP_ID>, <RESP_APPL_ID>, <SECURITY_GROUP_ID>) to re-create the original application context in your process.

Example of a PL/SQL rule function subscription

For example, for a particular requirement, consumer products in Oracle eBusiness Suite need to implement their custom recommendations after the Credit Request workflow has implemented its own recommendations for a particular credit request.

Here is one example of rule function.

If the following rule function is subscribed to Credit Request event: "":

FUNCTION Rule_Credit_Recco_Impl
(p_subscription_guid  in raw, 
p_event               in out wf_event_t)
 l_key         varchar2(240) := p_event.GetEventKey();
  l_org_id := p_event.GetValueForParameter('ORG_ID');
  l_user_id := p_event.GetValueForParameter('USER_ID');
  l_resp_id := p_event.GetValueForParameter('RESP_ID');
  l_resp_appl_id := p_event.GetValueForParameter('RESP_APPL_ID');
  l_security_group_id := p_event.GetValueForParameter('SECURITY_GROUP_ID');
  l_credit_request_id := p_event.GetValueForParameter('CREDIT_REQUEST_ID');
  l_source_name := p_event.GetValueForParameter('SOURCE_NAME');
  l_source_column1 := p_event.GetValueForParameter('SOURCE_COLUMN1');
  l_source_column2 := p_event.GetValueForParameter('SOURCE_COLUMN2');
  l_source_column3 := p_event.GetValueForParameter('SOURCE_COLUMN3');
  l_party_id := p_event.GetValueForParameter('PARTY_ID');
  l_cust_account_id := p_event.GetValueForParameter('CUST_ACCOUNT_ID');
  l_cust_acct_site_id := p_event.GetValueForParameter('CUST_ACCT_SITE_ID');
fnd_global.apps_initialize (l_user_id, l_resp_id, l_resp_appl_id, 
--Implement custom recommendations.

Credit Request Events

Credit Request events follow this naming pattern:<Phase>.<Action>.

This name contains three parts:

  1. means that the event belongs to Credit Request entity in the Credit Management application.

  2. <Phase> indicates the current stage in the life cycle of a credit request in which an action is going to be performed.

  3. <Action> indicates the action performed in the current phase of the credit request.

This table lists the possible phases and actions.

Credit Request Phase Action Description ID Parameter Name
Automation Failure Failure of an automated credit request processing because of non-availability of the required data-points on the checklist or the scoring model. CREDIT_REQUEST_ID
Recommendation Implement Implementation of the recommendations, coming out of the analysis performed on the credit request. CREDIT_REQUEST_ID