An interesting question came up on the ListServ this week — a user was wondering if a task could be created with the option that data sorted in the task was variable. An example user-case might be something like, a task where the replace all function may be variable depending which vendor file might be processed.
By default, the Task Automation tool has been designed to be pretty much like a macro recorder. You set values, it simply uses those values. However, at it’s core, the task automation tool is just a script engine — the tasks represent a simple set of commands that get interpreted by the automation engine. Given that, it would be pretty easy to provide the ability to support user defined values within a task. So, I’m giving it a go. I’ve defined a special mnemonic — {inputbox_[yourvalue]} which can be defined within a task — and when encountered, the task engine will prompt the user for data.
The important part of the mnemonic — the part the tells the engine that user data is required, is the first part of the mnemonic: {inputbox_. When this statement is seen, the engine pauses and passes the command to the pre-processor. The pre-processor looks at the start of the mnemonic, and then pulls the data after the {inputbox_ to give the user a prompt regarding the data that is being requested.
For example, say the user is creating a Replace All task and the program should request data for both the Find and the Replace strings. The mnemonic should look like the following for the Find expression: {inputbox_Find} and for the replace: {inputbox_Replace}.
When run, the pre-parser, when coming across these values, will break them down and prompt the user for input:
The pre-parser will then substitute the user provided values into the task and process the data accordingly. If the user cancels the dialog — the pre-parser will take that as an indication that this process should be skipped, and will move on to the next operation in the task.
This change will be part of the next update.
–tr
Comments
7 responses to “Task Automation Modifications”
Brilliant! How tight are the syntactical rules for [yourvalue]?
The syntax rules are simple, but set. Here’s the rules:
1) {inputbox_ — this value is case-sensitive; this must show up as is or it won’t be processed.
2) [yourvalue] — these can be any value except for a space. So:
** {inputbox_Find} is valid
** {inputbox_Find_What} is valid
** {inputbox_Find What} is not valid
** {InputBox_Find} is not valid
–tr
Just tested it out. Wow, is that ever handy. Thank you!
Glad that this looks like it will be useful.
–tr
Actually, it looks a bit game-changing to me, but maybe that’s just because I’m new at my job. Enthusiasm follows (and I hope this is the right place to continue the conversation — please tell me if it’s not). Anyway:
Following up on this new functionality, it occurs to me that I now have the ability to radically change my workflow.
Given:
Consortium-type environment
Files whose records are
a) sent from specific member libraries,
b) and which contain just one format
c) and perhaps even just one sort of content…
{…for example: a .mrc with only c) audiobooks on b) compact discs from a) branch #1…}
and which
d) need treatments which correspond to the type of records represented by a given file.
Implement:
By manually editing both the taskfile names and the _tasks.txt file, I can:
1) create prompted TASK calls, which
2) can be chained together to represent a decision tree, which
3) essentially creates a UI for selecting the type of file you have, and thus
4) allows the cataloguer to run a task set tailored to the situation by simply following the prompts.
5) N.B.: for ease of editing/troubleshooting, the file hierarchy of individual taskfiles will be arranged to reflect the decision tree.
It looks like the filenames generated by the Manage Task interface are just timestamps, right? Is there any functional information in them that I’d be wiping out if I renamed/remapped? Is it greedy for me to ask whether path editing could be switched on in the Task Manager interface (convenient, but as far as I can tell not required)?
Thanks again!
mf
oops. sorry about the tagging errors!
You are correct — the task names are time stamps. This is mostly done to make sure that tasks names are unique — especially if users are utilizing a networked folder for tasks with more than one user generating tasks at a time. While there is a chance of collision, I use a pretty granular time stamp so it’s pretty unlikely. So no, there isn’t any particular information that would be lost if you wanted to rename your individual tasks. As long as the _tasks.txt file has the various known tasks in the file so that the tool can find them — all the various task functionality should work just fine.
-tr