Script Library Management

This article contains the following topics:
casm172
This article contains the following topics:
 
 
You can use the same script functionality that gathers specific data or impacts certain changes on a remote machine in many various automated tasks. Support Automation provides the concept of script library to package such reusable code. You use script libraries to help you reuse and maintain code. These libraries contain functions written in JavaScript or VBScript that automated tasks can call. The automatic code completion feature of the Automated Task Editor provides a function description text and argument descriptions when you edit automated task step script code.
You can create your own libraries. The Automated Task Editor displays defined JavaScript and VBScript libraries on the left pane. Script libraries let you do the following:
  • Create libraries and functions
  • Provide descriptions of the Function arguments
  • Export and Import from XSDF files or directly from the Support Automation server
  • Define the function name, description, arguments, and script text
Return Objects from Library Functions
You can return an instance of an object from a library function, such as for library functions that manufacture HTML Components. Returning an object requires you to declare a class and instantiate an instance of that class. Class declarations are done differently in JavaScript and VBScript.
In JavaScript, you define classes by declaring a function that is actually the constructor for the class. Public properties and methods are added to the class using the
this
keyword. You declare private properties by using the
var
keyword. In JavaScript, you can declare a class inside a function definition.
In VBScript, class definitions are not permitted inside functions, however, you can provide the code that forms the implementation of a given function. You create class definitions using one of the following techniques:
  • Constructing the class definition code in a string and executing it with
    ExecuteGlobal
    .
  • Calling a second function and returning whatever it returns. End the function. Declare the class, then the second function.
Local File System/Registry Access
Many automated tasks require reading or modifying the file system or registry. The Windows Script Host (WSH) provides some scriptable COM components (such as FileSystemObject) to enable scripts to read or modify the file system or registry. Some antivirus programs implement script blocker utilities that interfere with those COM components, often flagging any script that tries to instantiate the relevant component as being malicious. Clearly, it is not desirable to have script blockers interfere with the activities of analysts who are trusted and trying to repair a problem. The CA SDM functions library contains functions for interacting with the file system and registry that enable much the same functionality that the Windows components expose, without being subject to the action of script blocker programs.
The standard WSH components are used when you write automated tasks for an internal corporate environment where the end-user computer state is known, and assumed that script blockers are not present. You can use the functionality in the CA SDM Functions COM component to implement any file system or registry activity for external environments (customers at home or on the public Internet) when the organization that is providing support does not control the end-user computer configuration.
Windows Management Instrumentation (WMI) Support
Automated tasks support Windows Management Instrumentation (WMI), a component of the Windows operating system that provides management information and control in an enterprise environment. By using industry standards, you can use WMI to query and set information about desktop systems, applications, networks, and other enterprise components.
WMI lets you access and modify the operating system. WMI is based upon SQL-style queries that allow an automated task to query information from the operating system and then, using objects, to manipulate that data. WMI is a powerful system and is often the preferred method for automated tasks to carry out their purposes.
Example: Script fragment that enumerates the currently configured Operating System Services.
strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colRunningServices = objWMIService.ExecQuery("Select * from Win32_Service") For Each objService in colRunningServices Wscript.Echo objService.DisplayName & VbTab & objService.State Next
Static Content Management
Automated tasks can present a user interface that requires you to use images or CSS files to appear correctly. This static content (images and CSS files) is associated with the automated task definition as the task is dependent on them. You can do the following:
  • Import static content and associate it to automated tasks.
  • Add, edit, delete, and upload to the Support Automation server.
  • Select an image or text file to import and assign a globally unique identifier (GUID).
  • Use the Automated Task Editor to assign static content items to automated tasks.
When you assign the static content item, you associate the automated task and it is saved in the XSDF with the task. The static content automatically deploys to the server when the dependent automated task deploys.
Static content is stored in the Support Automation database on the server. A servlet provides access to these images based on their ID. The Functions library call
Functions.GetStaticContentItemRef()
returns the URL to that servlet, which takes the ID as a parameter. The Automated Task Editor provides a toolbar button that brings up the Static Content Items dialog, which allows you to select the desired item. When you click OK, the
Functions.GetStaticContentItemRef()
call is automatically inserted into the code with the relevant ID.
Status content has a limit of 50 KB per item.
Functions and WScript Usage
The framework provides two scriptable COM components that are accessible to all automated tasks running in CA SDM. These COM components are Functions and WScript.
Functions
The functions component is a collection of procedure calls that are used for the following:
  • Accessing the local file system and or registry without triggering antivirus script blocker programs
  • Accessing the Support Automation server functionality such as:
    • Writing session log entries
    • Storing automated task acquired data
    • Setting automated task execution state
    • Sending email
    • Escalating between products
    • Executing custom server routines