Design | Narvar OrderAPI Move

Objective
Architecture Solution
Assumptions
Micro Service Processing Logic
Error Processing
Republishing the invoice message
Narvar Environment Details

Objective
As part of retiring OSB we need to replace the OSB flow for Narvar Order API call to move from ATG to micro service layer. Micro service layer
will process queuing.OMS.ORDER_TRANSACTION Kafka topic messages which is published by OMS for each status event. Currently ATG is
calling Narvar Order API during invoice message and micro service will only process invoiced-Shipped event messages from Kafka topic.

Architecture Solution
Micro service solution flow is defined in below with various options and as part of architecture review option 2 is agreed upon solution flow.

Narvar OrderAPI to Micro Service | Integration Options to Create Order in Narvar

Assumptions
1. GIH service is available in lower environment during micro service development.
2. GIH service will deploy their chnages on or before order api micro service move to production.
3. CI/CD pipeline will be ready by the time development is done.
4. Narvar Order API lower environment service will be available and has same logic as prod environment.

Micro Service Processing Logic

Filter invoiced-Shipped event messages from queuing.OMS.ORDER_TRANSACTION Kafka topic to process. Below conditions will be
performed to ignore the message(s)
Ignore non invoiced-Shipped messages
Ignore non sales order
Ignore non NA enterprise order
Ignore RFO (refund fullfilment Orders) orders
Ignore social orders
For non invoiced-Shipped/ignored message add info splunk logger like below
| ORDER_API | RESPONSE=SUCCESS | OrderNo=JiffyATG39709 | EntryType=Online |
EnterpriseCode=LULULEMON_CA_ECOMM | Event=<non invoiced-shipped> | Topic=queuing.OMS.
ORDER_TRANSACTION | Partition=1 | Offset=1235465
For invalid avro schema message and push the message to DLQ and add error splunk log. Refer republishing invoice message after
avro schema issue is resolved.
Splunk error logger like below
| ORDER_API | RESPONSE=ERROR | REASON_CODE=OMSAPIERR001 | REASON=Consumed error message due
to KafkaAvroDeserializerError, pushed to DLQ topic | OrderNo=JiffyATG39709 | Partition=1 | Offset=1235465
Get the KMS keys for the encryption keys from the message and decrypt the PII data
Since KMS keys are generated once a day to gain performance improvement cache the KMS keys with in micro service.
Define a scheduler process to clean up the cached KMS keys older than X days where X days is defined in application properties.
Push the message to DLQ if decryption error occurs or exception happened while fetching KMS keys. Refer republishing invoice
message after KMS issue is resolved.
Translate the message format to Narvar Order API format, below link will provide mapping logic.
Narvar Order API Interface
For any exception happens during translation push the message to DLQ. Refer republishing invoice message after translation
issue is resolved.
For non guest order fetch the omni_id (OKTA ID) from the message and invoke GIH service to fetch RSA flag.
GIH service call is wrapped around with circuit breaker to handle reprocess able errors and for non reprocess able error below rule will
be followed.
For unsuccessful/errored GIH calls read the value from create order message and pass it.
For error processing refer handling error scenarios.
For guest orders (non registered customers) set RSA flag to true.
Invoke Narvar Order API using the translated message
wrap around narvar calls with circuit breaker so that messages can be retried for error scenarios.
 For error processing refer handling error scenarios.
Add below successful splunk logger and commit the message (acknowledge the message)
| ORDER_API | RESPONSE=SUCCESS | OrderNo=JiffyATG39709 | EntryType=Online |
EnterpriseCode=LULULEMON_CA_ECOMM | Event=<non invoiced-shipped> | Topic=queuing.OMS.ORDER_TRANSACTION |
Partition=1 | Offset=1235465 | TotalTimeMs=250 | KMSCallProcessingTimems=35 | DecryptionProcessingTimeMs=15 |
TransaltionTimeMs=15 | GIHInovkeTimeMs=60 | NarvarInovkeTimeMs=125 |
For errored messages don’t commit the message (acknowledge the message) and error splunk logger
| ORDER_API | RESPONSE=ERROR | REASON_CODE=<error code> | REASON=<reason for the error> |
OrderNo=JiffyATG39709 | Event=<non invoiced-shipped> | Partition=1 | Offset=1235465

Error Processing
When Narvar service is down or any internal server error is returned then these errors are considered as reprocess able, which means
kafka topic offset is not committed.
When exception happens while fetching KMS keys or decrypting the message then these errors are non reprocess able and hence will
be pushed the message to DLQ. Refer how to resend invoice message for reprocessing the DLQ messages.
When exception happens while converting the message to avro schema, message is pushed to DLQ. Refer how to resend invoice
message for reprocessing the DLQ messages.
While invoking GIH service if GIH service throws any exceptions based on the error code message is considered for reprocessing or
pushing the message to DLQ. Refer how to resend invoice message for reprocessing the DLQ messages.
While translation if any error occurs push the message to DLQ. Refer how to resend invoice message for reprocessing the DLQ
messages.

Republishing the invoice message

In OMS for any invoice need to re publish follow below steps
From the DLQ get the invoice no and update invoice status in OMS DB
UPDATE yfs_order_invoice set status='00' where invoice_no=<invoice no>;

Narvar Environment Details

QA - https://ws-st01.narvar.qa/api/v1/orders
Prod - ??