Requests

Requests are messages that are displayed during the execution of tasks. Requests either require you to enter data for further processing or they draw your attention to potential problems. The tasks that have unattended requests stop processing and are in Waiting for user input status. Since requests may address critical issues, it is important that you can react to them quickly. As an operator and business user, you attend to the requests that occur during task execution. As a developer and object designer, you configure objects so that requests are sent when needed. Read Ways to Trigger Requests to learn about the possibilities you have to create requests.

Requests are displayed to you in the Requests view. They remain there until you or the user responsible for it has reacted to them.

Accessing the Requests View

You get the information that there are requests that you must attend to in one of the following ways:

• A pop up notification is displayed at the top of the screen for a few seconds. It contains a link to the Requests view.

  This notification method is used in the following situations:

  • When you are logged in to only one Client
  • When you are logged in to several Clients and the request originates in the Client that is currently in the foreground

• Web notifications

  Web notifications are messages displayed for a few seconds by your web browser. Each browser displays them in a slightly different way. They draw your attention to requests when the window where the request originates is not in the foreground.

  Web notifications specify the Automation Engine system and the Client on which the request has been triggered. They contain a link to the Requests view. Web notifications are displayed in the color that you have selected for the Client to which they apply.

  Web notifications are supported for the following browsers:

  • Chrome (https only)
  • Firefox
  • Edge

  Important!

  • Web notifications are not supported for IE.
  • Enable web notifications in your browser after logging in to the Automic Web Interface. For more information, see Before You Start.

• The Requests button in the menu bar displays the number of requests that are pending.

• From the Process Monitoring perspective, searching for tasks with Waiting for user input status. For this purpose, use the task filter. For more information, see Filtering Tasks.

To open the Requests view

Do one of the following:

• Click the link on the pop up dialog or web notification
• Click the Requests button on the menu bar.

Tip: Detach the Requests view from the browser window and arrange it side-by-side with the other windows you work with. This way you see and can react to incoming requests immediately.

The Requests View

The Requests view consists of two panes:

List of Tasks

The entries on the left pane are the tasks that triggered the requests that are waiting for you to react. They are listed in chronological order with the most recent one at the top. If a task has triggered several requests, it is displayed as many times as the number of requests it triggered. The list of requests is always up-to-date. If you submit a request, the associated entry is removed from this list.

Content Pane

The content pane displays the request and the options that you have for reacting to it. The appearance of this pane depends on the type of request. It can be short descriptions, one-line input fields created by :READ statements, or even complex forms created by PromptSets.

Types of Requests

Depending on what triggered the request, the following types are available:

• CALL
• PromptSet
• :READ
• Activation Report

CALL Requests

Notification (CALL) objects that have been configured to send either a Request, a Message, or an Alert trigger CALL requests. Since Notification objects can be configured to send notifications to multiple recipients, CALL requests are also sent to multiple users, namely the recipients. To see the list of recipients of a request, open the Recipients tab on the Requests of the Requests view. The Type column in the Recipients list identifies whether the recipient is a User in the system or an email address.

A CALL request can be accepted or rejected. The user who accepts it assumes the responsibility for the execution. When a CALL request is accepted, it disappears from the view of all recipients except the one who accepted it. It remains in the Requests view of the owner who accepted it until the Done button is pressed. If, instead of pressing Done, the owner rejects the request, it is displayed again to all recipients.

PromptSet Requests

PromptSets are interactive forms that are assigned to executable objects. When an object with a PromptSet is executed, the following happens:

• The PromptSet is called during its Activation stage.
• The task stops processing and its status changes to Waiting for User Input.
• A request is sent to the user who triggered the execution.

• The task remains in waiting status and the request in the Requests view until the user populates the required fields.

  The status of the task is visible to users in the same Client in the Tasks list (Process Monitoring perspective).

Note: When you define an executable object, you specify when it should be generated on its Attributes Page. If you want the online notifications (pop up dialog or web notification) to be displayed on screen, you must select the Generate task at: Activation time option. The reason is that PromptSet objects and PromptSets assigned to objects are resolved, and :READ statements are read during the activation stage of the object execution. For more information, see Generating at Activation or at Runtime.

Tip: Requests do not re-appear if the user gets disconnected or logs out without replying to the ongoing requests. If the user who triggered the execution is not available, the task remains Waiting for User Input. To unblock it, do the following:

1. Go to the Tasks list in Process Monitoring.

2. Select the task that triggered the request and do one of the following:

   • Right-click and select Open User Input to populate the form and submit it

   • Click Modify > Take over Task

     You are now the owner of the task, so you receive the request sent by the PromptSet.

For more information, see PromptSets (PRPT).

:READ Statement Requests

:READ requests are similar to PromptSet requests, although they create simpler forms with input fields only. The main differences are:

• Only the user that executed the task can access them
• They are called at a later point of the execution, namely during Generation. For this reason, if the owner of the task is not available, it is not possible for another user to take ownership of the task. The script stops processing until the request is resolved.

Tip: Use PromptSets instead. If a script stops because it is waiting for user input after it has already made changes to, for example, a file system, you may end up with inconsistencies.

Activation Report Requests

Activation Report requests provide information to the user about the execution of a task. They are called during Activation or Generation of the task. They are triggered by :PRINT statements on the script of the source object.

Activation Reports are for information purposes only.

Filtering Requests

The left pane of the view contains the list of all tasks that triggered requests that are still active. You can restrict the number of requests using the filter at the top of the pane. You can select one or more request types to filter them by types.

Reacting to Requests

Requests disappear from the view only after you have reacted to them by submitting, closing, or canceling it. When you submit a request, its status changes to Done and the task that triggered it ends its execution.

To React to Requests

1. Select a task on the left pane to display the content of the request on the right pane.

2. The content pane displays the request. Depending on the type of request triggered by the task, you have different options:

   To React to PromptSet Requests and :READ Statement Requests

   1. Populate the input fields, dropdown lists, checkboxes, and so forth.
   2. Click Cancel Task to completely cancel the associated task or Submit for the task to continue processing.

   To React to CALL Requests

   The information about the request is provided in three tabs. The Message tab is displayed by default and shows the text of the request.

   1. Do one of the following:

      • Click Accept to assume the responsibility for resolving the request. The request remains in the list and visible to all recipients until you press Done.

      • Click Reject if you are not going to resolve the request. If all recipients reject the request, or if it remains unattended for the period of time defined in the Notification object, the following can happen:

        If the Notification object that triggered it is configured to escalate it, the request is escalated. This means that the follow up Notification object assigned to the escalation is triggered.

        If not, the request notification is displayed again to all recipients.

   2. Take the actions that are necessary to resolve the issue addressed by the request.

   3. Optionally, open the Comment tab and enter information about the actions that you have taken. All other recipients can see your comment and add new ones.

      Maximum length: 1024 characters

   4. When you have finished, click Done. The request is now removed from the list.

   The Recipients tab shows the list of users that have received the request. The Status column lets you know what has happened to the request. The following status are possible:

   • Called means that the request has been delivered to the user but no action has been taken yet
   • Accepted means that the user has taken responsibility over the request
   • Rejected means that the user has not accepted the responsibility over this request

   To React to Activation Report Requests

   For Activation Reports there are no action options since they serve for information purposes only.

To Check What You Have Done to Resolve the Request

Do one of the following:

• Open the Executions list of the task. If necessary, open the Last Report of the execution and check the changes.
• If the task runs in a parent object (Workflow or Schedule, for example), open the parent monitor and check the changes in the Executions list and Last Report there.

Working with Requests in Bulk

You can perform operations on requests either individually or in bulk. If you select multiple requests of different types, the toolbar shows the options that are common to all selected types only.

To submit requests in bulk you must select requests of the same type.

See also:

Opening and Arranging Multiple Views