Resource Access Doc

The Resource Access Doc (RAD) sets up the communication information between the worker server and the actual device. The RAD is one of the most important data structures needed for device interaction. The RAD controls the device connection for IDT and UOWs. ITNCM - Base locates just one RAD when setting up the communication.

The RAD can control every aspect of device interaction, including the connection protocol, timeouts, various workflow elements and scripting.

RADs are created to manage devices at various VTMOS levels. Typically, RADs are built to handle all the devices in an implementation and they will be placed in the base realm for use. All devices that match the VTMOS criteria of the RAD will use it.

ITNCM - Base performs the following tasks when setting up communication for a device:

  1. Checks first to see if a custom RAD has been set on the device. A user views a custom RAD by right clicking on a device, and then proceeding to the Properties | Access Tab.
  2. If no custom RAD is located, ITNCM - Base checks the realm that the device is in currently to see if a RAD is available for that device.
  3. ITNCM - Base then checks all realms, moving upwards in the hierarchical structure until it reaches the top realm.
  4. If there is still no match, ITNCM - Base accesses the vendor tree from the database and gets the default RAD for this vendor type.

ITNCM - Base will either match the VTMOS information of the device with the one specified when creating a new RAD, or it will just match Vendor and Type when using the default.

Note: If a RAD GR is created, and custom changes are made, the RAD GUI on the actual device will reflect the changes made.

Every device has a RAD, even it is uses the default RAD that is part of its driver.

A RAD consists of four sections: access order, rollback, access types, and scripts.

  1. The access-order describes the order in which the drivers will process the access-types.
  2. The access-types set up the communications. The access-type describes the protocol used, and the flag settings. It also contains the script id which indicates if the default or a custom script is being used.
  3. The rollback options indicates the type of roll back supported for the device type. This refers to the ability to restore a devices configuration, if an error was received when changing the configuration.
  4. The scripts can be used to customise a device script.