Date post: | 24-Jan-2018 |
Category: |
Technology |
Upload: | mongodb |
View: | 303 times |
Download: | 0 times |
A Customer-Centric
Banking Platform Powered
by MongoDBAlan Reyes Vilchis
Technical Lead, Customer 360
Customer 360 Development Area
Customer 360 was born with MongoDB
adoption at Banco Azteca
Our objective is to build a customer-centric
services platform to be used by all of the
companies of the group
Grupo Elektra
Banco Azteca
Banco Azteca is changing its way to relate with the
Customers, under the motto:
“Everything that you can do in a branch,
you can do it in our app”
To achieve this objective we needed to review our
workflows
Before Platform 360
Branch
Unique
Customer
Banking Core Loans
App
Backend
After Platform 360
Platform 360
BranchApp
Backend
Unique
Customer
Banking
CoreLoans
Services
What are we building?
Digital Mobile Bank
iOS
Application
Android
Application
Application
Backend
Customer 360
Single View
System of
Record
Customer 360
Single View
Money Exchange before the Single View
Money Exchange
at branch
Banking
Core
Unique
Customer
Money Exchange
own database
The identification of customer required searches to different systems, using
different contracts and capabilities for each one of them
Money Exchange after the Single View
Money Exchange
at branch
Customer 360
Single View
The identification of customers can be done now in a single search, retrieving
results with the same or better quality
Single View Design
Person
Master
Sources
UC_1-1-1-1
ALNOVA_12345678
UC_1-3-20-12
LOANS_1-1-1-1
Structure of a Person’s Record on the single view:
Single View
Single View Data Flow
Banking Core
MS SQL Server
Unique Customer
Oracle
Loans
AS400
REST API
Unified Database
Talend
Talend
Scop
e
Bu
sin
ess
Ben
efi
ts
Transactions are written first to the single view, which
propagates the data back to the source system of record.
Writes are performed concurrently to the source systems as
well as the single view
The single view data model is enriched with additional
sources to serve more applications, including real-time
analytics. The single view becomes a platform serving
multiple applications
Single View
Platform
Records are copied via ETL or message queue
mechanisms from the source systems into the single view,
serving read queries. The single view serves one specific
application
Single View
Application
Single View
First
Dual Writes
Read
Centric
Transforming the role of
the single view
Reads & Writes
Single View Maturity Model
https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-
your-business-part-3
Architecture for Writes to the Single View
ET
L o
r M
es
sa
ge
Qu
eu
e
Web
Mobile
CRM
Mainframe
Single View Call Center
Analytics
Technical
Support
Billing
Update
Queue
Reads
Writes
Source Systems Consuming Systems
Load
https://www.mongodb.com/blog/post/10-step-methodology-to-creating-a-single-view-of-
your-business-part-3
System of Record
• New business logic and constraints for our new
mobile-first use cases
• Unique Customer didn’t allow to register
anonymous customers
• Need to manage the customers of new
businesses without requiring them to have their
own databases
Why was it needed?
Design of the System of Record
Structure of a Customer Record
Customer
Personal Data
Business
Extended A
Business
Extended B
Business
Extended C
(Virtual)
System of Record Data Flow
Unique Customer
Oracle
System of Record
REST API
Database Banking Core
MS SQL Server
Main technologies
• Horizontal scaling
• It’s flexible schema allows us to
– Reduce the development time in half, by integrating
the development work on the database and the
application
– Keep related objects with variable schemas together in
the same collection or array
MongoDB
Java
• Enterprise trusted
• Strong typing
• Plenty of libraries
Technical challenges
Integration of customer data
ID: 1
Name: John Smith
ID: 2
Username: jsmith
ID: 1
Name: John Smith
Username: jsmith
ID: 2
Primary: 1
Solution on a Relational Database
CustomerPrima
rycustomer_id
primary_id
CustomerData
customer_id
name
username
CustomerId
customer_id
Solution on MongoDB
{
"id": 1,
"name": "John Smith"
}
{
"id": 1,
"name": "John",
"username": "jsmith"
}
{
"id": 2,
"principal": 1
}
{
"id": 2,
"username": "jsmith"
}
Keep related objects together
Unique Customer ID
channel: 1
branch: 13
id: 87
Alnova ID
id_alnova: 1
Unique Customer ID
channel: 2
branch: 23
id: 54
Customer
Solution
CustomerLinkedUniqueCustom
ercustomer_id
channel
branch
id
CustomerLinkedAlnova
customer_id
alnova_id
Customer
customer_id
{
"id": 1,
"linked_ids": [
{
"origin": "bank",
"id": {
"bank_id": 1
}
},
{
"origin": "branch",
"id": {
"channel": 1,
"branch": 13,
"id": 87
}
},
{
"origin": "branch",
"id": {
"channel": 2,
"branch": 23,
"id": 54
}
}
]
}
VS
Integration of Java and MongoDB
Technologies stack
MongoDB
Native Java
Driver
MongoJack
Jackson
Value.Immutabl
e
Output:
Value.Immutables
Creates immutable implementations based on a contract
Output:
Value.Immutables
Immutables enforces consistency
Jackson
@Value.Immutable
interface Customer {
@JsonProperty("_id")
int getId();
@JsonProperty("first_name")
String getFirstName();
@JsonProperty("last_name")
String getLastName();
}
{
"_id": 1,
"name": "JOHN",
"first_name": "SMITH",
"last_name": "SMITH"
}
Jackson Mixin support
// Data Class
class Data {
String property;
String getProperty() {
return this.property;
}
String setProperty() {
tis.property = value;
}
}
Jackson
ObjectMapper
Data
instance
JSON// Annotated Contract
interface DataMixin {
@JsonProperty("property")
String getProperty();
}
MongoJack
Customer
MongoDB
Collection
JacksonCollection (MongoJack)
ObjectMapper (Jackson)
MongoJack Module
MongoDB Java Driver
DBObject
Common Library
Customer Class
Reusability
Customer
instance
JacksonCollection (MongoJack)
ObjectMapper (Jackson)
MongoJack
Module
JSON
HTTP API (Jersey Server)
ObjectMapper (Jackson)
MongoDB
Collection
HTTP Client (Jersey Client)
ObjectMapper (Jackson) Customer
object
Distributed transactions
Current Model
Customer
Extended A
Customer
Extended B
Customer
Customer Model
addAddress()
setName()
addLinkedId()
beginModify()
commit()
Controller
Proposed Model
Transaction
Actions
apply()
SetNameAction
AddLinkedIdActio
n
AddAddressAction
Customer
Extended A
Customer
Extended B
Customer
Controller
Action
prevalidate()
apply()
notify()
Transaction flow
Transaction
Prevalidation
Application
Notification External
services
Database
Summing up
Summary
To sum up, I showed you:
• How we have build our single view
• How we have build our system of record
• How we used MongoJack, Jackson and
Value.Immutables to map Java objects to MongoDB and
back
• How we designed a framework to apply complex
transactions
Thank you!
On behalf of the
Customer 360 Development Team
Q & A
Alan Reyes VilchisTechnical Lead, Customer 360
@KuttKatrea
Font Awesome by Dave Gandy - http://fontawesome.io