AutoStore: Why Multiple Tasks Are Needed

Our neighborhood market, the big-mega outlets, airport security screening, the DMV, and the interstate freeway system in most major metropolitan areas during rush hour traffic all have one thing in common: there are never enough open lanes.

To the endeavor of order and process, when the volume of activity is not accounted for, regulating the forward flow to a single line creates what we call in the industry as a bottleneck. Stalled movement feels like being tied up in a straight jacket.

One way to think about an AutoStore task how a printer prints. After the print command is launched, bits and bytes received by the printer trigger a series of events. Paper is pulled from the tray, the information is applied to the paper, and the final product is placed on the exit tray.

Before any print job is completed, the printer is in a busy state, and can't be used. Any other jobs that need to be printed are waiting in a queue, and begin after the printer has finished printing the job which preceded it.

A single task created in AutoStore works much like our printer analogy. In single-line fashion, the task must complete the present job before it can take on the next job waiting to be processed. If the task includes processor intensive duties such as OCR, it means that pending jobs must wait.

One of the many reasons to split the effort/work into different tasks in AutoStore is for the very issue described. Each task operates independent of each other, versus the linear task needing to finish the work before consuming the next job in the queue.

For some CFG files, I create a task for capture, and another for various processes. The job gets passed from the capture task into the process/route task using the Knowledge Package Builder (capture task) and the Knowledge Package Loader (process/route task) receiving the job.

Separate capture tasks for multiple capture sources could conceivably now feed separate process tasks, and even separate route tasks, so that a common configuration is administered for each form within the task.

For example, a Xerox, HP, and Kyocera capture task each have 10 forms. If there is OCR needed for each form, then OCR would need to be configured 30 times. A single OCR process task means it would be configured once inside a separate task.

In closing, a single task is fine for a single capture source with relatively low volume. By using multiple tasks, it is possible to scale an AutoStore configuration to handle larger processing by adding more lanes to the workflow.

Cheers!


Comments

Post a Comment

Popular posts from this blog

VBScript: Ensure Backslash Folder Path

Image
To preface what could be regarded as a very small thing, I am reminded of a common turn of phrase concerning the amount of perspiration that should be afforded to the "stuff" belonging to a particular size-category, and pretty sure there was a book written about that topic. Not to come across as disagreeable, but rather to invite a little balance based on my own general observations over time, an increase in cost with things such as time, money, even relationships, can be avoided when the "small stuff" is given the regard that it deserves. One of these tiny details has to do with string variables that reference folder paths within a script. There are times when it is important that a defined directory for a particular folder should and must always end with a backslash. As an example: folderPath = "C:\Example"   Of course, it really is not very difficult to manually enter that backslash into the path. folderPath = "C:\Example\" ...
Read more

AutoStore: Workflow Loop Example

Image
Regardless of the programming language, a looping-statement is a common declaration for iterating through collections of things, such as the items of an array, records selected from a database, elements within an XML file, or the files inside a directory. A recent AutoStore challenge was presented where a script was used to fetch data in a process that returned either one or many items. This was the easy part. However, each return record needed to be specific to an individual Route based on one of those items returned. Example Example1@email.com Example1/URL Example2@email.com Example2/URL Example3@email.com Example3/URL Although the captured document being processed would be common for all in the return, the recipient belonging to one of these unique records should not be aware of  nor  receive any of the information that would belong to a different recipient. Because an unknown number of return records would be expected, this presents a challenge due ...
Read more

AutoStore: Create a Custom RRT

Image
Have you ever needed to dynamically create a custom RRT for an AutoStore process? In my previous post AutoCapture Default Date , I described my very first AutoStore script where the value of an  Invoice Date  field in an AutoCapture Vendor Invoices  form was assigned a default value of the day prior from the current date. This Invoice Date  needs to be part of the file name, however its format contains slash (/) characters that cannot be part of the file name. So, we'll use the AutoStore VB/JScript process component to create a new RRT that's more friendly. To do so, we'll look at how to do the following: Bring the existing Invoice Date  value into the script Reformat the Invoice Date  to a Windows-friendly file name Output the reformatted Invoice Date to a new custom RRT After adding the VB/JScript process component in between the capture component and the Send to Folder route component of the configuration file, we open the AutoCap...
Read more