How an Automated Task Runs

This article contains the following topics:
This article contains the following topics:
CA SDM provides a framework which is a block of script code responsible for the code that deals with presenting user interfaces and retrieving user input from user interface steps. The framework exists so that you can do complex things with automated tasks, interface-related, using simple code, rather than complex code that would otherwise be necessary. The framework includes two objects (Task and Step). You can use these objects to interact with the framework and control how automated tasks execute, including setting up and accessing the user interface.
: When running an automated task in the Automated Task Editor, the editor acts as both server and client.
The following process describes what happens when you execute an automated task:
  1. Use the framework to assemble the script code to execute together with the step code in the automated task definition, and any dependent library code.
  2. The server assembles and distributes the code to the end-user environments.
  3. Both the end user and the analyst receive the entire assembled automated task.
  4. The server initiates each step in turn at the relevant client.
How Analysts Receive Data
You can have an automated task gather data and store it in the Support Automation database associated to the specific task execution. The data can be picked up by a post session integration that can use the data or pass it to an external system. In such a case, typically you construct this data as an XML fragment.
Use Functions.SetAcquiredData() to store data (text), associated with a task execution. Support Automation allows one such text field of any length to be stored for each execution of an automated task. You can store data in one step and access it in a subsequent step as follows:
  1. The server sends the initial state of this data storage to the client with the instruction to execute a step.
  2. At the end of the step, the client sends the persisted data state back to the server so the server can send this data to whichever client is executing the next step.
  3. An analyst user interface step can gather input from the analyst and store it.
  4. The end-user user interface step can access the data that was supplied by the analyst.