Requests

Requests are the requests that are processed within a process. Each request is an action in itself and contains all the necessary information to process a request. These requests are linked to a process with the underlying process steps underneath.

Priority

From Spider version 1.6.11 new functionality is added where requests and processSteps now have a priority status.

More information can be found at: Priority Requests

Statuses

In a global view, a request goes through a number of statuses to characterize whether it has been handled successfully or not. Some request processing requires approval from a second robot (four eyes) or approval or disapproval from a person (NeedsOk).

Because each request has an Id within the Spider, the track and trace of the request can be found in every aspect of Spider. The image below can also be found in the Spider Dashboard. Clicking on the "cards" will take you to all requests that have this status at once.

Todo

Requests that are ready to process. This can be scheduled rquests or normal requests. They can be imported from RPA robots or other applications that have access to the Spider. Click on the card to go directly to the requests that have the To do status.

Tip

It makes sense to then create a change request, otherwise it will be included as Failed in the Mt Info which may not be the intention. More information about Changed Requests

Drop functie

Starting from version 1.9.0, you can now drop one or more requests that have been added incorrectly, for example. Additionally, you can adjust the page display by changing the number of requests per page from 50 to 100.

This makes the work for an operator much easier, allowing them to act more quickly on changes.

This functionality is only available on the Todo page.

Running

As a robot submits a request to the Spider (reserving work), only the status of the workload is set to reserved (WRR) and the request moves to running, once it is started.

A request will only be in running once, unless it is offered again from RFN. After the robot has started/finished the first process step it will remain in running until the request goes to failed or all process steps have been successfully processed.

If a request remains in the running state, depending on the scraping time, the request is moved back to the todo, running (if the first process step is successful) or to the failed state.

A request can also be manually dropped from the running status by clicking on the [x] behind the request. After this the request is back in the Failed state.

Tip

The status of the request can still be changed after this. For example if this request is offered again. More information about Changed Requests

NeedsOK

As soon as the robot activates a NeedsOk, a person must give an approval or rejection. The Spider will send an email to the individuals who have the checkbox for NeedsOk selected in the process SLA. A request will not be processed further until it is either approved, rejected, or the time to respond has expired.

It also can be seen in the Spider dashboard in the 'card' NeedsOk.

If no timely action is taken on NeedsOk requests, they automatically move to Failed or RFN (depending on the process step). Requests with this status can be found under Menu > Confirmations > Needs Ok or by clicking on the Card from the dashboard.

If the person rejects a request, it receives a final status and can be found under `Menu > More Change Requests > Failed Requests.

If the person approves the request, the Spider will make the request available again for further processing.

Success

A request has been successfully processed. All underlying process steps have been completed

Succes And Finish

As of version 1.7.0, it is possible to skip underlying Process Steps and set them to a SuccessAndFinish state. The request will be marked as Success. This functionality is used when it is not necessary to execute further process steps and the request is already successful. The request is then no longer seen as a Failed request. An example of this:

Failed

Somewhere in the process, something went wrong. Either through process processing, a business rule or a human action (operator). A failed request can be completely false (Failed) or based on process processing (RFN).

From the Dashboard, you will see a request that has a Failed state. If you click on the Card you will see more detail.

ParentId

A parentId is used as a reference in requests for Track and Trace. To find out from which previous request a request comes you can click on the ParentId. The condition is that there must be a ParentId.

Click on the ParentId to view the details

ParentId - Child requests

Check the extra tab(Child) to see the child requests.

RFN

RFN requests are requests that have failed and can be reprocessed. They give an operator the option to either drop the request or resume it from a specific process step. The Spider then automatically assigns it again to a workstation.

Info

Starting from version 1.12.0, a search function has been integrated into the page. If there are multiple requests spread across several pages, it becomes easier to filter them.

• (1). Filter by a process subject
• (2). Filter by a requestId
• (3). If known, filter by a parentId. What is a parentId: ParentId info

An RFN request can be found in the Failed overview and is marked as RFN (Request Fail Not Reported).

If it says Request Fail Not Reported here, you can find this request in the menu Menu > Confirmations > RFN Requests.

For more information on the request, click on the (i) icon to view the Audit Trail.

There are several options for reprocessing an RFN request:

• Resubmit request, but reset the reports
• Resubmit request from the next step, once the previous steps have been successfully processed
• Approve the request after all Changed Failed ProcessSteps
• Drop request

RFN - Reports reset

If reports have already been created within the request, a choice can be made to reset one or more reports so that they are newly created on restart.

RFN - ProcessStep 1

Returning a request from the first process step. This is only possible if the request goes wrong at the first process step. Open the request

then you can select only the first process step. After this, click Restart. The request is offered to the Spider again.

RFN - ProcessStep keuze

• If the first process step has already been executed, the request can be completely restarted again, or it can be started from the next process step.

RFN - Drop

You want to drop the request instead of offering it again, so that it ends up with a Failed status.

This can be done in two places:

RFN Drop overview

Navigate to Confirmations > RFN Requests and click on (X).

RFN Drop Info

You want to see more information of the request and then decide if you want to restart it or drop it.

Navigate to Confirmations > RFN Requests and click on the (i) icon.

Click on Drop.

Failed End State

Once a request has a "true" Failed status (end status failed), it cannot be processed again.

Returned

Requests that have transitioned into a new request at a later time.

Changed

More information about changed requests: Changed Requests

Request Logging

Logging is present in the Spider for the requests processed. Clicking on one of the Cards in the dashboard will take you to the logging of a request.

If you click on a RequestId, you will automatically be pointed to the Request Log page.

Request Logs

Now if you need more detailed information of a particular request and you already know the RequestId, you can go directly to Request Logs from the menu. You can find the logs from the Menu > Information > Logs > Request Logs. Enter the Id in the search field and click Search. We are showing some statuses as an example.

Request Failed

Request Running

Request Success

Request Info

The spider provides a detailed view of information logging a request. By clicking on the Info icon next to the request, you will get a quick overview of the status of the request.

Info

Since version 1.9.0 the priority of the processStep is added to the information screen.

Explanation:

• [1] Process - To which process does this request belong.
• [2] Status - What is the global status of the request.
• [3] Which processStep and priority
• [4] Process step status - The status of the process step.
• [5] Body - What body information is included in the request.
• [6] ParentId - From which previous request does this request come.
• [7] Insert Date - When was this request inserted into the Spider.
• [8] Start Date - The date on which the robot may pick up the request .
• [9] Actual Start Date - The actual date/time the request started.
• [10] Finished Date - When was this request last processed.
• [11] Reports - What reports have been created on this request.
• [12] Signals - What signals have been created on this request.
• [13] Number of times restarted - The number of times this request has been presented to the robot again.

Request Details

To get more detail click on the [+] icon. This way you can find out what happened to the request and what problems there might be in the process.

Request Search

You can also find this via Information > logs > Request Search.

Select the process you want to search within. Then you can search by:

• Body
• Variable(s)

Here, you can search for variables or body information contained in a request. This is also the fastest way to find something from the past. In the example below, we want to know which requests have been processed where "Jacksonville" appears within our process.

This way, further information can be looked up for a request. By clicking on the requestId, you will be directed to the request logging.

Starting from version 1.7.0 variables marked as deleted for privacy reasons are no longer included in the search function.

Tip

The condition is that you must be within the SLA within the process, otherwise, the requests cannot be viewed.

Diagram

The diagram below provides insight into a request processing by a robot. This is still without "Needs Ok", "RFN" and "RFC" capabilities.

Info

March 2024: This process diagram is scheduled for an update.