third time’s the charm – ignore this experiment

Hello,

I am a robot hired by the Performance Management Team to tell you the story of Dynamic S.L.A. Order Exceptions Notifications.

,

You know the players:

Retailers, submit, cancel and return orders.

Suppliers, acknowledge, ship and invoice orders.

Dynamic S.L.A. enters the scene as soon as a retailer submits a new order into the system.

Retailers will have created Filter Rules in the portal.

,

S.L.A. Filter rules are created to persuade suppliers to respond, in a timely fashion, to the following:
acknowledge an order,
ship an order,
invoice an order,
respond to a request to cancel an order,
and respond to a request to return an order.

When suppliers fail to comply with these rules, order exceptions will incur.

,

Here we have a list of S.L.A. exceptions.

Both retailers and suppliers have access to the current list of open order exceptions.

Suppliers can opt-in to receive exception summaries in an email notification.

,

In the portal, Notifications, and Performance page,

Suppliers can opt out or in, and select the days and time of delivery.

These notification preferences are saved in a Dynamo D.B. table.

Let’s now switch to view the server processing.

,

Here is the user configuration dynamo D.B. table.

It contains records that look like this.

Notice the frequency string, this is a cron string indicating when the supplier representative has requested to receive order exceptions notifications.

Let’s view the whole process.

,

This diagram,

shows that, as we’ve mentioned, individual users for a supplier can save their own notification configurations.

This cron lambda will periodically scan the Dynamo D.B. table for S.L.A. participating suppliers scheduled to receive notifications.

Requests are enqueued in S.Q.S.

This queue consuming lambda will receive the notification requests:
perform Elastic Search queries,
format the query results and,
delivery the request payloads into the R Streams notification pipeline.

,

Here,

R Streams then transitions requests,
finally arriving at the notification queue.

Then, the payloads are transformed through HTML templates,
using handlebars J.S.
converting them into formatted emails ready for delivery.

,

Amazon Simple Email Service will delivery the emails,
handling bounces, rejections and suppressed addresses.

,

The final product arrives in a supplier representative’s inbox,

If a supplier is associated with multiple retailers, this one email will contain partitioned summaries for all retailers.

,

For visibility,
the server side process is monitored within Data Dog,
with logs and metrics being delivered for analysis and alerting.

,

That’s the process.

Thanks for watching.