Service - Sell Offer Manager: Difference between revisions
Jump to navigation
Jump to search
Line 86: | Line 86: | ||
[[Standard LogicalResults Per Service|LogicalSortedRequest]] | [[Standard LogicalResults Per Service|LogicalSortedRequest]] | ||
== | == AwaitingMultipleSteps == | ||
[[NPM module - izara-shared|AwaitingMultipleSteps]] | |||
* stores pending sellOfferPriceSortResultId | |||
* | |||
== FindDataMain == | == FindDataMain == |
Revision as of 14:42, 25 December 2021
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
LogicalResultsData
LogicalAwaitingStep
LogicalSortedRequest
AwaitingMultipleSteps
- stores pending sellOfferPriceSortResultId
FindDataMain
FindDataAwaitingStep
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, but 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
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")