Data Models
The Originations Data Storage microservices stores all data in a container within a NoSQL document database. This DB is MongoDB.
A document database does have logical relationships within the collections and documents - for the Storage Manager Microservice and full flexibility for the caller - the Entity Item Entry (data payloads) are stored as unstructured (or semi-structured) data with optional validation that can be configured by the client if required.
For each entity_definition defined by the client, when in-flight data is sent via a payload this is (if enabled) validated then stored against a specific collection enabling fast searching, retrieval and updates for future operations.
The database diagram would not be fixed and would be dynamic based on the configuration and number of entity_definition(s), a logical view of the database however would be as follows:
Logic Structure
{
"code": "OnboardingJourneyABC",
"purgeAnchorPoint": "created, lastUpdated or empty",
"purgeDuration": "60",
"reminderAnchorPoint": "created, lastUpdated or empty",
"reminderDuration": "53",
"searchPaths" : {
"mobile" : {
"searchPath" : "contact.phone.mobile",
"returnEntityItemEntry" : "true"
},
"firstname" : {
"searchPath" : "account.name.firstname",
"returnEntityItemEntry" : "true"
},
"street" : {
"searchPath" : "contact.address.line1",
"returnEntityItemEntry" : "true"
},
"city" : {
"searchPath" : "contact.address[0].city",
"returnEntityItemEntry" : "true"
}
},
"entityItemDefinitions": {
"PII": {
"type": "JSON",
"seed": {
"firstName": "",
"lastName": "",
"age": ""
},
"validationSchema": {
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://example.com/product.schema.json",
"title": "PII JSON Schema",
"description": "PII Details for onboarding application",
"type": "object",
"properties": {
"firstName": {
"type": "string",
"description": "The person's first name."
},
"lastName": {
"type": "string",
"description": "The person's last name."
},
"age": {
"description": "Age in years which must be equal to or greater than zero.",
"type": "integer",
"minimum": 0
}
}
},
"applyValidation": "true"
},
"ADDRESS": {
"type": "JSON",
"seed": {
"street": "",
"suburb": "",
"state": "",
"country": ""
},
"validationSchema": "",
"applyValidation": "false"
},
"PERSONAL": {
"type": "JSON",
"seed": {
"street1": "",
"suburb": "",
"state": "",
"country": ""
},
"validationSchema": "",
"applyValidation": "false"
}
},
"eventTasks": {
"APPLICATION_SUBMITTED": {
"eventType": "UPDATED",
"dependsOn": "",
"userType": "MetaData",
"entryCondition": {
"key": "Status",
"previousOperand": "E",
"previousValue": "InProgress",
"targetOperand": "E",
"targetValues": ["UnderReview","AutoApproved","AutoDenied"]
}
},
"FUNDING_REQUEST_RAISED": {
"eventType": "UPDATED",
"dependsOn": "APPLICATION_SUBMITTED",
"userType": "Funding",
"entryCondition": {
"key": "FundingStatus",
"previousOperand": "E",
"previousValue": "",
"targetOperand": "E",
"targetValues": ["Opted"]
}
}
},
"createdDate": "2020-07-21T17:32:28Z",
"createdById": "32423",
"updatedDate": "2020-08-21T10:32:28Z",
"updatedById": "54323",
"integrityValue": "10023"
}
Notes:
- A payload of data would only need to reference the EntityDefinition (for optional seed data and validation)
- A payload would not need to be fully complete to update, 'partial' payloads are also supported as long as a traceable dot notation JSON path can be established
For example, from the example below, to update only the fragment 'office2' phone number all that would need to be sent in the payload with basic a unique predicate identifier would be:
[{
"customer-address" : {
"primaryAddress" : {
"phone" : {
"office2" : "02-8765-5678"
}
}
}
}]
Example : Data adhering to a simple optional schema being purged 60 days after creation with no email reminders:
Stored using the following structure:
[{
"_id" : "5ce8050c3fd48a59557122ca",
"customerName" : "James Bond",
"customer-address" : {
"primaryAddress" : {
"street" : "Level 2/1a Rialto Lane",
"city" : "Sydney",
"state" : "NSW",
"postcode" : "2095",
"phone" : {
"office1" : "02-1234-5678",
"office2" : "02-8765-4321"
}
},
"secondaryAddress" : {
"street" : "Floor 10, 85 Castlereagh Street",
"city" : "Sydney",
"state" : "NSW",
"postcode" : "2000",
"phone" : {
"office1" : "02-1234-5678",
"international" : "+612-8765-4321"
}
}
}
}]
There are two options for defining the EntityDefinition to be used fully supported by the Storage Manager Microservice:
- Non validated data (persistence similar to Journey Manager), or
- Validated data for specifically defined FieldDefinitions within the EntityDefinition.
For non validated data persistence, the EntityDefinition would be defined as follows:
EntityDefinition 'InflightOnboardingJourneyACME"
[{
"code" : "InflightOnboardingJourneyACME",
"purgeAnchorPoint" : "created",
"purgeDuration" : "60",
"reminderAnchorPoint" : "",
"reminderDuration" : ""
}]
Note: When a new EntityDefinition is persisted, additional metadata is added (i.e. createdDate, etc).
Validation of the JSON payload will be handled by the JSON Schema, XML data by XML Schema.
In this topic