Before a *forms user ever fills out their first *form, they need to go into the Preferences tab on the site to identify the default Tasks that they would like invoke for each type of *form. Each *forms Task is a complete set of instructions for accomplishing one goal using the data that is entered on the specific type of *form with which the Task is associated. Tasks are associated with a specific *form Type (Text, Link, Article, Event, or Contact), a specific target site, and optionally, a second site from which your credentials are drawn, it the Task involves logging you on to one site using credentials from another.
Once a user establishes their default preferences, their selected Tasks will automatically be associated with every *form of that type that he or she completes. Clicking on the Tasks button on the *form entry page will pull up a list of the user’s default Tasks, and specific Tasks can be deselected for this specific instance by unchecking the box in front of Task name.
When the user submits the *form, the select Tasks are first queued up for processing by the user’s *forms Local Agent. These pending Tasks can be reviewed using the Pending tab on the Splatforms.com web site for as long as they are in pending status. Once the instructions have been picked up by the Local Agent and carried out, the results will be available in the Processed tab.
Internally, a Task is composed of one or more Steps, and each Step is made up of two parts: 1) what to do, and 2) what to do with the response once you’ve done it. The “what to do” portion of the Step is simply a URL, an HTTP method, and some other optional parameters. The “what to do with the response” portion is series of one or more inspection operations that either look at the response returned by the target site or extract information from the response returned by the target site. Task developers create the Tasks by specifying what steps to take, in what order, and set down the rules for evaluating the responses returned by the target site for every action taken by a Step within the Task.
Tasks generally fall into two distinct categories: 1) API Tasks, which are usually a single step following some API specification published by the target site, and 2) User Emulation Tasks, wherein the individual Steps of the Task represent the activities that a human user would take in interacting with the target site via their web browser. User Emulation Tasks are usually multi-Step Tasks, and typically would contain some version of the following sequence of Steps:
- Fetch a login page
- Submit the user’s user id and password via the login page
- Fetch an input form
- Submit the *form data via the input form
Each step would include the two part process of 1) carrying out the Step and 2) evaluating the target sites response. For example, in the first Step listed above, the instructions might be to first issue an HTTP GET request to the URL of the site’s login page, and once that was carried out, the HTTP Response Code and response text would be inspected to ensure that a login page was actually received before moving on to Step #2.
Of course, it is not necessary for a *forms user to understand any of the internals of how all of this works. They simply need to know what Tasks they would like to have performed on their data so that they can set up their preferences and start entering data into *forms. But it does help to have some level of understanding of the process when you are looking at the results in the Processed tab, particularly when you click on the Outcome and start looking at the processing details.