Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
To use the ProcMan RestAPI for a process, the actions of that process must use the controller hos_ctr_all.php
The module m_jcl_copy can't be used. The module m_jcl_copy_auto must be used.
The module m_jcl_commit can't be used. The module m_jcl_commit_api must be used.
You must create a new specific process if you want to use the RestAPI. It is strictly not recommended to use normal processes by RestAPI. This will cause problems, because e.g. input validation is not available for the RestAPI. This means if you have a process JCL_NEW, you must create an additional process JCL_NEW_RESTAPI!
Important: If a process contains one of the following modules, the process activity can not be used by the ProcMan REST-API.
The following modules are currently not supported:
m_tws_ad_appl_from_task
m_tws_adhoc_appl_tws_upd
m_dsn_*
m_jcl_recovery (security reasons)
See all modules listed in REST-API Modules
To enable the ProcMan RestAPI, the hwm_universal_interface_config.php must be configured. This file can be found in "/etc/hwm_universal_interface_config.php". Please set the correct values for "url" and "cainfo" your installation.
The documentation can then be opened by https://<procmanurl>:<port>/hwm_rest_api.php
Also, please ensure that the process you want to use with the RestAPI is using the "hos_ctrl_all.php" command. See the screenshot below. If your process is using "hos_ctrl.php", you can simply use the newer "hos_ctrl_all.php" as this one is downwards compatible.
tbd.
To enhance the lifespan of the login token, edit the file "etc/hwm_rest_api_config.php" and adjust the "token_validity" (default 1 hour) and "max_token_validity" (default 3 hours).
Input data for the REST-API activity must be entered in JSON format in activity_input_data item of the JSON structure.The format of the data must always be like this:
Tasks are scanned from top to bottom and regular expressions and wildcards can be used in task names. The program merges options of all task blocks whose names match the current task name. it is similar to environment options.
If you want to set some value for all tasks then simply put it in a block with an asterisk as a task name.
Optional parameters are in green in the sample code. Currently there is only one optional parameter called restart_process. Normally you should not enter it. But if you do and set its value to true then the process is restarted from whatever state it currently is. The restart deletes all data created by the process from the database and archives. You can use this option for example if you get an error and wish to restart the process from the beginning instead of creating a new one. Please note that as this restart removes all data of the process then it should be used only in the first activity.
Alternatively to the GUI, the cURL command-line system utility (available on Linux, on Windows 10 version 1803 or later and on Windows Server 2019 or later) can be used to try out the REST API communication and functions. The command-line cURL calls have to look like this:
Instead of <instruction_parameters> in the command above, URL encoded parameters (param1=val1¶m2=val2&…) of a concrete REST API function have to be specified.
The parameter --insecure at the end of the command avoids that the execution ends with an error because the CA certificates are unknown, so the server certificate issuer cannot be verified. Alternatively, the CA certificates can be provided in the command in further parameters. For the full list of the parameters accepted by cURL, execute
from the command-line.
The first REST API function called has to be a login, which creates on success a new session and returns an authentication token for the session. The token has to be passed to every further REST API function in a parameter. At the end, the session can be closed by calling the function logout.
The following example makes a REST API login, calls two further REST API functions and closes the session. Beware, that the session authentication tokens are in the reality longer (128 characters) than in the example.
This module selects the environment used in the process and returns it via i_environment interface. When only one environment exists in your configuration then it is selected automatically and no input in interactive mode or via REST-API is needed. If more environments exist in your configuration then:
A prompt is displayed in the interactive mode and you must select the environment from a select box
An exact specification of the environment is required in JSON input object in REST-API mode
The ProcMan’s REST API provides a GUI, in which the currently implemented functions and the structure of the requests and responses are described. Moreover, the GUI provides the possibility to edit the requests, to test the execution of the REST API functions and to display the responses. The GUI can be started from the Browser using the URL:
https://<procman_dns>:<procman_port>/hwm_rest_api.php
Every module that supports REST-API is included in this section where the format of input JSON object is fully described.
This module shows files that are ready to be copied to the target libraries. The files originate from the previous activity (in 2 and more step processes) or are inserted directly in the approve module. The module started via REST-API is useful mainly in the second case. Files can be provided via input JSON object and imported to the process. It is also possible to continue in the process just after import is done or to interrupt it for later access in interactive mode. You can import JCL, PROC and SYSIN files via REST-API, as is illustrated by the following examples.
As interrupt element is specified and equals true then the process is interrupted after requested members are imported to the process by m_jcl_approve module. This allows you to open the process in interactive mode and check the result. The import element must be an object, which can contain these items:
Specifies what to do when an imported member already exists in the process (optional, the default value is "error"). Possible values are:
error - an error is written to the log and the module fails
skip - the member is not imported
overwrite - the existing member is overwritten.
contains masks of JCL members that are imported (optional)
contains masks of PROC members that are imported (optional)
contains masks of SYSIN members that are imported (optional)
The following example imports members from SYSH_ID system and P391D.HOS.TEST library matching OPC* mask. The members are imported as JCL objects. When a member that already exists in the process exists also in the library, it is skipped and the old one remains unchanged in the process.
In this example members matching the masks specified in jcl object are imported as JCL members. Procedures matching the mask in proc object are imported as PROC members and sysin files matching masks in sysin object are imported as SYSIN members. If any of the imported members already exists in the process then it is overwritten. When the module succeeds to import members then the next task automatically starts, as interrupt option equals false. If all the following tasks are silent (require no interaction) then the activity runs to its end (is set as Complete when finished).
You can import SYSIN members with any LRECL. The module recognizes LRECL of the dataset that contain imported SYSIN members and stores this information together with the member to the database.
jcl, proc and sysin objects must contain mask item, which must be an array of elements in SYS/DSN(MEM) format. The system must exist in configuration option in . DSN is a library where members are read from (wildcards are not allowed here). Members can contain wildcards. All members matching the specified masks are imported.
This module shows a list of filer that must be confirmed. In case of REST-API execution the list of confirmed members must be provided via the input JSON object.
If all members of the process are found in the list of confirmed members then the module ends successfully.
The format of the file name must be (exactly): SYSTEM/DSN(MEMBER).
In the following example OPCTEST1, OPCTEST2 and OPCTEST3 members from P391D.HOS.TEMP1 on SYSH_ID system are confirmed.
Confirms all members of the process. To do it set the value of confirm to 'all'.
This module performs checks of file uniqueness and their usage in parallel processes. When some of these checks fails then an error or a warning is shown, depending on the configured check severity. In the interactive mode the user if informed by a message printed on the screen. When just a warning is shown then the user can confirm the message and continue. This is not possible for errors, where the continuation is not allowed.
In REST-API mode no such page is visible. When an error is found then the process is always interrupted and the message can be seen in the report. When a warning is detected then stop_when_warning parameter configures what to do. In the following examples we suppose that m_jcl_check_parallel module is started by t0450 task.
In this case, the process is not interrupted when the check finds warnings because stop_when_warning=false. The process is interrupted only when the check finds errors.
In this case, the process is interrupted when the check finds any warning or error.
The "mapping" feature is not supported in this module when used by RestAPI!
In the interactive mode this module allows you to select files you want to add to your JCL/PROC/SYSIN process from the archive. When this process starts via REST-API then it is silent (not visible at all) and all the input must by provided via JSON object. In this case it is necessary to specify all information needed, which means: source system and library, target system and library, check system and members. Source files can be specified with wildcards in dataset/member names. Also versions can be specified, but they are optional and can't be used together with wildcards. When they are missing then the latest versions of selected files are used.It is also possible to optionally specify mapping using map_source_system, map_source_library, map_target_system and map_target_library. By default this mapping is not used.
As the interrupt parameter is specified and equals true then the process is interrupted after requested members are imported to the process by m_jcl_select_file_arc module. This allows you to open the process in interactive mode and check the result.
The import element must be an object, which must contain these items:
Specifies the system where members are checked (where SmartJCL runs). It must be one of systems defined in system_mapping array.
specifies members to be imported. Each of them is described by an object with target key:
The example imports all members matching OPC* member mask that exist in P391D.HOS.TEST library on SYSH_ID system.
The target and source libraries are equal (there is no mapping).
SmartJCL analysis runs on SYSH_ID system.
the process is interrupted after the members have been imported.
As the interrupt parameter is specified and equals true then the process is interrupted after requested members are imported to the process by m_jcl_select_file_arc module. This allows you to open the process in interactive mode and check the result.The import element must be an object, which must contain these items:
Specifies the system where members are checked (where SmartJCL runs). It must be one of systems defined in system_mapping array.
Specifies members to be imported. Each of them is described by an object with target key. The format of files (specified as an array of strings) is SYS/DSN(MEM) or SYS/DSN(MEM)/MainVersion.SubVersion when versions are explicitly specified.
The example imports the latest versions of TEST1 and TEST2 members and 3.1 version of TEST3 member from P391D.HOS.TEST library on SYSH_ID system.
The target and source libraries are equal (there is no mapping).
SmartJCL analysis runs on SYSH_ID system.
The process is interrupted after the members have been imported.
When the process config allows to process also deleted members then they can be imported into m_jcl_select_file_arc module when deleted=true is set. In this example two deleted members are loaded. The process immediately continues after successful import because interrupt=false is set:
When you specify any of map_source_system, map_source_library, map_target_system and map_target_library then the appropriate standard values (without map_ prefix) are replaced with mapped ones just before the module ends. This way you can select a file from a library but save it somewhere else. You can therefore copy a file instead of changing it.In this example the latest version of TEST1 and 3.1 version of TEST3 members from P391D.HOS.TEST library are loaded from the archive. The target location is not the same but is changed to P391D.COPY.JOBLIB.
In the interactive mode this module is used for displaying content of generated jobs, procedures and SYSIN members. It also allows checking of SmartJCL log files. In the REST-API mode this module ends automatically when no error was issued by SmartJCL generator and when the automatic interruption is not set. When there is an error then the process is always interrupted so that you can open it interactively and check the result. Let's suppose that t1000 task calls m_jcl_generate module in the following examples.
In this case, the process started via REST-API always interrupts in m_jcl_generate module as interrupt=true.
In this case, the process started via REST-API interrupts in m_jcl_generate module only when the JCL generator failed (its return code was greater than 4).
In the interactive mode this module allows you to select files you want to add to your JCL/PROC/SYSIN process. When this process starts via REST-API then it is silent (not visible at all) and all the input must by provided via JSON object. In this case it is necessary so specify all information needed, which means: source system and library, target system and library and check system. Source files can be specified with wildcards in dataset/member names.
As interrupt parameter is specified and equals true then the process is interrupted after requested members are imported to the process by m_jcl_select_file_sys module. This allows you to open the process in interactive mode and check the result. The import element must be an object, which must contain these items:
Specifies the system where members are checked (where SmartJCL runs). It must be one of systems defined in system_mapping array.
Specifies members to be imported. Each of them is described by an object with these options:
source: the files to import. It must be an array where each item has SYS/DSN(MEM) format. Wildcards are allowed in member names.
target: the target library where the file should be stored in SYS/DSN format.
The example imports all members matching OPC* member mask that exist in P391D.HOS.TEST library on SYSH_ID system.
The requested target location is P391D.HOS.JOBLIB on SYSH_ID system.
SmartJCL analysis runs on SYSH_ID system.
The process is interrupted after the members have been imported.
The example imports P391D.HOS.TEST(ABC) and P391D.HOS.TEST(DEF) members from SYSH_ID system.
The requested target location is P391D.HOS.JOBLIB on SYSH_ID system.
SmartJCL runs on SYSH_ID system.
Once members are imported, the next tasks start automatically because interrupt=false.
The example imports P391D.HOS.TEST(ABC) and P391D.HOS.TEST(DEF) and sets their target location to P391D.HOS.JOBLIB on SYSH_ID system.
The example imports P391D.HOS.TEST(MEM1) and P391D.HOS.TEST(MEM2) and sets their target location to P391D.HOS.JOBLIB2 on SYSH_ID system.
SmartJCL runs on SYSH_ID system.
Once members are imported the next tasks start automatically, because interrupt=false.
The example creates a new member, whose source lines are provided in the input JSON object in lines array.
CommentShare feedback on the editorthe requested target location is P391D.HOS.JOBLIB(NEWMEM) on SYSH_ID system.
CommentShare feedback on the editorSmartJCL runs on SYSH_ID system
In the interactive mode this module allows you to enter user data required for JCL statements. In REST-API mode your process in always automatically interrupted when this module is reached in case some user input is required. When no input is needed (i.e. when PRX rules set all fields or when no form is requested) then it is possible to set automatic confirmation and continuation with next tasks. This is controlled by the interrupt parameter. In the following examples we suppose that m_jcl_fillforms is started by t0700 task.
In this case the process started via REST-API always interrupts in m_jcl_fillforms module as interrupt=true. Such interrupted process can then be opened interactively and you can enter missing user fields and then continue.
In this case the process started via REST-API interrupts in m_jcl_fillforms module only when some user input is required (because interrupt=false). When all fields are properly set by PRX rules and their state is set to OK then no interruption occurs and the process automatically starts following tasks.
Editing member/dataset names is impossible in this module if used by REST-API!
The REST-API for this module can only be used to edit content.
In the interactive mode this module allows you to edit files provided in input interfaces. When the activity is started by REST-API then you can provide new content of selected members via the input JSON object.
As the interrupt parameter is specified and equals true then the process is interrupted after the new content of JOBA is set. It allows you to open it later in the interactive mode and check it.The change array contains all required changes in selected files. It must be an array of object, there each object must contain member and lines attributes.
The member is a member name that is searched for in input interfaces (i_file_list_sys, i_file_list_arc, i_file_list). When it is not found then en error is triggered.
lines is an array of strings, where each array element is a line of a member.
As interrupt parameter is missing the module starts another module in the sequence once it has finished.Two members are edited: JOBA and JOBB.
The message "The activity cannot be submitted" is returned by the REST API in the case that the requested activity (specified in the JSON structure by either the process ID and the action name or by the step ID) does not exist!
Please check the hwm_universal_interface_config.php and if the correct URL for the RestAPI is set there! It must be the system on which the RestAPI should create processes, submit activities etc.
Please check if in the actions the command hos_ctrl_all.php is set!
If the RestAPI returns the following message:
Then, most probably, there is an issue with the environment submitted in the data key.
In the following example, the source system in the "items" key was wrong. ENTW_ID is not correct, it must be ENTW_id because this is set in the hosts file to resolve the name to a system.
When calling scripts from Windows Task Scheduler -> In php.ini include_path = ‘.;[PATH]’ specify additional path to etc. directory and htdocs directory. directory and htdocs directory. This can be checked in a CLU with echo %path%.
Module for ADHOC record in IWSz process
The REST-API for this module can only be used to create or modify ADHOC records in IWSz process.
In the interactive mode, this module allows to create or modify ADHOC records and edit the operation list with JCL edit and JCL check.
Important: Currently, it is not possible to edit the operation list with JCL edit and JCL check by Rest-API!
In the most simple case it is possible to create ADHOC record where all parameters are adjusted using Procman process config and environment config.
The REST-API should only contain the instruction "CreateADHOC" for the task with m_tws_adhoc_appl module.
In case that the ADHOC record loads JCL from the z/OS request, you have to call the previous task m_jcl_select_file_sys (t0130 in the example below) with selection criteria.
In the following example, the member JOB1 from the library JOBLIB1 is loaded.
The request for ADHOC record can contain ADHOC parameters.
The parameters are placed in request to the adcom section inside inputAD node.
List of available parameters that can be used:
adowner: Owner ID
addesc: Text
adodesc: Owner Text
adprior: Priority
adgroup: Authority group id
adrjvtab: Variable table