Filtering Query for Orchestrator API (Swagger)

Help Orchestrator
, ,
1

Hello everyone,
currently I am facing a challenge when using querys via the Orchestrator API (Swagger).

General Information
Generally, we have a standard logging-scheme for robots which includes the following three transaction end-states:

  • “Processing status: Successful”
  • “Processing status: Business Rule Error”
  • “Processing status: Technical Error”

The corresponding status is logged by every robot after each transaction with the activity Log-Message.

Actual Challenge
We decided to use a script via VBA so we can post API-Request towards the Orchestrator-API. This way we want to generate a reporting, which summarizes the accumulated amount of each processing status for a given period of time for each robot.

For example:
Period of Time: 01.01.2024 - 31.12.2024
Robot: Example-Robot
Count for Successful: 350
Count for Business Rule Error: 100
Count for Technical Error: 50

When trying to query the count for the different states we use the following filter-function:

Filter: (Contains(Message,‘Verarbeitungsstatus’) and Contains(Message,‘erfolgreich’))
Select: Message

RequestURL: https://exampleURL.de/odata/RobotLogs?%24filter=(Contains(Message%2C’Processing status’)%20and%20Contains(Message%2C’Successful’))&%24select=Message&%24count=true

Unfortunately the results still include Log-Messages with other states. For example:

{
“@odata.context”: “https://exampleURL.de/odata/$metadata#RobotLogs(Message)”,
“@odata.count”: 4,
“value”: [
{
“Message”: “Processing status: Successful”
},
{
“Message”: "Processing status: Successful "
},
{
“Message”: “Processing status: Technical Error”
},
{
“Message”: “Processing status: Business Rule Error”
}
]
}

Is there somebody who knows how to handle this?

Thanks so far!
Yannik

2

Hey. Why poll logs when you can poll queue items and filter by status? Unless your “Technical Error” is not the same as System Exception.

The endpoint for retrieving queue items is described here: Orchestrator - Queue Items Requests

3

Hey Mateusz, unfortunately we do not use queue items as standard, and since there are over 100 robots it is not an option to change all of them to a queue-based working-mode. Do you have another idea?

4

Hmm it’s not usually a good idea to reinvent the wheel. With such custom built framework it’s harder to find solutions online, like you’re just witnessing now :slight_smile: give me one moment to play around with similar query myself.