Service - Sell Offer Manager: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
Line 113: Line 113:
//price: "xx", //removing and using findDataMain process
//price: "xx", //removing and using findDataMain process
//expiryTime: "xx", //removing and using findDataMain process
//expiryTime: "xx", //removing and using findDataMain process
status: "xx", // "recalculating"|"complete"|"error", not really needed, but added as a reference
status: "xx", // "recalculating"|"complete"|"error", not really needed, added as a reference
errorsFound: [], // stringSet, when recalculating, will reset to empty, once finished if any errorsFound then status will be "error"
errorsFound: [], // stringSet, when recalculating, will reset to empty, once finished if any errorsFound then status will be "error"
// uniqueRequestId: "xx", (I think no longer used) used for idempotence when first process request called, in case that invocation fails and restarts, can be removed when set to complete/error
// uniqueRequestId: "xx", (I think no longer used) used for idempotence when first process request called, in case that invocation fails and restarts, can be removed when set to complete/error
Line 127: Line 127:
* sellOfferPlanQuantities works out the combined total for multiple sellOfferPlans, all sellOfferPlans must offer the given payment and delivery Ids, if not will be status error
* sellOfferPlanQuantities works out the combined total for multiple sellOfferPlans, all sellOfferPlans must offer the given payment and delivery Ids, if not will be status error
* combinedSubtotal / orderQuantity / sellOfferPrices are values found during re-calc
* combinedSubtotal / orderQuantity / sellOfferPrices are values found during re-calc
* price is stored in FindData table, and price is recalculated whenever FindData expires. This will mean should always request price via FindData, cannot request directly from orderPrice table


= Complex Filter requests =
= Complex Filter requests =

Revision as of 12:14, 10 January 2022

Overview

Each sell offer is handled by a Service - Sell Offer (handlers) service.

The Sell Offer Manager service handles shared orchestration of the Sell Offer Handler services.

Repository

https://bitbucket.org/izara-market-products/izara-market-products-sell-offer-manager/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "ProductGraphServiceName"
	configTag: "ProductGraphServiceName"
	configValue: xxx // eg: "ProductGraph"
}
{
	configKey: "SellOfferHandlerService"
	configTag: xxx // sellOfferHandlerServiceNameTag, eg: "SellOfferStandard", this is what is saved in each catalog record
	configValue: {
		serviceName: xxx // eg: "SellOfferStandard", this is the actual deployed service name}
	}
}
{
	configKey: "TranslateIdsType"
	configTag: xxx // eg SellOffer > Product would be sellOffer_product
	configValue: {
		ttl: 64000 // number of seconds TranslateIdsCache records live for
	}
}

SellOffers

Records which Handler manages each sell offer

{
	sellOfferId
	sellOfferHandlerServiceNameTag
}
  • partition key: sellOfferId
  • sort key: (none)

TranslateIdsCache

Stores a record for one translateId data which can be queried as a cache rather than performing the translateIDs logic

{
	cacheId // fromType + "_" + fromDataId + "_" + toType
	toDataId
	expiryTime
}
  • partition key: cacheId
  • sort key: toDataId
  • expireTime is set as an automatic DynamoDB TTL attibute

LogicalResultsMain

LogicalResultsMain

LogicalResultsData

LogicalResultsData

LogicalAwaitingStep

AwaitingStep

LogicalSortedRequest

LogicalSortedRequest

AwaitingMultipleSteps

AwaitingMultipleSteps

  • stores pending sellOfferPriceSortResultId

FindDataMain

FindDataMain

FindDataAwaitingStep

AwaitingStep

FindDataSortedRequest

FindDataSortedRequest

OrderPrice

Cache of one completed total calculation for list of sellOffer quantities, and one combination of deliverToLocationId, / sellOfferPlanUserPaymentMethodLinkId / sellOfferPlanDeliveryMethodLinkId. Price includes Payment and Delivery method costs.

{
	orderPriceId: "xx",
	sellOfferQuantities: {},
	deliverToLocationId: "xx",
	//price: "xx", //removing and using findDataMain process
	//expiryTime: "xx", //removing and using findDataMain process
	status: "xx", // "recalculating"|"complete"|"error", not really needed, added as a reference
	errorsFound: [], // stringSet, when recalculating, will reset to empty, once finished if any errorsFound then status will be "error"
	// uniqueRequestId: "xx", (I think no longer used) used for idempotence when first process request called, in case that invocation fails and restarts, can be removed when set to complete/error
	combinedSubtotal: "xx",
	orderQuantity: "xx",
	sellOfferPrices: {}
}
  • partition key: orderPriceId
  • sort key: (none)
  • orderPriceId is {hash of sellOfferQuantities / orderQuantity / deliverToLocationId / sellOfferPlanDeliveryMethodLinkId / sellOfferPlanUserPaymentMethodLinkId
  • sellOfferPlanQuantities works out the combined total for multiple sellOfferPlans, all sellOfferPlans must offer the given payment and delivery Ids, if not will be status error
  • combinedSubtotal / orderQuantity / sellOfferPrices are values found during re-calc
  • price is stored in FindData table, and price is recalculated whenever FindData expires. This will mean should always request price via FindData, cannot request directly from orderPrice table

Complex Filter requests

{
	filterType: "sellOffer" //unique id is sellOfferId
	type: "group",
	elements:
	[
		{
			type: "complexFilter",
			complexFilter: {
				filterType: "sellOfferPlan",
				// see [[Service - Sell Offer Plan|Complex Filter requests]]
			}
		},		
		{
			type: "complexFilter",
			complexFilter: {
				filterType: "sellOfferTermLink",
				// see [[Service - Sell Offer Terms|Complex Filter requests]]
			}
		},	
		{
			type: "complexFilter",
			complexFilter: {
				filterType: "planDeliveryPaymentCombination",
				// see [[Service - Sell Offer Plan|Complex Filter requests]]
			}
		},
		{
			type: "complexFilter",
			complexFilter: {
				filterType: "orderPrice",
				// see below
			}
		},		
		...
	]
}
  • TranslateIds from planDeliveryPaymentCombination to sellOffer will find all unique sellOfferIds in the range of combinations
  • TranslateIds from orderPrice to sellOffer will find all unique sellOfferIds in the range of orderPrices
{
	filterType: "orderPrice" //unique id is orderPriceId
	type: "group",
	elements:
	[
		{
			type: "logical",
			logicalTag: "maxPrice"|"minPrice"|"averagePrice",
			comparison: "xx", // "equals"|"greaterThan"|"lessThan"|"greaterThanEquals"|"lessThanEquals"
			value: "xx",
			orderQuantity: 1,
			deliverToLocationIds: [],
			paymentMethodIds: [],
			deliveryMethodIds: []
			excludeEmpty: true
		},
		{
			// finds all orderPrices for one sellOfferId according to all combinations of deliverToLocationIds / paymentMethodIds / deliveryMethodIds
			type: "logical",
			logicalTag: "sellOfferQuantityLocationIdCombinations",
			sellOfferId: "xx",
			orderQuantity: 1,
			deliverToLocationIds: [],
			paymentMethodIds: [],
			deliveryMethodIds: [],
			excludeEmpty: true
		},
		{
			//will create a set of orderPrices, one per sellOffer according to aggregate function
			type: "logical",
			logicalTag: "aggregatedSellOfferPrices",
			orderQuantity: 1,
			deliverToLocationIds: [],
			paymentMethodIds: [],
			deliveryMethodIds: [],
			aggregate: "xx", // "maxPrice"|"minPrice"|"averagePrice",
			excludeEmpty: true
		},
		...
	]
}
  • do not have open ended filters (like orderPrice status) because orderPrice does not have a defined set of underlying records, instead each element needs to contain filters that will create a list of orderPrices (that can be filtered in some way once created)
  • excludeEmpty: if true will not store values that are null/zero/empty string (eg orderPrices that are status "error")

Working documents

Sell Offer Manager