This appendix describes business events that you can use with Oracle Credit Management.
This appendix covers the following topics:
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.
Log on to Oracle Applications with the System Administrator responsibility.
Navigate Workflow > Add subscription to Event.
Every Credit Request event follows the same naming convention:
"oracle.apps.ar.cmgt.CreditRequest.<phase><action>"
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 oracle.apps.ar.cmgt.CreditRequest.Recommendation.implement event.
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.
Per Oracle Workflow coding standards, two kinds of subscriptions exist for use:
Oracle Workflow Release 2.6 rule function (which is a PL/SQL function)
Workflow processes
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.
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.
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: "oracle.apps.ar.cmgt.CreditRequest.Reccomendation.implement":
FUNCTION Rule_Credit_Recco_Impl
(p_subscription_guid in raw,
p_event in out wf_event_t)
RETURN VARCHAR2
IS
l_key varchar2(240) := p_event.GetEventKey();
....
BEGIN
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,
l_security_group_id);
--
--Implement custom recommendations.
--
END;
Credit Request events follow this naming pattern: oracle.apps.ar.cmgt.CreditRequest.<Phase>.<Action>.
This name contains three parts:
oracle.apps.ar.cmgt.CreditRequest means that the event belongs to Credit Request entity in the Credit Management application.
<Phase> indicates the current stage in the life cycle of a credit request in which an action is going to be performed.
<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 |