The file hwm_universal_interface.php contains configurations of communication between ProcMan and external systems. For the Control-M module the communication with the Control-M Automation API must be configured here. After the ProcMan installation the file hwm_universal_interface.php (and/or hwm_universal_interface.php.sample) already contain an example configuration for communication with Control-M Automation API.
For to make it work, the url setting have to be modified to the URL of a real Control-M installation. If the Automation API is accessed via https, and the setting ssl_verifypeer is set to true, the setting cainfo must point on a file containing the proper CA certificate (or CA certificate chain) in PEM format, with which the Control-M server certificate has been signed.
If a communication with Automation APIs of several Control-M installations is required, uncomment the code block in the function ctm_request() and adjust the system ID to URL mapping.
The file hos_ctm_config.php contains basic options and there is normally no need to change it.
There can be one or several call configuration files containing settings for different process types and/or process type activities. After the installation there is one such configuration file named hos_ctm_call_config.php in the etc directory. Further configuration files can be created by copying the hos_ctm_call_config.php (or hos_ctm_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_ctm*call_config.php (e.g. hos_ctm_my_ctm_call_config.php).
Like described later in this document, most of the options in these configuration files (except those containing non scalar array values), can be overridden in the ProcMan actions calling the Control-M module. How many configuration files will be needed depends on how many different processes using the Control-M 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 Control-M 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.
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_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_key - The name prefix of Control-M object parameters, specified in the Global/Process Definition dialog, building the object key.
docu_param_prefix_data - The name prefix of Control-M object parameters, specified in the Global/Process Definition dialog, building the data content of the objects.
docu_param_prefix_trigger - The name prefix of Control-M object parameters, specified in the Global/Process Definition dialog, building the data content of the objects and triggered depending on the value of other Control-M 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(${CTM.KEY.SYSTEM}, 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' => '${CTM.KEY.SERVER}.'/'.${CTM.KEY.FOLDER}'
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_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:
ctm_definition_format – Folder definition format which is either 'xml' or 'json'. Default is 'xml'.
ctm_param_system – Control-M object parameter name for the Control-M Enterprise Manager system.
ctm_param_server – Control-M object parameter name for the Control-M server (data center).
ctm_param_folder – Control-M object parameter name for the Control-M folder.
ctm_param_definition – Control-M object parameter name for the Control-M folder XML/JSON definition.
ctm_stage – Stage name of the activity.
ctm_rules_file – A file containing customer specific rules for automatic checking and changing of the definition. If not specified or empty no customer specific rules will be applied.
ctm_enable_import – If the multiple folder import operation shall be enabled set the appropriate option to 'Y', otherwise to 'N'.
ctm_enable_file_multi_import – If the multiple folder import operation from XML/JSON files shall be enabled set the appropriate option to 'Y', otherwise to 'N'.
ctm_enable_em_import – If the import of folder definition from a Control-M Enterprise Manager into the editor shall be allowed, set this option to 'Y' otherwise to 'N'.
ctm_enable_file_import – If the import of folder definition from a local XML/JSON file into the editor shall be allowed, set this option to 'Y' otherwise to 'N'.
ctm_enable_file_export – If the export of folder definition from the editor into a local XML/JSON file shall be allowed, set this option to 'Y' otherwise to 'N'.
ctm_communication – Communication ID from the etc/hwm_universal_interface_config.php file.
ctm_em_id – Control-M Enterprise Manager ID. The mapping of the EM IDs to their URLs must be configured in the request callback in etc/hwm_universal_interface_config.php. The EM ID is passed to the request callback in the parameter $inData['system'].
ctm_user – User for the communication with the Control-M Enterprise Manager.
ctm_password – Password (encrypted in admin dialog) for the communication with the Control-M Enterprise Manager.
ctm_list_folders_report – Name of the report defined in Control-M for generating list of folders.
ctm_alternative_em – Optional list of alternative Control-M Enterprise Manager systems, if the ProcMan activity has to handle several different source/target EM systems. For the specified EM systems only ctm_em_id is a mandatory option. The options ctm_user, ctm_password and ctm_list_folders_report are taken from the above global options if not specified.
Example:
ctm_source_em – Optional lists of source Control-M Enterprise Manager system IDs. If not specified, the EM system ID set in ctm_em_id is taken as the only source EM system. The option can be set as an array of IDs (e.g. array('DEV', 'TEST')), or as a comma separated list of IDs (e.g. 'DEV,TEST').
ctm_target_em – Optional lists of target Control-M Enterprise Manager system IDs. If not specified, the EM system ID set in ctm_em_id is taken as the only target EM system. The option can be set as an array of IDs (e.g. array('TEST', 'PROD')), or as a comma separated list of IDs (e.g. 'TEST,PROD').
ctm_source_em_expr – Alternatively to ctm_source_em an expression can be specified here to let the source Control-M Enterprise Manager system ID to be evaluated from an expression (e.g. '${SOURCE_SYS}').
ctm_target_em_expr – Alternatively to ctm_target_em an expression can be specified here to let the target Control-M Enterprise Manager system ID to be evaluated from an expression (e.g. '${TARGET_SYS}').
ctm_stage_em – Mapping of stages to possible target Control-M Enterprise Manager system IDs. It is very important for generating delete statements for several stages in one activity and for testing if the folders specified in the process are in use by other processes. The entries have the format <stage> => <list of EM IDs>. The list of EM IDs can be either an array of IDs (e.g. array('DEV', 'TEST')), or a comma separated list of IDs (e.g. 'DEV,TEST').
Example:
ctm_process_em – Mapping of stages to the target Control-M Enterprise Manager system IDs of a process. The IDs are evaluated from the specified expressions. This is especially important, if the stage system is not constant, but specified in a process parameter. If an entry for a stage is missing, the first system specified in ctm_stage_em for the stage is used as the process stage system ID. The entries have the format <stage> => <EM ID expression>.
Example:
ctm_report_max_wait_time – Timeout in seconds for waiting for a report is generated by Control-M. The value can be either an integer or a string containing an integer (e.g. '10').
ctm_deploy – If the folder definitions have to be deployed to Control-M Enterprise Manager by the activity set to 'Y' otherwise to 'N'.
ctm_deploy_block_size – Maximal count of folder definitions sent to Control-M Enterprise Manager in one block. The value can be either an integer or a string containing an integer (e.g. '20').
ctm_deploy_ignore_sync_errors – Whether synchronization errors on deployment shall be ignored (in specified systems) or handled as true errors (in not specified systems). The options can be set as an array of IDs (e.g. array('DEV', 'TEST')), or as a comma separated list of IDs (e.g. 'DEV,TEST').
ctm_key_delimiter – Delimiter between the Control-M server and folder in the key. The value is '/' by default.
ctm_known_folders_check – If enabled (set to 'Y'), a check whether the in process selected folders are already known in ProcMan is performed and the result is displayed in the dialog.
ctm_display_kf_expanded – Specifies whether the known folders check information is initially expanded (set to 'Y') or collapsed (set to 'N') in the dialog.
ctm_kf_stages – Shows known folder checks only for specified stages. By default it shows the checks for all stages. The options can be set as an array of IDs (e.g. array('DEV', 'TEST')), or as a comma separated list of IDs (e.g. 'PROD,TEST').
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'.
ProcMan supports two formats of folder definitions defined by Control-M: XML and JSON. As the structure of the definitions in the two formats is very different, the rules configurations for the two formats are different in ProcMan as well. In this chapter the rules configuration files for both formats will be described.
There can be one or several rules configuration files for different process types and/or process type activities. After the installation there are two such configuration file named hos_ctm_rules_config.php (contains basic rules example for the XML format) and hos_ctm_rules_config_json.php (contains basic rules example for the JSON formats) in the etc directory. Further rules configuration files can be created by copying the hos_ctm_rules_config*.php (or hos_ctm_rules_config*.php.sample) and editing the copy for the purpose it shall fulfil. The name of the copy is arbitrary, but we recommend to call it hos_ctm*rules_config.php (e.g. hos_ctm_my_ctm_rules_config.php).
This type of configuration files defines rules for validation checks and automatic changes applied on the Control-M folder definitions handled by the ProcMan processes. Which rules configuration file has to be used by an action can be specified either in the ctm_rules_file option in the call config file of the action, or in the action call parameter ctm_rules_file (described later in this document). How many rules configuration files will be needed depends on how many different processes using the Control-M module will be defined and on how different the rules configurations for the processes and/or for the activities in the process will be. One extreme is to define only one rules configuration file for all processes/activities with eventually complex conditions handling the differences. Another extreme is to define a special rules configuration for each activity of each process, in which case the amount of the rules configuration files may become big. There is no general rule how many rules configuration files have to be defined. It is up on the administrator to find a good compromise.
Each rules configuration can contain a check and a change section:
The check section contains validation check rules. The change section contains automatic change rules.
Checks for the XML format
The checks are defined in the check section of the configuration. It contains a list of partial checks. Each check definition consists of several parameters. Possible parameters are element, attribute, variables, condition, mandatory_attribute, at_element_end, name, warning, message, translate.
If the parameter element is present, the check will be evaluated only for the specified element(s) in the Control-M XML definition. The value of the parameter can be a string (one element) or an array of strings (several elements). If the element parameter is missing, the check will be evaluated for all elements.
If the parameter attribute is present, the check will be evaluated for the specified attribute(s) in the Control-M XML definition. The value of the parameter can be a string (one attribute) or an array of strings (several attributes). If the attribute parameter is missing, the check rule is applied for the element instead of for attributes.
In the variables parameter variables can be defined and initialized by expressions. They can be used then in further variables and/or condition expressions. The value of this parameter is an array containing items, in which the key is the variable name (string) and the value is an expression (string). The syntax of the expressions is the same like for the when parameter.
In the condition parameter a check expression can be specified. The syntax of the expressions is the same like for the when parameter. If the condition expression is evaluated to a boolean true value, the check has passed. If it is evaluated to a boolean false value, the check has failed.
If there are attribute names specified in the mandatory_attribute parameter, the check fails, if some of the attributes are missing in the element definition. This kind of checks are performed only for elements, so this parameter is ignored, if the check rule contains also attributes specified in the 'attribute' parameter. This parameter is further ignored, if also condition is specified in the rule. The value of the parameter can be a string (one attribute) or an array of strings (several attributes).
By the parameter at_element_end can be determined, whether the check rule has to be performed prior to or after the check rules have been applied for the sub elements of the element. If this parameter is omitted or set to false in a rule, the rule is applied prior to, otherwise after checking the sub elements.
If a name of the rule is specified in the name parameter, the name is displayed in error/warning messages.
The parameter warning indicates whether the failed check has to be handled as a warning or an error. If it is specified and the parameter value is true, the failed check is handled as a warning. Otherwise it is handled as an error.
The parameter message can contain the error/warning message used when the check fails. If it is missing a standard message is used. The parameter value can be either the text of the message, or a dictionary key.
The parameter translate when specified and having value true indicates, that the message shall be handled as an dictionary key and translated depending on the user's language settings.
Example:
Checks for the JSON format
The checks are defined in the 'check' section of the configuration. It contains a list of partial checks. Each check definition consists of several parameters. Possible parameters are: member, variables, when, condition, mandatory_member, at_object_end, name, warning, message, translate, delimiter.
If the parameter member is present, the check will be evaluated for the specified member(s) in the Control-M JSON definition. The value of the parameter can be a string (one member) or an array of strings (several members). The object IDs for some Control-M object types are in the JSON format not specified in a member of the object definition itself unfortunately, but as a member key of the object in the parent object (e.g. folder/job name of a folder/job object). However, in the ProcMan rules the object keys can be referenced in the rules, as if they were specified in an object member by using '#ObjectKey' in the member parameter. If the member parameter is missing, the check rule is applied for the objects itself instead of for members of the objects.
In the variables parameter variables can be defined and initialized by expressions. They can be used then in further variables and/or condition expressions. The value of this parameter is an array containing items, in which the key is the variable name (string) and the value is an expression (string). The syntax of the expressions is the same like for the when parameter. If also a nonempty string or an array of nonempty strings is specified in the delimiter parameter and some of the specified delimiters is present in the value of the member for which the rule is applied, the expression is evaluated for all parts of the member value separated by the delimiter.
In the condition parameter a check expression can be specified. The syntax of the expressions is the same like for the when parameter. If the condition expression is evaluated to a boolean true value, the check has passed. If it is evaluated to a boolean false value, the check has failed.
If there are member names specified in the mandatory_member parameter, the check fails, if some of the attributes are missing in the object definition. This kind of checks are performed only for objects, so this parameter is ignored, if the check rule contains also members specified in the members parameter. This parameter is further ignored, if also condition is specified in the rule. The value of the parameter can be a string (one member) or an array of strings (several members).
By the parameter at_object_end can be determined, whether the check rule has to be performed prior to or after the check rules have been applied for the sub objects of the object. If this parameter is omitted or set to false in a rule, the rule is applied prior to, otherwise after checking the sub objects.
If a name of the rule is specified in the name parameter, the name is displayed in the error/warning messages.
The parameter warning indicates whether the failed check has to be handled as a warning or an error. If it is specified and the parameter value is true, the failed check is handled as a warning. Otherwise it is handled as an error.
The parameter message can contain the error/warning message used when the check fails. If it is missing a standard message is used. The parameter value can be either the text of the message, or a dictionary key.
The parameter translate when specified and having value true indicates, that the message shall be handled as an dictionary key and translated depending on the user's language settings.
Example:
Changes for the XML format
The changes are defined in the change section of the configuration. It contains a list of partial changes. Each change definition consists of several parameters. Possible parameters are: element, attribute, variables, condition, constant, evaluate, delimiter.
If the parameter element is present, the change will be applied only on the specified element(s) in the Control-M XML definition. The value of the parameter can be a string (one element) or an array of strings (several elements). If the element parameter is missing, the change will be applied on all elements.
If the parameter attribute is present, the change will be applied on the specified attribute(s) in the Control-M XML definition. The value of the parameter can be a string (one attribute) or an array of strings (several attributes). If the attribute parameter is missing, the change will not be applied on any attribute.
In the variables parameter variables can be defined and initialized by expressions. They can be used then in further variables and/or condition expressions. The value of this parameter is an array containing items, in which the key is the variable name (string) and the value is an expression (string). The syntax of the expressions is the same like for the when parameter.
In the condition parameter a change expression can be specified. The syntax of the expressions is the same like for the when parameter. If the condition expression is not specified or it is evaluated to a boolean true value, the change will be applied. If it is evaluated to a boolean false value, the change will be skipped.
If the parameter constant is specified, the value of the attribute in the Control-M XML definition is replaced with the value specified here, when the change is applied for an attribute.
If the parameter evaluate is specified, the value of the attribute in the Control-M XML definition is evaluated from the expression specified here, when the change is applied for an attribute.
The parameter delimiter can be combined with the parameter evaluate. One delimiter can be specified as a string or several as an array of strings. In this case the attribute value is considered to consist of parts separated by the specified delimiter(s) and the 'evaluate' expression will be applied on each part separately.
Example:
Changes for the JSON format
The changes are defined in the change section of the configuration. It contains a list of partial changes. Each change definition consists of several parameters. Possible parameters are: member, variables, when, condition, constant, evaluate, delimiter.
If the parameter member is present, the change will be applied only on the specified member(s) in the Control-M JSON definition. The value of the parameter can be a string (one member) or an array of strings (several members). The object IDs for some Control-M object types are in the JSON format not specified in a member of the object definition itself unfortunately, but as a member key of the object in the parent object (e.g. folder/job name of a folder/job object). However, in the ProcMan rules the object keys can be referenced, as if they were specified in an object member by using '#ObjectKey' in the member parameter. If the member parameter is missing, the change rule is applied for the objects itself instead of for members of the objects.
In the when parameter an expression, which determinate whether the rule shall be applied or not, can be specified. If the parameter is omitted or if the expression is evaluated to a boolean true value, the variable settings and the change (depending on the condition) are applied. If it is evaluated to a boolean false value, the rule is ignored for the current object/member (no variable settings and no change will take place). The syntax of the expressions is the same like for the when parameter in the checks.
The variables parameter works in the same way like for the checks.
In the condition parameter a change expression can be specified. The syntax of the expressions is the same like for the when parameter. If the condition expression is not specified or it is evaluated to a boolean true value, the change will be applied. If it is evaluated to a boolean false value, the change will be skipped.
If the parameter constant is specified, the value of the member in the Control-M JSON definition is replaced with the value specified here, when the change is applied for an member. If the member value is an array, the change is applied on all scalar values in the array (and in its eventual sub-arrays).
If the parameter evaluate is specified, the value of the member in the Control-M JSON definition is evaluated from the expression specified here, when the change is applied for an member. The syntax of the expressions is the same like for the when parameter. If the member value is an array, the change is applied on all scalar values in the array (and in its eventual sub-arrays).
The parameter delimiter can be combined with the parameter evaluate. One delimiter can be specified as a string or several as an array of strings. In this case the attribute value is considered to consist of parts separated by the specified delimiter(s) and the evaluate expression will be applied on each part separately.
Example:
ctm_check_outcond(<system>, <report name>, <cond name>, <cond ODATE>)
This function checks whether the out-condition specified by the name and ODATE is defined on the specified Control-M system. The report specified by the name is used to obtain the list of out-conditions and must be defined on the Control-M system.
ctmcheckoutcond(<system>, <report name>, <cond name>, <cond ODATE>)
This function is an alias for the function ctm_check_outcond.
ctm_check_incond(<system>, <report name>, <cond name>, <cond ODATE>)
This function checks whether the in-condition specified by the name and ODATE is defined on the specified Control-M system. The report specified by the name is used to obtain the list of in-conditions and must be defined on the Control-M system.
ctmcheckincond(<system>, <report name>, <cond name>, <cond ODATE>)
This function is an alias for the function ctm_check_incond.
ctm_check_delcond(<cond name>, <cond ODATE>)
This function checks whether the delete condition (delete condition is actually an out-condition with sign "-") specified by the name and ODATE is defined in the currently analyzed JOB or SMART/SUB_FOLDER/TABLE. It can be used for example in rules for in-conditions to check, whether matching delete conditions are defined.
ctmcheckdelcond(<cond name>, <cond ODATE>)
This function is an alias for the function ctm_check_delcond.
ctm_check_del_cond(<cond name>, <cond ODATE>)
This function is an alias for the function ctm_check_delcond.
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.
In the when parameter an expression, which determinate s whether the rule shall be applied or not, can be specified. If the parameter is omitted or if the expression is evaluated to a boolean true value, the variable settings and the check are applied. If it is evaluated to a boolean false value, the rule is ignored for the currently checked element/attribute (no variable settings and no check will take place). The syntax of the expressions is the same like for the process parameter initialization and verification in the global/process definitions in the . Using $ in the expression, the current value of the attribute can be referenced. Using the syntax ${param_name} expression parameters can be used in the expressions. The param_name can be either the name of a process/activity parameter, HWM parameter, previously defined variable or one of the for Control-M activities predefined automatic variables (action, stage, element, parent, parents, platform). In addition to the standard functions, the Control-M module defines its own functions, which can be used in the expressions (see below).
In the when parameter an expression, which determinate whether the rule shall be applied or not, can be specified. If the parameter is omitted or if the expression is evaluated to a boolean true value, the variable settings and the check are applied. If it is evaluated to a boolean false value, the rule is ignored for the currently checked object/member (no variable settings and no check will take place). The syntax of the expressions is the same like for the process parameter initialization and verification in the global/process definitions in the . Using the syntax ${param_name} expression parameters can be used in the expressions. The param_name can be either the name of a process/activity parameter, HWM parameter, previously defined variable or one of the for Control-M activities predefined automatic variables (action, stage, type, list). In addition to the standard functions, the Control-M module defines its own functions, which can be used in the expressions (see below).
In the when parameter an expression, which determinate whether the rule shall be applied or not, can be specified. If the parameter is omitted or if the expression is evaluated to a boolean true value, the variable settings and the change (depending on the condition) are applied. If it is evaluated to a boolean false value, the rule is ignored for the current element/attribute (no variable settings and no change will take place). The syntax of the expressions is the same like for the process parameter initialization and verification in the global/process definitions in the Using $ in the expression, the current value of the attribute can be referenced. Using the syntax ${param_name} expression parameters can be used in the expressions. The param_name can be either the name of a process/activity parameter, HWM parameter, previously defined variable or one of the for Control-M activities predefined automatic variables (action, stage, element, parent, parents, platform). In addition to the standard functions, the Control-M module defines its own functions, which can be used in the expressions (see below).