CASE STUDY : Retail SuperMarket UseCases over Self Service Catalogue

​In this Blog , we are looking at a Retail Outlet who provide home delivery of Orders by segregating Orders into Vans and segregating Vans into Waves where each Wave would comprise of Several Vans and each Van would comprise of several orders and how the Retail Outlet manages Order Cancellations , Van Closures etc on Stores front through Self Service Catalogue thereby avoiding direct interaction of Store Personnel with the Background DBs or the underlying APIs exposed by the Application.

Problem Statement:

The Retail Outlet is needing to present an Abstracted interface for the Store personnel with respect to Order Cancellations in the event of a Power Outage , Internet Outage etc.
Likewise when there is a problem on the Application Side with respect to “Closing the VAN” process to ship Orders out , there is a need to look at why the “VAN Closure process” did not go through which could be due to a variety of reasons like “a Barcode on an Item not scanned” to “all Items Scanned , but Final Sign off not done on the Portal, post Pick” or “Pick not completed on the Order”.

Solution:
Using HCL Workload Automation Self Service Catalogue capabilities , we would look at how we can implement the below UseCases one by one :
 

1. Order Cancellation by WAVEID
2. Order Cancellation by ORDERID
3. Order Cancellation by VANNO
4. VAN Closure issues

 
Order Cancellation by WAVEID:
In order to cancel orders based on WAVEID , a Self Service Catalogue would be presented to the Store personal which would comprise of the below interface on his Hand Held Device like a Tablet:

The Store Personnel would go ahead and select “Cancel By WaveID” , this would then trigger a Workflow in HWA similar to the below one :

The Store Personnel goes ahead and enters a WAVEID which he wishes to cancel and hits Submit which could be due to a  “Power Outage” or “Internet Outage” .
​
This presents an Status Interface like below for the Store Personnel :

​This inturn triggers a JobstreamFlow in HWA in the background as below :

Job Descriptions :
​
CHECKWAVESTATUS Job : This would check WAVE Status ID from the DB Table for Waves and decide whether the WAVE ID returned as response to the query is “ACTIVE” or “NOT ACTIVE” , depending on the Value , Conditional Dependencies are defined to decide whether WAVE is “ACTIVE” or “NOT ACTIVE”.WaveID is passed as input from Self Service Catalogue to this job to be used within the Query.

So , in this case the Conditional Dependency is mapped to WAVESTATUSID being 3 as ACTIVE.
​
CHECKVANSTATUS_BY_WAVEID Job : This job does a query in the DB on the VAN table by passing WAVEID as an argument passed as a Variable from the Self Service Catalogue and queries to check on VAN Status , if the VAN is “Open” , then the VANSTATUS is returned as “0” , then the Conditional Dependency is set to TRUE. WaveID is passed as input from Self Service Catalogue to this job to be used within the Query.

A VAN Status of “2” is mapped to “CLOSED” in this case .
 
CANCELWAVEORDER Job : This job deletes all Orders from the Wave based on the Input WAVEID , again this is realized as a DB job in this case and the same is passed an input to the query .

CANCELVAN_WAVEID Job : This job deletes a VAN from VAN Table based on the Input WAVEID passed to the job . This is again realized as a DB job (ofcourse the API of the Application if used can also be used to realize the job as a RESTFUL job or WebServices Job or Java Job depending on the API exposed).

Order Cancellation by ORDERID :
 
In order to cancel orders based on ORDERID , a Self Service Catalogue would be presented to the Store personal which would comprise of the below interface on his Hand Held Device like a Tablet :

​The Store Personnel would go ahead and select “Cancel By OrderID” , this would then trigger a Workflow in HWA similar to the below one :

The Store Personnel goes ahead and enters a ORDERNUMBER which he wishes to cancel and hits Submit which could be due to a  “Customer reason” or similar.
​
This presents an Status Interface like below for the Store Personnel :

This inturn triggers a JobstreamFlow in HWA in the background as below :

Job Descriptions :

FETCHVANNO Job :  This is a DB job of type SQL which would fetch the VANNO from the VAN Table taking input ORDERNUMBER from Self Service Catalogue in the form of a HWA Parameter.

FETCHWAVEID Job : This is a DB job of Type SQL which would fetch the WAVEID from the WAVE table taking input ORDERNUMBER from the Self Service Catalogue in the form of a HWA Parameter.

EXTRACTVANNO and EXTRACTWAVEID jobs : These jobs would fetch VANNO and WAVEID from the output from previous jobs using Unix commands by parsing output.

STORE_VANNO and STORE_WAVEID jobs : These jobs would store the VANNO and WAVEID as HWA Variables using output of previous as inputs and using parms utility.
​
CHECKWAVESTATUS job : This job would check on the Wave Status through a query taking WAVEID as input , a WaveStatusID of 3 indicates Wave is active.

​CHECKVANSTATUS Job :  This job would check the VAN Status and find out if the VAN is Open , if the VAN is Open , Van Status of 0 is mapped to “OPEN” and Van Status of 2 is mapped to “CLOSED”.

CANCELORDER job : This job is a DB job that would cancel the Order as per input of ORDERID passed as input from Self Service Catalogue.
 
Order Cancellation by VANNO :
 
From Self Service Catalogue , The Store Personnel would go ahead and select “Cancel By VANNO” , this would then trigger a Workflow in HWA similar to the below one :

The Store Personnel goes ahead and enters a VANNO which he wishes to cancel and hits Submit which could be due to a  “Power Outage” or “Internet Outage” or similar.

This presents an Status Interface like below for the Store Personnel :

As you can see from the Above Output , the Cancellation could not proceed ahead in this case , lets analyze the Flow that triggered in the background this time :

In this case there are primarily 3 jobs :
​
CHECKVANSTATUS Job : This job gets the VAN Status depending on the input “VANNO” passed, if Van Status returned is 0 then VAN is open , if VAN Status is 2 , then VAN is closed , in this the query from VAN table returned 2 indicating VAN was closed , so this triggered the negative Case that is the VAN could not be cancelled as it is not Closed .
 
This would trigger an Event Rule within HWA and notify on a Teams Channel to Store Personnel as below on their Hand Held Device :

CANCELVAN Job : This job would remove the VAN Entry from VAN table as a normal DB job.
​
CANCELVANORDER Job: This job would remove the Order entry from VAN table using the input VAN NO.
 
VAN Closure issues:
 
VAN Closure option presented in the Self Service Catalogue would be used to trigger this option :

Once the VANNO is entered as 7 , this inturn would trigger a Jobstream Flow in the Background as follows :

Job Descriptions :
 
QUERYVAN job : This job would run to query the VAN Table to fetch the Total Items in the VAN overall , the Total Items Picked, the Total Pending Items , The Total Items allocated.

EXTRACT_LP_DETAILS Job :  This job would assign values of the Total Items Picked, the Total Pending Items , The Total Items allocated etc. from previous job and assign them to HWA Variables through parms utility.
​
LP_PENDING_CHK :  This job would checking the pending Items to be picked concerning an order and exactly highlight which Items are pending to be picked up.
 
LP_ALLOCATED_CHK : This job would check if Allocation is done for all items , if not this would trigger a message on Teams indicating the Item that is not Scanned.
 
Teams Notification for BarCode Scan pending items :

 
As you can see from above message BarCode Scanning is pending on Order Numbers : a1480269981,a1480269982,a1480269983 which prevented the VAN from getting Closed.
 
This Teams message would be posted on the Hand Held Device of Store Personnel directly through an Event Rule through a Webhook.
 
 Conclusion :
 
Using Self Service Catalogue Feature of HWA , we can create an Abstract Interface for all Store Personnel in the Retail Outlet to Automate Sensitive Operations in the background without exposing them to the background interface of the Orchestrator while achieving the below :
 

1. Prevent enormous amounts of manual work and co-ordination and ticketing on regular requests to Help Desk and Application Teams.
2. Increased Efficiency in terms of FTE and time savings for the Store , Application Teams.
3. Simplified and Abstracted interface to prevent Store Personnel from interfacing with the Application directly.

---

Author's Bio

Sriram. V - Technical Advisor HCL Workload Automation

I have been working with Workload Automation for the last 14 years donning many hats as Scheduler , Administrator , SME , India SME of the Product in IBM for many years supporting 30-40 Customers of the Product directly , joined the Product Team in HCL in 2017 with a stint with the SaaS DevOps Team hosting the SaaS Offering of Workload Automation supporting 70+ Customers on SaaS before joining the Tech Advisors & Lab Services Team in late 2019 and have been working closely with Sales in selling our Product and also on Post Sales Migration from Competition , Post Sales Implementation and Cloud Transformation of existing On-Prem Customer Base