• 2024/05/04

AddQueueItem을 사용하게 되는 환경

UiPath Academy를 통해, 여러가지 과제를 수행하다 보면 Dispatcher와 Performer라는 개념에 대해 배우게 된다.
여기서 Dispatcher는 Unattended Robot(이하 UR) 혹은 Attended Robot(AR)이 바라보는 Queue에 Queue Item을 적재하는 역할을 하며, Performer는 UR 혹은 AR이 업무를 수행하는 그 자체라고 설명한다.

하지만 이러한 경우, 한 가지 프로세스에 대해 두 개 이상의 Robot 혹은 하위 프로세스를 요구하는 것과 마찬가지인데다가, UR의 경우에는 업무 수행 요청자가 Queue Item을 적재하기 위한 기본 조건이나 그 외 UiPath에 대한 필수적인 교육이 뒷받침 되어야 하는 경우가 종종 발생할 수 있다.

게다가 Cloud 나 Web 환경이 적절하게 구축되어 있는 사무용 환경에서, 프로세스 하나 가동하자고 비용과 시간을 들여 교육 및 자원을 소모할 필요가 있을까에 대한 의구심과 경제성에 대한 불신을 가지게 될 수도 있다.

이러한 상황에 대한 해결책이 Web API를 통해, Queue Item을 추가하는 Orchestrator 제공 API이다.

Orchestrator API

내부망에서는 Orchestrator의 웹 주소 뒤에 /swagger/ 를 입력하여 접속하면, API를 확인할 수 있는 페이지로 이동이 가능하다. Cloud 에서도 접속이 가능하긴 한데, 인증 문제 때문에 실습하기는 어려운 형태로 되어 있다.

혹시라도 Cloud 환경의 API에 대해 확인하고자 한다면 다음 링크를 참조하자.

UiPath Cloud Swagger : https://platform.uipath.com/default/default/swagger/

AddQueueItem API 구조 살펴 보기

Queue 하위의 API들

우리가 보고자하는 것은 Queues의 두 번째에 있는 POST 타입의 AddQueueItem 이다.
AddQueueItem API는 기본적으로 CRUD 중에서 C에 해당되며, 더군다나 POST 타입이기 때문에 사용 시에는 서버 환경에 대해 충분히 파악한 후에 사용하도록 하자.

크게 body, expand, select, X-UIPATH-OrganizationUnitId 로 구성되어 있다.

이 글에서 주로 살펴볼 것은 body 부분이다.

구조(application/json)

각 Key에 대한 설명은 다음과 같다.(오케스트레이터 한글 기준)

  • Name : Queue의 이름
  • Priority : Queue Item의 우선 순위(High, Normal, Low 세 가지로 설정 가능)
  • SpecificContent : Queue Item에 넣을 데이터
    Json 형태로 넣을 수 있으며, 데이터 구조의 depth(수준)는 1단계만 지원한다. 2단계는 지원하지 않으며, 2단계 json 구조를 입력할 경우, 2단계 하위에 중복되는 key name은 중복처리 되어 API가 실행되지 않는다.
    예를 들어, “user” : { “name” : “홍길동” }, “cert” : { “name” : “hongGD” } 를 입력할 경우 “name”이 중복된 것으로 인식해버린다.
  • DeferDate : 유효한 시작 시간. 트랜잭션 리스트에서는 “연기”에 표시되는 시간이다.
  • DueDate : 유효한 기한. 트랜잭션 리스트에서는 “기한”에 표시되는 시간이다.
  • RiskSlaDate : 해당 Queue Item의 처리 기한이 임박(Risky)하다고 간주되는 시간이다.
  • Reference : Queue Item의 “참조”에 표시되는 내용.
    개인적으로는 트랜잭션 리스트에서 Queue Item을 직관적으로 구분하기 위해 사용하곤 한다.
  • Progress : 프로세스의 진행률을 기록할 수 있는 필드.
    별도의 액티비티를 사용해야 하는 것으로 알고 있다.(제보 부탁드립니다.)

API의 활용

웹 페이지에서 간단한 설정(드롭다운 혹은 체크박스, Input 필드 등)을 통해 마우스 클릭 몇 번만 거쳐 Queue Item을 손쉽게 설정할 수 있는 API의 활용은 상당한 비용과 시간을 아껴줄 수 있을 것이다.
특히, RPA라는 개념이 시장에 전파되고 있는 지금 시기에, RPA 포털 서비스와 RPA 작업 환경을 동시에 구축하고자 하는 조직이나 기업들의 경우에는 단순히 API를 이용해 오케스트레이터나 프로세스의 상태 만을 보기만 하던 상황에서 RPA 포털을 통해 조직원들이 능동적으로 RPA Bot을 실행시키도록 하여, 관리 포인트를 줄임과 동시에 업무의 효율화를 꾀할 수 있는 더 많은 기능을 제공하고 있으니, RPA 개발자라면 한 번 쯤은 참조하거나 아예 공부해보는 것도 좋은 길이라 생각한다.

Leave a Reply

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다