There are two schools of thought on what a person needs to know before attempting to create or modify a *form Task. One theory maintains that a *form Task Developer needs to understand the HTTP protocol, the request/response cycle upon which all web traffic is based, the inner workings of the Splatforms.com infrastructure, including the role of the *forms Local Agent, the Velocity scripting language, XML syntax, and the intimate details of the operation of the specific target site for which the Task is intended. The opposing opinion is that, while having a deep and thorough understanding of all of these subjects may certainly have its potential benefits, all that you really need to know in order create a Task of your own is a working sample Task that you can carefully tweak here and there to get the results that you are looking for.
The truth is probably somewhere in the middle of those two extremes, but the bottom line is that you definitely do not need to be an expert, a programmer, or a software engineer to make a copy of an existing Task and tinker with it to try to make it do something slightly different. It is helpful to understand at least a little bit of what you are doing and why you are doing it, though, so we are going to try to hit the high points without getting too mired in the intimate details.
Ultimately,*form Tasks are instructions for the *forms Local Agent. The *forms Local Agent resides on the user’s computer and plays the role of the user when interacting with the target web site. From the perspective of the target web site, they can see web traffic coming from the user’s PC authenticated using the user’s username and password as if the user were sitting there typing away at the keyboard. What actually happens during this process is that the *forms Local Agent will receive some directive from Splatforms.com, it will carry out that directive by making an HTTP call of some kind to the target web site, and it will then take the target web site’s response to that call and send it back to Splatforms.com for evaluation. Based on that evaluation, Splatforms.com will then send another directive to the *forms Local Agent, and the process repeats. All of this is done without the need for the user to be there sitting at the keyboard, freeing them up to pursue other activities.
The directives sent to the *forms Local Agent come from the steps within a *form Task. The evaluation of the target web site’s response is performed on Splatforms.com using the evaluation criteria defined for that step. A *form Task, then, is the collection of steps and subsequent evaluation criteria necessary to walk the *forms Local Agent through the process of performing a specific set of interactions with the target web site. It doesn’t really matter if you understand exactly how all of these things work together to make this happen, but you do need to know the general flow of information between the *forms Local Agent, the target web site, and Splatforms.com, as well as the role that the steps and evaluation criteria within the Task play in orchestrating the entire process.
With that little bit of knowledge, you should be able to start looking at existing Tasks to see how they are built and begin to understand how they work. From there, it’s not too great of step into making your own copy of a Task and starting to play around with it to see what you can do differently.
Next time, we’ll grab some existing Tasks and see if we can make some simple modifications to make them do different things. In the meantime, if you have ever processed any Tasks of your own, you can sign on to your Splatforms.com account and go to the processed tab and drill down into the results and actually see the results of each step processed, which will also give you a better idea of how all these things work together to get to that desired end result.