Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The file hos_docu_config.php contains basic options and there is normally no need to change it.
The configuration files are placed in the etc subdirectory of the ProcMan installation directory.
Dependent on how many activities a process definition has and on whether different configurations of the Universal Object Module for the activities are needed, one or several activity actions have to be defined. A command which is executed by an activity action looks like this:
or
hos_docu_call_config file is a Universal Object call configuration file in the etc directory, having the structure of the etc/hos_docu_call_config.php file described above.
options can be used to override the options specified in the configuration file.
Example:
Further there can be one or several configuration files containing settings for different process types and/or process type activities. After the installation there is one such configuration file named hos_docu_call_config.php in the etc directory. Further configuration files can be created by copying the hos_docu_call_config.php (or hos_docu_call_config.php.sample) and editing the copy for the purpose it shall fulfill. The name of the copy is arbitrary, but we recommend to call it hos_docu_call_conf_*.php (e.g. hos_docu_call_config_my_docu.php).
Like described in the next chapter, quite all the options in these configuration files (except those containing non scalar array values), can be overridden in the ProcMan actions calling the Universal Object module. How many configuration files will be needed depends on how many different processes using the Universal Object module will be defined and on how different the configurations for the processes and/or for the activities in the processes will be. One extreme is to define only one configuration file for all processes/activities and handle the differences in the calls in actions. In this case, if there are bigger differences among the configurations, the statements for overriding the settings in the actions may become very long. Another extreme is to define a special configuration file for any activity of any process. In this case no settings have to be overridden in the actions, but the amount of configuration files may become big. There is no general rule how many configuration files have to be defined. It is up on the administrator to find a good compromise.
In a Universal Object module call configuration file following options can be set:
readonly – Has to be set to _'_N' for activity actions, to 'Y' for report actions.
rejectable – If set to 'Y' the activity can be rejected, otherwise not.
possible_rejects – Definition of possible rejects. It is an array of single reject definitions, like this: <key> => array(<description>, <return code> [, <translate> ]). <key> is a unique string, it must not contain the character comma (,) and it can be used in the option rejects to specified which reject definitions can be used in the activity. <description> is a string, it is either the description or a dictionary key. <return code> is a string, it specified the return code of the activity if the definition has been selected for rejection. <translate> is a string, is optional. If the value is 'Y' or 'y' the <description> is handled as a dictionary key, otherwise it is not translated, which is also the default.
Example:
rejects – A comma separated list of keys defined in the option possible_rejects. Only rejects specified here are displayed for a selection when the activity shall be rejected.
hos_reject – Specifies whether a special HOS reject has to be called (if set to 'Y') or not (if set to 'N') which is the default behavior. This option takes effect only if the ticket dialog is embedded in a HOS controlled process (e.g. JCL, TWSz, etc.).
param_prefix – The name prefix of object independent process parameters.
param_prefix_trigger – The name prefix of object independent process parameters triggered depending on the value of other object independent process parameters.
form_name – The name of the HTML forms in processes/activities using the configuration.
ok_question – A dictionary id of the confirmation question which shall be displayed before the activity is completed. If empty, no question is displayed.
discard_question – A dictionary id of the confirmation question which shall be displayed before the activity last changes are discarded. If empty, no question is displayed.
memo_visible – If 'Y' the free text memo field is displayed in the activity, otherwise not.
memo_mandatory - If 'Y' a nonempty text is required in the free text memo field to complete/reject the activity, otherwise not.
memo_rows – Number of displayed rows of the free text memo field.
memo_columns – Number of displayed columns (text width in characters) of the free text memo field.
memo_max_len – Maximal allowed count of characters in the free text memo field. 0 means unlimited.
display_gpd_expanded – If 'Y' the global process data information section is initially displayed, otherwise it is initially hidden.
display_apd_expanded – If 'Y' the additional process data information section is initially displayed, otherwise it is initially hidden.
display_mh_expanded – If 'Y' the memo history information section is initially displayed, otherwise it is initially hidden.
display_af_expanded – If 'Y' the attached files section is initially displayed, otherwise it is initially hidden.
exec_ext_cmd_communication – Communication ID from the etc/hwm_universal_interface_config.php file. It can be used to specify that an external command shall be executed for every process when the activity finishes. If not defined or set to an empty string, no external command will be executed.
exec_ext_cmd_command – Command ID from the etc/hwm_executor_config.php file on the external system where the external command shall be executed. It is executed only if a valid communication ID is specified in exec_ext_cmd_communication, otherwise it is ignored.
ext_cleanup – External cleanup script. This option is dedicated for cases when the ticket module is combined with other HOS modules (e.g. HOS_JCL) in one process type.
docu_stage_archive – The name of the stage archive, which is the archive in which an activity using this configuration writes the objects when it is completed.
docu_final_archive – The name of the final archive, which is the archive in which the last activity of a process using this configuration writes the objects when it is completed.
docu_ignore_object_existence – If set to 'N', objects already existing in the archive can be modified only by a change. If a creation of a new object should ignore, that the object already exists in the archive and overwrite it, set to 'Y'.
docu_finalize_process – If the final actions for the process have to be done by the activity set to 'Y', otherwise to 'N'. It has only effect if stage archive is the same like the final one.
docu_archive_objects – If 'Y' the objects will be written in the stage archive on the activity completion, otherwise only in the interim (work) archive.
docu_interim_archive – The name of the interim (work) archive, which is the archive in which the process activities write the work versions of the objects. Beware that the interim archive name must be the same for all activities of a process type.
docu_id_descr – Text describing the object ID in the dialogs. By default (when set to '') the translation of the hos_docu_mID entry from the dictionary is being used.
docu_id_descr_trnsl – If docu_id_descr is specified and not empty, it specifies whether the text in docu_id_descr has to be translated from the dictionary (on value 'Y') or not (on value 'N').
docu_param_prefix_data - The name prefix of Universal Object parameters, specified in the Global/Process Definition dialog, building the data content of the objects.
docu_param_prefix_trigger - The name prefix of Universal Object parameters, specified in the Global/Process Definition dialog, building the data content of the objects and triggered depending on the value of other Universal Object parameters.
docu_show_key_in_filter – The key parameters of an object are normally a part of the object ID. If this is the case, the key parameters normally do not need to be shown in the filter dialog, but only the object ID. Set the value of this option to 'Y' if the key parameters shall be displayed in the filter dialog, or to 'N' if not.
docu_object_count_param – The name of the process parameter in which the count of objects used in the process shall be stored.
docu_objects_mandatory – If there must be at least one object used in the process to be able to complete the activity set it to 'Y', otherwise to 'N'.
docu_enable_new – If the functionality for creating new objects has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_import – If the functionality for importing of new objects from a comma separated file (csv) has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_change – If the functionality for changing objects in the object archive has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_substitute – If the functionality for substituting parameters in selected objects in the archive has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_copy – If the functionality for creating new objects as a copy of existing objects in the archive has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_delete – If the functionality for deleting objects from the archive has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_restore – If the functionality for restoring deleted objects in the archive has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_view – If the functionality for viewing objects in the current process has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_edit – If the functionality for editing objects in the current process has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_clone – If the functionality for creating objects as a copy of existing objects in the current process has to be enabled set it to 'Y', otherwise to 'N'.
docu_enable_remove – If the functionality for removing objects from the current process has to be enabled set it to 'Y', otherwise to 'N'.
docu_on_obj_in_use_new – Sets the behavior when a newly defined object in the current process is also used in another active process. If set to 'E', an error is displayed in the case of a parallel usage of an object. If set to 'W', a warning is displayed in this case.
docu_on_obj_in_use_change – Sets the behavior when a changed object in the current process is also used in another active process. If set to 'E', an error is displayed in the case of a parallel usage of an object. If set to 'W', a warning is displayed in this case.
docu_on_obj_in_use_delete – Sets the behavior when a deleted object in the current process is also used in another active process. If set to 'E', an error is displayed in the case of a parallel usage of an object. If set to 'W', a warning is displayed in this case.
docu_enable_edit_save – If the possibility to save an edited object without doing validation check has to be enabled set it to 'Y', otherwise to 'N'. If it is set to 'Y', it implies that also the option docu_enable_check_column is set to 'Y', regardless of what is set in the configuration file for that option.
docu_confirm_edit_cancel – If the canceling of editing an object has to be confirmed set it to 'Y', otherwise to 'N'.
docu_system_gen_expr – Specifies an expression, how the system parameter of an object has to be generated from the object parameters. If set to empty string, a default expression is used for the generation of the system parameter. Example: 'docu_system_gen_expr' => 'substr(${DOCU.KEY.SYS1}, 0, 3)'
docu_key_gen_expr – Specifies an expression, how the key parameter of an object has to be generated from the object parameters. If set to empty string, a default expression is used for the generation of the system parameter. Example: 'docu_key_gen_expr' => '${DOCU.KEY.DIR}.'/'.${DOCU.KEY.FIL}'
docu_key_params_in_key – List of key parameters for which the complete values can be found in the object key. This is used when searching objects specified by a filter. This can make the search faster, as the searching of values in the object key is faster than searching them in the object content. Example:
docu_object_enabled_expr – Specifies an expression, how can be decided from the object parameters whether the object is enabled or disabled. If set to empty string, the enabled/disabled feature is switched off and there will be nowhere shown the enabled/disabled information about objects. Example: 'docu_object_enabled_expr' => ' ${DOCU.DATA.ENABLED} = 'Y''
docu_edit_rejected_version – If set it to 'N', after a reject the users will edit last object versions stored by their activities (if such exist). If set it to 'Y', after a reject the users will edit the latest object versions stored in the process, even if they have been stored by later activities.
docu_enable_system_column – If the system column shall be displayed in the objects overview table set it to 'Y', otherwise to 'N'.
docu_enable_check_column – If the column with the information whether the object parameters already have been validated or not shall be displayed in the objects overview set it to 'Y', otherwise to 'N'.
docu_file_version_action_map – When selection lists of files from the internal archives are displayed (e.g. in the report), the file version description contains beside the timestamp also the action name of the activity which stored the version. If an alias name is specified here for an action, then the alias name is used in the version description instead of the action name. This allows to shorten the file version descriptions. Example:
docu_report_archives – This option is used only by process report actions (started with the option 'readonly' => 'Y'). This option specifies from which archives the objects shall be displayed in the process report and what heading (description) the partial report parts shall be displayed with. Each archive has to be specified like this:
archive id is the archive name of a final or a stage archive used by the process (see options docu_final_archive and docu_stage_archive).
description text specifies either directly the text or a dictionary id of the text, which shall be displayed as a heading of the archive section in the process reports.
translate description text specifies on value false, that the description text shall be used in the archive section heading; on value true, that the description text is handled as a dictionary entry id and its translated value shall be used in the archive section heading.
Example:
docu_browser_process_type – This option is used only by actions called from the Object Browser. It specifies the name of the process definition in which the object parameters are defined. This option is necessary because the Object Browser actions (unlike process actions) are not started in a process context, so they have to be informed about the process definition in which the object parameters are defined.
docu_browser_selection_params – This option is used only by actions called from the Object Browser. A list of important object parameters, which shall be displayed in the Object Browser’s selection overview table, can be specified. For each object in the table the values of the specified parameters will be displayed, beside the standard parameter values.
Example:
docu_browser_enable_compare - If the compare of the current version of an object with its older versions shall be enabled set it to 'Y', otherwise to 'N'.
one or several activity actions
one report action
one cleanup action
one Object Browser action
docu_id_srch_class – The name of an existing search class defined in the . This allows to use the ProcMan’s search function to search for processes in which objects specified by their object ID have been used. If set to ''" this feature is switched off.
docu_param_prefix_key - The name prefix of Universal Object parameters, specified in the , building the object key.
How to define actions is described in the documentation . For each Universal Object process we need:
Activity actions, report action and cleanup action have to be specified in the process definition. How to define process definitions is described in the documentation .
The Object Browser action has to be specified in the Object Browser definition. How to define Object Browser definitions is described in the documentation .
The Object Browser action is called when a user clicks on an Object Browser menu item. A command which is executed by the Object Browser action looks like this:
hos_docu_call_config file is a Universal Object call configuration file in the etc directory, having the structure of the etc/hos_docu_call_config.php file described above.
Example:
Although there is a possibility to specify different report actions for each activity, normally we need only one report action for all activities of the process. For report actions the configuration option readonly must be set to 'Y'. That can be either done in a special configuration file for the report action or by using a configuration file of an activity action and overriding the readonly option in the call parameter. A command which is executed by the report action looks for the first case like this:
or for the second case like this:
hos_docu_call_config file is a Universal Object call configuration file in the etc directory, having the structure of the etc/hos_docu_call_config.php file described above.
Example:
The cleanup action is called when a process is deleted. A command which is executed by the cleanup action looks like this:
hos_docu_call_config file is a Universal Object call configuration file in the etc directory, having the structure of the etc/hos_docu_call_config.php file described above.
Example:
A Universal Object process contains none, one or several Universal object creations/changes/deletions. Process parameters are stored once in each Universal Object process. Object parameters are stored in each Universal object of a Universal Object process. There are two types of object parameters: key object parameters and data object parameters. The key object parameters build together a unique key of Universal objects. As the process and object parameters are defined in the same place in the process definition, the type of any parameter is recognized based on its name prefix. So you have to choose good name prefixes for the different types of parameters before you start to define them in the process definition. For example you can choose the 'PROC.' prefix for process parameters, 'OBJ_KEY.' prefix for the object key parameters and 'OBJ_DATA.' prefix for the object data parameters. The chosen prefixes have to be specified in the configuration file etc/hos_docu_call_config.php (like described above the file name can be a different one) in the options param_prefix, docu_param_prefix_key and docu_param_prefix_data.
Process and object parameter definitions specify which parameters will be displayed in the user input dialogs, process reports and Object Browser. The parameters have to be defined in process definitions. How to define parameters in a process definition is described in the documentation .
ProcMan allows optionally so called triggering in dialogs. It allows to show/hide parts of the dialogs dynamically dependent on the value of some process/object parameters. The triggered parameters must have different name prefixes than the standard process and object parameters. For example you can choose 'PROC_TRIG.' prefix for triggered process parameters and/or 'OBJ_TRIG.' prefix for triggered object parameters. The chosen prefixes have to be specified in the configuration file etc/hos_docu_call_config.php (like described above the file name can be a different one) in the options param_prefix_trigger and/or docu_param_prefix_trigger. For more information about the triggering see the documentation .