Splatforms and Tasks

Posted on June 25, 2010
Filed Under Splatforms | 8 Comments | Share this post via splatforms.com

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:

  1. Fetch a login page
  2. Submit the user’s user id and password via the login page
  3. Fetch an input form
  4. 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.

Comments

8 Responses to “Splatforms and Tasks”

  1. Anatomy of a Splatforms Task : Splatforms on December 2nd, 2010 12:39 pm

    […] with it. That “stuff” that is done using that data gets done by running Tasks. While the underlying infrastructure is the heart and soul of the splatforms.com operation, it is […]

  2. Auto submit to over 100 sites for free : Splatforms on December 7th, 2010 6:57 am

    […] of the site and call it production-ready, we have been spending quite a bit of time building Tasks lately, and we now have over 100 Tasks in the portfolio for the Link *form alone. When you couple […]

  3. More Fun with Velocimacros : Splatforms on May 23rd, 2011 12:26 pm

    […] features of Velocity is the ability to create reusable functions known as Velocimacros. The Splatforms Task specification provides a section in the Task definition where Task Developers can include any […]

  4. So many ways to fill out a *form : Splatforms on June 11th, 2011 6:08 am

    […] we discuss the wonders of *forms, we are usually focused on the back-end — the hundreds of Tasks available to deliver your *form data to a plethora of target destinations. But equally impressive […]

  5. Version 1.1.6 of the *forms Local Agent Released : Splatforms on June 11th, 2011 9:31 pm

    […] is not a bug fix release; it just provides enhanced exception reporting for those instances when a Task step fails to complete successfully. While the additional information provided in this new release […]

  6. When Your *form Task Fails : Splatforms on July 28th, 2011 12:39 pm

    […] much as we’d love to tell you that every single Task for every single Target Web Site always succeeds for every single user, the reality is that this is […]

  7. Build Your Own *form Task : Splatforms on August 27th, 2011 5:05 pm

    […] 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 […]

  8. Build Your Own *form Task, part 2 : Splatforms on September 2nd, 2011 8:37 pm

    […] conceptual, and theoretical prerequisite stuff out of the way, let’s look at some real Tasks and see if we can’t actually make something out of something else. One of the simplest ways […]