AutoStore: RRT Anatomy
One of the many great things that make AutoStore so powerful is the Runtime Replacement Tag, better-known by its more familiar acronym as the RRT. These placeholders of information positioned inside the desired location of an AutoStore workflow configuration provide solution designers with the ability to simplify front-end business processes by connecting variable source values to create both well-structured and dynamic routes.
Adding RRTs to a configuration is quick and simple. For a given component's configuration properties, set the mouse cursor, and from the list of available RRTs, drag-and-drop the desired RRT.
For example, an RRT could variably define the email address that the Send to Mail Recipient should send the message to, or perhaps define all or part of a UNC path for the Send to Folder component to write the file over to.
Most of the components in AutoStore have an RRT that show up in the list of available RRTs, as well as a description in its Help file. By most, that means that not every AutoStore component has an RRT. With that said, every RRT's makeup has a basic anatomy. Here's an example of an RRT for a field with "CompanyName" assigned as the name for the WebCapture Component:
~WCC::%CompanyName%~
Let's take look at each part:
Because of obvious differences in the components, the available RRTs from one AutoStore component to another do vary. Also, various multi-function device (MFD) manufacturers may expose different information, and routing details for one component are just not relevant with each other, such as Folder routing and Email routing. Also, there are different types of RRTs available.
Many basic configurations use a single task to define the workflow, and the drag-and-drop method of incorporating RRTs is usually quite sufficient. There are cases where an RRT needs to be typed in. One case would be when the Knowledge Package Builder and Knowledge Package Loader are used, and another is when using the VB/JScript process component to create an RRT.
Some components have RRTs that contain additional parameters, such as Barcode, which is one of the more commonly used components. For example, the Barcode component has an RRT for a Specific Barcode, where one parameter is for the page number, and another for the specific barcode on the page when there is more than one barcode on the page.
~LTB::PageNumber,BarcodePosition~
In a job where there are two pages and two barcodes on both pages, if we want the 2nd barcode value on the 1st page, then we could use the following RRT:
~LTB::1,2~
The OCR component also has an RRT where more than one parameter is available. When setting up a OCR zone, the name of the zone and the page number are specified in order to obtain that value.
~FRO::%ZoneName%,PageNumber~
Using the Knowledge Package Builder/Loader allows for values to be passed from one AutoStore task over to another by packaging up the workflow data. The Fields in the Builder essentially build new fields for consumption by the Loader in another task. The Help file for the Knowledge Package Builder/Loader references its RRT identifier as "ASX".
Creating an RRT with a script using the VB/JScript component is usually done so where the RRT identifier of "USR" is established. As long as the references are the same in both the script and also at the point where the RRT value is consumed, using "USR" is not mandatory, however it is common to do so as a best practice because "USR" is safe by avoiding a conflict with other components.
Caution must be taken when typing out RRTs, as there are some rules which must be followed.
Possessing the basics to RRTs is one of the keys to understanding how to handle the metadata within an AutoStore configuration.
Adding RRTs to a configuration is quick and simple. For a given component's configuration properties, set the mouse cursor, and from the list of available RRTs, drag-and-drop the desired RRT.
For example, an RRT could variably define the email address that the Send to Mail Recipient should send the message to, or perhaps define all or part of a UNC path for the Send to Folder component to write the file over to.
Most of the components in AutoStore have an RRT that show up in the list of available RRTs, as well as a description in its Help file. By most, that means that not every AutoStore component has an RRT. With that said, every RRT's makeup has a basic anatomy. Here's an example of an RRT for a field with "CompanyName" assigned as the name for the WebCapture Component:
~WCC::%CompanyName%~
Let's take look at each part:
- The start and end tildes (~) mark the RRT enclosure
- After the start tilde is the component's unique 3-letter RRT identifier
- The two colons (::) separate the identifier and the tag name
- Before the last tilde is the actual replacement tag name
Because of obvious differences in the components, the available RRTs from one AutoStore component to another do vary. Also, various multi-function device (MFD) manufacturers may expose different information, and routing details for one component are just not relevant with each other, such as Folder routing and Email routing. Also, there are different types of RRTs available.
- FRTN (Field Replacement Tag Name) - Created by the configuration builder, and the tag name is between percent marks. These are commonly form fields created for user input, such as the Fields tab of a capture component, but also include fields from the Knowledge Package Builder. When defined, the field tag name is wrapped in percent (%) characters.
- RRTN (Reserved Replacement Tag Name) - These are unique to the component. Examples include available device information from an MFD component such as the IP Address, or the File Counter from the Send to Folder component.
- SSRTN (Special Set Replacement Tag Name) - Hold information about the job, and are typically date and time RRTs, such as the Year, Month, Day, Hour, Minute, and Seconds.
Many basic configurations use a single task to define the workflow, and the drag-and-drop method of incorporating RRTs is usually quite sufficient. There are cases where an RRT needs to be typed in. One case would be when the Knowledge Package Builder and Knowledge Package Loader are used, and another is when using the VB/JScript process component to create an RRT.
Some components have RRTs that contain additional parameters, such as Barcode, which is one of the more commonly used components. For example, the Barcode component has an RRT for a Specific Barcode, where one parameter is for the page number, and another for the specific barcode on the page when there is more than one barcode on the page.
~LTB::PageNumber,BarcodePosition~
In a job where there are two pages and two barcodes on both pages, if we want the 2nd barcode value on the 1st page, then we could use the following RRT:
~LTB::1,2~
The OCR component also has an RRT where more than one parameter is available. When setting up a OCR zone, the name of the zone and the page number are specified in order to obtain that value.
~FRO::%ZoneName%,PageNumber~
Using the Knowledge Package Builder/Loader allows for values to be passed from one AutoStore task over to another by packaging up the workflow data. The Fields in the Builder essentially build new fields for consumption by the Loader in another task. The Help file for the Knowledge Package Builder/Loader references its RRT identifier as "ASX".
Creating an RRT with a script using the VB/JScript component is usually done so where the RRT identifier of "USR" is established. As long as the references are the same in both the script and also at the point where the RRT value is consumed, using "USR" is not mandatory, however it is common to do so as a best practice because "USR" is safe by avoiding a conflict with other components.
Caution must be taken when typing out RRTs, as there are some rules which must be followed.
- An RRT is definitely, absolutely, positively, completely, totally, and 100% case sensitive.
- The RRT identifier is unique to the component. The Send to Folder component does not know what to do with a Send to Mail RRT.
Possessing the basics to RRTs is one of the keys to understanding how to handle the metadata within an AutoStore configuration.
Comments
Post a Comment