From OCS Inventory NG
Jump to: navigation, search

Manage teledeploy workflow

To use the teledeploy workflow, it is necessary to configure and adapt to their needs. You can activate the status of requests, add values to filds, add tabs, add multivalues fieds.

Operating principe of teledeploy workflow

Detailed diagram

En schema workflow.jpg


A user/requester do a request to create a teledeployment package on a set of machine. A group of administrators will study this request and accept it or not.

  • If this request is rejected, user/requester can modify it and resubmit.
  • If this request is accepted, a deployment package will be created and activated.

When the packet is created and activated, it goes into testing phase on a test environment.

  • If a problem is encountered, the demand may return to a previous state.
  • If no problem encountered, a teledeployment is done on a small area (a little network for exemple).

Group of administrators check the progress of the deployment.

  • If a problem is encountered, the demand may return to a previous state.
  • If package is valid, it will be deployed on targer computers
Warning: When a request is made, the requester must complete all required fields in all tabs. Values ​​are stored in tab to tab without having to validate the request.


Workflow activation

To begin, go in the general configuration.

Doc guiwk1 en.jpeg

Set option TELEDIFF_WK to ON.

Doc guiwk2 en.jpeg

You can now proceed with setting up your workflow .

Configuration of workflow status

Click on Teledeploy, and next on Workflow for Teledeploy.

Doc guiwk3 en.jpeg

At the first connection, you will need to configure a first status of request. Otherwise, the workflow will not work. Statutes are used to define the step of request.For this you have 9 levels available. In order to accommodate a maximum of users, the various statutes are activated according to your needs.

  • NIV0 DELETE : Request deleted
  • NIV1 WAITING FOR INCLUSION : Request pending consideration
  • NIV2 ACKNOWLEDGEMENT : Incomplete request
  • NIV3 REFUSAL : Request refused
  • NIV4 NEED TO CHANGE : Request to modify
  • NIV5 CREATE PACKAGE : Package under development
  • NIV6 LOCAL TEST : Package being tested locally
  • NIV7 PERIMETER LIMITED DEPLOYMENT : Package being deployed on a small area
  • NIV8 DURING DEPLOYMENT : Package being deployed

Of course you can edit each text status to your liking and change the meaning according to your needs.

Doc guiwk4 en.jpeg

Once all statutes to your environment enabled, you can move on the configuration.

Configure the application form

By default, 5 tabs are created in Workflow for teledeploy.

Doc guiwk5 en.jpeg
  • Requester Information tab contains field :
    • Requester : Requester is displayed automatically when creating request.
  • General Information Package contains fields :
    • Package Name : The name that the requester want to define to this package.
    • Description : Short description of the package.
  • Short description of the package contains fields :
    • Priority : allow requester to define if package must be deployed quickly or not.
    • Uuser notified : define if final user will have a warning message during package installation.
    • User can defer : define if final user may defer installation.
    • triggers a reboot : define if a reboot will be necessary after package installation.

For all these fields, before activate Workflow for Teledeploy, you have to add values you want in drop-down menus. For exemple, in order to add values to drop-down menu Priority, click on Doc gui user7.jpg, near Doc guiwk7 en.jpeg.

A popup will open where you can add your values.

Doc guiwk8 en.jpeg

You will have your different values ​​in a table.

Doc guiwk9 en.jpeg

These values ​​will then be visible to all users of workflow, and selectable from the dropdown list.

  • Validation information tab contains fields :
    • Stock control to validate the installation: Requester define criteria that allow to verify that the installation on the client was successful.
    • Status : Defined the status of the request in the workflow process
  • History cintains an array of different states of requests.

You can add tabs and fields that you want to the request form. Click on Workflow for Teledeploy and on Interface tab.

Doc guiwk10 en.jpeg

In a first time, you can start adding your own tabs by clicking on Doc gui user7.jpg in section Doc guiwk11 en.jpeg.

A popup opens and allows you to manage your tabs.

Doc guiwk12 en.jpeg

By default, you will found tabs displayed in requester console. By choosing a field in this tab, you will see technical information in this field and modify some parameters.

Doc guiwk13 en.jpeg

You can also add your own fields in the selected tab.

Click on Doc gui user7.jpg in section Doc guiwk14 en.jpeg

A popup opens and allows you to manage your tabs.

Doc guiwk15 en.jpeg

Description of different fields in this form:

  • New Field : corresponding to the name of this field in the application. It should be in SQL format.
  • Caption : define fiels caption to display in drop-down menu.
  • Field Type : define field type (text, textare, checkbox, radiobutton, drop-down menu, file).
  • Mandatory : validation of the entry form can't be done without this field completed.
  • Field restreint : This field will not be visible by profiles without the option of restriction on fields of Workflow for Teledeploy to NO. Doc guiwk16 en.jpeg
  • Linked to a status : This field will be displayed at a certain level of status application.

Manage workflow steps

The final configuration step is to define the parameters of the workflow.

Doc guiwk17 en.jpeg

Description of options :

  • IT_SET_NIV_CREAT : Define the request level that will create the package in the web interface
  • IT_SET_NIV_TEST : Define the level witch will allow to deploy a package on a test area
  • IT_SET_NIV_REST : Define the level witch will allow to deploy a package on a restreint area
  • IT_SET_NIV_TOTAL : Define the level witch will allow to deploy a package on a production area
  • IT_SET_MAIL : Send mail (if the server is configured for this) in order to warn users of the different steps of a request
  • IT_SET_PERIM : You can define your deployment areas on the criteria of TAG or on a group. If you choose to define from a TAG, you must complete the field IT_SET_TAG_NAME
  • IT_SET_TAG_NAME : Choose the TAG that will define your test area is restreint
  • IT_SET_NAME_TEST : Field value of your test area. If you have IT_SET_PERIM to TAG, you have to complete the value that your machines will have, to be considered in test perimeter. Else, you will have to choose dynamic or static group witch complete this function.
  • IT_SET_NAME_LIMIT : Same principle for IT_SET_NAME_TEST, but for restrained perimeter

If you choose to define your perimeters on groups, an information message will appear in the detail of a group.

Doc guiwk20 en.jpeg
Warning: Depending on the user profile, he sees all the requests, or those of his group.

Doc guiwk18 en.jpeg

or he sees only the requests made by him.

This choice is done through profiles management.

Doc guiwk19 en.jpeg

Using workflow

Note: Only profiles with the option of configuration toYEScan configure the workflow. Once the workflow configured and enabled, you can not deploy a package without going through a request.

Doc gui wk23 en.jpeg

To activate the workflow for a profile, you must turn the page : ms_teledeploy_workflow

When a request is made by a user, only the user (or group affiliation if it is configured as well) can change it. For an administrator of the workflow, the input fields will be grayed out.

Doc gui wk21 en.jpeg

The administrator has the power to change the application in its statutes.

Doc gui wk22 en.jpeg