Clients

Clients are the most general objects in ProcMan. Logically they can represent something in a real world, for example customers, organization units, etc. Technically, they are containers of other objects definitions and process instances (processes in the Work list). Clients in ProcMan are organized hierarchically. In the top of the clients hierarchy is always the client ROOT, which is the ancestor of all other clients. Each client can have any number of children clients. The client hierarchy in ProcMan can be arbitrarily deep. The definition of other objects like roles, user accounts and process definitions as well as assignments of roles to user accounts is being done in clients. Each definition of such objects and each role assignment in a client, are only visible and effective in the client itself and in its descendant clients. Process instances (processes in the plant list) that are assigned to a client are only visible in the respective client itself.

Clients list

Click Clients to start the client administration dialog. Beware that you can administrate in this dialog only descendants’ clients. Sample: you are logged in client ROOT then you can administrate the descendants of client ROOT.

After the dialog has been started, the list of already defined descendant clients of the logged in client is displayed (see picture below). If the current client has no descendants a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the client definition forms for new and edited clients, by selecting another function from the ProcMan menu. The last entries are discarded.

Creating a new client

A new client can be defined by clicking the New button in the clients list form. After that a form with the client definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new client is created and appears in the clients list. By clicking the Cancel button the dialog returns to the clients list without creating a new client.

The field Name has to be filled with the name of the new client. The name of the client can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent client of the new client has to be selected.

The field Description can be filled with a textual description of the new client. It is a free text, which can contain any printable characters. It also can be left empty.

With the field Calendar you assign a calendar to the client. The calendar specifies which days shall be handled as free days for this client (e.g. every Sunday, Christmas days, etc.). This can be relevant when the user makes date entries in the general process data. Calendars can be defined in the Calendar administration dialog. If the calendar which shall be used by the new client is not defined yet, this field can be left empty. It can be set later by editing the client or in the Calendar assignment administration dialog. If there is no calendar specified for the client then all days are handled as working days.

The check-box Allow to select this client on login specifies whether the users can select this client for to login in. Beware that this option is only a helper to reduce the list of clients displayed at the login time. If you disallow all clients where a user would normally be able to login, the effect of this option will be switched off and the user will be able to select from the complete list of clients in which he is authorized to login.

The check-box Enabled specifies whether the client can be used in ProcMan or not. If a client is not enabled, all its descendants’ clients are also disabled (even if they are set to be enabled).

Editing a client

Select a client from clients list form (checking the radio-button at the beginning of the table row) and click the Edit button. Alternatively a client definition can be edited also by clicking on the client name in the table of the clients list form. After that a form with the client definition fields appears. This form is the same like the form for a new client except, that the field Parent is read-only and cannot be changed.

Deleting a client

Select a client from clients list form (checking the radio-button at the beginning of the table row) and click the Delete button in the clients list form. Beware that this action also deletes all descendant clients and all processes for this clients. To avoid deleting clients by mistake only disabled clients can be deleted. An alternative to the deletion of a client is to disable the client.

Adding a client into the Transfer Case

Select a client from the client list form (checking the radio-button at the beginning of the table row) and click the Into Transfer Case button in the client list form. After the selected client has been added into the Transfer Case you can add another client or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

Accounts in ProcMan store information about users. They contain login information (user name and password) as well as additional optional information (description, e-mail, phone number, etc.) about the user.

Accounts can be defined in a way that ProcMan verifies the user name and password at login, or the database server verifies the user name and password at login, or they can be imported from an LDAP server, which also verifies the user name and password at login.

Beware that the user names are unique in the whole ProcMan system. There cannot be defined an account with some user name in one client and another account with the same user name in another client. If different accounts are meant then their user name must be unique. If the same account is meant then the best praxis is to define it in an ancestor client of all clients where it shall be used.

Initially, there is an account defined in the ProcMan, which is a master administrator (has assigned the role ADMIN in the client ROOT). Its user name is admin and its password is also admin. It is strongly recommended to change the password of this master administrator after the installation. Alternatively another master administrator can be defined and the admin account can be deleted then.

By clicking on the Accounts menu item the account administration dialog is being started. Beware that this dialog can only administrate the accounts defined in the client, in which the user starting it is currently logged in, and in the descendant clients of this client.

After the dialog has been started, the list of already defined accounts is displayed (see picture below). If there are no accounts a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the account definition forms for new and edited accounts, for changing password or in the LDAP import forms, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Roles

Roles are there to group individual user and to give them certain rights in ProcMan. Often defined roles are developer, tester, admin, approver, production planner etc.

Roles also manage the set of functions which can be started by a user. Such functions are for example administration, creating a process, or starting a specific process activity. Therefore each user must be assigned to minimum one role.

The roles in ProcMan are organized hierarchically. Any role can be a root role (with no parent roles) or a child role of another role. Any role can have an arbitrary count of children roles. The role hierarchy in ProcMan can be arbitrarily deep. The semantic of the role hierarchy is, that if a user has a role assigned, he is implicitly authorized also in all ancestor roles of the assigned role, but in no descendant role of the assigned role (except that a descendant role is assigned explicitly to the user).

However, the hierarchical organization of roles needs not to be used if there is no concrete need for it. In this case all roles can be defined without parent and children.

Beware that the role names are unique in the whole ProcMan system. There cannot be defined a role with some name in one client and another role with the same name in another client. If different roles are meant then their name must be unique. If the same role is meant then the best praxis is to define it in an ancestor client of all clients where it shall be used.

There is a special role initially named ADMIN defined in the client ROOT. This role allows the users to which it is assigned to administrate ProcMan and recall/delete processes in the work list (if administrators are authorized to do this). This role cannot be deleted or disabled, but the name and/or description of this role can be changed in the roles dialog.

Roles list

By clicking on the Roles menu item the role administration dialog is being started. Beware that this dialog can only administrate the roles defined in the client, in which the user is currently logged in, and in the descendant clients of this client.

After the dialog has been started, the list of already defined roles is displayed (see picture below). If there are no roles a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the role definition forms for new and edited roles, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new role

A new role can be defined by clicking the New button in the roles list form. After that a form with the role definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new role is created and appears in the roles list. By clicking the Cancel button the dialog returns to the roles list without creating a new role.

In the field Client the client in which the role will be created has to be selected.

The field Name has to be filled with the name of the new role. The name of the role can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent role of the new role has to be selected or it can be left empty.

The field Description can be filled with a textual description of the new role. It is a free text, which can contain any printable characters. It also can be left empty.

The check-box Process Administration, if checked, specifies that users to which the role is assigned can recall/delete processes in the work list (if administrators are authorized to do this), but they cannot administrate ProcMan (they do not even see the administration dialog menu).Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to administrate processes.

The check-box User Administration, if checked, specifies that users to which the role is assigned have limited administrator permissions, allowing them to administrate accounts, timezone assignments and role assignments. Users having this role will have an administration dialog menu, limited to this these functions. Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to administrate users.

The check-box Revision, if checked, enables for users to which the role is assigned a special menu item Revision – Deleted Processes. When the menu item is clicked by a user, a list of deleted processes is displayed to the user. The list is similar to the Deleted Processes tool for the administrators (described later in this documentation), except that the Delete button is missing. Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to view the deleted processes.

The check-box Enabled specifies whether the role can be used in ProcMan or not. If a role is not enabled it behaves like if the role would not be defined at all. Moreover if a role has descendant roles and it is not enabled, the descendants are disabled as well, even if they are set to be enabled.

Editing a role

A role definition can be edited by selecting it in the roles list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the roles list form. Alternatively a role definition can be edited also by clicking on the role name in the table of the roles list form. After that a form with the role definition fields appears. This form is the same like the form for a new role except, that the fields Client and Parent are read-only and cannot be changed.

Deleting roles

One or more roles can be deleted by selecting them in the roles list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the roles list form. Beware that with the roles also all descendant roles are deleted. An alternative to the delete of a role is to disable it. In this case neither the role, nor its descendant roles are deleted.

Adding roles into the Transfer Case

Select one or more roles from the roles list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the roles list form. After the selected roles have been added into the Transfer Case you can add another roles or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

A new account can be defined by clicking the New button in the accounts list form. After that a form with the account definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new account is created and appears in the accounts list. By clicking the Cancel button the dialog returns to the accounts list without creating a new account.

In the field Client the client in which the account shall be defined has to be selected.

The field Name has to be filled with the user name, which is used to login into ProcMan. The user name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored.

The check-box Case sensitive specifies whether the name shall be handled as case sensitive or insensitive. If it is checked the name will always to be typed exactly like in this form at login. Otherwise any alphabetic letter in the user name can be typed as a capital or a small letter at login.

In the field Description the new account can be described. If the account is related to a real person, its full name can be typed here. If it is a special account, for example an administrator or a technical user, it can be described what the account is good for here. This field can also be left empty.

In the field z/OS Login a previously defined authentication z/OS system can be selected. (How to configure authentication z/OS systems is described in later chapters). If a system is selected no password is required to be specified for the user in this dialog.

The check-box Database Login specifies whether the user name and password specified at login shall be verified by the database server. If it is checked no password is required to be specified for the user in this dialog.

The fields Password and Repeat Password have to be filled with the initial password of the user. Both must not be empty and must contain the same text.

In the field Timezone the timezone of the user can be selected. This information is being used in ProcMan to display timestamps in the proper timezone of the user. This field can also be left empty. In this case the timezone of the ProcMan server is being used for the account. Alternatively the timezones can be assigned to accounts also in the Timezone assignment administration dialog.

In the field Company the company of the user can be filled. It can also be left empty.

In the field Department the department of the user can be filled. It can also be left empty.

In the field Telephone the phone number of the user can be filled. It can also be left empty.

In the field Mobile the mobile-phone number of the user can be filled. It can also be left empty.

In the field E-mail the e-mail address of the user can be filled. It can also be left empty. If the field is filled and ProcMan is configured to sending e-mails via an SMTP server (see the documentation ProcMan – Install and Customize), generated messages will be sent to this e-mail address depending on settings done in the Processes administration dialogs.

The check-box Enabled specifies whether the account can be used in ProcMan or not. If an account is not enabled it behaves like if it would not be defined at all.

In the section Additional Recipients can be specified who else shall be notified by an email when a notification email is sent to the user. The recipients can be specified by entering email addresses and/or by entering process parameter names from which email addresses shall be read and/or by selecting roles from the list of roles (to specifiy that all users having the selected role in the current client context shall be recipients) and/or by selecting users from the list of users in this section.

Alternatively to creating the accounts in the ProcMan, accounts can also be imported from an LDAP server. For such accounts the user name and password are verified by the LDAP server instead of by ProcMan at login.

ProcMan supports also importing accounts from more than one LDAP servers. In this case for each account are the user name and password verified by the LDAP server from which the account has been imported.

LDAP import form

Accounts can be imported from LDAP servers by clicking the LDAP button in the accounts list form. After that a LDAP Import form appears (see picture below).

Beware that the object structure on the LDAP server strongly depends on the type of the server (RACF, Active Directory, OpenLDAP etc.) and on the organization structure of the company mirrored in the object structure on the LDAP server. Therefore the proper filling of this form must be done hand-in-hand with the administrator of the LDAP server, which should know the proper distinguished name (shortly dn) and the object class of the account objects in LDAP as well as the names of the from the LDAP server returned attributes.

After filling the fields in this form and clicking the OK button the dialog lists all users found on the LDAP server matching the specified criteria in the LDAP import – User selection form. By clicking the Cancel button the dialog returns to the accounts list.

If the accounts shall be imported from a LDAP server from which an successful import already has been done before, by clicking the Use known LDAP button and selecting the LDAP server from the list on the following form, the LDAP import form will be filled with the values used before without a need to type them again.

The field LDAP host has to be filled with the IP address or the DNS name of the LDAP server. Alternatively the LDAP server can be specified in the URL format ldap[s]://<host>[:<port>] here (e.g. ldaps://ldap.my_company.com:390). For encrypted secure LDAP connection the LDAP server can be specified only in the URL format with ldaps as service.

The field LDAP port has to be filled with the port number of the LDAP service on the LDAP server. In the case that the LDAP server have been specified in the URL format in the field LDAP host, the port number specified here is ignored.

The field Bind password has to be filled with the password of the user specified in the Bind dn field. Beware that this password is used only for one LDAP import. It is nowhere stored in ProcMan. So it has to be typed for every new import again and again, even if the form has been filled using a known LDAP.

The field Search dn has to be filled with the distinguished name identifying where to search for the user objects in the object structure on the LDAP server.

The field User dn identifier has to be filled with the name of the attribute in which the LDAP server returns the user distinguished names after applying Search dn and Filter.

The field User identifier has to be filled with the name of the attribute in which the LDAP server returns the user name after applying search for a particular user distinguished name.

The check-box User names are case sensitive specifies whether the imported user names shall be handled as case sensitive or insensitive. If it is checked the names will always to be typed exactly like they have been imported from the LDAP server at login. Otherwise any alphabetic letter in the user names can be typed as a capital or a small letter at login.

The field Show only users matching filter has to be filled with a pattern string specifying, that the user name of the users returned by the LDAP server must match this pattern to be shown in the users list in the following LDAP import – User selection form. The pattern string can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the user names, they must be escaped with a backslash (\ ) like this: \* ,\? Also if backslash is meant as a character appearing in the user names it must be escaped like this: \\.

In the field Description identifier the name of the attribute in which the LDAP server returns the user description can be filled. This field can be left empty but no user description will be imported in this case.

In the field Company identifier the name of the attribute in which the LDAP server returns the name of the company can be filled. This field can be left empty but no company will be imported in this case.

In the field Telephone identifier the name of the attribute in which the LDAP server returns the phone number of the user can be filled. This field can be left empty but no phone number will be imported in this case.

In the field Mobile identifier the name of the attribute in which the LDAP server returns the mobile-phone number of the user can be filled. This field can be left empty but no mobile-phone number will be imported in this case.

In the field E-mail identifier the name of the attribute in which the LDAP server returns the E-mail address of the user can be filled. This field can be left empty but no E-mail address will be imported in this case.

The check-box Users are allowed to change their passwords specifies whether the users authenticated by the LDAP server can change their passwords or not.

In the selection-box LDAP server/backend type the type of the LDAP server/backend has to be selected. It is displayed only if the check-box Users are allowed to change their passwords is checked. Currently only RACF or other can be selected here. To select a proper type here is important because changing of a password via LDAP works different for RACF and for other LDAP servers/backends.

In the field Password identifier the name of the password attribute in the LDAP structure for a user has to be specified. It is displayed only if the check-box Users are allowed to change their passwords is checked and if the type other is selected in the selection-box LDAP server/backend type. In this case a non-empty attribute name has to be specified here.

LDAP import – User selection form

After filling the fields in the LDAP import form and clicking the OK button the dialog lists all users found on the LDAP server matching the specified criteria in the LDAP import – User selection form (see picture below).

By clicking the Cancel button the dialog returns to the accounts list without importing any new accounts.

In the field Client select the client in which the accounts shall be imported.

The users which have been found on the LDAP server are listed in a table. Users which shall be imported can be selected by checking the check-box in the first column of the table rows. Users which are not selected are ignored by the import. At the opening of this form only users which are unknown in ProcMan (they have no accounts yet) are selected. However the initial selection of the users can be freely changed. If a user which is already known in ProcMan is selected, the import will actualize the account from LDAP (replace the description, company, e-mail etc. with the current one).

By clicking the OK button the import is started and for the selected users the ProcMan accounts are being created or actualized in the specified client. After the import has been finished the dialog returns to the accounts list.

Known LDAPs form

After clicking the Use known LDAP button in the LDAP import form the dialog opens the Known LDAPs form (see picture below).

By clicking the Cancel button the dialog returns to the LDAP import form.

When a LDAP system is selected by checking the check-box in the first column of the row of the LDAP system and clicking the OK button the dialog returns to the LDAP import form and fills it with the values stored for the selected LDAP system. Alternatively to click on the IP address / DNS name of the host in the table of known LDAPs has the same effect.

This form also allows to delete LDAP systems from the table of known LDAPs by selecting on or more LDAP systems and clicking the Delete button. Only LDAP systems which are currently not in use by any account in ProcMan can be deleted.

Authentication by a z/OS system is an alternative way to verify the user and password on login in ProcMan. By this method, the user and password are sent to and verified on the z/OS system using HORIZONT z/OS utilities.

z/OS system configuration list

z/OS system configurations can be managed in the dialog started by clicking the z/OS button in the accounts list form. After that a list of already configured z/OS systems is displayed (see picture below).

By clicking the Cancel button the dialog returns to the accounts list.

Creating a new z/OS system configuration

A new z/OS system configuration can be defined by clicking the New button in the accounts list form. After that, a form with the z/OS system configuration definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new configuration is created and appears in the z/OS system configuration list. By clicking the Cancel button the dialog returns to the z/OS system configuration list without creating a new configuration.

The field Name has to be filled with a unique name of the configuration. The name of the configuration can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form, the name is converted into uppercase. The name can be selected in the z/OS Login field of the account form or in the change password form to specify, that this configuration shall be used for the authentication of the account.

The field Server (IP or DNS) has to be filled with the IP address or the DNS name of the z/OS system.

The field Port has to be filled with the port on which the HORIZONT z/OS utilities service (also known as HORJLST) on the z/OS system is waiting for connections.

The field Member has to be filled with the member name of the HORIZONT z/OS utilities handler (also known as HORJSRV) on the z/OS system. After submitting the form, the name is converted into uppercase.

Editing a z/OS system configuration

A z/OS system configuration definition can be edited by selecting it in the z/OS system configuration list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the configuration list form. Alternatively a configuration definition can be edited also by clicking on the configuration name in the table of the z/OS system configuration list form. After that a form with the z/OS system configuration definition fields appears. This form has the same input fields like the form for a new configuration definition.

Creating a copy of a z/OS system configuration

An z/OS system configuration definition can be copied by selecting it in the z/OS system configuration list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the configuration list form. After that the form for a new configuration, prefilled with the values of the selected configuration appears. Before saving the configuration definition at least the name of the configuration has to be changed.

Deleting z/OS system configurations

One or more z/OS system configurations can be deleted by selecting them in the z/OS system configuration list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the configuration list form.

An account definition can be edited by selecting it in the accounts list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the accounts list form. Alternatively an account definition can be edited also by clicking on the account name in the table of the accounts list form. After that a form with the account definition fields appears. This form is the same like the form for a new account except, that the fields Client, Name and the Case sensitive check-box are read-only and cannot be changed and the fields Password and Repeat Password are missing.

This form can be used for editing of accounts verified by ProcMan as well as those verified by a LDAP server at login.

One or more accounts can be deleted by selecting them in the accounts list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the accounts list form. An alternative to the delete of an account is to disable it.

Beware that the password changing dialog cannot be started for LDAP authenticated accounts.

Beside that the password of a user can be changed in this dialog, it allows also to switch among the ProcMan, the z/OS and the database server authentication methods.

A password can be changed for an account by selecting it in the accounts list form (checking the check-box at the beginning of the table row) and clicking the Password button in the accounts list form. After that a form for changing of the password appears (see picture below).

By clicking the Cancel button, the dialog returns to the accounts list without changing the password.

By clicking the OK button the dialog changes the password for the previously selected user and returns to the accounts list.

The read-only field Name informs about the user name of the account for which the password or authentication method shall be changed.

The check-box Database Login specifies whether the user name and password specified at login shall be verified by the database server. If it is checked, no password is required to be specified for the user in this dialog.

The fields Password and Repeat Password have to be filled with the new password of the user. Both must not be empty and must contain the same text.

Timezones assignment to accounts is used in ProcMan to display timestamps in the proper timezone of the users. If no timezone is assigned to an account the ProcMan server timezone is being used.

Alternatively to the timezone assignment dialog the timezones can also be set in the account definition of every single user.

By clicking on the Timezone assignment menu item the timezone assignment administration dialog is being started (see picture below).

This dialog can be left by clicking the Cancel button. It can also be left at any time by selecting another function from the ProcMan menu.

By clicking the OK button the timezone selected in the field Timezone is assigned to the selected accounts in the Users table (the check-box at the beginning of the table row is checked).

A user can have different roles in different clients. The role assignment is used in ProcMan to specify which roles a user has in which clients. A user must have at least one role in one client assigned to be able to login in ProcMan.

The role assignment dialog in ProcMan can work in two modes: ‘assigning users to a role’ or ‘assigning roles to a user’. Both modes lead to the same results.

By clicking on the Role assignment menu item the role assignment administration dialog is being started. After the dialog has been started, the list of roles which can be assigned to users in the current client and its descendant clients is displayed (see picture below).

The mode of the dialog can be changed by selecting Assign roles to a user in the selection field above the list. The list of roles changes into the list of users which can be assigned to roles in the current client and its descendant clients (see picture below) in this case.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the following forms for assigning users to a role or for assigning roles to a user, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

If the mode Assign users to a role is selected and a role is selected (the radio-button at the beginning of a row in the roles list table is checked), by clicking the OK button the users assignment form is started (see picture below). Alternatively a clicking on the role name in the roles list table has the same effect.

By clicking the Cancel button the dialog returns to the roles list form discarding all changes.

In the field Client the client has to be selected in which the assignment shall be done.

In the Users table users has to be selected (by checking the check-box at the beginning of the rows) which shall be assigned to the previously selected role in the specified client. In the Users table some check-boxes can be checked and read-only which means that the users are already assigned to the role in an ancestor client of the specified client and thus this assignment is inherited and effective also in the specified client.

After the assignment in one client has been done, another client can be selected in the field Client and users can be selected for assignment to the role and so on. The dialog remembers assignments in all selected clients which have been done.

By clicking the OK button all the assignments are saved and the dialog returns to the roles list form.

Calendars are global objects in ProcMan, which means that they are not defined in clients or other objects.

Calendars in ProcMan are dedicated to specify free days (Saturdays, Sundays, New Year’s Day, etc.). They are used for selection and checking of process entry date, time and timestamp values, which are foreseen to contain only values referring to working days.

Calendars are in ProcMan organized hierarchically. Any calendar can be a root calendar (with no parent calendar) or a child calendar of another calendar. Any calendar can have an arbitrary count of children calendars. The hierarchy of calendars can be arbitrarily deep. If a calendar has a parent calendar it inherits free day definitions from all its ancestor calendars.

Calendars list

By clicking on the Calendars menu item the calendar administration dialog is being started.

After the dialog has been started, the list of already defined calendars is displayed (see picture below). If there are no calendars a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the calendar definition forms for new and edited calendars, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new calendar

A new calendar can be defined by clicking the New button in the calendars list form. After that a form with the calendar definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new calendar is created and appears in the calendars list. By clicking the Cancel button the dialog returns to the calendars list without creating a new calendar.

The field Name has to be filled with the name of the new calendar. The name of the calendar can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent calendar of the new calendar has to be selected or it can be left empty.

The field Description can be filled with a textual description of the new calendar. It is a free text, which can contain any printable characters. It also can be left empty.

In the field Regular free days the days which are considered to be free days every week can be selected. By checking check-boxes in the Free day column can be specified which week days shall be handled as free days. By checking check-boxes in the Allow selection column can be specified which free days shall be handled as work days (ProcMan allows a special handling of such week days, e.g. to show a warning in the case that such day has been selected).

The Merge with parent regular free days check-box appears only in the case that the new calendar has a parent calendar specified. If the check-box is checked the fee days settings inherited from the ancestor calendars and shown in the additional columns Free day from Parent and Allow selection from Parent are used in the new calendar without a need to do them for the new calendar again. However there can be selected further days in addition to the inherited days in the field Regular free days in the new calendar. If the check-box is not checked only days selected in the field Regular free days will be used by the new calendar.

In the table Other free days you can define days which are considered as free days and associated to a special date. If the new calendar has specified a parent calendar the free days inherited from the ancestor calendars are displayed at the beginning of the table as read-only rows. The date to which the free day is associated has to be filled in the Date column. The filled value has to contain at least the day and the month, optionally also the year. If the year is required but not specified the current system year is filled in by ProcMan.

The date field accepts different date formats e.g. YYYY-MM-DD, DD.MM.YYYY or MM/DD/YYYY. For the date selection the picker (button with question mark) right of the date-edit field can be used. In the field in the column Description a description of the free day can be typed. If the check-box in the Every year column is checked it means that the entered date made of the day and the month is a free day every year. In this case the year needs not to be specified in the date field as it is ignored anyway. If the specified free day is/was an every year free day only in some period, the years when it started to be a free day and/or the year when it finished to be a free day can be specified by selecting the years in the Since year and Until year columns. The check-box in the Allow selection column specifies when checked that the date can be used as a working day even though it is a free day. The buttons New and Delete below the table can be used to create new rows in the table or delete rows selected by checking the check-box at the beginning of the table rows.

Editing a calendar

A calendar definition can be edited by selecting it in the calendars list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the calendars list form. Alternatively a calendar definition can be edited also by clicking on the calendar name in the table of the calendars list form. After that a form with the calendar definition fields appears. This form is the same like the form for a new calendar.

Deleting calendars

One or more calendars can be deleted by selecting them in the calendars list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the calendars list form. Beware that with the calendars also all descendant calendars are deleted.

Adding calendars into the Transfer Case

Select one or more calendars from the calendars list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the calendars list form. After the selected calendars have been added into the Transfer Case you can add another calendars or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

If the mode Assign roles to a user is selected and a user is selected (the radio-button at the beginning of a row in the users list table is checked), by clicking the OK button the roles assignment form is started (see picture below). Alternatively a clicking on the user name in the user’s list table has the same effect.

By clicking the Cancel button the dialog returns to the users list form discarding all changes.

In the field Client the client has to be selected in which the assignment shall be done.

In the Roles table roles has to be selected (by checking the check-box at the beginning of the rows) which shall be assigned to the previously selected user in the specified client. In the Roles table some check-boxes can be checked and read-only which means that the roles are already assigned to the user in an ancestor client of the specified client and thus this assignment is inherited and effective also in the specified client.

After the assignment in one client has been done, another client can be selected in the field Client and roles can be selected for assignment to the user and so on. The dialog remembers assignments in all selected clients which have been done.

By clicking the OK button all the assignments are saved and the dialog returns to the users list form.

The search function in the work list (or any other filter list) returns processes containing a specified text in selected search areas (e.g. description, memo, JCL member name, etc.). The selection of the search areas allows the user to specify more precisely for what shall be searched and it avoids a lot of trash (uninteresting processes) returned by the search function. The classification of process data into the search areas is realized by the definition of the search areas and their association with the input fields of the process forms. Values filled in such input fields are stored (after submission of the forms) in a way, that the search function knows in which stored values it shall search for the specified text depending on the selected search areas.

There is no need to define search areas for all process data. Useful searches are for: object name, JCL account parameter etc. See also filter functions.

The association between search areas and input fields in process forms can be done for common process forms in the Global definitions and Process definitions dialogs. If the process forms are generated by proprietary php scripts the association can be done by using ProcMan API functions defined in the httpd/htdocs/hwm_api.php script in the ProcMan installation directory. The API functions are documented in the script itself, but this way to build the associations is dedicated only for advanced php developers.

The search areas in ProcMan can be organized in a hierarchy of search area groups. This allows clustering of search areas which logically belong together and provides the user with a possibility to select/deselect a whole group of search areas in the work list search function by one click. Any group can be a root group (has no parents) or a child group of another group. Any group can contain an arbitrary count of search areas and/or child groups. The search area group hierarchy can be arbitrarily deep.

Search area list

By clicking on the Search areas menu item the search area administration dialog is being started.

After the dialog has been started, the list of already defined search areas and groups is displayed (see picture below). If there are no search areas and/or groups defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the search area definition forms for new and edited search areas, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

To achieve that processes of a client can use a calendar for selecting and checking their date, time and timestamp values for using only working days, the calendar has to be assigned to the client. A calendar can be assigned to as many clients as needed. To a client only one calendar can be assigned. If no calendar is assigned to a client there are all dates handled as working days.

Alternatively to the calendar assignment dialog a calendar can be assigned to a client also in the client definition.

Calendar assignment

By clicking on the Calendar assignment menu item the calendar assignment administration dialog is being started.

After the dialog has been started, the list of already defined calendars is displayed (see picture below). If there are no calendars defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the following calendar to clients assignment form, by selecting another function from the ProcMan menu. If this happens in the following form the last changes done in the form are discarded.

Calendar to clients assignment

A calendar assignment can be started by selecting it in the calendars list form (checking the radio-button at the beginning of the table row) and clicking the OK button in the calendars list form. Alternatively a calendar assignment can be started also by clicking on the calendar name in the table of the calendars list form. After that a form with the clients list appears (see picture below).

By clicking the Cancel button the dialog returns to the calendars list form discarding all changes.

In the Clients table clients can be selected (by checking the check-box at the beginning of each client row) to which the previously selected calendar shall be assigned.

By clicking the OK button the assignment is saved and the dialog returns to the calendars list form.

Actions list

By clicking on the Actions menu item the actions administration dialog is being started.

After the dialog has been started, the list of already defined actions is displayed (see picture below). If there are no actions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the action definition forms for new and edited actions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new action

A new action can be defined by clicking the New button in the actions list form. After that a form with the action definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new action is created and appears in the actions list. By clicking the Cancel button the dialog returns to the actions list without creating a new action.

In the field Client the client in which the action will be created has to be selected.

The field Name has to be filled with the name of the new action. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new action. It is a free text, which can contain any printable characters. It also can be left empty.

The field Command has to be filled with the command which shall be executed by the action. Currently only php scripts in the ProcMan installation directory on the ProcMan server can be used as executable commands.

In Command parameters parameters of the command can be specified by their names and values, if any needed.

In the field Role a role can be selected to specify that the action can only be started by users having assigned the selected role.

The check-box Enabled specifies whether the action can be used in ProcMan or not. If an action is not enabled it behaves like if it would not be defined at all.

Editing an action

An action definition can be edited by selecting it in the actions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the actions list form. Alternatively an action definition can be edited also by clicking on the name in the table of the actions list form. After that a form with the action definition fields appears. This form is the same like the form for a new action except, that the field Client is read-only and cannot be changed.

Copying an action

An existing action can be used as a base for a new one by selecting it in the actions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the actions list form. After that the form for a new action prefilled with the settings from the selected action appears. Beware that at least the action name must be changed before the new action can be created.

Deleting actions

One or more actions can be deleted by selecting them in the actions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the actions list form. Beware that only actions which are not in use by process definitions can be deleted. An alternative to the delete of an action is to disable it.

Adding actions into the Transfer Case

Process definitions can be seen as types of processes handled by ProcMan. Every process in ProcMan must be started as an instance of a process definition. A process definition contains settings necessary for the life cycle of processes using it, like user parameters which have to be specified when starting a process, definition of activities, dependencies among the activities, etc.

Each process definition must use a global definition. Settings stored in a global definition are shared by all process definitions using it, which means that they take effect in all processes of all process definitions using the global definition. Settings special for a kind of processes are stored in the process definition, which means that they take effect only for processes using the process definition.

Process definitions list

By clicking on the Process definitions menu item the process definitions administration dialog is being started.

After the dialog has been started, the list of already defined process definitions is displayed (see picture below). If there are no process definitions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the process definition forms for new and edited process definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new process definition

A new process definition can be defined by clicking the New button in the process definitions list form. After that a form with the process definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new process definition is created and appears in the process definitions list. By clicking the Cancel button the dialog returns to the process definitions list without creating a new process definition.

In the field Client the client in which the process definition will be created has to be selected.

In the field Global definition the global definition used by the process definition has to be selected.

The field Name has to be filled with the name of the new process definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new process definition. It is a free text, which can contain any printable characters. It also can be left empty.

In the field Role of process creator the role has to be selected, which a user must have assigned, to be able to create processes of this process definition.

In the field Role with permission to read reports a role can be selected, which allows users having this role, to access the process reports of processes of this process definition, even if they are not permitted to change anything in the processes and/or their activities.

The check-box Allow creation of new processes specifies whether new process instances of this process definition can be created. If it is unchecked, users still can proceed with they work in existing processes of this definition in the work list (submit, interrupt, reject, complete, etc. activities of the processes), but no new processes of this definition can be created.

The check-box Enabled specifies whether the process definition can be used in ProcMan or not. If a process definition is not enabled it behaves like if it would not be defined at all.

Further fields are organized in sections. Each section can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the section title.

Process definition specific process parameters

In this section process parameters can be defined for all processes using this process definition. The values of these parameters can be filled by users in the dialog for process creation, in dialogs of process activities or evaluated and set by the process activities without user interaction. In opposite to parameters defined in the global definitions parameters defined in process definitions are not displayed in the work list.

Moreover based on the parameter definitions in this section the process creation dialog is generated for processes using this process definition. The generated dialog provides users with entry fields for setting values of the process parameters. The look of these entry fields has also to be defined here.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Global definition specific process parameters in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Global definition specific process parameters for more information.

If the check-box in the field Include process parameters from the global definition is checked (which is the default), the parameters defined in the global definition used by this process definition are used for the generation of the process creation dialog. In this case the global definition parameters are also displayed in the table of parameters in this section. If the check-box is not checked the global definition parameters are ignored when the process creation dialog is generated and they are not displayed in the table of parameters in this section.

In the rows for the general and global definition parameters in the parameters table there is a Change or a Global button at the end of each row. By clicking the Change button the button description changes to Global and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become active. This allows changing the behavior and the look of the parameter fields in generated dialogs, inherited from the global definition, for processes of this process definition. By clicking a Global button the button description changes to Change and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become read-only. In this case the changes (if any) done in the process definition for the parameter are ignored and the behavior and the look of the parameter fields in generated dialogs inherited from the global definition will be used.

Attachment of files

In this section can be specified whether external files (e.g. pdf, doc, ppt, etc.) can be attached to processes using this process definition.

The fields of this section can be edited when the section is open (see picture below).

If the check-box in the field Get the attachment settings from the global definition is checked it depends on the settings in the global definition whether it will be allowed to attach external files to processes using this process definition or not (for the global definition this property is set in the Attachment of files section in the Global definitions administration dialog). If the check-box is checked the check-box in the field Allow attachment of files is read-only and depending on what is set in the global definition it is checked or not. Otherwise the setting inherited from the global definition can be changed in this process definition.

If the check-box in the field Allow attachment of files is checked it will be allowed to attach external files to processes using this process definition.

Status of activities

In this section can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).

The definitions done in this section are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) mappings of control codes to activity statuses here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is that the settings inherited from the global definition are displayd here in read-only modus for information. Please refer to the description of Status of activities of global definitions for more information.

Sending of messages

In this section can be specified in which cases e-mail messages shall be sent to which users. Sending of messages in two situations can be defined here: when the status of a process of this process definition has been changed and when the status of an activity of a process of this process definition has been changed.

The definitions done in this section for sending messages when the status of activities has been changed are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) message sending rules here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.

Beware that e-mails can be sent only if an SMTP server has been configured after the ProcMan installation (please refer to the ProcMan installation and customize guide for more information). Moreover e-mails can only be sent to users which have an e-mail address specified in their accounts.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Sending of messages in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Sending of messages of global definitions for more information.

The tables with message sending definitions for both parts: when processes change their status and when activities change their status contain message sending definitions inherited from the global definition displayed as readonly rows.

If the check-box in the field Include message sending from the global definition is checked, the message sending definitions for messages sent when processes change their status are inherited from the global definition and displayed in the table as readonly rows. If the check-box is not checked the message definitions from the global definition are neither inherited nor displayed. Beware that the checking or not of this check-box has no effect on the definitions of messages sent when activities change their status which are always inherited from the global definition.

Process Activities

In this section the activities of the process definition, the dependencies among them and other settings relevant to process activities has to be defined. An activity is associated with exactly one action which is executed when the activity is started from the work list. The ProcMan controls whether an activity can be started depending on fulfillment of its preconditions. Moreover ProcMan manages who is authorized to start an activity dependent on the role associated with it.

The fields of this section can be edited when the section is open (see picture below).

The activitiy definitions are displayed as a table where each row represents one activity. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity. The name can be eight characters long and can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase. The activity id must be unique in the scope of one process definition but the same ids can be used in different process definitions.

If the check-box in the field OR Precondition is checked this activity becomes active (status Ready) if at least in one of the dependencies between the predecessor activities and this activity the dependency condition is fulfilled. If the check-box is not checked in all the dependencies between the predecessor activities and this activity the dependency conditions must be fulfilled before this activity becomes active.

If the check-box in the field Start Activity is checked the activity of a process becomes the status Ready and can be started immediately after the process has been created.

If the check-box in the field End Activity is checked the activity will be an end activity. A process becomes the status Complete only if all the end activities of the process have the status Complete.

In the field Role the role which is authorized to start this activity can be selected. If a role is selected here then this role is authorized to start the activity. If it is empty the role specified in the action definition of the action selected in the Action Id field is authorized to start the activity.

In the field Action Id the action has to be selected which shall be executed by the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

In the field Report Action Id the action has to be selected which shall be executed when the report function of the work list is called for the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

If the check-box in the field Include status setting from the global definition is checked the settings done in the Status of activities section of the global definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include status setting from the process definition is checked the settings done in the Status of activities section of the process definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include message sending from the global definition is checked the settings done in the Sending of messages section of the global definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include message sending from the process definition is checked the settings done in the Sending of messages section of the process definition are used for this activity. Otherwise they are not used.

Further fields are organized in subsections. Each subsection can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the subsection title.

Autocomplete of activities

In this subsection can be specified, that some activities can be completed automatically, without calling the associated action.

The fields of this subsection can be edited when the subsection is open (see picture below).

The autocomplete entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be autocompleted.

The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autocompleted, otherwise it is handled as a manual activity and must be started from the work list by a user with the appropriate role. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).

The field Control Code has to be filled with the control code which shall be set when the condition is fulfilled and the activity is being autocompleted. In this case the status of the activity is set depending on the Status of activities settings set in the global definition, process definition and/or activities of the process definition.

In the case on the screenshot above the activity TEST is being autocompleted, if the value of the process parameter TICKET.AC is '1', otherwise it is a manual activity. The value of the process parameter can be set in the process creation dialog and/or in the activity DEV.

There can be specified more entries for one activity in this section. In this case the first entry for which the condition is fulfilled is used for setting the control code and status of the activity when the autocomplete expressions are evaluated.

Autoexecute of activities

In this subsection can be specified, that the actions of some activities can be executed automatically, without a need to manually submitting them from the work list.

The fields of this subsection can be edited when the subsection is open (see picture below).

The autoexecute entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be autoexecuted.

The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready or Interrupted or Recalled. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autoexecuted, otherwise it is waiting for the fulfillment of the condition, without changing its status. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).

Activities defined in this way can however be submitted also manually from the work list. A special dialog appears in this case. It allows a manual emergency execution or rejection of the automatic action.

Beware, that the actions of such activities can only be autoexecuted, when the Automaton background process (service) is running and properly configured for the autoexecution.

Beware, that not any defined action can be specified in process activities for autoexecutions. The command called by the action must be implemented and configured in a way, so that it supports the autoexecution.

Status of activities

In this subsection can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).

If there has been specified for an activity that the status settings from the global and/or process definition are to be included, the settings done in the Status of activities section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the action called by the activity can return also control codes not specified in the global and/or process definition or if a different activity status shall be set for a control code than specified in the global and/or process definition a new specification must be done here. If no status settings are included from the global and/or process definition for an activity, mapping of all possible control codes returned by the action called by the activity to the activity statuses has to be done here.

The fields of this subsection can be edited when the subsection is open (see picture below).

The structure of this subsection is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Status of activities of global definitions for more information.

Dependencies

In this subsection dependencies for defined activities can be created. A dependency is a relation between two activities where one of them is a predecessor and the other is a successor. There is a condition assigned to each dependency. After the action started by the predecessor activity ends, the control code returned by the action is checked against the condition of the dependency. If the control code matches the condition, the dependency is fulfilled. If all dependencies (for OR preconditions at least one of the dependencies) between predecessor activities and a successor activity are fulfilled, the precondition of the successor activity is fulfilled and the successor activity becomes active (status Ready).

There can also be defined special GOTO dependencies among activities in ProcMan. Such dependencies are ignored in the precondition check of successor activities. If a GOTO dependency is defined between a predecessor and a successor activity and the action started by the predecessor activity returned a control code matching the condition of the dependency, no precondition check takes place for the successor activity and the successor activity becomes active (status Ready).

The fields of this subsection can be edited when the subsection is open (see picture below).

The dependencies are displayed as a table where each row represents one dependency. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be the predecessor of the dependency.

The field Successor Activity Id has to be filled with the name of the activity which shall be the successor of the dependency.

If the check-box in the field GOTO (no precondition check) is checked the dependency is set to be a GOTO dependency (described above).

In the field Condition the operator has to be selected which shall be applied to compare the control code returned by an action started by the predecessor activity with the parameters of the condition.

In the fields Condition Parameter 1 and Condition Parameter 2 the parameters of the condition operator has to be specified. Two parameters are used only for operators testing whether the control code returned by an action is within or without a range. By other operators the second parameter is ignored. By the operators Anyway and Otherwise also the first parameter is ignored. If the operator Anyway is set, any control code matches the dependency condition and the dependency becomes always fulfilled. If the operator Otherwise is set, no control code matches the dependency condition and the dependency never becomes fulfilled, which makes sense in some cases when for the successor activity the OR precondition is set. Beware that the parameters are handled as integers only if the value of the control code as well as the values of the parameters contain only digits. Otherwise they are handled as strings.

Sending of messages

In this section can be specified to which users e-mail messages shall be sent when the status of the activities has been changed.

If there has been specified for an activity that the message sending from the global and/or process definition are to be included, the settings done in the Sending of messages section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the messages in situations not specified in the global and/or process definition or if massages shall be send to different users than specified in the global and/or process definition, a new specification must be done here. If no message sending specifications are included from the global and/or process definition all the message sending definitions for the activity have to be done here.

The fields of this subsection can be edited when the subsection is open (see picture below).

In the part Messages sent to users when processes change their status activities can be specified, to the last update users of which shall a message be sent, when the process changes its status. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.

The structure of the first table of the part Messages sent to users when process activitys change their status is similar to the structure of the section Sending of messages in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Sending of messages of global definitions for more information.

In the second table of the part Messages sent to users when process activities change their status activities cab be specified, to the last update users of which shall a message be sent, when process activities change their status. Activity Id has to be set to the activity name of activity, of which status change shall cause the sending of a message. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.

Activity Recall Conditions

In this subsection can be specified from which status an activity can be recalled, eventually dependent on the status of successor activities and who can recall the activity.

The fields of this subsection can be edited when the subsection is open (see picture below).

The recall conditions are displayed as a table where each row represents one recall condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity for which the recall condition in the row is specified.

In the field When Status the satus has to be selected from which the activity can be recalled.

The field Successor Activitiy Id can be filled with the name of the successor activity. If no successor is specified the recall of the activity from the specified status can be done independent on the status of successors.

The field When Successor Status the status of the successor specified in Successor Activity Id can be selected. If the successor activity and its status are specified, the activity can be recalled from the specified status only if the successor has the specified successor status. There can be more rows in the table which differ only in the status of the successor status. In this case the recall of the activity is possible if the recall condition in one of the rows is fulfilled. If the activty has more successors, conditions for all the acceptable statuses of all successors for the recall of the activity has to be defined here. In this case for each successor is checked whether there is a corresponding condition specified here to allow the recall of the activity.

If the check-box in the field Admin is authorized is checked the administrator is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to recall the activity if the condition specified in this row is fulfilled.

Process delete conditions

In this subsection can be specified for all activities which status they can have to be allowed to delete the process. When a process is deleted, there is checked whether for all activities of the process a delete condition is fulfilled. It is enough that for one activity no delete condition is fulfilled to refuse the deletion of the process.

The fields of this subsection can be edited when the subsection is open (see picture below).

The process delete conditions are displayed as a table where each row represents one delete condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity for which the process delete condition in the row is specified.

In the field When Status the satus has to be selected in which the activity can be to allow the deletion of the process.

If the check-box in the field Admin is authorized is checked the administrator is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to delete the process if the condition specified in this row is fulfilled.

The field How many Days after the last update date can be specified how many days after the last change in this activity has been done and the condition specified in this row is fulfilled the process can be deleted. Here a positive integer value must be filled in.

Process cleanup action

In this section a cleanup action can be selected, which is called when a process of this process definition is being deleted. The cleanup action can for example remove all entries in the database associated with the deleted process, delete all temporary files used by the process, etc. If there is no cleanup action selected, no action is being called when a process of this process definition is being deleted.

The fields of this subsection can be edited when the subsection is open (see picture below).

In the field Cleanup Action the action which shall be called when a process of this process definition is being deleted can be selected. The selection can be done from a list of defined actions which is displayed by clicking the question mark (?) button right to the field for displaying the name of the selected action. By clicking the Clear button the selection is cleard.

Documentation

When a user is creating a process of this process definition, editing it, working in an activity of it or viewing the report for it he can open the process documentation by clicking the documentation icon in the top of the ProcMan window (see picture below). In this case the process documentation is generated from the entries done in the documentation section of the global definition and from the entries done in this section.

The process documentation is organized in chapters which can contain a multiline plain text, but no objects like pictures, tables, etc.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Documentation in the Global definitions administration dialog. The only difference is that the documentation inherited from the global definition is displayed here in read-only modus for information. Please refer to the description of Documentation of global definitions for more information.

Editing a process definition

A process definition can be edited by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the process definitions list form. Alternatively a process definition can be edited also by clicking on the name in the table of the process definitions list form. After that a form with the process definition fields appears. This form is the same like the form for a new process definition except, that the fields Client and Global Definition are read-only and cannot be changed.

If there are already processes using the edited process definition in ProcMan, the activities and/or activity dependencies has been changed and the changes has been submitted, the original process definition is renamed (the new name is set to be the original name with the current timestamp suffix) and disabled and the changed definition is saved as a new process definition. This is because the existing processes are using the activity specification of the original process definition and would not work with the activity specification changed by editing the process definition.

Copying a process definition

An existing process definition can be used as a base for a new one by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the process definitions list form. After that the form for a new process definition prefilled with the settings from the selected process definition appears. Beware that at least the process definition name must be changed before the new process definition can be created.

Deleting process definitions

One or more process definitions can be deleted by selecting them in the process definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the process definitions list form. Beware that only process definitions which are not in use by existing processes can be deleted. An alternative to the deleting of a process definition is to disable it.

Adding process definitions into the Transfer Case

Select one or more process definitions from the process definitions list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the process definitions list form. After the selected process definitions have been added into the Transfer Case you can add another process definitions or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

A global definition serves to store shared settings of all process definitions which using this global definition. A change in a global definition has an immediate effect on all process definitions using it. Thus the process tables in the work list can differ depending on the settings in the global definitions (different count and heading of the columns) the processes using different global definitions are displayed in separate tables for each global definition in the work list.

Global definitions list

By clicking on the Global definitions menu item the global definitions administration dialog is being started.

After the dialog has been started, the list of already defined global definitions is displayed (see picture below). If there are no global definitions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the global definition forms for new and edited global definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new global definiton

A new global definition can be defined by clicking the New button in the global definitions list form. After that a form with the global definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new global definition is created and appears in the global definitions list. By clicking the Cancel button the dialog returns to the global definitions list without creating a new global definition.

In the field Client the client in which the global definition will be created has to be selected.

The field Name has to be filled with the name of the new global definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new global definition. It is a free text, which can contain any printable characters. It also can be left empty.

The check-box Enabled specifies whether the global definition can be used in ProcMan or not. If a global definition is not enabled it behaves like if it would not be defined at all.

Further fields are organized in sections. Each section can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the section title.

Global definition specific process parameters

In this section process parameters can be defined which shall be displayed in the work list for all processes using this global definition. The values of these parameters can be filled by users in the dialog for process creation, in dialogs of process activities or evaluated and set by the process activities without a user interaction.

Moreover based on the parameter definitions in this section the process creation dialog is generated for processes using this global definition. The generated dialog provides users with entry fields for setting values of the process parameters. The look of these entry fields has also to be defined here.

The fields of this section can be edited when the section is open (see picture below).

The process parameters have to be defined in the displayed table. Each row of the table represents one parameter. In the top of the table standard process parameters are displayed with a gray background for which only fields in some columns are editable. In the bottom of the table new parameters specific for this global definition can be defined. Table rows can be added or deleted using the plus (+) and minus (-) buttons at the end of the rows.

The field Name has to be filled with the name of the parameter. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Type the type of the parameter values has to be selected. The only difference between the types STRING and LONG_STRING is that the long string parameters are initially displayed in the work list in a slim column and the values of the parameters are shortened. By clicking on a control element in the column header the values are displayed in the full length and the column becomes as wide as needed.

The parameters of the type USER are displayed in the work list as links and by clicking on such a link the information about the user is shown in a popup window.

The parameters of the type STRING and NUMERIC can be defined to be displayed as links on pages of external systems (e.g. customer’s ticket system). By clicking on the button Extended right of the type selection field, a dialog is being displayed, where the link target can be defined as an expression. The expression syntax is the same like for the dialog element definition described later in this chapter. In the case that the value of the parameter shall be displayed as an read-only text (e.g. in the work list), it will be displayed as a link with the value of the evaluated expression as target, if the value of the evaluated expression is a string starting with 'http://' or 'https://'. Otherwise it is displayed as a normal text. The value of the parameter can be referenced in the expression by using the pseudo variable $. Currently other parameters cannot be referenced from the expression. For example, if there is defined for a STRING parameter X an link expression like this 'http://ticket.my_company.com:8080/ticket’.$.’.htm?mode=readonly’, the read-only value 123456 of the parameter X will be in the pages displayed as a link with the target: ‘http://ticket.my_company.com:8080/ticket123456.htm?mode=readonly’. When a user clicks on such link a new Window/Tab is opened where the link target page is displayed.

The field Description can be filled with a textual description of the parameter. It is a free text, which can contain any printable characters. It also can be left empty.

If the check-box Translate description is checked the value specified in the field Description is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.

If the check-box Translate parameter values is checked the value of the parameter is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case entries for all possible parameter values must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.

In the field Search area a search area can be selected. Use the question mark (?) button for selection of the search class from a list. Use the Clear button to remove a selected search area from this field. In the case that a search area is set in this field the work list search function will search for texts in the values of this process parameter when the search area has been selected in the dialog of the search function.

The check-box Enabled specifies whether the parameter can be used in ProcMan or not. If a parameter is not enabled it behaves like if it would not be defined at all.

The check-box Show in process dialog specifies whether an entry field shall be generated for this parameter in the process creation dialog.

In the case that an entry field shall be generated for the parameter in the process creation dialog, the properties of the entry field can be defined when clicking the Edit button in the Process dialog attributes column. After clicking the Edit button a dialog appears (see picture below).

After filling the fields in this form and clicking the OK button the definition of the entry field is passed to the dialog for a new global definition. Beware that the entry field definition is not persistently saved at this moment. It is saved only when the whole global definition is created by clicking the OK button in the calling dialog. By clicking the Cancel button the dialog returns to the calling dialog for the global definition discarding all settings done in it.

The read-only fields Name and Type in the top of the form inform about the name and the type of the parameter for which the dialog entry field shall be defined.

The rest of the form is divided into sections. The sections allow defining of different look and functionality of the entry field depending on the context defined by the logged in user, the role in which he is currently working and the client in which he is logged in. For example it can be defined that the entry field is in processes of one client displayed as an editable text and in another client as a selection box with predefined values, and/or the entry field is for one role editable but for another role read-only. Each section is displayed as a line with a plus (+) / minus (-) control element at the beginning for opening / closing the section and followed by Client, Role and User fields.

The client, role and user fields have to be filled with pattern strings which are checked at the time the entry field shall be generated. The entry field definition in the first section, in which the current context is matching the patterns, is used for the generation. If no such section has been found defaults depending on the type of the parameter are used for the entry field generation. The patterns can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the value, they must be escaped with a backslash (\) like this: \*, \?. Also if a backslash is meant as a character appearing in the value it must be escaped like this: \\.

Right of the client, role and user field is a button with a question mark (?). By clicking the button defined clients, roles or users can be selected and filled into the fields from a list in a popup window. The user field has moreover right of the button with the question mark two further buttons: plus (+) and minus (-) which allow adding further or delete user patterns in the section. When it is checked whether the current context is matching the section patterns, in the case of user patterns is checked whether the name of the logged in user is matching at least one of the specified patterns.

Initially there is only one section in which all the pattern fields are filled with asterisk so any context would match the patterns of this section. If this is expected the entry field definition can be done in this section and it will be used any time the entry field is generated. Otherwise the patterns in the initial section can be changed, further sections can be added or deleted using the plus (+) or minus (-) buttons at the end of the section row and the entry field definition can be done in every section.

Which form fields for the entry field definition are displayed in the sections is dependent on the type of the process parameter.

If the check-box in the field Hidden is checked the entry field is generated and filled with a default value but not visible.

If the check-box in the field Readonly is checked the generated entry field is only for reading.

If the check-box in the field Mandatory is checked the value entered by the user in the generated entry field must not be empty which is being verified automatically. The generated entry field has in this case a light blue background color.

If the check-box in the field Width selection button is checked right of the generated entry field a question mark (?) button is displayed. By clicking on the question mark button a selection popup window is displayed in which the user can select the value he wants to fill into the entry field.

In the field Type the type of the generated entry field has to be selected. If the type is text a single line text input element is generated. If the type is multiline a multiline text input element is generated. If the type is selection a selection box with predefined values is generated. If the type is checkbox a check-box is generated.

In the field Size can be specified how many characters wide the generated single line text input element shall be. If none is specified a default value is used.

In the field Rows can be specified how many rows high the generated multiline text input element shall be. If none is specified a default value is used.

In the field Width can be specified how many characters wide the generated multiline text input element shall be. If none is specified a default value is used.

In the field Maximal length can be specified the maximal count of entered characters in the generated single line or multiline text input element. If none is specified there is no limit set in the element.

In the field List of possible values the values which can be selected in the generated selection box have to be specified. For adding/deleting lines in the list the plus (+) and minus (-) buttons right of the value fields can be used.

The string value specified in the option Custom Data type is used at the dialog generation time, for selecting entries, having this value in the first column (data_type), from the database table custom_data. The data rows selected this way from the database are then used for adding selection options in the generated selection box. For each row selected this way, one additional selection option is being generated. Following rules are applied for adding of the selection options:

1. The first not empty value in the string columns (data_str_1, data_str_2, ..., data_str_6) of a row is used as the value (what is set on selection as the parameter value) of the newly generated option.

2. The second not empty value in the string columns (data_str_1, data_str_2, ..., data_str_6) of a row is used as the description (what the user sees in the selection box) of the generated option.

3. If only one of the string columns (data_str_1, data_str_2, ..., data_str_6) of a row contains a not empty value, then this value is used for both, the value and the description of the generated option.

4. If the rows have different values in the integer columns (data_int_1, data_int_2), the values are used for sorting the entries from the smallest to the greatest, for generating the options in the sorted order.

5. If the rows have same values in the integer columns (data_int_1, data_int_2), the generated options are sorted by the description.

If the check-box in the field By default checked is checked the generated check-box is initially checked, otherwise not.

In the field Value when checked the textual value which shall be set into the process parameter when the generated check-box is checked has to be specified.

In the field Value when unchecked the textual value which shall be set into the process parameter when the generated check-box is not checked has to be specified.

If the check-box in the field Ignore calendar settings is checked the value the user entered in the generated entry field for a process parameter of type DATE is not checked whether it is a working date due to the settings done in the used calendar.

In the field Offset days can be specified how many working days in the future the value in the generated entry field of a process parameter of type DATE must be set by the user. If no offset days value is specified the value in the entry field can be set with a date even in the past. If the offset days value is greater or equal 0, the date value in the entry field must be at least the current date plus count of days specified in the offset days value or later.

In the field Increment offset days after a time value can be specified. If it is empty the value in the Offset days field is being used every time for counting the next possible date value in the generated entry field. If it is not empty every day after reaching the time specified here the value in the Offset days field incremented by one more day is being used every time for counting the next possible date value in the generated entry field.

If the check-box in the field Time for UTC conversion (From the next TIME parameter) is checked the process parameter of type DATE is coupled with the next defined process parameter of type TIME. Through this coupling the values which the user enters in the generated entry fields for both process parameters are handled as the date and time part of a timestamp. The timestamp is converted by ProcMan in the UTC timezone and the values of the process parameters are stored in this form.

In the field Time for UTC conversion (otherwise) a time value can be specified. If the process parameter of type DATE is not coupled with the next defined process parameter of type TIME, or the value in the entry field generated for the TIME parameter is missing for some reason, the time value specified here is used as the time part of the timestamp for the UTC conversion.

If the check-box in the field Date for UTC conversion (From the previous DATE parameter) is checked the process parameter of type TIME is coupled with the previously defined process parameter of type DATE. Through this coupling the values which the user enters in the generated entry fields for both process parameters are handled as the date and time part of a timestamp. The timestamp is converted by ProcMan in the UTC timezone and the values of the process parameters stored in this form.

In the field Default value the default value which shall be initially set for the generated entry field can be specified.

If the check-box in the field Evaluate default value is checked the text in the field Default value is handled as an expression (the expression syntax is described later in this chapter). In this case the expression is evaluated every time the entry field is generated and the result of the evaluation is used as the default value of the generated entry field.

In the field Triggering of dynamic dialog parts can be specified that some parts of the generated dialog will only be shown depending on a fulfillment of specified conditions. Each such dynamic part is represented by a row in the table in this field. Rows can be added or removed using the plus (+) and minus (–) buttons in the end of each row. In the Title field a text can be specified which appears as a heading when the part is shown. If it is empty no heading will be shown. If the check-box in the Translate field is checked the title is handled as a key in the dictionary and translated to the proper language depending on the user’s language settings. In this case the entry must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation. The value of the field Parameter Prefix specifies the name prefix of parameters which belong to the dynamic part. If the expression (the expression syntax is described later in this chapter) specified in the Condition field is fulfilled (its evaluation returns a value interpreted as a logical true), the dynamic part is displayed, otherwise it is hidden.

If the check-box in the field Do not check whether user exists is checked the value entered in the generated entry field for a process parameter of the type USER is not check whether it is a known user name in ProcMan.

In the field Role one or more roles can be specified. The question mark (?) button right of the value field can be used to select a role from a list displayed in a popup window. For adding/deleting further roles the plus (+) and minus (-) in the right of each role line can be used. If one or more roles are specified, it is checked whether the user, of which user name the user entered in the generated entry field, has one of the roles specified here.

In the field Input value verification condition an expression (the expression syntax is described later in this chapter) can be specified for to verify the value entered by the user in the generated entry field. The evaluation of the expression takes place every time the form in which the entry field has been generated is being submitted by a user. If none expression is specified no verification takes place. If it is specified and the evaluation of the expression returns a value which is interpreted as a logical false, an error message is displayed and the user must correct the input value before he can continue.

In the field Error message when verification failed a message text can be specified which is displayed when the evaluation of the verification condition returns a value which is interpreted as a logical false. If none specified a default message is displayed in this case.

If the check-box in the field Translate (Error message when verification failed) is checked the value specified in the field Error message when verification failed is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.

In the field Input value second verification condition an expression (the expression syntax is described later in this chapter) can be specified for to verify the value entered by the user in the generated entry field. The evaluation of the expression takes place every time the form in which the entry field has been generated is being submitted by a user. If none expression is specified no verification takes place. If it is specified and the evaluation of the expression returns a value which is interpreted as a logical false, a warning message is displayed and the user can correct the input value or continue without changing the value.

In the field Warning message when verification failed a message text can be specified which is displayed when the evaluation of the second verification condition returns a value which is interpreted as a logical false. If none specified a default message is displayed in this case.

If the check-box in the field Translate (Warning message when verification failed) is checked the value specified in the field Warning message when verification failed is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.

In the field Help text a help text can be specified which is being displayed right of the generated entry field.

If the check-box in the field Translate (Help text) is checked the value specified in the field Help text is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.

Like described above expressions can be used in the definition of a generated entry field which are evaluated every time when the field is generated to initialize its value and when the form with the field is submitted by a user to verify the value entered in the field. Following elements can be used in the expressions:

Literals – string literals (starting and ending with a single quote ('), backslash () is used for escaping special characters), decimal numeric literals (using point (.) as a decimal delimiter), Boolean literals (true and false)

Operators – arithmetic operators (+, -, *, /, % (modulus)), bitwise operators (&, |, ^ (xor), ~ (not), << (shift left), >> (shift right)), comparison operators (=, == ,!=, <>, <, >, <=, >=), logical operators (!, not, &&, and, ||, or, xor), string concatenation operator (.))

Parentheses – for sub expressions

Conditional expression – condition ? expr1 : expr2 – If the condition is evaluated as a Boolean true then the conditional expression returns the result of the evaluation of the expression expr1, otherwise it returns the result of the evaluation of the expression expr2.

Type casting – (string), (int) and (float)

Parameter references - $ references the value of this process parameter, ${name} references the value of the process parameter with the specified name, ${name=literal} references the value of the process parameter with the specified name using the default value specified in the literal if the process parameter is unknown. For the standard process parameters the following names can be used: !GROUP, !DESCRIPTION, !PREDECESSOR, !EARLIEST_DATE, !EARLIEST_TIME, !LATEST_DATE, !LATEST_TIME, !MEMO.

Function calls – name(parameter list) calls the function specified by the name with the parameters specified in the parameter list.

Currently following functions can be called from the expressions:

• in(string | int, …) – Checks whether the value of the first parameter (needle) is equal to a value in one of the further parameters (haystack). Returns true if the needle has been found in the haystack, false otherwise.

• trim(string) – Returns a string which is produced from the input string by removing whitespaces at the beginning and at the end.

• ltrim(string) or lefttrim(string) – Returns a string which is produced from the input string by removing whitespaces at the beginning.

• rtrim(string) or righttrim(string) – Returns a string which is produced from the input string by removing whitespaces at the end.

• concat(string, …) or strconcat(string, …) – Returns a string which is produced as a concatenation of all strings passed in the parameters. Alternatively the string concatenation operator (.) can be used instead of calling this function.

• upper(string), toupper(string) or strtoupper(string) – Returns a string which is produced from the input string by changing all alphabetical characters into upper case.

• lower(string), tolower(string) or strtolower(string) – Returns a string which is produced from the input string by changing all alphabetical characters into lower case.

• len(string), length(string) or strlen(string) – Returns the length of the input string.

• substr(string, int [, int]) or substring(string, int [, int]) – Returns a substring of the input string in the first parameter from the zero based position in the second parameter to the end of the string or with the length specified in the optional third parameter.

• pos(string, string [, int [, bool]]), position(string, string [, int [, bool]]) or strpos(string, string [, int [, bool]]) – Returns the index of the first/last (dependent on the fourth parameter) occurrence of the string in the second parameter in the string in the first parameter. If the optional third parameter is passed to the function the search starts at the position specified by this parameter. If the fourth parameter is not specified or false, the function returns the index of the first occurrence, if the parameter is true, the function returns the index of the last occurrence.

• match(string, string) or strmatch(string, string) – Returns true if the string in the second parameter matches the pattern string in the first parameter, or false otherwise. The pattern string can contain wildcards asterisk () which means any string (even an empty string) and question mark (?) which means any character. The backslash () can be used for escaping special characters (, ? and ) in the pattern string.

• eol() or eoln() – Returns a string containing only the end of line character.

• translate(string) or trnsl(string) or trnslt(string) – Returns the dictionary translation of the in the parameter specified dictionary key according to the user’s language setting.

• date([bool [,string [, string [, bool [, bool]]]]]) – Returns a date string. If the optional first parameter is true the returned date is formatted using the date format specified in the ProcMan’s Options dialog. If the optional first parameter is omitted or false the returned date is formatted using the YYYYMMDD format. If the optional second parameter is omitted or null the current date (or reference date if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the date part of the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users are using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.

• time([bool [,string [, string [, bool [, bool]]]]]) – Returns a time string. If the optional first parameter is true the returned date is formatted using the HH:MM:SS format. If the optional first parameter is omitted or false the returned date is formatted using the HHMMSS format. If the optional second parameter is omitted or null the current time (or reference time if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the time part of the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.

• ts([bool [,string [, string [, bool [, bool]]]]]) or timestamp([bool [,string [, string [, bool [, bool]]]]]) – Returns a timestamp string. If the optional first parameter is true the date part of the returned timestamp is formatted using the date format specified in the ProcMan’s Options dialog, there is a space between the date and the time part and the time part of the returned timestamp is formatted using the HH:MM:SS format. If the optional first parameter is omitted or false the returned timestamp is formatted using the YYYYMMDDHHMMSS format. If the optional second parameter is omitted or null the current timestamp (or reference timestamp if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users are using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.

• weekday(string) – Returns the numeric representation of the week day (0 = Sunday through 6 = Saturday) of the date specified in the parameter, or -1 on error.

• freeday(string [, bool]) – Returns true if the date specified in the first parameter is a free day according to the current calendar, otherwise it returns false. If the optional second parameter is false free days marked in the calendar as selectable (allow selection) are considered not to be free days and the function returns false for them.

• workday(string [, bool]) – Returns true if the date specified in the first parameter is a work day according to the current calendar, otherwise it returns false. If the optional second parameter is true free days marked in the calendar as selectable (allow selection) are considered to be work days and the function returns true for them.

• addworkdays(bool, int [, bool [, string]]) – Adds the count of work days specified in the second parameter to the current date (or reference date if specified in the fourth parameter) according to the current calendar and returns the final date as a string. If the first parameter is true the returned date is formatted using the date format specified in the ProcMan’s Options dialog. If the first parameter is false the returned date is formatted using the YYYYMMDD format. If the optional third parameter is omitted or false also a selectable free day can be returned. If it is true only a workday can be returned. If the optional fourth parameter is omitted or null the current date is used as the reference date for the evaluation. If it is a string containing a valid date the specified date is used as the reference date for the evaluation. Although the function accepts various date formats we recommend to pass date values in YYYYMMDD format in this parameter, to avoid eventual problems when users are using different date formats.

• timestampreached(string [, bool]) or tsreached(string [, bool]) – Returns true if the time specified as a timestamp in the first parameter is a time in the past or the current time, otherwise it returns false. Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, to avoid eventual problems when users are using different date formats. If the optional second parameter is missing or true, the timestamp is handled as an UTC time, otherwise as a local time.

• datetimereached(string, string [, bool]) or dtreached(string, string [, bool]) – Returns true if the time specified by the date int the first parameter and the time in the second parameter is a time in the past or the current time, otherwise it returns false. The date can be specified as a date value or a timestamp value. The time can be specified as a time value or a timestamp value. Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameters, to avoid eventual problems when users are using different date formats. If the optional third parameter is missing or true, the timestamp built from the date and time is handled as an UTC time, otherwise as a local time.

• client() – Returns the name of the process client.

• user() – Returns the name of the current user.

• userdescr() or userdescription() – Returns the description of the current user.

• role() – Returns the name of the role in which the current user is currently working.

• param(string) or processparam(string) – Returns the current string value of the ProcMan process parameter having the parameter ID specified in the function parameter. If the parameter ID is unknown or the parameter has no value yet it returns an empty string.

• paramdate(string) or processparamdate(string) – Returns the current string value of the ProcMan process date parameter having the parameter ID specified in the function parameter. The returned date is formatted using the date format specified in the Options dialog of the current user. If the function cannot return a valid date for some reason (unknown parameter ID, not a date parameter, missing value for the parameter, etc.) it returns an empty string.

• paramtime(string) or processparamtime(string) – Returns the current string value of the ProcMan process time parameter having the parameter ID specified in the function parameter. The time (internally stored in UTC) is converted in the time zone of the current user before it is returned. The returned time is in the format HH:MM:SS. If the function cannot return a valid time for some reason (unknown parameter ID, not a time parameter, missing value for the parameter, etc.) it returns an empty string.

• mapcustomdata(string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data and on success it returns the required value at the specified column. The first parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The second parameter is the name of the table column, from which the value returned by the function shall be read, from the found record. One of the following values can be specified in the parameter: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table record which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the second function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in further parameters (see example below). If the function does not find any record matching the specified type and/or key, the function returns the value false.

• searchcustomdata(string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data and on success it returns the value true, otherwise it returns the value false. The first parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The optional further parameters specify the key of the database table record which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the following values: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in further parameters.

• mapcustomdataregex(string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data. For each value in the specified column of found records, it applies a filter function, which replaces placeholders in the specified regular expression with the found value and checks, whether the regular expression matches the specified reference value. If this is the case for some found value, it returns this value. The first parameter is a regular expression which may contain one or several placeholders <param>, specifying where values selected from the custom_data table have to be placed. The second parameter is the reference value, which shall match the regular expression. The third parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The fourth parameter is the name of the table column, from which the value returned by the function shall be read, from the found record. One of the following values can be specified in the parameter: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table records which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the second function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in the further parameters (see example below). If the function does not find any record matching the specified type and/or key, or if for none of the values in the found records in the specified column the regular expression matches the reference value, the function returns the value false.

• searchcustomdataregex(string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function works in the same way like mapcustomdataregex (see description above). The only difference is, that instead of the found value it returns true on success.

• replacecustomdata(string, bool, string, string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data. For each value pair <needle, value> in the specified columns of found records, it replaces the occurrences of needle in a specified string with the value. It returns the string containing the replacements, or the original string if no replacements have been found. The first parameter is the string in which the replacements shall be done. If the second parameter is true, the search for the replacements is case sensitive, if it is false, the search is case insensitive. The third parameter is the needle prefix. The fourth parameter is the needle suffix. On the search for the replacements, the function searches for strings made as a concatenation of the prefix, the needle and the suffix. The needle prefix and/or suffix parameters can be set to an empty string, if the needles does not need to be searched in a specific prefix and/or suffix context. The fifth parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The sixth parameter is the name of the column, in which the custom data table records contain the needles. The seventh parameter is the name of the column, in which the custom data table records contain the values for the replacement of needles. One of the following values can be specified in the sixth and seventh parameters: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table records which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the sixth/seventh function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in the further parameters (see example below).

Here are some examples of usage of expressions:

The above expression can be used for an initialization of a text entry field with a value starting with the client name, continuing with underscores (_) and being 16 characters long.

The above expression can be used for verifying the values entered in a text entry field. The verification would accept only values having 10 or more characters starting with the client name and values having exactly 18 characters and ending with the value specified in the field Group ID.

The above expression can be used for an initialization of a date entry field. If the current day is the 15th day of the current month or lower the date field is initialized with the date one week later, otherwise it is initialized with the date two weeks later. Moreover, the initial date is formatted in the format set for the user.

The above expression searches in the ProcMan’s database table custom_data for a record which has the value 'DEPARTMENT NAME PREFIX' in the column data_type, the value 'R&D' in the column data_str_1 and the value 'UNIT 317' in the column data_str_2. If it finds such a record, it returns the value of the column data_str_3 of the record. If such a record cannot be found in the database table, it returns the value false.

The above expression searches in the ProcMan’s database table custom_data for records which have the value 'STAGE' in the column data_type and the value 'TEST' in the column data_str_1. If it finds such records and some of the records has the value 'PROD' in the column data_str_2, the function returns the value 'PROD', because the regular expression in the first parameter matches the reference value in the second parameter for this value. If none record was found, having a value in the column data_str_2, for which the regular expression would match the reference value, it returns the value false.

The above expression searches in the ProcMan’s database table custom_data for records which have the value 'STAGE' in the column data_type and the value 'PROD' in the column data_str_1. If it for example finds two records, a record having the value 'part1' in the column data_str_2 and the value 'x1' in the column data_str_3 and a record having the value 'part3' in the column data_str_2 and the value 'x3' in the column data_str_3, it returns the string '.x1.part2.x3.part4.'.

The key words (e.g. and, string, etc.) and function names in the expressions are case insensitive.

Expressions can be debugged by prepending them with the debug or the dbg key word. For example:

In this case the expression is evaluated in a normal way and in addition a debug information about the evaluation is being written into the hwm-expression-<current_date>.log file in the ProcMan’s log directory. The debug information contains the original expression, the expression generated for the evaluation from the original expression, the parameter and the context parameters passed to the evaluation and either the result of a successful evaluation, or the error message of a failed evaluation.

Attachment of files

In this section can be specified whether external files (e.g. pdf, doc, ppt, etc.) can be attached to processes using this global definition or not.

The fields of this section can be edited when the section is open (see picture below).

If the check-box in the field Allow attachment of files is checked it will be allowed to attach external files to processes using this global definition.

Status of activities

In this section it can be specified what status of activities of all processes using this global definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).

The definitions done in this section are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) mappings of control codes to activity statuses here spares a lot of definition work by avoiding the necessity of repeating the same specifications in all process definitions or even for all activities in the process definitions using the global definition.

The fields of this section can be edited when the section is open (see picture below).

The input fields in the section are organized in a table where each row represents a single condition. Condition rows can be added or deleted using the plus (+) or minus (-) buttons at the end of each row. There can be more conditions setting the same status of activities defined. Beware that there should not be more conditions which are true for the same control code otherwise it is not clear which condition will be applied for setting the activity status, as the order in which the conditions are evaluated is not fix.

In the field Set Status the activity status has to be selected which shall be set when the control code returned by an action fulfills the condition.

In the field Condition the operator has to be selected which shall be applied to compare the control code returned by an action with the parameters of the condition.

In the fields Condition Parameter 1 and Condition Parameter 2 the parameters of the condition operator has to be specified. Two parameters are used only for operators testing whether the control code returned by an action is within or without a range. By other operators the second parameter is ignored. Beware that the parameters are handled as integers only if the value of the control code as well as the values of the parameters contain only digits. Otherwise they are handled as strings.

Sending of messages

In this section can be specified in which cases generated e-mail messages shall be sent to which users. Sending of messages in two situations can be defined here: when the status of a process of this global definition has been changed and when the status of an activity of a process of this global definition has been changed.

The definitions done in this section for sending messages when the status of activities has been changed are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) message sending rules here spares a lot of definition work by avoiding the necessity of repeating the same specifications in all process definitions or even for all activities in process definitions using the global definition.

Beware that e-mails can be sent only if an SMTP server has been configured after the ProcMan installation (please refer to the ProcMan installation and customize guide for more information). Moreover e-mails can only be sent to users which have an e-mail address specified in their accounts.

The fields of this section can be edited when the section is open (see picture below).

The input fields in this section are organized in two tables: one for processes and one for activities. Each row in these tables describes to whom a message shall be sent in the case that a process or an activity changes its status. Rows can be added or deleted by clicking the plus (+) or minus (-) buttons at the end of each row in both tables.

In the field When Status the status has to be selected for to specify that when a process or an activity changes to this status a message shall be sent.

If the check-box in the field Message Process Creator is checked a message informing the process creator user is sent when the process becomes the selected status.

If the check-box in the field Message Users which completed start activities is checked a message informing the users which completed the start activities of the process is sent when the process becomes the selected status.

If the check-box in the field Message last update User of activities is checked a message informing the users which completed all activities of the process is sent when the activity becomes the selected status.

If the check-box in the field Message last update User of successor activities is checked a message informing the users which completed the successor activities of the process is sent when the activity becomes the selected status.

In the field Message other user a user name of the user which shall be informed by a message when the process or activity becomes the selected status can be specified. Clicking the question mark (?) button right to the text input field allows selecting the user from a list which appears in a popup window. The user entered here can also be a special user dedicated only for this purpose which has no role assigned and/or having a collective e-mail address (the e-mails sent to this address are delegated by the mail server to further addresses) specified in he’s account.

Documentation

When a user is creating a process of this global definition, editing it, working in an activity of it or viewing the report for it he can open the process documentation by clicking the documentation icon in the top of the ProcMan window (see picture below). In this case the process documentation is generated from the entries done in this section and from the entries done in the documentation section of the process definition.

The process documentation is organized in chapters which can contain a multiline plain text, but no objects like pictures, tables, etc.

The fields of this section can be edited when the section is open (see picture below).

Chapter specifications are displayed as table rows. Rows can be added or deleted by clicking on the plus (+) or minus (-) buttons at the end of each row.

In the field Title the title of the chapter has to be specified which shall be displayed in the generated documentation.

In the field Language the language of the chapter specification has to be selected. If a value other than asterisk () is selected, the chapter will appear in the generated documentation only if the calling user has the same language set in the ProcMan options. If the value asterisk () is selected here, the chapter will appear in the generated documentation independent of what language the calling user has set in the ProcMan options.

The fields Client, Role and User have to be filled with pattern strings which are checked at the time the documentation shall be generated. The generated documentation will contain only those chapters for which the process client, the role in which the current user is currently working and the user name of the current user are matching the patterns specified here. The patterns can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the value, they must be escaped with a backslash () like this: *, ?. Also if backslash is meant as a character appearing in the value it must be escaped like this: \.

Right of the client, role and user field is a button with a question mark (?). By clicking the button defined clients, roles or users can be selected and filled into the fields from a list in a popup window. The user field has moreover right of the button with the question mark two further buttons: plus (+) and minus (-) which allow adding further or delete user patterns in the chapter row. Only those chapters can appear in the generated documentation where the user name of the current user is matching at least one of the specified user patterns.

By clicking the plus (+) or minus (-) control element at the beginning of each chapter row the multiline text field for editing of the chapter text is being displayed or hidden. The text specified in this text field is displayed as the content of the chapter in the generated document.

Editing a global definition

A global definition can be edited by selecting it in the global definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the global definitions list form. Alternatively a global definition can be edited also by clicking on the name in the table of the global definitions list form. After that a form with the global definition fields appears. This form is the same like the form for a new global definition except, that the field Client is read-only and cannot be changed.

Copying a global definition

An existing global definition can be used as a base for a new one by selecting it in the global definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the global definitions list form. After that the form for a new global definition prefilled with the settings from the selected global definition appears. Beware that at least the global definition name must be changed before the new global definition can be created.

Deleting global definitions

One or more global definitions can be deleted by selecting them in the global definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the global definitions list form. Beware that by deleting of a global definition also all process definitions using this global definition are deleted. Beware that only global definitions which are not in use by existing processes can be deleted. An alternative to the deleting of a global definition is to disable it.

Adding global definitions into the Transfer Case

Select one or more global definitions from the global definitions list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the global definitions list form. After the selected global definitions have been added into the Transfer Case you can add another global definitions or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

The Object Browser provides a read-only access on the objects (e.g. Universal objects, JCL members, TWS applications, etc.) stored by ProcMan processes in the ProcMan archive. It allows a user to get information about objects, without a need to know by which processes the objects have been created/changed.

Object Browser definitions list

By clicking on the Object Browser menu item the process definitions administration dialog is being started.

After the dialog has been started, the list of already defined object browser definitions is displayed (see picture below). If there are no object browser definitions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the object browser definition forms for new and edited process definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new object browser definitions

A new object browser definition can be defined by clicking the New button in the object browser definitions list form. After that a form with the object browser definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new object browser definition is created and appears in the object browser definitions list. By clicking the Cancel button the dialog returns to the object browser definitions list without creating a new object browser definition.

In the field Client the client in which the object browser definition will be created has to be selected.

The field Name has to be filled with the name of the new object browser definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description has to be filled with a textual description of the new process definition. It is a free text, which can contain any printable characters. This text will be displayed in the Object Browser menu of the logged in users.

The check-box Translate description specifies whether the text specified in the Description field contains a dictionary key and has to be translated using the dictionary into the language of the logged in user.

In the field Action the action has to be selected which shall be executed when a user clicks on the menu item for this object browser definition. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

The check-box Enabled specifies whether the object browser definition can be used in ProcMan or not. If a object browser definition is not enabled it behaves like if it would not be defined at all.

In the table Roles by which the Object Browser is allowed to be started the roles can be selected, by checking the check-box in the beginning of each row. Only users having at least one of the selected roles in the client (or its sub-clients), in which they are logged in, will see this object browser definition in their menu and can start it.

Editing an object browser definition

An object browser definition can be edited by selecting it in the object browser definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the object browser definitions list form. Alternatively, an object browser definition can be edited also by clicking on the name in the table of the object browser definitions list form. After that a form with the object browser definition fields appears. This form is the same like the form for a new object browser definition except, that the field Client is read-only and cannot be changed.

Copying an object browser definition

An existing object browser definition can be used as a base for a new one by selecting it in the object browser definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the object browser definitions list form. After that the form for a new object browser defintion prefilled with the settings from the selected object browser definition appears. Beware that at least the name must be changed before the new object browser definition can be created.

Deleting object browser definitions

One or more object browser definitions can be deleted by selecting them in the object browser definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the object browser definitions list form.

Adding object browser definitions into the Transfer Case