|
|
| Line 1: | |||
| + | =Types of Notifications= | ||
| + | There are basically 3 locations/events/reasons that can be configured that will send a notification when something particular happens. They are Event Notifications, Approval Processes, and Manual Tasks. | ||
| + | =Prerequisites for Configuring Notifications= | ||
| + | Before setting up notifications, one should be familiar with Roles, Users/Groups, and Permissions at least. The following steps are the prerequisites for setting up notifications: | ||
| + | #Implement LDAP or manually assign email addresses to uDeploy users. | ||
| + | #Configure the server settings with an email client. | ||
| + | #Configure the roles on each level of uDeploy that you want to configure notifications (Components,Environments,Applications,Resources). | ||
| + | #Add the users/groups that you want to receive the notifications to the roles. | ||
| + | =Configuring Notifications= | ||
| + | ==Event Notifications== | ||
| + | Event Notifications notify users when an event takes place on the server. The events that can initiate notifications are Process Success, Process Failure, Process Started, Approval Completed, and Approval Failed. The first three are for when a deployment starts, successfully finishes, or fails. The last two are for when you have an approval process configured, and an approval had been granted or rejected. The notifications can be configured to be received by users that are set in component, environment, or application roles. The following steps for configuring these notifications assume that you have already set up a role to receive the notifications. If not, see our guide to setting up roles. | ||
| + | #Navigate to the Settings>Notification Scheme tab. | ||
| + | #Create a new notification scheme, or edit the existing Default Notification Scheme. | ||
| + | #Add/edit a notification entry. | ||
| + | #Choose the type, target level the role is configured on, the role name, and the email template name and save. Note that the type of notification has a default template that it is designed to work with. See below. | ||
| + | #Edit or create the Application that these notifications will be applied to. | ||
| + | #Select the appropriate Notification Scheme from the drop down list and save. | ||
| + | The following are the templates that correspond to the notification type: | ||
| + | *Process Success = ApplicatoinDeploymentSuccess | ||
| + | *Process Failure = ApplicationDeploymentFailure | ||
| + | *Process Started = ProcessRequestStarted | ||
| + | *Approval Completed = DeploymentReadied | ||
| + | *Approval Failed = ApprovalFailed | ||
| + | <br> | ||
| + | *Note: The "Description" field in the email is populated from the "Description" field when requesting the process. Versions earlier than 4.7.2 seemed to have issues populating this field in the email. | ||
| + | ==Approval Processes== | ||
| + | An approval process can be configured on an environment to require a specified user to log in and grant or reject an approval before a process/deployment can execute. This can be used to ensure that the process being executed is configured correctly, and/or as an added layer of security, ensuring that only the appropriate users are requesting the deployment. This will also send a notification to the users in the approval role configured on the layer of the tool. The following are the steps to configure approvals and assume you have already configured the role doing the approval: | ||
| + | #Create or edit an the environment that is to require approvals, checking the "require approvals" box and save. This will create a tab on the environment called "Approval Process" | ||
| + | #Navigate to the Application>Environment>Approval Process tab. | ||
| + | #Drag the approval steps onto the field, creating an approval process. The available step under each expandable menu correspond to roles configured on the tool level. This works similarly to editing a component or application process. | ||
| + | #Connect the steps from start to finish in the order that you want them to execute and save. This can be executed in parallel or series, or a mixture of both. | ||
| + | <br> | ||
| + | *Note: The "Description" field in the email is populated from the "Description" field when requesting the process. Versions earlier than 4.7.2 seemed to have issues populating this field in the email. This only sends a notification that an approval is pending. If you need notifications that the approval was granted or rejected, see Event Notifications above. | ||
| + | ==Manual Tasks== | ||
| + | Typically, Manual Tasks are configured on a component or application to ensure that a user executes some sort of task that either cannot be performed by the tool, or should only be entrusted to a live user. They may also be used as an ad-hoc approval that can interrupt a deployment at a particular point. Note that the main differences between real approvals and manual tasks are that granting or rejecting an approval can be configured to send a corresponding notification, where a manual task cannot, and that Manual Tasks can interrupt a deployment, where approvals cannot. Configuring manual tasks involves identifying the reason for the manual task, locating the points in the deployment process that will need a manual task, and editing that particular point in the deployment by adding a manual task step via the process editor on the component or application. It also requires that the executing users be assigned to a role on the component, environment, or resource. The following are the steps to implementing Manual Tasks, which assumes you have created the roles that will receive the task notifications and that are required to fulfill the manual task, and that you have created a process/deployment before hand: | ||
| + | #Navigate to the Component/Application>Tasks tab on the component or application that will need the manual task. | ||
| + | #Create a new task definition by clicking "Create New Task Definition", and filling in the Name, Description, and Template Name. | ||
| + | #Edit the component or application process where you need the manual task. | ||
| + | #Drag and connect the manual task step from the Utility Steps menu, selecting a name for the step, the previously created Task Definition, and the component/environment/resource role that the user belongs to that may complete the manual task, and save. | ||
| + | Note: The name and description fields are normally used to detail the task to be completed by the user, be it a real task or just reviewing the results of a portion of the deployment. Also, the only two templates known to work with the manual task are ApprovalCreated and TaskCreated. | ||
