Skip to main content

SCV Replica Integration (On-Prem & Cloud)

Existing On-Prem CMD & SCV Replica Integration

Below are few application which are consuming the data from CMD via SCV Replica on on-prem system.

CODS, GCSS, GEMS, RKTS, AFLS, MEPC.

CODS, GCSS, GEMS applications are planning to move to EMP platform to consume CMD data directly.

RKTS, AFLS, MEPC applications are not ready to move to EMP platform so we need to continue the existing SCV replica for these systems to continue consuming messages.

Below are different use cases list and expected message from CMD replica MQ feed.

  1. Normal Customer
    1. Create customer
    2. Update customer
    3. Inactivate customer
  2. Customer with contact
    1. Create Customer
    2. Update contact
    3. Add new contact
    4. Remove contact
    5. Inactivate Contact
    6. Reactivate Contact
    7. Inactivate customer having multiple contact
  3. Customer with web bl information
    1. Create Customer with WEB BL information
    2. Update customer Web bl information
    3. Inactivate customer having WEB BL
  4. Customer with CBU information
    1. Create Customer with CBU information
    2. Remove CBU information
    3. Update CBU information
    4. Inactivate customer having CBU
  5. Customer with Customer relationship
    1. Create customer with customer relationship
    2. Remove customer relationship
    3. Inactivate customer having customer relationship
  6. Create Customer contact with Communication preference information
    1. Create customer
    2. Add contact
    3. Add communication preference
    4. Remove communication preference
    5. Inactivate customer

The below diagram shows the existing on-prem SCV replica solution.

The Filed mapping between CMD to SCV Replica TAGs is provided in below confluence page.

CMD & Interface Field Mapping

CMD application publish the CREATE & UPDATE events on Customer, Contact, Concern & Customer Facility entities to SCV Replica.

SC300S Power Center Job picks the message (with code & action) from queue and process it to prepare snapshot of customer/contact/concern/facility entity message in XML format.

SC300S job connects to CMD and GEO database to get complete snapshot of the respective entity information and push the snapshot XML message into message queue. Sample message is given below.

CMD MQ Push (SCV Replica) Java application will consumes the snapshot XML message pushed by SC300S job and convert the XML message into TAG based encoded message which can be readable by SCV Replica consumers.

CMD MQ Push, publishes separate entities (Customer, Contact, Concern & Customer Facility) into separate output queues with TAG based structure.

CMD MQ Push also connect to CMD (C_PTR_ALT_CODES, C_PTR_REL, C_PTR_CONT tables) and GEO (C_ALT_CODE, C_GDA_DFND,AREA C_TYP_TYPE tables) database to get additional information.

The fields from SC300S job message is mapped to SCV replica TAG based message fields based on below mapping

CMD & Interface Field Mapping

Below are the tables and fields red by CMD MQ Push application

CMD/GEO Table.Field Name
C_ALT_CODE.GDA_DFND_AREA_ROWID
C_ALT_CODE.CODE
C_TYP_TYPE.CODE
C_GDA_DFND_AREA.ROWID_OBJECT
C_GDA_DFND_AREA.NAME
C_GDA_DFND_AREA.DESCRIPTION
C_GDA_DFND_AREA.TYP_TYPE_CD
C_GDA_DFND_AREA.ACTIVE_FLAG
C_GDA_DFND_AREA.NAME
C_PTR_CONT.prmry_email
C_PTR_ALT_CODES.CODE
C_PTR_ALT_CODES.CREATE_DATE
C_PTR_ALT_CODES.LAST_UPDATE_DATE
C_GDA_DFND_AREA_REL.Gda_Dfnd_Area_Prnt_Rowid
C_GDA_DFND_AREA_REL.Typ_Type_Cd

SCV Replica Solution Design on Cloud​

The below diagram shows the how the SCV replica solution needs to be implemented in modern platform without impacting the few SCV Replica consumers.

On modernization platform, below are the events on which the SCV message replication event should be triggered to publish the message to SCV consumers. These events should be identified by Ingest API or separate component to trigger the SCVReplicator java component.

  1. Normal Customer
    1. Create customer
    2. Update customer
    3. Inactivate customer
  2. Customer with contact
    1. Create Customer
    2. Update contact
    3. Add new contact
    4. Remove contact
    5. Inactivate Contact
    6. Reactivate Contact
    7. Inactivate customer having multiple contact
  3. Customer with web bl information
    1. Create Customer with WEB BL information
    2. Update customer Web bl information
    3. Inactivate customer having WEB BL
  4. Customer with CBU information
    1. Create Customer with CBU information
    2. Remove CBU information
    3. Update CBU information
    4. Inactivate customer having CBU
  5. Customer with Customer relationship
    1. Create customer with customer relationship
    2. Remove customer relationship
    3. Inactivate customer having customer relationship
  6. Create Customer contact with Communication preference information
    1. Create customer
    2. Add contact
    3. Add communication preference
    4. Remove communication preference
    5. Inactivate customer

EMP Publish services:

EMP publish services (Customer, Contact, Concern & Customer Facility) needs to be developed/updated to include additional fields which are missing in the current version of the AVRO schema which are required for SCV Replica consumers.

  1. Respective entity JSON object will be generated along with additional fields required for SCV replica
  2. Using GEO APIs, get the country, state, city codes as applicable

The EMP publish services AVRO message structure if already defined and might need to be enhanced with additional fields required for SCV replica.

TBD

CityGeo exception will not occur on modern platform as GEO application will provide all GEO Ids.

SCVPush Java component Logic:

SCVPush is an existing Java component needs to be refactored to consume JSON message from On Ground EMP topic replicated from cloud EMP topics instead of XML message. Below are key points:

  1. Existing CMD MQ Push application will be refactored to consume JSON message from On Ground EMP topic replicated from cloud EMP topics instead of XML message.
  2. Extract the data elements from JSON message and map it to respective SCV specific TAGs mentioned in CMD & Interface Field Mapping page.
  3. Push the encoded (in TAG format) message to IIB to push further to SCV consumer specific MQs.
  4. Each entity message is processed independently and each entity message should have all required data elements as part of the message.
  5. Deploy the application on-prem Weblogic server.

Sample output message from SC300S Job (On-Prem)

`<?xml version="1.0" encoding="UTF-8" standalone="no"?>`
<CUSTOMER
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ACTION &gt; UPDATE</ACTION>
<SEQUENCENO &gt; 88223</SEQUENCENO>
<ORGDETAIL>
<CUSTNO1>
<CUSTNO &gt; 11700187045</CUSTNO>
<COUNTRYCODE &gt; 117</COUNTRYCODE>
<CUNAME &gt; ACCENTURE 001</CUNAME>
<CNSTATUS &gt; ACTIVE</CNSTATUS>
<CNTYPE &gt; 1</CNTYPE>
<LEGACYCUSTNO &gt; IE00187045</LEGACYCUSTNO>
<LEGACYSYSTEMID &gt; 1</LEGACYSYSTEMID>
</CUSTNO1>
<CNACCOUNTGROUPID &gt; 2</CNACCOUNTGROUPID>
<CSHORT &gt; ACCENTURE </CSHORT>
<AFFILIATEID &gt; 1</AFFILIATEID>
<AFFILIATEID &gt; 2</AFFILIATEID>
<AFFILIATEID &gt; 5</AFFILIATEID>
<AFFILIATEID &gt; 6</AFFILIATEID>
<AFFILIATEID &gt; 7</AFFILIATEID>
<AFFILIATEID &gt; 8</AFFILIATEID>
`<GEO\_REGION\_ID > 0000000000048</GEO\_REGION\_ID>`
<LANGUAGEKEYID &gt; EN</LANGUAGEKEYID>
</ORGDETAIL>
<LOCDETAIL>
<CUSTNO2>
<CUSTNO &gt; 11700187046</CUSTNO>
<COUNTRYCODE &gt; 117</COUNTRYCODE>
<CUNAME &gt; ACCENTURE 001</CUNAME>
<CNSTATUS &gt; ACTIVE</CNSTATUS>
<CNTYPE &gt; 2</CNTYPE>
<LEGACYCUSTNO &gt; IE00187046</LEGACYCUSTNO>
<LEGACYSYSTEMID &gt; 1</LEGACYSYSTEMID>
</CUSTNO2>
<STREETNAME &gt; GRAND CANAL SQUARE</STREETNAME>
<STREETNO &gt; 1</STREETNO>
<ALINE2 &gt; GRAND CANAL HARBOUR</ALINE2>
<ALINE3 &gt; 2 DUBLIN</ALINE3>
<CITYGEOID &gt; 1JKROT9381ABJ</CITYGEOID>
</LOCDETAIL>
<LKSTATUS &gt; ACTIVE</LKSTATUS>
<PHONE &gt; 353-0000000000</PHONE>
<EMAIL>Standard@pilot.com</EMAIL>
</CUSTOMER>

Questions/Points to be relooked into to clarify

  1. For Location (Customer Facility) few fields like customerNumber,name,countryCode,customerType,status,createTimeStamp,countryGeoId,locationCode,createByUser,updateByUser,addressName,zipCode,zipGeoId,zipCity are missing in EMP publish facility we need to include them to send SCV replica. OR we need to verify that these fields are really required to send.
  2. There are around 20 attributes which we need to check whether these fields are required or we can skip them. Need to analyze, If required how to get them. These fields are listed in filed mapping page.
  3. In existing MQ PUSH application, we are using few tables CUSTOMER_ACTION_HIST, CBU_ACTION_HIST, CMD_MQPUSH_FAILED_MESSAGES, CMD_MQPUSH_MESSAGES, CMD_MQPUSH_PARKED_MESSAGES etc in MD schema. In modernization solution where we need to keep these tables? Are these tables really required now?
  4. In SC300S job, we need to check and implement logic related to below items:
    1. CityGeo Exception logic
    2. How AFFILIATEID Ids are getting generated
  5. Need to update MQ PUSH application to consume messages from respective topics and deploy it in Weblogic server.
Was this page helpful?