Known Issue: An error occurs when you create a REST Service Instance for UiPath

  • 16 February 2021
  • 0 replies
  • 35 views

Badge +9
 

Known Issue: An error occurs when you create a REST Service Instance for UiPath

KB003613

PRODUCT
K2 Cloud Update 12
K2 Five 5.4

 

Issue Description

When you create a REST Service Instance for UiPath an error occurs stating: “SmartObject Server Exception. A nested transaction was not committed”.

Cause

UiPath has changed their authentication method and does not support basic authentication on the Cloud. K2’s integration was designed for basic authentication, and in the current process, it will not work for Cloud UiPath as you cannot use static credentials on a Public Cloud API. UiPath changed how we authenticate with the API.

As per their documentation https://docs.uipath.com/orchestrator/v0/reference/consuming-cloud-api, this has not changed for on-premises Orchestrator or Orchestrator installed in your Private Cloud. This means they have changed their authentication process which require new fields to be sent in body and request header. There have been other changes such as UiPath needing to send the tenant name along with bearer token in the headers with every request.

The current process that K2 uses to integrate with Ui Path uses a REST Broker with OAuth. We have tested with the new OAuth2 parameters and the customer header with the REST broker and it does not support it. The REST broker would need to be rearchitected to use the new functionality.

Resolution/Workaround

Currently there is no workaround available. The development team are busy investigating the possibility for an enhancement.

Considerations

UiPath does still support the original OAuth authentication on UiPath on-premises and UiPath on Private Cloud. This means K2 supports UiPath for their on-premises customers as well as their customers with a Private Cloud setup.

 

A Private Cloud can either be inside an organization or remotely managed by a third party and accessed over the Internet (but unlike a Public Cloud, it is not shared with anyone). This explains why Private Cloud and on-premises support Basic Authentication which uses a username and password with a token.

 


0 replies

Be the first to reply!

Reply