8 Understanding the Process Integration for Collection Management

This chapter provides an overview of the collections integration flows and discusses Oracle Communications Billing and Revenue Management (BRM) and Siebel customer relationship management (Siebel CRM) interfaces, Oracle Application Integration Architecture (Oracle AIA) components, and integration services.

Process Integration for Collection Management Overview

Collection management is a process to collect money from subscribers after the grace period provided to pay the dues is over. If subscribers do not make a payment after the grace period, service providers may choose to remind the subscribers at first with a letter or a phone call. If these contact methods fail, service providers may decide to take actions such as inactivating the service.

The process integration for collection management provides synchronization of collections actions based on specified collections scenarios between BRM and Siebel CRM, and administration of these collections actions and credit alerts.

The collection management business process covers the entire collections life cycle across BRM and Siebel CRM to define activities typically performed, such as:

1. In BRM, a collections scenario is defined, created, and associated with a sequence of actions that must be performed.

2. Any bill units that move into collections and require an actionable event are passed to Siebel CRM as an action notification event in the form of a credit alert.

3. Siebel CRM capabilities can be accessed by the collections agent to create additional activities which can be associated with a credit alert.

The process integration for collection management consists of these integration flows:

• Synchronizing Collection Scenarios and Actions integration flow

• Synchronizing Credit Alerts integration flow

Collection Management Business Process Flow

Figure 8-1 illustrates the overall flow for the process integration for collection management.

Figure 8-1 Collection Management Business Process Flow

Description of "Figure 8-1 Collection Management Business Process Flow"

Assumptions and Constraints for Working with Collection Management

These are the assumptions and constraints for the process integration for collection management:

• Cross reference data and domain value map (DVM) setup should be verified for a successful collections batch load run.

• To achieve and maintain high performance, the database memory area must be large enough to hold the frequently accessed data in the cache.

• If an amount due alert has not been sent by BRM a default 0 (zero) amount is set in the integration process.

• When creating a credit alert, a default agreement association is provided at the account-level and not the credit alert-level.

• The integration supports multiple billing systems, with the assumption that a given Siebel CRM billing profile is mapped or synchronized to a single billing system. With this assumption, the ready-to-use credit alert status update flow from Siebel CRM to billing routes updates back to the appropriate billing system. However, the inbound Oracle Data Integrator (ODI) based flow that synchronizes credit alerts from BRM to Siebel CRM requires some manual adjustments (cloning of ODI artifacts and other design-time changes) for each additional billing system that gets added.

  See "Solution Assumptions and Constraints" in "Understanding the Process Integration for Billing Management" for other dependencies.

  See the discussion of configuring multiple BRM instances in Oracle Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management for more information about configuring multiple billing systems.

• BRM collections messages are stored in BRM tables, which can be queried from BRM database views. In a multischema scenario, a unified view is available on BRM to query the information of collections actions and scenarios.

• No cross-reference for the collections action ID exists. The BRM Portal Object (POID) for the collections action ID is sent to Siebel CRM as the integration ID. This POID is used for all references to the action and when an Update Collection Action and Update Collection Action status is selected.

• In case of failure executions, there are two options available for the administrator:

  • Re-execute the ODI scenario manually.

  • Start the SyncCollectionHeaderInfoBRMCommsReqImpl service using the timestamp details. This will start the ODI web service to begin the scenario.

• ODI uses SMTP port 25 to send notification mails. To use a different port you must configure the SMTP Port in ODI. See the discussion of defining Java options in ODI on the Oracle Support Web site:

  https://support.oracle.com/epmos/faces/DocumentDisplay?id=1317507.1

Synchronizing Collection Scenarios and Actions Integration Flow - BRM to Siebel CRM

This section provides an overview of the Synchronizing Collection Scenarios and Actions integration flow and discusses how to:

• Configure the AIAConfigurationProperties.xml file in an Oracle AIA layer

• Receive and transform the data

For information about configuring BRM for integrated collections management, see:

• Setting Up BRM

• Oracle Communications Billing and Revenue Management Concepts

• Oracle Communications Billing and Revenue Management Collections Manager

For information about managing collections in Siebel CRM and configuring Siebel CRM for integration, see Siebel Communications Guide.

Understanding Synchronizing Collection Scenarios and Actions Integration Flow

The synchronizing collection scenarios and actions integration enables the transfer of collections data from BRM database views to Siebel Enterprise Integration Manager (EIM) tables. This integration uses ODI to transfer the data from BRM to Siebel CRM.

Figure 8-2 illustrates the synchronizing collection scenarios and actions integration flow.

Figure 8-2 Collections Data Synchronizing Activity Flow Diagram

When you initiate this process by creating a new collections action or updating an existing collections action, the following events occur:

1. A collections process is started in BRM and the actions data is populated into two database views:

   • UNIFIED_COLL_ACTION_IF_VIEW which contains all the collections action data (for example, to send dunning letter)

   • UNIFIED_COLL_SCENARIO_IF_VIEW which contains the status of billing profiles (for example, Entered Collections or Exited Collections).

2. When the collections process is finished, BRM creates a CollectionsInfoChange business event and publishes it to an Advanced Queue (AQ) database queue with the start and end timestamp for the collection event. The timestamp information is in Unix format. For example, 1319357706.

3. The SyncCollectionsInfoChangeBRMAQ service receives an AQ queue business event notification message and passes the timestamp details to SyncCollectionHeaderInfoBRMCommsReqImpl BPEL service.

4. The SyncCollectionHeaderInfoBRMCommsReqImpl BPEL service reads the required parameters from AIAConfigurationProperties.xml file and calls the ODI Web Service to start the SCEN_SYNCCOLLECTIONACTION scenario.

5. SCEN_SYNCCOLLECTIONACTION process starts ODI interfaces to perform the following:

   • Reads data from UNIFIED_COLL_ACTION_IF_VIEW and updates this data by performing a cross-reference and DVM lookup, and querying Siebel CRM base tables.

   • Reads data from the UNIFIED_COLL_SCENARIO_IF_VIEW view and updates this data by performing a cross-reference and DVM lookup, and querying Siebel CRM base tables.

   • Updates the AccountID and BillingProfileID columns using cross-reference data.

   • Updates the Currency Code, Action Name, Priority, and similar columns using DVMs.

6. The updated data is mapped to the EIM_ALERT_CUT table. For every row inserted into the EIM tables, the value of the IF_ROW_STAT column is set to FOR_IMPORT.

7. The Entered Collections and Exited Collections rows are extracted from the EIM_ALERT_CUT table and written to the EIM_ACCNT_PROF table. This data is responsible for changing the status of Billing Profile.

8. A success or failure notification mail is sent to the administrator. If a failure message is received the administrator must take the appropriate action. See "Handling Errors" for more information.

9. Siebel CRM runs a batch job and moves the data from the EIM table to the base table and creates credit alerts.

Table 8-1 Synchronizing Collection Scenarios and Actions Integration Flow

Work Location	Step
BRM	1. Collections actions are generated and stored in a database view. 2. Publishes an event to the AQ queue with timestamp details.
Integration Process (ODI)	3. AQ Consumer Service receives the message and passes on the details to a BPEL Service. 4. BPEL Service calls the ODI Web service with a timestamp value as input parameters. 5. Integration flow reads the messages from the BRM database views. 6. Data is collected from BRM, updated by cross-references and DVM lookup, and inserted into the Siebel EIM tables. 7. After the ODI Scenario is processed, a success or failure notification message is sent to the Administrator.
Siebel CRM	8. Siebel CRM runs a batch job to move data from the EIM table to the Base table and creates credit alerts. 9. If required, updates the billing profile.

Time Zone Handling

Oracle AIA does not do a time-zone conversion when synchronizing credit alerts from BRM to Siebel CRM.

BRM publishes collection StartTime and EndTime timestamp details in BRM local server time in epoch format.

Configuring and Generating Data in BRM

You must configure BRM for integrated collections management as described in:

• Setting Up BRM

• The discussion of using integrating collections with your external CRM application in Oracle Communications Billing and Revenue Management Concepts

• The discussion of integrating Collections Manager with custom client applications in Oracle Communications Billing and Revenue Management Collections Manager

When you have configured BRM for integrated collections management, BRM generates collections data as follows:

1. A customer enters collections and one of the following collections activities occurs:

   • An account enters or exits collections.

   • A collections action object is created or updated.

   • A /schedule object is created.

2. A collections process is started in BRM and data is populated to the UNIFIED_COLL_ACTION_IF_VIEW and UNIFIED_COLL_SCENARIO_IF_VIEW views.

See Oracle Communications Billing and Revenue Management Collections Manager for more information about how BRM handles collections.

Receiving and Transforming the Data

The synchronizing collection scenarios and actions process integration uses ODI to receive, transform, and load the BRM data into the Siebel CRM EIM tables.

Figure 8-3 Synchronizing Collection Scenarios and Actions from BRM to Siebel CRM Sequence Diagram

These tasks are performed as a part of the data load process:

1. In BRM the pin_collections_process utility generates the following new BRM business event:

   /event/notification/collections/info_change

2. The Data Manager AQ queue receives the payload data and publishes a new CollectionsInfoChange business event to the AQ queue. This includes the start and end timestamps, and the Account POID from the BRM event.

3. An Oracle AIA BPEL service SyncCollectionsInfoChangeBRMAQ receives a message from the AQ queue that new data is available and starts the SyncCollectionHeaderInfoBRMCommsReqImpl BPEL service.

4. The SyncCollectionHeaderInfoBRMCommsReqImpl BPEL service receives the timestamp parameters and reads the required parameters from the AIAConfigurationProperties file. Using the parameters it calls the ODI web service to start the SCEN_SYNCCOLLECTIONACTION process.

5. SCEN_SYNCCOLLECTIONACTION process starts ODI to perform the following:

   • Reads data from the UNIFIED_COLL_ACTION_IF_VIEW view and updates this data by performing a cross-reference and DVM lookup, and querying Siebel CRM base tables.

   • Reads data from the UNIFIED_COLL_SCENARIO_IF_VIEW view and updates this data by performing a cross-reference and DVM lookup, and querying Siebel CRM base tables.

   • Updates the AccountID and BillingProfileID columns using cross-reference data.

   • Updates the Currency Code, Action Name, Priority, and similar columns using DVMs.

6. The updated data is mapped to the Siebel EIM_ALERT_CUT table.

7. The Entered Collections and Exited Collections rows are extracted from the EIM_ALERT_CUT table and written to the EIM_ACCNT_PROF table. This data is responsible for changing the status of Billing Profile.

8. For every row inserted in the EIM tables, the value of the IF_ROW_STAT column is set to FOR_IMPORT.

Note:

Before ODI loads the enriched collections data into the Siebel EIM tables, it performs data cleansing. All existing records that were successfully imported into the Siebel base table are deleted from the EIM tables.

Configuring AIAConfigurationProperties file to work with ODI

This section discusses how to configure the AIAConfigurationProperties.xml file to work with ODI.

Based on your requirements, after you have installed the process integration for collection management, you need to change the default values of the collections parameters to suit your implementation.

To configure the AIAConfigurationProperties.xml file to change the default values, do the following:

1. Open $AIA_INSTANCES/config/AIAConfigurationProperties.xml file in a text editor.

   See "Building AIA Integration Flows" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information on how to reload updates to AIAConfigurationProperties.xml file.

2. Locate <ModuleConfiguration moduleName="CollectionsParameters"> and update the following default values:

   • FromMailAddress

   • ToMailAddress

   • MailServer

   • ODI.USERNAME

   • ODI.PASSWORD

   • ODI.WORKREPNAME

   • BatchSize

   • Default.SystemID

   • AIAHome

   • IF_ROW_BATCH_NUM_CreatedStart

   • IF_ROW_BATCH_NUM_CreatedEnd

   • IF_ROW_BATCH_NUM_UpdateStart

   • IF_ROW_BATCH_NUM_UpdateEnd

   • IF_ROW_BATCH_NUM_Error

   • AL_SOURCE_CD

   • AL_TYPE_CD

   See "Configuring the Process Integration for Collections Management" for more information about these properties.

Synchronizing Credit Alerts Integration Flow - Siebel CRM to BRM

This integration flow synchronizes the credit alerts from Siebel CRM to BRM.

This integration flow uses the following services:

• UpdateCreditAlertSiebelCommsReqABCSImpl with operation UpdateCreditAlert

• UpdateCreditAlertBRMCommsProvABCSImpl with operation UpdateCreditAlert

Figure 8-4 illustrates the synchronizing credit alerts integration scenario.

Figure 8-4 Synchronizing Credit Alerts from Siebel CRM to BRM Sequence Diagram

When you initiate the synchronizing credit alert process, the following events occur:

1. Siebel CRM starts Oracle AIA UpdateCreditAlertSiebelCommsReqABCSImpl service.

2. The UpdateCreditAlertSiebelCommsReqABCSImpl service transforms Credit Alert Status Siebel Application Business Message (ABM) ListOfSWICUTCreditManagementIO to the UpdateCreditAlertListEBM message. Based on the Billing Profile ID it sets the Target System ID in the EBM and calls the UpdateCreditAlertBRMCommsProvABCSImpl service.

3. The UpdateCreditAlertBRMCommsProvABCSImpl service searches for the Billing Profile ID, and sets the Target System ID and URL of target BRM instance.

   The UpdateCreditAlertBRMCommsProvABCSImpl service then transforms the UpdateCreditAlertListEBM message to an ABM and starts the PCM_OP_COLLECTIONS_SET_ACTION_STATUS BRM opcode.

4. The credit alert or action status is updated to Closed in BRM.

Table 8-2 Synchronizing Credit Alerts Integration Flow

Work Location	Step
Siebel CRM	1. The action status for a billing profile is updated.
Integration Process (Oracle AIA)	2. Requester Application Business Connector Service (ABCS) receives the request from Siebel and transforms the application business specific message (ABM) to application neutral message (EBM). 3. Provider Application Business Connector Service (ABCS) transforms EBM to ABM and starts a BRM op-code.
BRM	4. The BRM op-code updates the status of the given collections action in BRM.

Handling Errors

The process integration for collection management handles BPEL services and ODI errors.

Handling BPEL Service Errors

For BPEL service errors, do the following:

SyncCollectionHeaderInfoBRMCommsReqImp

This service uses the default error handling capability of Oracle AIA.

• Faults: On Error the collections Application Business Message (ABM) is transformed to a fault message and returned to the calling process. The fault message contains the collections run timestamp details. The Error BPEL process is started. An Exception is raised.

• Based on your Error Handling Notification configuration, an email is sent to the user.

  According to the message received the user must take the appropriate action.

UpdateCreditAlertSiebelCommsReqABCSImpl

This service uses the default error handling capability of Oracle AIA.

• Faults: On Error the Credit Alert ABM is transformed to a fault message and returned to the calling process. The fault message contains the Credit Alert details. The Error BPEL process is started. An Exception is raised.

• Based on your Error Handling Notification configuration, an email is sent to the user.

  According to the message received the user must take the appropriate action.

UpdateCreditAlertBRMCommsProvABCSImpl

This service uses the default error handling capability of Oracle AIA.

• Faults: On Error the Credit Alert ABM is transformed to a fault message and returned to the calling process. The fault message contains the Credit Alert details. The Error BPEL process is started. An Exception is raised.

• Based on your Error Handling Notification configuration, an email is sent to the user.

  According to the message received the user must take the appropriate action.

See Oracle Application Integration Architecture Foundation Pack for more information.

Handling ODI Error Messages

After each scenario run a notification email is sent to the user's email address.

Note:

The FromMailAddress and ToMailAddress must be set in the AIAConfiguraionProperties.xml file. See "Configuring AIAConfigurationProperties file to work with ODI" for more information.

On receiving a notification email, for failed jobs do the following:

1. Take the appropriate action based on the message received.

2. Re-start the scenario by doing one of the following:

   1. Manually restart the scenario. See "Restarting Your Job Manually" for more information.

   2. Re run the job by passing the timestamp details to the SyncCollectionHeaderInfoBRMCommsReqImpl service.

Restarting Your Job Manually

The notification mail contains the start and end timestamps, for example:

Coll_StartTime: 1299794311
Coll_EndTime: 1299794315

To restart your job manually:

1. On the Oracle AIA system, navigate to the following file path:

   ODI_HOME/oracledi/agent/bin
   

   where ODI_HOME is the path to ODI home

2. Run the following command, where Start_Time_Stamp and End_Time_Stamp are the timestamp values shown in the notification email:

   • In a Linux environment:

     ./startscen.sh SYNCCOLLECTIONACTION 001 GLOBAL
     "GLOBAL.Coll_StartTime=Start_Time_Stamp"
     "GLOBAL.Coll_EndTime=End_Time_Stamp"
       
     

   • In a Windows environment:

     startscen.bat SYNCCOLLECTIONACTION 001 GLOBAL
     "GLOBAL.Coll_StartTime=Start_Time_Stamp"
     "GLOBAL.Coll_EndTime=End_Time_Stamp"
       
     

   For this command, ODI_HOME is the path of ODI home.

Note:

Make sure that Java home is set in the path before you run this command by running the source <aia.home>/bin/aiaenv.sh command.

BRM Interfaces

The synchronizing credit alerts integration uses the following BRM interface:

• PCM_OP_COLLECTIONS_SET_ACTION_STATUS

See Oracle Communications Billing and Revenue Management Opcode Flist Reference for more information.

Siebel CRM Interfaces

The synchronizing credit alerts integration uses this Siebel CRM interface:

• Outbound web service UpdateCreditAlertSiebelCommsReqABCSImplServicePort operation UpdateCreditAlert

See "Web Services Reference" in Siebel Order Management Guide Addendum for Communications for more information.

Industry Oracle AIA Components

The synchronizing credit alerts integration uses the following delivered enterprise business objects (EBOs) and enterprise business messages (EBMs):

• CreditAlertEBO

• UpdateCreditAlertListEBM

The industry EBO and EBM XML schema (EBM XSD) files are located under the Metadata Services (MDS) repository at: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/Communications/EBO/

The industry enterprise business service (EBS) WSDL files are located under the MDS repository at: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/Communications/EBO/

For detailed documentation of individual EBOs and EBMs, click the Oracle AIA Reference Doc link on EBO and EBM detail pages in the Oracle Enterprise Repository (OER).

See "Configuring and Using Oracle Enterprise Repository as the Oracle SOA Repository" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information on how to use and configure OER to provide the Oracle AIA Reference Doc link.

EBOs can be extended such as adding new data elements. These extensions are protected and will remain intact even after a patch or an upgrade, so long as the extensibility guidelines are followed.

See "Working with AIA Design Patterns", AIA Assets Extensibility Patterns, Extending Existing Schemas in AIA in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information.

Integration Services

These services are delivered as part of the process integration for collection management:

• UpdateCreditAlertSiebelCommsReqABCSImpl

• UpdateCreditAlertBRMCommsProvABCSImpl

• SyncCollectionsInfoChangeBRMAQ

• SyncCollectionHeaderInfoBRMCommsReqImpl

UpdateCreditAlertSiebelCommsReqABCSImpl

UpdateCreditAlertSiebelCommsReqABCSImpl is a Business Process Execution Language (BPEL) process. It performs the following actions:

• Receives Siebel Credit Alert ABM containing billing profile ID, credit alert ID, integration ID, and status.

• Transforms the ABM to UpdateCreditAlertListEBM and starts the UpdateCreditAlertBRMCommsProvABCSImpl service.

UpdateCreditAlertBRMCommsProvABCSImpl

UpdateCreditAlertBRMCommsProvABCSImpl is a BPEL process. It performs the following actions:

• Receives UpdateCreditAlertBRMCommsProvABCSImpl from the requestor service.

• Transforms the UpdateCreditAlertListEBM to BRM opcode PCM_OP_COLLECTIONS_SET_ACTION_STATUS flist.

• Starts BRM PCM_OP_COLLECTIONS_SET_ACTION_STATUS and updates the status of the credit alert or action to Closed.

SyncCollectionsInfoChangeBRMAQ

SyncCollectionsInfoChangeBRMAQ is a mediator based service. It performs the following actions:

• Reads the message from AQ event message published by BRM.

• Starts SyncCollectionHeaderInfoBRMCommsReqImpl

SyncCollectionHeaderInfoBRMCommsReqImpl

SyncCollectionHeaderInfoBRMCommsReqImpl a BPEL process. It performs the following actions:

• Receives the timestamp values.

• Reads the properties from the AIAConfigurationProperties.xml file

• Transforms the input message to an ODI web service message type.

• Starts the operation of the ODI web service.

Integrating Collections in a Multischema Environment

In BRM, you can distribute your data amongst multiple schemas in the same database to increase scalability and support load balancing. To distribute BRM accounts and associated objects amongst multiple schemas, you can migrate them between schemas in batches, with each batch consisting of a list of accounts identified by their BRM Portal Objects (POID), source and destination schema numbers.

See Oracle Communications Billing and Revenue Management Concepts and Oracle Communications Billing and Revenue Management System Administrator's Guide for more information about multischema architecture and account migration.

To communicate the correct account information between BRM and Siebel CRM, a common Oracle AIA identifier and an Oracle AIA cross-reference table is used to map accounts between BRM and Siebel CRM. The Oracle AIA cross-reference table uses BRM POIDs that include the BRM schema number. The BRM POID is made of a schema number, an object type, a unique object ID, and a revision number. For example:

0.0.0.2 /account 11599 4

where:

• 0.0.0.2 is the BRM schema number

• /account is the object type

• 11599 is the unique object ID

• 4 is the revision number

To integrate collections with Siebel CRM in a multischema environment, BRM populates the custom views UNIFIED_COLL_ACTION_IF_VIEW and UNIFIED_COLL_SCENARIO_IF_VIEW in BRM collections tables with the POID schema number, hard-coded as 0.0.0.1 for /collections_action regardless of the schema where the account resides. For example, for the account in the secondary schema shown in the example above, the value for a late fee would be 0.0.0.1/collections_action/late_fee 100845 0 in the UNIFIED_COLL_ACTION_IF_VIEW.

By including the hard-coded POID schema number, the schema numbers of the action objects being published to Siebel CRM do not change in the custom views, even if the action objects are migrated from one schema to another. Siebel CRM always reads the objects as residing in schema 0.0.0.1, whether it is a single-schema or a multischema environment. During the Synchronizing Credit Alerts integration flow, when synchronizing credit alerts from Siebel CRM to BRM, the integration reads the schema number for the account object POID to get the appropriate schema number for the /collections_action POIDs.