The configuration files are placed in the etc subdirectory of the ProcMan installation directory.

This document describes the installation, configuration and customization of the ProcMan’s Universal Object Module. The Universal Object Module allows defining of a special kind of processes dedicated to create new, change and delete different types of Universal objects in ProcMan.

A Universal object is a set of textual, numeric, date/time, etc. data specified by a user. There is a history of object versions maintained in ProcMan. Moreover, the Universal Object Module provides an Object Browser for accessing the latest versions of objects easily.

Since version 5.0 a plugin system is provided. It allows to adjust/extend the standard behavior of the Universal Object Module: additional options can be supported, dialogs can be adjusted/extended, special automatic checks of the object definitions can be implemented, automatic changes of the object definitions when moving through the process activities (staging) can be implemented, reading object definitions from and writing them back to external systems is possible. This way for example the ProcMan module for the Control-M scheduler is implemented, as a plugin of the Universal Object Module.

In ProcMan versions before 3.0.21 the Universal Object Module was called Docu Module. Therefore, the files as well as options and parameters associated with this module still contain 'docu' or 'DOCU' in their names.

• one or several activity actions

• one report action

• one cleanup action

• one Object Browser action

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:

'possible_rejects' => array(
    'DEV' => array('hwm_mRejectDEV', '1', 'Y'),
    'TEST' => array('Test', '1'),
),

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}.&#039;/&#039;.${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_key_params_in_key' => array(
    'DOCU.KEY.DIR',
    'DOCU.KEY.FIL',
),

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} = &#039;Y&#039;'

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_file_version_action_map' => array(
    'DOCU_TEST_OPEN' => 'DEV',
    'DOCU_TEST_APPROVE' => 'TEST',
    'DOCU_TEST_CLOSE' => 'PROD',
),

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:

<string: archive id> => array(
    'description' => <string: description text>,
    'translate_description' => <bool: translate description text>
),

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_report_archives' => array(
    'DOCU_REQ' => array(
        'description' => 'Requested Documentation',
        'translate_description' => false,
    ),
    'DOCU' => array(
        'description' => 'hos_docu_mAccepted',
        'translate_description' => true,
    ),
),

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_selection_params' => array(
    'DOCU.KEY.APPLICATION',
    'DOCU.DATA.RESPONSIBLE_PERSON',
),

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'.

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:

hos_docu_call.php?config=<hos_docu_call_config file>

or

hos_docu_call.php?config=<hos_docu_call_config file>&<options>

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:

hos_docu_call.php?config=hos_docu_call_config.php&memo_visible=N&docu_stage_archive=DOCU_STAGE_2

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_object_browser.php?config=<hos_docu_call_config file>

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:

hos_docu_object_browser.php?config=hos_docu_call_config.php

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.

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:

hos_docu_call.php?config=<hos_docu_call_config file>

or for the second case like this:

hos_docu_call.php?config=<hos_docu_call_config file>&readonly=Y

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:

hos_docu_call.php?config=hos_docu_call_config.php&readonly=Y

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:

Imagine that in a company planed batch programs are running on several systems. The company needs an information system for production planners, where they can find emergency instructions for every planed batch program, in the case that it fails. For sure the information system shall also allow creating of new emergency instructions and maintaining of existing once.

In this example is shown how to configure the ProcMan’s Universal Object Module to handle this issue. The emergency instructions will be maintained by processes of a dedicated process type. The production planners can access the emergency instructions using the Object Browser.

In this example the process for maintaining emergency instructions has two activities. In the first one the developers specify a request for creating new or changing/deleting of existing emergency instructions. In the second activity the production planners approve the developer requests and save the requested emergency instructions into the ProcMan’s repository.

First, we need configuration file/files for the new process. In this example we will use one configuration file in all actions. After creating the configuration file etc/hos_docu_call_config_EI.php (EI means Emergency Instructions) as a copy of the sample file etc/hos_docu_config.php.sample and editing it, the configuration file looks like this (normally it would contain also descriptions in comments, but for the purpose of this document we removed them):

<?php
    $hos_docu_call_config = array(
        'readonly' => 'N',
        'rejectable' => 'N',
        'param_prefix' => 'EI.PROC.',
        'param_prefix_trigger' => '',
        'form_name' => 'frmEI',
        'ok_question' => '',
        'discard_question' => 'hwm_mMemoConfirmDiscard',
        'memo_visible' => 'Y',
        'memo_mandatory' => 'Y',
        'memo_rows' => '5',
        'memo_columns' => '100',
        'memo_max_len' => '0',
        'display_gpd_expanded' => 'Y',
        'display_apd_expanded' => 'Y',
        'display_mh_expanded' => 'Y',

        'docu_stage_archive' => 'EI',
        'docu_final_archive' => 'EI',
        'docu_archive_objects' => 'Y',
        'docu_interim_archive' => 'EI_INTERIM',
        'docu_id_descr' => '',
        'docu_id_descr_trnsl' => 'N',
        'docu_id_srch_class' => '',
        'docu_param_prefix_key' => 'EI.KEY.',
        'docu_param_prefix_data' => 'EI.DATA.',
        'docu_param_prefix_trigger' => '',
        'docu_show_key_in_filter' => 'Y',
        'docu_object_count_param' => 'OBJECT_COUNT',
        'docu_objects_mandatory' => 'Y',
        'docu_enable_new' => 'Y',
        'docu_enable_import' => 'Y',
        'docu_enable_change' => 'Y',
        'docu_enable_substitute' => 'Y',
        'docu_enable_copy' => 'Y',
        'docu_enable_delete' => 'Y',
        'docu_enable_restore' => 'Y',
        'docu_enable_view' => 'Y',
        'docu_enable_edit' => 'Y',
        'docu_enable_clone' => 'Y',
        'docu_enable_remove' => 'Y',
        'docu_on_obj_in_use_new' => 'E',
        'docu_on_obj_in_use_change' => 'E',
        'docu_on_obj_in_use_delete' => 'E',
        'docu_enable_edit_save' => 'Y',
        'docu_confirm_edit_cancel' => 'Y',
        'docu_system_gen_expr' => 'trim(${EI.KEY.SYSTEM})',
        'docu_key_gen_expr' => 'trim(${EI.KEY.DIR}).\'/\'.trim(${EI.KEY.FILE})',
        'docu_object_enabled_expr' => '${EI.DATA.ENABLED} = \'Y\'',
        'docu_edit_rejected_version' => 'N',
        'docu_enable_system_column' => 'Y',
        'docu_enable_check_column' => 'Y',

        'docu_report_archives' => array(
            'EI' => array(
                'description' => 'Accepted emergency instructions',
                'translate_description' => false,
            ),
        ),

        'docu_browser_process_type' => 'EMERGENCY_INSTRUCTIONS',
    );
?>

While editing the configuration file we have decided that the process ID will be 'EMERGENCY_INSTRUCTIONS', that the name of the repository archive will be 'EI', that the process parameter prefix will be 'EI.PROC.', that the prefixes of object key/data parameters will be 'EI.KEY.'/'EI.DATA.' , that there will be an object key parameters 'EI.KEY.SYSTEM'/'EI.KEY.DIR'/'EI.KEY.FILE' containing the information about the system/directory/file name of a program which is the object of an emergency instruction and that there will be an object data parameter 'EI.DATA.ENABLED' containing the information whether an emergency instruction is enabled or not. Further we have specified expressions for how the system, key and enabled information of an emergency instruction will be evaluated from the object parameters.

In the Administration Dialog of ProcMan we define actions which we will need in the emergency instructions.

Action for the developer requests:

Action for the planner approval:

Action for the process report:

Action for the cleanup on process deletes:

Action for the Object Browser:

In the Administration Dialog of ProcMan we define the process for the emergency instructions:

In the process definition we define the parameters we need, using proper parameter name prefixes:

The file hos_docu_config.php contains basic options and there is normally no need to change it.

The activity_input_data member is optional and can be omitted from the REST API request, if the default settings for the options settable in the structure shall be used and no further Universal Object instructions shall be added to the process by the activity (e.g. if all the object instructions have been added to the process by previous activities).

If it is specified, it has to contain a JSON object, containing option settings and/or Universal Object instruction definitions in its members.

If the value of the option complete is true (default), the activity will be completed, if it is false, the activity will be interrupted after a successful submission.

If the value of the option ignore_missing_checks is true (default), the submission of the activity will not report an error if some of the object instruction definitions in the process have not been checked in the dialog. If the check feature is enabled for the activity (docu_enable_edit_save = 'Y' or docu_enable_check_column = 'Y' in the activity configuration) and the value of ignore_missing_checks is false, the submission of the activity will report an error if some of the object instruction definitions in the process have not been checked by a user in the ProcMan dialog. This option does not affect the internal checks performed on the REST API submission. These checks are performed anyway. It only gives the possibility to force that someone checks it also in the dialog.

The option ticket can contain new values for the ticket process parameters (defined in the process definition admin dialog). The value of this option must be a JSON object containing the parameter IDs as member names and the new values which shall be set for the parameters. For checking the values are applied the same rules like in the dialog.

The option memo can contain a memo text, which shall be added to the process memos. It is mandator only if it is required by the activity.

The option objects can contain an array of object manipulation instructions. It is not mandatory, so it can be omitted from the request. The instructions specified here do not replace the instructions already defined in the process (defined in previous or this activities), but they are applied incrementally on them (e.g. already defined new/change/delete instructions can be removed, or further new/change/delete instructions can be added to them).

Each item in the array in the objects option has to be a JSON object. It must contain a member instruction the value of which has to be one of remove, new, change, or delete. The instruction remove removes a previously defined new/change/delete object manipulation instruction from the process. The instructions new, change and delete add a new/change/delete object manipulation instruction to the process. Further each JSON object can contain the members key and/or object. The value of the member key has to be a JSON object, containing the members system and id. The member system can be omitted, if process type does not support it, otherwise it has to contain the system of the object. The member id has to contain the id of the object. The value of the member object has to be a JSON object, having the object key and data process parameters (specified in the process definition) as key and the requested values of these parameters as values. Not all object process parameters must be necessarily specified (e.g. for the instruction change only parameters which shall be changed, or for the instruction new only parameters which are mandatory must be specified). For the instructions remove and delete the member key is mandatory. Fort the instruction change the object key must be specified either in the member key or in the key object parameters in the member object. The data object parameters which shall be changed have to be specified in the member object in this case. For the instruction new the key and data object parameters have to be specified in the member object. The only meaningful case to use the member key for the instruction new is, when the key of the object previously added as a new object shall be changed. In this case the member key has to contain the current key of the object in the process and the key object parameters in the member object the new key.

Example of a request:

{
    "process": 123,
    "action": "EMERGENCY_INSTR_REQUEST",
    "ignore_predprocess_status": true,
    "activity_input_data": {
        "complete": true,
        "ignore_missing_checks": true,
        "ticket": {
            "EI.PROC.CHANGE_ID": "123456"
        },
        "memo": "Modification for ticket 123456.",
        "objects": [
            {
                "instruction": "remove",
                "key": {
                    "system": "SYS1",
                    "id": "dir0\/file0"
                }
            },
            {
                "instruction": "new",
                "object": {
                    "EI.KEY.SYSTEM": "SYS1",
                    "EI.KEY.DIR": "dir1",
                    "EI.KEY.FILE": "file1",
                    "EI.DATA.ENABLED": "Y",
                    "EI.DATA.INSTRUCTION": "Some instruction"
                }
            },
            {
                "instruction": "change",
                "key": {
                    "system": "SYS1",
                    "id": "dir1\/file2"
                },
                "object": {
                    "EI.DATA.INSTRUCTION": "Changed instruction"
                }
            },
            {
                "instruction": "delete",
                "key": {
                    "system": "SYS2",
                    "id": "dir2\/file3"
                }
            }
        ]
    }
}

A response on a successful REST API activity submission contains in its actvitiy_output_data member a JSON object with a member objects, containing a JSON array of objects in the process. The process objects in the array are represented by a JSON object containing the Universal Object Module instruction (new, change or delete) and the object key containing the sysem and id.

Example of a response:

{
    "step": 456,
    "process": 123,
    "action": "EMERGENCY_INSTR_REQUEST",
    "action_description": "Emergency Instruction Request",
    "role": "DEVELOEPER",
    "user": "xy1234",
    "status": "Complete",
    "return_code": "0",
    "start": "20220101094842",
    "update": "20220101095720",
    "end": "20220101095720",
    "activity_output_data": {
        "objects": [
            {
                "instruction": "delete",
                "key": {
                    "system": "SYS2",
                    "id": "dir2\/file3"
                }
            },
            {
                "instruction": "change",
                "key": {
                    "system": "SYS1",
                    "id": "dir1\/file2"
                }
            },
            {
                "instruction": "new",
                "key": {
                    "system": "SYS1",
                    "id": "dir1\/file1"
                }
            }
        ]
    }
}

Since ProcMan 5.0.4 there is a possibility to start Universal Object activities via REST API. For more information about ProcMan’s REST API start in your Browser https://<procman_dns>:<procman_port>/hwm_rest_api.php (replace <procman_dns> and <procman_port> so they match your ProcMan installation) and see the description of the partial REST API instructions.

Activities can be started using the submit_activity REST API instruction. The Universal Object submissions expect a specific structure of the data passed in the member activity_input_data of the parameter data in the REST API submit_activity request. The structure of a response on such a request contains a member activity_output_data, which is also Universal Object Module specific.

Automatic activities can also be triggered via the REST API. As such activities do not expect any input, any try to pass data to the activities in the activity_input_data member of the REST API request will be ignored. The activity_output_data member of the REST API response will always be empty for such activities as well.