Table Overview

1. WS Tables

These are the table used to store the information in the same form as returns from Chrome. These are
the raw data with no IDs and never used by application. In theory, there is NO use of these data, except
for some trouble shooting or for history.

2. Chrome Table (of CDM database)

These tables are filled with the help of WS tables. Relevant information extract from above tables are
and filled in these tables. This table referred by CDM application. These tables are also being referred by
HVMS application, if the requested VIN is not there in native HVMS database.
3. Chrome Table of (of HVMS database)

These tables are the replica of #2. HVMS application has direct interaction of these table only The
request gets propagated only in case of non-availability of VIN in this database.

4. Mobile Table (of HVMS database)

These tables are just a condensed form of #3. The SQLite database gets created using these tables.
Propose changes

For creating the inventory, we don’t require all mention information in place. We’ll divide the saving
part in 2 chunks.

1. Save in real time: The following tables will get populate in real time. These are the least required
information; we need to have while creating an Inventory (This can be a few more).
a. CHROME_MAKE
b. CHROME_MODEL
c. CHROME_BODY
d. CHROME_YMMBCV
e. Chrome_VINEquipment
f. Chrome_Category

2. Save Asynchronously: We’ll save the rest of the information asynchronously.

Alternative Approach

Issue

 VIN Decoding from all backend/front end application like (UCR, HVMS, UCR-Device and HVMS-
Device), happens by using their own web service which in turn calls the CDM system.
 CDM system tries to find the requested information at its own level.
 In case of failure, the chrome service is called.
 The scalability of the changes made to the process is minimal as it leaves lesser scope for any
change request, as one change is translated to the web services configured to every application
in -turn pointing to CDM system for data exchange.
HVMS Device -> DecodeVINMobile -> DecodeVIN -> CDMDecodeVIN

HVMS Web -> DecodeVINWeb -> DecodeVIN -> CDMDecodeVIN

Formulate a centralized Service which takes care of the following:

1. Communicate with various applications.

2. Reference of this service will be used in each application leaving the web service in a reusable
state for any further integration if needed.
3. Web service inserts the record to relevant database.
4. Currently, CDM system returns the information in JSON format which is de-serialized by the
application to the corresponding tables and is then inserted in the form of records.

Steps and Regression

Proposed Steps:

 Create a new web service, touching the existing code.

 Move the all common code to the centralized system and test this well.
 Change the reference of the system allowing backwards integration to the old state in case of
any disaster or system downtime.
 No change in any DB schema leaving the application unaltered from the functional perspective.