RPA 개발의 특징인 자동화를 다룰 예정입니다. 개발자가 전통적인 IT language 또는 솔루션과 가장 크게 차이점을 느끼는 것이 대상을 인식하고, 인식한 대상에게 작동하는 부분일 것입니다.
이 때 대상을 인식하는 방식은 크게 오브젝트로 인식하는 것과 이미지로 인식하는 2가지가 있습니다. 통상적으로 이미지 인식방식은 해상도의 UI옵션설정에 영향을 받을 수 있어 오브젝트 인식방식이 더 안정적인 방식으로 받아들여지고 있습니다.
오브젝트 인식이란 대상 화면 내 여러 객체의 속성값을 구분하여 원하는 객체를 인식하는 방식입니다.
¶ 오브젝트 인식
¶ 작동방식
-
a.works가 프로그램에 Click을 발생시키는 방법은 두가지가 있습니다.
-
이 두 가지 옵션은 Software, Hardware로 UI 자동화중 입력을 처리하는 모든 이벤트아이템에 속성으로 정의되어 있습니다.
-
기본은 Software로 사용하고 정상작동하지 않을 경우에만 옵션을 변경하면서 테스트합니다.
- Hardware
- Hardware Driver를 이용한 입력 방식.
- 단, 실제 마우스와 동일하게 동작하며, Button Down이 선동작하지 않으면 Button Up이 수행되지 않음
- Software
- Software를 이용한 입력방식.
- 단, Button Down이 선동작하지 않더라도 Button Up이 수행 됨
- Hardware
¶ 오브젝트 인식 방법
-
a.works가 오브젝트를 인식하는 방식은 6가지 중 선택할 수 있습니다.
-
Selector Mode라고 표현되고, Automatic, MSAA, UIA, IE, JAVA, SAP가 있습니다.
-
Function key F4를 클릭하면 모드가 변경됩니다.
-
Default는 Automatic 모드로 대상 오브젝트에 가장 적합한 방식을 자동으로 설정합니다.
-
오브젝트가 원하는 형태로 인식되지 않을 경우 모드를 변경하면서 테스트합니다.
구분 설명 MSAA 기술내용은 포스코ICT에게 문의 필요 UIA 기술내용은 포스코ICT에게 문의 필요 IE 대상 오브젝트가 IE인 경우 선택 JAVA 대상 오브젝트가 java로 개발된 경우 선택 SAP 대상 오브젝트가 SAP인 경우 선택 Automatic 자동 선택
¶ Selectors
-
자동으로 생성된 Selector를 사용하면 일시적 속성이 포함될 수 있기 때문에, 수동으로 그 Selector를 수정해 주어야 할 때도 있습니다.
-
안정적인 Selector는 개발/테스트/운영 등의 환경 변화나 사용자 ID 등에 상관없이 항상 같은 오브젝트를 성공적으로 식별할 수 있어야 합니다.
-
이렇게 Selector를 개선하기 위해 Object Editor를 사용하는 팁들이 있습니다.
-
위의 selector를 보면, aa_name에 특정 제목이 있는 것을 볼 수 있습니다. 이 속성들을 수정하여, 다음과 같이 두번째 row를 찾는 개선된 Selector를 구할 수 있습니다.
- 일시적 속성값들은 유지가능하고의미있는 값으로 바꿉니다.
- 속성값의 가변 부분들은 와일드카드(*)로 교체합니다.
- 속성값이 모두 와일드카드(예, name=’*’)면, 다른 속성은 모두 삭제합니다.
- idx 속성값은 1이나 2처럼 아주 작은 값이 아니면 사용하지 않습니다.
- Selector에는 String 표현식으로 변수를 이용할 수 있습니다.
¶ 이미지 자동화
이미지 자동화는 대상업무시스템이 UI자동화를 할 수 없는 비표준 기술에 의해서 개발되었거나 Citrix 등과 같은 VDI환경에서 자동화해야 할 경우에 사용합니다.
이미지 자동화 관련 이벤트아이템은 지정된 이미지의 템플릿을 지정하고 그 위치를 화면에서 검색하고 위치에 마우스를 통해 입력하여 자동화를 수행합니다.
이미지 자동화를 이용하여 업무를 수행할 경우 반드시 화면에 대상 업무시스템이 표시되어 있어야 하며, 숨겨진 상태에서는 자동화를 수행할 수 없습니다.
이미지의 템플릿(작은 이미지 조각)을 지정하고 그 해당 이미지가 화면에 나타난 경우 위치를 찾거나 마우스를 그 위치에 클릭, 더블클릭하는 등의 자동화를 수행합니다.
이미지 자동화를 통해 개발 시, 다음을 고려해야 합니다.
-
해상도
- 이미지 인식은 데스크탑(PC)의 윈도우 테마나 화면 해상도 같은 환경변수에 민감합니다.
- 프로그램을 Citrix로 실행할 때, 해상도는 태스크 개발 시의 크기 보다 크거나 같은 해상도로 유지되어야 합니다.
- 아니면, 작은 이미지로 인한 왜곡을 보상하기 위해 캡처된 이미지의 정확도(일치율)을 낮춰야 합니다.
- 시각적 요소의 유사성을 보증하려면 해상도가 다를 경우 프로그램이 어떻게 조정되는지를 체크하여야 합니다.
- 특히 Offset 옵션을 이용한 좌표기반 기법을 사용할 때 더욱 주의해야 합니다.
-
OCR 엔진
- OCR 인식 결과가 좋다면, 환경적인 영향을 최소화하기 위해 텍스트 자동화를 대안으로 시도해보는 것도 좋습니다.
- OCR 엔진마다 특성과 인식율의 차이가 있습니다.
- OCR엔진을 사용할 때는 인식율 테스트가 반드시 선행되어야 합니다.
- 인식율 테스트는 대상 텍스트의 성격에 따라 달라지겠지만, 일반적인 경우에는 한글, 영문, 숫자가 혼합된 형태로 테스트되어야 합니다.
- OCR이 반드시 필요한 경우라면 상용서비스를 제공하는 민간기업의 OCR엔진도 선택의 대상이 될 수 있습니다.
- Google Cloud, MS Azure, AWS Service 등에서 제공하는 OCR 엔진의 인식율은 상당히 높습니다.
- 네이버에서 준비하고 있는 클로바 서비스는 한글인식에 강점이 있으나 아직 상용서비스를 시작하지 않았습니다.
- 적용 대상업무의 효과성과 상용서비스 비용을 비교하여 도입을 검토할 수 있습니다.
¶ 화면 동기화
-
RPA의 특징을 한가지 더 본다면 바로 이 화면 동기화입니다.
-
전통적인 프로그램이 실행할 때 영향을 주는 것은 실행 당시의 네트워크 속도, DB 성능, 실행하는 서버 또는 데스크탑의 물리적인 성능(CPU, 메모리 사용율 등)일 것입니다. 즉 H/W적인 요소만 해당됩니다.
-
그러나 RPA는 물리적인 요소에 영향을 받는 S/W(대상 시스템들, 사용하는 애플리케이션 들)의 상태에도 함께 영향을 받습니다.
-
예를 들어 로그인 해야하는 그룹웨어가 서버 성능으로 인하여 속도가 느리다면 로그인 화면은 매우 느리게 열릴 것입니다. 그러면 RPA 로봇은 로그인 화면의 상태를 체크하면서 대상 화면의 속도에 맞게 천천히 수행해야 합니다.
-
그렇지 않으면 로봇은 실행오류를 일으킬 것입니다. RPA 업무프로세스를 개발할 때 중요하게 확인해야 하는 부분입니다.
-
RPA에서는 요구된 프로세스 각 단계의 자동화를 수행하기 위해서 버튼을 클릭하거나 키보드 또는 마우스의 입력 등을 구현합니다.
-
화면 자동화 수행은 로봇 PC에서 동작하는 애플리케이션의 오브젝트를 셀렉터(Selector)에 의해서 찾고, 그 오브젝트에 지정된 행동을 수행하기 위해서 자동화 이벤트아이템을 사용합니다.
-
예를들어, 통합업무시스템에서 업무코드를 입력하고 업무화면으로 이동하는 동작의 경우, 업무화면을 실행하게 되면 원하는 업무화면이 실행되었는지를 확인한 뒤에 다음 단계로 이동하여야 합니다.
-
만일 그 업무화면이 실행되지 않았을 때 다음 단계를 수행한다면, 개발자가 기대한 동작이 수행되지 못할 가능성이 높기 때문입니다.
-
마우스, 키보드 등의 입력으로 인해서 새로운 화면의 전환이 발생하는 경우, 그 화면의 상태를 확인한 후에 다음 단계의 동작으로 넘어가야 합니다. 아래는 그에 대한 몇 가지 원칙입니다.
- 대상 프로그램이 로봇이 기대하는 상태가 되지 않는 예기치 않은 상황이 발생할 수 있습니다. 이 경우 처음으로 확인해야 하는 것은 로봇의 동작에 대해 프로그램이 응답하는데 걸리는 시간입니다.
- Before Wait Time, After Wait Time 속성을 사용하면 프로그램이 응답하기 전 기다리는 시간을 설정할 수 있습니다. 하지만, 특정 스텝으로 진행하기 전에 프로그램의 상태를 검증해야 하는 상황이 있을 수 있습니다. 적합한 이벤트아이템을 적극 활용하여 상태를 검증하도록 해야 합니다.
- OCR Text Exists, Exist File, Exist Directory
- Object Match, Image Match
- Find Process
- Open Browser, Start Process 이벤트아이템 등으로 애플리케이션을 실행했을 때는, 해당 화면이 실행되었는지 확인한 후 다음 동작을 수행합니다.
- 버튼 클릭 또는 마우스 입력 등의 결과로 새로운 윈도우가 실행될 경우, 해당 윈도우가 실행되었는지 확인(Object Match, Image Match 등) 후 자동화 동작을 수행해야 합니다.
¶ Queue 활용
-
연관된 2개의 업무 프로세스가 수행순서에 따라 데이터를 전달하는 경우이거나, 업무 프로세스의 수행조건이 외부 시스템(레거시 시스템, api 호출 등)과 연계하여 데이터를 생성하는 영역과 데이터를 가공/처리하는 영역으로 분리되어 있는 경우에 Queue 활용을 적극적으로 검토할 수 있습니다. 데이터를 생성하는 영역을 Dispatcher라 하고, 데이터를 가공/처리하는 영역을 Performer라 합니다.
-
Dispatcher에 의해서 데이터가 지정된 큐에 추가되고, Performer가 실행되면서 실제 업무 프로세스가 처리됩니다. Dispatcher와 Performer는 꼭 1:1일 필요는 없습니다. 데이터 생성의 원천이 다양하면 그 만큼의 Dispatcher가 있을 수 있으며, Queue에 쌓이는 데이터가 많으면 필요한 만큼 Performer를 늘릴 수 있습니다. Queue 활용모델은 이러한 유연성으로 인해 활용가치가 있습니다.
-
동일한 업무 프로세스에서 대량의 업무건을 처리할 때, Queue 활용의 효과가 증대됩니다. 대량의 반복적인 업무는 하나의 로봇에서 수행되기 보다는 유휴 로봇을 최대한 활용하여 동시에 업무를 수행하게끔 구현할 수 있습니다. 대량 업무의 실행 명령을 전달하는 방법으로 Queue를 사용할 수 있습니다. 업무 프로세스는 지정된 Queue에 처리할 데이터가 남아 있는지 확인하여, 잔여 업무건이 없는 경우 종료하게 됩니다.
-
Queue를 활용하고자 할 때, 그 설계와 구현에 있어서 고려해야 할 사항은 다음과 같습니다.
- Queue 데이터 항목 선정
- Queue 생성 및 할당
- 업무 데이터의 입/출력 설계
- 한 건의 업무 수행 후 결과 리포팅 방법
- (필요시) 전체 건 수행완료 후 결과 리포팅 방법
¶ Queue의 명명규칙
- Queue명 : Q_[과제코드]_[Queue 명]
- Queue를 사용하는 프로세스의 코드를 포함시켜 어떤 업무 프로세스에서 사용되는 지를 명시합니다.
¶ Reference Key
- Queue의 업무 항목(QueueItem)을 각각 유일하게 구별하기 위한 값이 있어야 합니다. 고유한 참조값은 이미 처리된 데이터인지를 구별할 수 있는 값으로 업무의 번호, 고객의 번호 등으로 대체하여 사용할 수 있습니다.
¶ QueueItem 사용
- Performer가 수행되기 위해 필요한 데이터는 업무가 요구하는 기본 정보입니다. QueueItem은 DataTable 형태로 사용할 수 있습니다. 통상적으로 1개의 QueueItem에 1개의 Row가 있는 DataTable을 저장합니다.