Requests

Requests are messages that are displayed during the execution of objects. Requests either require you to enter data for further processing or they draw your attention to potential problems. Tasks that have still unattended requests have the 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 object 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.

This page includes the following:

Notification of Requests

When a request is triggered, the following happens:

Types of Requests

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

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.

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.

PromptSet Requests

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

Note: When you define an executable object, you specify when it should be generated on its Attributes Page. If you want the Requests dialog 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: 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.

:READ Statement Requests

:READ requests are similar to PromptSet requests, although they create much simpler, one-line input fields. The main differences are:

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.

Working with the Requests Dialog

Detaching the Requests Pane

By default the Requests dialog is displayed in the middle of your screen blocking the main page. To detach it, click the detach button on the top right corner of the dialog. This opens a dedicated browser window with the list of requests. This way you can arrange this and any other windows side by side, which is helpful when comparing values or investigating the reason for a problem.

Reacting to Requests

Requests are removed from the view only after you have clicked the Submit button, which implies that you have taken care and resolved it. When you submit a request, its status changes to Done and the task ends its execution.

To check what you have done to resolve the request, do one of the following:

The Requests view consists of two panes, the list of tasks on the left and the content pane on the right. To react to requests, do the following:

  1. Select an entry on the left pane to display the content of the request on the right pane.

    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.

    Use the dropdown at the top to filter the list of requests by their type.

  2. 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 vary from short descriptions, to one-line input fields created by :READ statements, complex forms created by PromptSets.

    To React to PromptSet 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 :READ Statement Requests

    Enter the required value in the input field and click Submit.

    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 pop up is displayed again to all recipients.

    2. Take the actions that are necessary to resolve the issue addressed by the request.
    3. 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.
    4. When you have finished, select Done and click Submit. 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
    • Accepted means that the user has taken responsibility over the 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: