Top=

2. ELCM Integration with OBCL/FCUBS

The ELCM integration with OBCL/FCUBS enables the following:

ELCM standalone integration with FCUBS and OBCL
New services for FCUBS/OBCL integration
- ELCM with FCUBS/OBCL-SYNC Mode
- ELCM with FCUBS/OBCL-ASYNC Mode

ELCM co-deployed with FCUBS/OBCL
Linking LC contract and corporate deposits in collateral

This chapter contains the following sections:

Section 2.1, "Prerequisites"
Section 2.2, "Interface of standalone ELCM with FCUBS/OBCL"
Section 2.3, "Integration Process"
Section 2.4, "ELCM Co-deployed with FCUBS/OBCL"
Section 2.5, "LC, TD, BC, CD, and MM Contract to Link in Collateral"

2.1 Prerequisites

2.1.1 Prerequisites in Oracle Banking ELCM

The following parameters should be set up in Oracle Banking ELCM.

In ‘CSTB_PARAM’ table, if the ‘ELCM_SETUP_MODE’ is set to ‘E’ then the POJO call is initiated.
If the option ‘ELCM_SETUP_MODE’ is not set to 'E', then in 'CSTB_PARAM' table 'OBCL-ELCM-EXT-CALL' parameter should be maintained.
If 'OBCL-ELCM-EXT-CALL' is set to 'Y', then in 'CSTB_PARAM' table 'ELCM-CALL-MODE' parameter is verified.
If 'ELCM-CALL-MODE' parameter value is set to 'S', then ELCM web service Sync call is made from OBCL.
If 'ELCM-CALL-MODE' parameter value is set to 'A', then ELCM web service ASync call is made from OBCL.

2.2 Interface of standalone ELCM with FCUBS/OBCL

Interface between FCUBS or OBCL to ELCM supports two modes.

ELCM with FCUBS/OBCL-SYNC mode
ELCM with FCUBS/OBCL-ASYNC mode

2.2.1 ELCM with SYNC Mode

For this implementation, a new adapter layer is created in FCUBS /OBCL system to interact with ELCM through web services.
During contract creation, if a limit request is created, FCUBS/OBCL logs the request to the service log tables.
Adapter layer prepares the request based on the service log entry and invokes the web service of ELCM for further processing.
Response received from the external limit system is shown during the transaction itself.

2.2.2 ELCM with FCUBS/OBCL-ASYNC Mode

For ASYNC installation mode, communication between the FCUBS/OBCL and ELCM does not happen in single transaction window.
FCUBS/OBCL transaction authorization would not be allowed until response from limit system is received.
During contract creation, if a limit request is created, FCUBS/OBCL logs the request to the service log tables.
A job/scheduler processes these records from this table, creates a request xml and the sends the request to ELCM for processing.
If the processing from the ELCM side has any overrides, then an override error message is converted to an information message, sent to FCUBS side stating the record have overrides which needs to be manually accepted/rejected.
Override error message details and request xml are logged into the override tables in ELCM and to the cstb_overide tables.
Override Action screen is introduced for accepting or rejecting the override information. In addition, the processing of the transactions are performed after the overrides are accepted or rejected.

2.3 Integration Process

This section contains the following topics:

Section 2.3.1, "Maintaining Override Action"
Section 2.3.2, "Querying Valid Lines"
Section 2.3.3, "Maintaining External System"
Section 2.3.4, "Configuring Accounting System for a Host Code"
Section 2.3.5, "Maintaining Integration Parameters"
Section 2.3.6, "ELCM Web Services"

2.3.1 Maintaining Override Action

To invoke this screen, type ’GEDOVDAC’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

Specify the following:

Message ID

Indicates an unique message ID. The adjoining option list displays all the valid message IDs. You can select the appropriate one.

User Reference

The user reference number gets defaulted once you select the message ID. The reference number is the identification that you specify for searching the messages. The User reference is the OL contract reference number and you can query the overrides based on the contract reference.

Calling System

Indicates the source system that calls ELCM. For example, OBCL or FCUBS.

Request Sequence Number

This is a DB sequence number generated by the system which is maintained along with message ID to make a composite key.

Override Sequence Number

Indicates the number of overrides for a single transaction. For example, if there are 2 overrides for single transaction it shows as 2 different overrides.

Request ID

Unique id for the Request XML that comes from the external system.

Error Code and Error Message

The overrides in the ELCM while booking the contract is displayed here along with the error message and error code. You have to accept or reject these overrides.

Accept and Reject

If 'Accept' button is clicked, the system allows you to process the transaction.

If 'Reject' button is clicked, the overrides are rejected and you have to delete the transaction and book a new transaction.

Click ‘Request Details’, the ‘Override Request Details’ screen appears. The following details are fetched from the external system.

Status - The status of the override is displayed.
- O – The override is open, that is, pending for approval or rejection
- S – Accepted
- R - Rejected

User Reference - Contract reference is displayed.
Linkage Reference Number - The reference number of Limit attached in the contract is displayed.
Customer Number - Indicates the customer CIF
Limit Type - Type of the limit attached. Collateral – C, Liability – L, Facility - F and Collateral Pool - P
Utilization Currency - Indicates the contract currency
Utilization Amount - Indicates the contract amount.
Error Code - ELCM override code displaying during contract creation
Calling System - Indicates the source system that calls ELCM. For example, OBCL or FCUBS.

2.3.2 Querying Valid Lines

FCUBS requires limit details for linkages at a module level. In this case, FCUBS interacts with the ELCM systems and request for valid limit details for the customer. Response received from the limit systems are displayed for linkages.

A new web service ‘ELValidLimitService’ is developed in ELCM which returns all the valid lines from facility, collateral, and collateral pool.
360 customer view also invokes the ‘ELValidLimitService’ for displaying the limit details.

ELCM process web service request from the FCUBS and sends response back to FCUBS with valid line details.

To invoke this screen, type ‘GEDQVLLN’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

Specify the following:

Customer

Specify the customer code. The adjoining option list displays all the valid customer codes. You can select the appropriate one.

Product

Specify the product code. The adjoining option list displays all the valid customer codes. You can select the appropriate one.

Branch

Specify the code for the branch. You can select the branch code from the option list. The list displays all valid branch codes maintained in the system i.e both current branch code and other branch codes.

Currency

Specify the limits currency. The option list displays all valid limits currencies. Choose the appropriate one.

Tenor

Specify the limits tenor.

Availment Date

Specify the limits availment date.

Valid Lines can be fetched based on filter conditions.

Customer Number
Currency
Product Code
Tenor
Branch
Availment Date

Product code and tenor are the optional search parameters and others are the mandatory search criteria.

2.3.3 Maintaining External System

To invoke this screen, type ’GEDEXMNT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

External System Code

A unique code for maintaining external system details, that is for WSDL URL. For example, external system code for OBCL is OBCL, for FCUBS it is ROFC.

Description

This field is optional. It describes about external system code. For example, if you have multiple ROFCs you can differentiate in description.

External System

Indicates external system class. You can either select ‘FCUBS’ or ‘Others’ from the drop-down list.

External System User ID

Indicates the user ID used for login.

Module ID

Indicates the module code used for external system. For example, TD, ST, OL, MM, and so on.

WSDL Link

Indicates the link to access the web service.

The following table indicates the maintenance required for ROFC interface.

External System	Module	Description
ROFC	CASA	Service to be invoked in ROFC during facility modification
ROFC	OVD	Service to be invoked in case of deferred override response or dual-auth response
ROFC	OB	Service to be invoked to send guarantee collateral details
ROFC	LC	Service to send LC collateral linkage details
ROFC	TD	Service to block TD
ROFC	CD	Service to block CD
	ACCSYS	Service to handoff accounting entries

The following table indicates the maintenance required for OBCL interface.

External System	Module	Description
OBCL	OVD	Service to be invoked in case of deferred override response or dual-auth response

2.3.4 Configuring Accounting System for a Host Code

You can configure the accounting system using host code in the ‘Host Parameter’ screen. This screen captures all the external system details for the given host code.

To invoke this screen, type GEDHSTMN in the field at the top right corner of the application toolbar and click the adjoining arrow button.

Specify the following details

Host Code

Specify the host code.

Host Description

Specify the brief description for the host.

Accounting System Code

Specify the accounting system code.

2.3.5 Maintaining Integration Parameters

You have to maintain integration parameters for ‘External LOV’ and ‘ELCM Utilization’. This maintenance must be done for all branches. This maintenance is done through ‘Integration Parameters Maintenance’ screen.

To invoke this screen, type ‘IFDINPRM’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

You need to maintain the integration parameters for the following:

External Lov – ExtLovService
ELCM Utilization – ELUtilizationService

External Lov

External System - External system name is specified here. For example, OLELCM
Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM and ExtLovService for External LovExtLovService.
Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
Communication Mode – The communication mode can be SYNC/ASYNC.
Rest Service IP – You have to maintain the IP address. For example, ELCM IP.
Rest Service Port – You have to maintain port details. For example, ELCM Port.
Rest Service Pattern - You have to maintain rest service pattern. For example, LovService
Rest Service Context – You have to maintain rest service context. For example, FCJNeoWeb
External User - ELCM user should have access to all branches and autoauth

ELCM Utilization

External System - External system name is specified here. For example, OLELCM.
Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM and ExtLovService for External LovExtLovService.
Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
Communication Mode – The communication mode can be SYNC/ASYNC.
WS Service Name – The service name needs to be maintained here. For example, ELUtilizationService.
WS Endpoint URL – The WSDL of the services are maintained here. For example, ELCM utilization service WSDL link
WS User – ELCM user should have access to all branches and autoauth.
External User - ELCM user should have access to all branches and autoauth.

2.3.6 ELCM Web Services

A new web service ‘ELValidLimitService’ is developed in ELCM which returns all the valid lines from facility, collateral, and collateral pool. In addition, it also invokes 360 customer view.

The new header tag used in ELCM web services are the following:

2.3.6.1 Finalreq

This header tag is for identifying the override information from the FCUBS system.
FinalReq is set as “N” if there are overrides in the FCUBS system.
FinalReq is set as “Y” if there is a no override in the FCUBS system.
If FinalReq is set as ‘N”, then ELCM processes the records, validate all the business rules but the transaction is not persisted.
If the FinalReq Flag is set as ‘Y’, then only the records are persisted in ELCM side and the success response is sent to the user.

2.3.6.2 Mode

This header tag is identity installation mode for the ELCM system.
Mode can be Async(A) ,Sync(S) or default
If FinalReq is ‘N’ and mode value is set ‘A’, then the override error message is converted to an information message and then updated in the response xml and is returned to the calling system.

2.3.6.3 Ext Trip Id

Ext trip is a place holder to send Multi Trip ID specific for ELCM to FCUBS/OBCL once the overrides have been accepted.

2.4 ELCM Co-deployed with FCUBS/OBCL

In a co-deployed system of FCUBS/OBCL and ELCM, the process flow between the systems happens through Application (JPA) layer. Insulation layer is calling the GatewayEJB of ELCM with same request xml.

In the standalone version of ELCM, changes are made to process all ELCM Function IDs in the Application layer itself. To support this, the Function IDs for which persistence was done using POJO in DB was converted to JPA.

ELJBean class has been modified to route to business process flow to application layer instead of database.

2.5 LC, TD, BC, CD, and MM Contract to Link in Collateral

The TD, SB, CA,CD and MM contract can be linked to collateral using External LOV service. ExtLovService is configured for external FCUBS system through IFDINPRM screen.

These term deposits or contracts can be created as a collateral through Accounts and Contracts collateral creation screen (GCDCOLAC). Post linkage a block is created on the TD, SB, CD and CA accounts using the below services.

TD – FCUBSCustomerService
CD - FCUBSSTService
SB/CA- FCUBSCustomerService