Service - Import Data

Overview

Orchestrates importing of objects/data into project.

Repository

https://bitbucket.org/izara-core-import-export-data/izara-core-import-data-import-data/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "objectType",
	configTag: "xx" // {objectType, eg: sellOffer/Product/VariantProduct etc..}
	configValue: {
		createObjectServiceName: "xx" // {service name service that handles this type}
		createLinkServiceNames: {
			"xx": "yy", // index is name of link to objectType, value is serviceName
		}
	}
},

ImportBatchMain

{
	importBatchId: "xx", // random uuid
	userId: "xx", // submitted by userId
	startTime: currentTime.getTime(),
	batchConfig: {}, // same as request
	status: "xx", // "* NOT YET:processingRawRecords" | "processingObjects" | "error" | "complete" 
}

• partition key: importBatchId
• sort key: {none}

ImportBatchErrors

{
	importBatchId: "xx",
	errorId: "xx", // random uuid
	error: "xx", 
}

• partition key: importBatchId
• sort key: {none}

RawRecord

• NOT YET: maybe move into CSV processing, as each format might have own way of handling per line/record formats

Is a raw copy, split out into fields, of one submitted record. One record may have multiple objects in it's fields.

{
	importBatchId: "xx",
	rawRecordId: "xx", // random uuid
	fields: {}, // key is the name of the field
	recordNumber: ##, // eg the line number of the record
	status: "xx",
	errorsFound: {},
}

• partition key: importBatchId
• sort key: rawRecordId

RawRecordAwaitingProcess

• NOT YET: maybe move into CSV processing, as each format might have own way of handling per line/record formats

Is a list of raw records waiting to be saved into PendingObjectMain so can be handled asynchronously, and trigger next step of process when all complete.

{
	importBatchId: "xx",
	rawRecordId: "xx",
}

• partition key: importBatchId
• sort key: rawRecordId

PendingObjectMain

One item per object that needs to be created.

{
	importBatchId: "xx",
	objectId: "xx", // hash of object with importBatchId, userId, objectType, and fields properties
	objectType: "xx", // eg variant|product|sellOffer|sellOfferPrice|sellOfferPlan|...
	fields: {}, // key is the name of the field
	rawRecordId: "xx",
	status: "xx",
	errorsFound: {},
}

• partition key: importBatchId
• sort key: objectId
• there is the possibility of a feed sending the same objectType and fields multiple times in a single request, above design will only handle this once, I think this is OK, maybe do a check and add error if duplicates found

PendingObjectReference

Creates a link between submitted referenceId and saved object, so can find when other objects reference it.

{
	importBatchId: "xx",
	referenceId: "xx", // objectType_{feed supplied referenceId}
	objectId: "xx", // eg variant|product|sellOffer|sellOfferPrice|sellOfferPlan|...
}

• partition key: importBatchId
• sort key: referenceId
• when creating maybe throw error if item exists with different objectId

PendingObjectAwaitingProcess

List of PendingObjectMains waiting to be either sent out to external service create function, and trigger next step of process when all complete.

{
	importBatchId: "xx",
	pendingObjectId: "xx", // {objectType}_{objectId}
}

• partition key: importBatchId
• sort key: objectId

PendingLink

One item per link between objects.

{
	importBatchId: "xx",
	pendingLinkId: "xx", // {objectId}_{referenceId}
}

• partition key: importBatchId
• sort key: pendingLinkId
• currently think of objects that can be independently created, then the link gets made, but perhaps could also use for cases where one object must be created before another can be.

PendingLinkAwaitingProcess

• Maybe this table not needed, maybe we can paginate processing of PendingLinks, but that would be sync processing, if we want async processing maybe need this table

List of PendingLinks waiting to validate reference and store awaitingSteps.

{
	importBatchId: "xx",
	pendingLinkId: "xx", // {objectId}_{referenceId}
}

• partition key: importBatchId
• sort key: pendingLinkId
• maybe make sortKey objectId only, but then could not have multiple parents
• maybe save in this record needed fields, eg objectType/reference

Process

1. * NOT YET: go through RawRecordAwaitingProcess and create items in PendingLink for each link between objects, PendingObjectMain for each item found, and PendingObjectReference for any references found (also PendingLinkAwaitingProcess and PendingObjectAwaitingProcess)
2. iterate PendingLinkAwaitingProcess to check reference valid and create awaitingMultipleSteps for the object and the referenced object, save into awaitingMultipleSteps for ImportBatchMain
3. if any errors found prior to this step stop processing and mark feed as status error
4. send PendingObjectAwaitingProcess to external services. Save into PendingObjectProcessing (maybe not needed)
5. as objects are created will trigger lambda that sets status of PendingObject, removes awaitingMultipleSteps for ImportBatchMain and checks if any PendingLink awaitingMultipleSteps exist for that object and all steps complete, if yes process the links. Check if awaitingMultipleSteps for ImportBatchMain complete
6. if PendingLink awaitingMultipleSteps exist and complete, send to external service to create the link
7. Lambda subscribes to create link flow, removes PendingLinkProcessing (maybe not needed), check if awaitingMultipleSteps for ImportBatchMain complete.

External service requests

Both createObject and createLink.

• standard Lambda like ProcessLogical and FindData
• ImportData subscribes to standard complete topic: CreateObjectComplete
• Each external service can handle processing and recording the objectId to return in their own way, eg by having another table that links the external service's identifier with the ImportData objectId, querying this table to make CreateObjectComplete message
• userId is also sent as need to record user creating objects
• objectId is also sent, must be returned in CreateObjectComplete message

Linking objects

Two types of linking:

1. Independent: objects can be created independently of each other in any order
2. Dependent: One object must be created before the other in a specific order

for Config setting objectType.parentLinks either object can be the parent for Independent links, for Dependent links the object created first is considered the parent.

Two object types may have multiple types of links connecting them so each parentLinks element has a list of linkTags which reference what type of link is being created.

For each parentLinks element there will be a matching entry in the other object's childObjectTypes array.

Object hierarchy and field schema

• Some fields will be required, some optional
• some fields possibly have system defaults
• perhaps user can setup default templates (do later if has value)
• schema will need to state identifier fields for each object, if set in feed Import Data knows is pointing to existing child/parent object, if empty needs to create new
• perhaps each objectType states it's child objects, as more likely to be aware of these than parent objects

where to store/set schema

Considering external service delivers this to ImportData in Initial Setup, as seed data injected directly into Import Data Config Dynamo table.

Working documents

Working_documents - Import Data