Queue Schema Validation Does Not Return Helpful Exception Message

Feedback Orchestrator
,
1

When applying a schema validation to an Orchestrator Queue, one would hope that there would be an exception message that would explain which field(s) did not properly validate and also the reason. Currently it only states that there was an exception validating, and it does not even fill in the CSV line numbers when attempting to manually input a file to the queue:

image
image594Ă—850 38.9 KB

This is extremely important if trying to integrate UiPath processes into a broader company-wide network of processes where other teams would want to use the AddQueueItem endpoint and hope to get back some validation reason instead of that the data simply did not pass if that is the case.

I have tried looking into the forum history, and I only found two tangentially related forum posts. Others seem to have the same sort of issue, but the real heart of the problem is the Orchestrator not giving back enough information to diagnose the problem:

3

I wanted to update this to hopefully bump the issue but also give an example of how this is going to present as a huge maintainability issue if pushed to production as-is:

Imagine that there is an enterprise-level process that would like to leverage UiPath. The current enterprise process uses API calls to push data, so it would like to use a UiPath endpoint to be able to send the data over, the obvious option would be to use the AddQueueItem endpoint that is provided by the Orchestrator out-of-the-box. Wanting to be able to give some early validation warnings synchronously (knowing that final success/failure can only be given asynchronously and could potentially take a long time depending on average transaction processing time and queue), one would expect to provide a queue schema. When the enterprise process starts sending data, they are either going to get back a 201 success code or an exception. The exception message is simply something like “Data did not meet the queue schema requirements.” This means that there are going to be questions relating to why that specific payload was not accepted by UiPath, and the UiPath developer that is tasked with figuring out is not going to have any further information to go on.

Best case scenario:
UiPath to give a full error message with the fields that exceptioned out, the values passed, and the validations that it did not pass (note that this could mean things like with If-statements with compound validations, not just field values)

Workaround 1 (Validations, but slow):
Could keep the validation schema in an asset, when the transaction is picked up to process, then it can be checked against using the json schema format.

Workaround 2 (Validations, but not as slow):
Have a separate process that listens to an input queue for the data where the queue does not have validations. This process solely does validations and either responds back to the enterprise process with a helpful validation exception or passes the work to the work queue

Workaround 3 (Rely on sanity checks):
Not as good as using the schema validation depending on the sanity checks and all validations would likely be given on a per-field basis instead of everything together. This is also harder to update if field changes are made.

5

I am experiencing the same issue currently with a json schema queue and am looking for the fix if anyone has found it. Thanks!

1 Like