Online Returns return processor ECS component¶
Overview¶
This repository contains a service. Online Returns return processor task will fetch return products detail from Kafka server and will persist same in return product RDS tables. This processor will call Product V1 and Price V2 service to enrich min details and catchweight details for return products.
Catchweight Logic- Get Gtin details where isPrimaryBarcode= true and type is not null/blank, if type=EAN13/UCC14 then get its corresponding Gtin Id. if type=VPLU then apply some logic and get its corresponding Id. If Gtin type= VPLU, get its vpluId ,then search for gtin details having type =VPLUBC if Gtin with type VPLUBC is found then get its gtinId. Check if gtinId contains vpluId, ends with “000000” and gtinId startsWith “01”, “02”, “03”, “20”, “21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”. If the conditions are all true then plucode = gtinId else raise an alert.
Accounts Needed¶
AWS accounts will be required for DEV/SIT/PROD.
References¶
Unit tests & code coverage at about 90%+.
Configuration for multiple environments, DEV/SIT/PRD.
Document |
Ref |
|---|---|
Architecture Document |
|
Jira Story |
|
Bitbucket Repository |
Testing Approach¶
We will be using a BDD approach where the behaviour will be tested first the code will be developed to match the tested behaviour.
Deployment strategy¶
The deployment is handled by a jenkins multibranch pipeline, https://jenkins.p.morconnect.com/sonarqube/dashboard?id=storepick-online-returns-return-processor-dev. The commit in the develop branch will automatically deploy the application to the aws environments. The release is done by standard process of tagging the release branch, and by building and deploying from the tags. The tag format is sit-v*-<commit> for nonprod and prd-v*-<commit> for the production release. These tags are manually built on jenkins after the change request has been approved. The release branch is merged to the stable master branch after the successful production deployment.
Backout¶
To back out we will build off the last release in the master branch and redeploy an old tag version, this shall take around 5 minutes. This will minimise the data loss in case a problem is discovered.
