This appendix covers the following topics:
Integration can be achieved by coding one or more of the following form level triggers in the integration form:
On Insert
On Update
Custom1
Custom2
Modules within the CRM application must be integrated with each other to ensure smooth flow of data and business logic throughout the application. The Relationship Plans module within Customer Care enables organizations to set up plans that they can offer to their customers and ensure a constantly growing customer base.
The relationship plans module is a busy point of integration, because of the very fact that almost every other module within CRM needs to have a consistent view of all the existing plans in the application. To help in this integration process, the relationship plans module facilitates an "ENABLE PLAN" form, which enables other modules to integrate with relationship plans.
This section provides a technical overview of relationship plans.
Forms Used: CSCUTILS.fmb - Setup Form and Outcomes Window
The tables used are:
CSC_PLAN_ENABLE_SETUP
OKC_PROCESS_DEFS_V
The packages and procedures are:
PACKAGE CSC_PLAN_OUTCOMES PROCEDURE GET_OUTCOMES ( p_FUNCTION_ID NUMBER, p_TRIGGER_EVENT VARCHAR2, p_PARTY_ID NUMBER, p_CUST_ACCOUNT_ID NUMBER, p_END_USER_TYPE VARCHAR2 := NULL p_APPLICATION_SHORT_NAME VARCHAR2, p_MSG_TBL OKC_AQ_PVT.MSG_TAB_TYP)
Description of Parameters:
P_FUNCTION_ID - The integrating form function id from table FND_FORM_FUNCTIONS
P_TRIGGER_EVENT - The triggering event that calls the outcomes. The valid values are INSERT, UPDATE, CUSTOM1, and CUSTOM2.
P_PARTY_ID - Party Id from HZ_PARTIES.
P_CUST_ACCOUNT_ID - Customer account Id from HZ_CUST_ACCOUNTS_ALL
p_END_USER_TYPE - The end user type. AGENT or CUSTOMER
P_APPLICATION_SHORT_NAME - The short name of the application from FND_APPLICATION.
P_MSG_TBL - The msg_tbl has the following structure:
ELEMENT_NAME VARCHAR2(4000)
ELEMENT_VALUE VARCHAR2(4000)
The element name is the name of the action attribute element name. The element value is the actual value of the element name.
Prerequisites for enabling relationship plans include:
Relationship Plans have to be defined and attached to the specific customer.
Actions, Conditions, and Outcomes must be defined using the Events screens.
The steps to enable modules in relationship plans are as follows:
Register the integrating module form with the relationship plan's setup form.
Attach library CSCUTILS.pll
(from $CSC_TOP/resource
) in the integrating form.
Subclass relationship_plans_outcomes and enable_relationship_plans object groups from the CSCUTILS.fmb
form (from $CSC_TOP/forms/US
).
Call CSC_PLAN_OUTCOMES.GET_OUTCOMES
procedure from all of the above mentioned form level triggers. The outcomes are fired only for triggers that are enabled in the setup form.
Add the following code to the APP_CUSTOM
package body in the integrating form:
if (wnd='OUTCOMES') then cscutils_app_custom.close_windo('OUTCOMES'); --move focus to required block/field. for eg: GO_BLOCK('target block'); end if;
Execute user defined triggers, Custom1 and Custom2 from the required integration point as follows.
execute_trigger('CUSTOM1');
This section describes the functionality of the CSCUTILS setup form.
To enable a module for relationship plans, the module must register its form functions with the relationship plans' registering table called CSC_PLAN_ENABLE_SETUP
. This can be done via the Enable Relationship Plans - Setup form.
The Function column specifies the integrating form function name.
The Application column specifies the application the form function belongs to.
The integrating module has four form level triggers which can be coded to achieve integration with the relationship plans module. They are:
On Insert
On Update
Custom1
Custom2
By checking one or more of these triggers, the enable plan APIs can be executed from the integrating module.
A relationship plan's outcomes can be of two types - synchronous and asynchronous. Asynchronous outcomes are fired immediately but the resulting outcomes are processed in the background. Synchronous outcomes are fired immediately and the results are shown in the Outcomes window. The user can then select or deselect the outcomes and execute them.
Outcome Name is the name of the outcome.
Outcome Type is the type of the outcome, such as Alert or Script.
Description is the description of the outcome, such as the alert text for alerts.
The Execute button executes the outcome.
The Cancel button closes the Outcome window.
Create a message with the alert text as the message text. This is the same as defining an error message.
Define the outcome in the Process Definition screen. Use the same message name defined in step 1 for the outcome name.
Define the parameters for the outcomes. Use the same message token names defined step 1 as the parameter names.
For more information about defining outcomes, refer to Events documentation.
Defining a plan which has only one outcome to be fired raises no issues. The outcome is fired and the control passes on normally to the next logical step. If there are two or more outcomes to be fired, the control passes to the OUTCOMES block which lists the different outcomes and the user can select which of the outcomes are to be executed. This raises a potential error situation if the enable relationship plans triggers are called from triggers that do not permit restricted procedures to be part of their code. This is due to the fact that there is a GO_BLOCK statement executed in the GET_OUTCOMES program unit when transferring control to the OUTCOMES block to display the various outcomes.
You must make sure that the form functions integrating with the Relationship Plans module takes into account the above situation and performs the right code calls. A workaround for the above scenario would be to create a timer and then execute the Enable Relationship plan trigger from the WHEN-TIME-EXPIRED trigger.