Administration Guide : More Details about Triggers and Actions : Files used in Actions

Files used in Actions
The files and executables used with Trigger Sets reside in a few places on the file system.
The actions directory
All files used to establish Trigger Sets reside in the actions directory.
On Unix systems:
/usr/etc/webnative/actions/name_of_action/
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action
All files for specific Actions reside in the subdirectories of the action directory.
Action executables
On Unix systems:
/usr/etc/webnative/actions/name_of_action/action_executable
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
action_executable.exe
or
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
action_executable.bat
The executable itself must have the same name as the Action directory. On Unix systems, there should be no extension. For Windows users, however, the Action must be named either name_of_action.exe or name_of_action.bat when the Action has been written as a batch script.
Action configuration files
On Unix systems:
/usr/etc/webnative/actions/name_of_action/name_of_action.conf
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.conf
This file is used by the Xinet Administration GUI to provide input about settings. As an example, let’s look at the copy Action configuration file provided with Xinet:
[setup]
stdargs=f
custargcount=2
[arg0]
label=Destination (must exist)
rows=1
cols=64
type=path
[arg1]
label=Overwrite/Append/Fail
option_count=3
option_value0=O
option_name0=Overwrite
option_value1=A
option_name1=Append Unique Number
option_value2=F
option_name2=Fail
The first section, [setup], describes how the Action will be called using standard arguments. The options include:
fid the file ID
kid the keyword ID
uid the user ID
f the full path to the file
p the HTML path
k the keyword that changed to initiate the action
u the user that set the keyword value
dat the current date
new the current (new) value
old the previous (old) value
typ the File Type
cre the File Creator
A .conf file may use any combination of these to run the Action, so long as they are comma-separated. For an example of this, look at the configuration file provided with the email Action.
The next option inside [setup] is the number of custom arguments that will be set in the configuration file itself. In this case, there are two custom arguments, arg0 and arg1.
The next section, [arg0], provides information about the first argument. The description, label, will appear in the Xinet GUI to the left of the argument. The next two options, rows and cols, specify that the argument input area is a text field and describe the size of the input area in the GUI. The final descriptor, type=path, tells Xinet to protect special characters in this text area because the characters must be used later as a file-system path. There are no other type indicators at this time, so it is only necessary to include this option when your Action requires user input of a file-system path.
Notice how the final section, [arg1], is slightly different than the description input for [arg0]. Though both use the label, what follows is very different. In this case, arg1 is selected by the user using a pull-down menu in the GUI. The option_count setting tells the GUI how many options will be in the pull-down menu. Each of the options has both a name and a value. The option_value will be the actual argument passed to the Action at time of execution. The option_name is the information the administrator will see in the Xinet GUI when creating settings for the Action. For example, if a user selects Append in the administration GUI, the Action will execute with -arg1 A.
One might optionally add a boolean option to the example shown on page 465. To do so, increase the custargcount=2 to custargcount=3 and, add to the end of the file, something like the following:
[arg2]
label=Digest
type=check box
which would add the following option to the flags in the xinet ADMINISTRATION view Adding a boolean option to an Action configuration file
Files used for Action GUI information
 
On Unix systems:
/usr/etc/webnative/actions/name_of_action/name_of_action.desc
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.desc
This file is used by the Xinet Administration GUI to provide instructions and helpful information at the top of the Action Settings screen. If this file does not exist, the section of the GUI marked Description will be blank.
The Action .buildconfig files
On Unix systems:
/usr/etc/webnative/actions/name_of_action/name_of_action.buildconfig
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.buildconfig.exe
or
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
name_of_action.buildconfig.bat
In some cases, the Action configuration file should reflect information that is unique to the specific server running Xinet. For example, the archive Action should show a list of schedules that is accurate for the current server, and allow the administrator to choose one. In these cases, Xinet uses the .buildconfig executable to automatically generate the name_of_action.conf file. The .buildconfig file may be written in any language that can be executed by the server, but it must generate a properly formatted .conf file to be useful. On Unix systems, see the archive.buildconfig file for one example of how this may be implemented. The .buildconfig file, if it exists, only executes when the settings window for the Action is viewed via the Xinet Administration GUI.
Administrative settings files
On Unix systems:
/usr/etc/webnative/actions/name_of_action/settings/name_of_setting
On Windows systems:
Program Files\Xinet\WebNative\Bin\actions\name_of_action\
settings\
name_of_setting
All settings created by the administrator are saved inside this setting directory. They should not be edited by hand; only in the Xinet Administration GUI.
Log files
The Logging, Triggers page of the xinet ADMINISTRATION view presents information from the trigger.log file. You can also find this file on the server in the following place:
On Unix systems:
/var/adm/fullpress/trigger.log
On Windows systems:
Program Files\Xinet\FullPress\trigger.log
Most of the interesting logging for Trigger Sets goes to this file. It is a clear-text file (on Unix, you can easily run tail -f on this while monitoring system activity) and the file to which, by default, all Actions are logged. When troubleshooting Trigger Sets, this is the most useful log file. A more detailed discussion of this file follows.