개발 갈무리

현상 : AR인 곳에서 batch 파일이나 스케줄러를 통해 프로세스를 실행시키고자 할 때 발생. 이벤트 뷰어에서 "Please provide the Folder Path for process" 라는 문구가 뜸

원인 : 오케스트레이터 다른 폴더내에 같은 프로세스명이 있어 어떤 걸 실행시킬지 판단 불가

조치 : 오케스트레이터 폴더 path를 인수로 주거나 겹치는 프로세스를 삭제

https://docs.uipath.com/robot/docs/arguments-description

예시 : UiRobot.exe execute --process UiPathDemoProcess --folder OrchFolder1 --input "{'inArg' : 'value' , 'Integer' : 3}"

조건문을 쓰다 보면 And와 Or를 자주 쓰게된다.

그러나 항상 불편한 점이 있다.

ex) dtContainer isnot nothing AND dtContainer.rows.count > 0

예시와 같은 조건을 걸면 dtContainer가 Nothing인 경우에 에러가 난다.

Nothing인 DataTable에 .rows라는 메서드를 적용할 수 없기 때문이다. (NullpointException)

물론 이런 경우 미리 build data table을 해서 테이블 기본 할당을 해놓고 row만 체크할 수도 있다.

하지만 이는 개발관점에서도 비효율적이고 프로세싱에서도 손해가 있는 방법이다.

첫번째 조건이 False일 때, AND로 이어진 구문은 더이상 검사할 필요가 없다

마찬가지로 Or로 이어진 구문도 앞에 나온 조건이 True면 Or 뒤에 구문은 볼 필요가 없다.

Uipath에서 이런 기능을 해주는 것이 AndAlso, OrElse라고 한다.

[파이썬에서는 And, Or만 있고 이게 기본적으로 AndAlso, OrElse의 기능을 함]

따라서 And와 Or는 항상 AndAlso, OrElse에 비해 어떤 상황이든 효율적이지 않다.

앞으로는 개발 시에 AndAlso, OrElse로 바꿔적으려고 한다.

설계와 개발을 하다보면 바로 정보를 가져올 수 없거나 인식 기점을 직접적으로 가져올 수 없는 경우가 있다.

혹은 직접적으로 가져오는 경우 예외 케이스가 많아지는 경우도 있다.

그 경우 Proxy 연상이 필요하다.

예시1)

조회 후 로딩이 끝나면 엑셀 다운로드를 눌러 파일을 다운로드 하는 진행에서

로딩이 언제 끝나는지 체크가 되지 않거나 힘든 경우를 가정하자.

그럼 보통은 delay를 주고 로딩 이미지 exist를 찍었다가 false면 진행시키려고 했다가

로딩 이미지 인식이 제대로 안 되거나 움직이거나 하는 케이스들로 고생하는 경우가 많다.

position attribute 등으로 직접적인 커버를 할 수도 있으나

기본적으로는 로딩 자체가 모달 팝업같은 형태를 띄기 때문에

로딩 중에는 화면 내 input이 작동하지 않는다.

따라서 그냥 엑셀 다운로드를 누르고 다운로드 창이 뜨는지 retry scope으로 체크해도 같은 효과를 볼 수 있다.

예시2) 

가령 RPA가 수행될 때 녹화가 수행되도록 하기 위해 녹화 프로그램의 단축키를 누르는 상황이 있다고 하자.

이 경우 녹화 프로그램을 켜고 단축키를 눌렀을 때,

폴더에 녹화를 위한 새 파일이 생겼는지를 체크하는 게 직접적이다.

이때 가장 정확한 방식은 기존 폴더의 최신 파일이름과

녹화 단축키 버튼 Send 후 폴더의 최신 파일이름을 비교하는 방식일 수 있다.

그걸 비교하기 위해서는 기존 폴더의 최신 파일이 없이 이번 녹화파일이 해당 폴더의 첫 파일인 경우 등을 고려해야 한다.

그러나 단축키 send 직전 폴더의 파일 개수를 세고 그보다 늘었는지를 체크하기는 쉽다.

좋은 개발자라면 위의 예시를 보는 중에 의문이 생길 수 있다.

'로딩이 안 끝나도 클릭이 돼버리면 정합성 문제가 생기는 거 아닌가?'

'그 타이밍에 임시파일 등이 생기면 틀어지는 거 아닌가?'

너무 당연하게도 proxy 연상을 통한 방식은 직접적이지 않기 때문에 틀어질 가능성은 있다.

다만 살짝만 보완해도 직접적인 방식과 거의 같은 수준의 안정성을 보여준다.

가령 임시파일이 생기는 케이스의 경우 확장자를 mp4 같은 영상 확장자로 필터링하면

.dat 같은 임시파일에 대해 신경쓰지 않아도 된다.

RPA Studio단에서의 설계는 이런 형태의 Proxy 연상이 빠르게 가능해지면서 성장하는 편이다.

어떤 면에선 '잔머리'라고도 볼 수 있다.

잔머리가 무조건 좋은 건 아니지만 초보 개발자일수록 너무 어렵게 생각해서

개발을 못 하는 케이스가 많아 글을 써본다.(나 포함)

그런 경우 이런 proxy 연상들을 서로 공유하면서 하나의 tip으로 가져가면

현업분들의 요구사항에 대응하는 실력이 빠르게 크는 거 같다.

for /f “skip=1 tokens=3” %%s in (‘query user %username%’) do ( %windir%\System32\tscon.exe %%s /dest:console /password:password )

bat파일로 저장 후 관리자 권한 실행 => RDP로 붙은 세션 날려버림

다시 잠그려는 경우

Rundll32.exe user32.dll, LockWorkStation

https://docs.microsoft.com/ko-kr/windows-server/administration/windows-commands/tscon

VNC를 사용하지 않는 사이트에서는 프레임워크에 포함하여 사고를 미연에 방지할 수 있을 듯

현상 : 라이선스 갱신 이후 오케스트레이터 라이선스 조회 안 됨 + 라이선스 명칭이 studio에서 studio pro로 변경됨

추정원인 : DB 권한없음

조치 : DB  owner를 DB user account랑 일치시킴

듣고 정리한 케이스인데 보통 관련된 경우를 피하기 위해

온프레미스에서 오케스트레이터 설치 시 DB Owner 및 User에 권한을 부여하는 것을 꼭 체크해야 한다.

String을 편집하다 보면 줄바꿈의 다양한 종류를 접하게 된다.

결과적으로는 어떤 줄바꿈이든 이 3가지 중 하나다.

\n (=vbLf, chr(10))

\r (드물게) (=vbCr, chr(13))

\r\n (=vbCrLf, chr(13)+chr(10), Environment.NewLine)

엑셀에서는 줄바꿈이 나오면 \n으로 기록된다.

이외 다른 텍스트 필드에서는 대부분 \r\n이다. ^[각주:1]

대부분은 같은 줄바꿈이라면 이중 무엇을 써도 상관이 없으나,

string에서 double quotation이나 기타 특이한 문자가 나오는 경우 등에서 \n, \r\n 같은 형태로 replace를 적용하면

제대로 인식 못 하는 케이스가 존재한다.^[각주:2]

이런 케이스를 피하기 위해선 chr(10), chr(13)+chr(10) 형태로 찾아서 인식하는 게 가장 안전하다.

1. Throw가 된 후 변수 유지

기존에 Exception이 나면 정보가 저장되지 않고 빠져나간다고 알고 있었다.

가령 io_dtData라는 datatable 변수에 가공이 있었는데 Exception이 나는 경우,

in 했을 때의 상태가 유지되는 것으로 알았는데 최근 테스트를 해보니 가공된 채로 전달이 됨을 확인했다.(2022-06)

2. For Each + Try Catch에서 Break

Try Catch와 For each를 겹쳐놓고 Try 중간에 Break가 되어도 Finally는 수행함

 For each

  Try

      Try Sequence

      Break

  Catch

       Exception Sequence

  Finally

        Finally Sequence (Break가 돼도 수행함)

End For each

3. Try Catch 안에 Try Catch

Try Catch 안에 Try Catch를 쓰고 그 안쪽에서 Throw가 되면

Try(2) Sequence (Throw) => Catch(2) Exception Sequence => Finally(2) => Try(1) Sequence => Finally(1)^[각주:1] 순으로 수행

(원리를 알면 자연스러운 전개다)

Try

  Try

    Throw

  Catch

  Finally

Catch

Finally

Retry Scope은 안정적인 수행을 위해서 자주 쓰인다.

기본적으로 Action 부분과 Condition으로 나뉘며,

Condition이 만족되지 않는 경우 혹은 Action 부분에서 에러가 났을 경우에만 Retry를 하게 된다.

1. 용도

 Retry Scope는 보통 페이지가 이동될 때 그 트리거를 제대로 발동했는지 체크하기 위해 사용된다. 가령 클릭이 씹혀서 다음 단계로 못 나가는 케이스를 방지한다.

2. 장단점

 Retry Scope은 사실 For each와 Try Catch의 조합으로 대체될 수 있다. 다만 그렇게 쓰는 것보단 훨씬 편하고 빠르게 쓸 수 있고 가독성도 좋은 편이라 자주 쓰인다. 그러나 에러났을 때 Retry Scope 내의 display name을 뱉어주지 않는다. 즉, Action중 어디서 에러가 났는지 알기 어렵다.

3. 주의점

 위의 장단점, 용도를 생각하면 Retry Scope은 2가지 원칙을 가지고 써야 한다.

  첫 째로 Action은 간결하게 짧게 끊어서 구성하며 트리거나 인식의 변화가 존재해야 한다.^[각주:1]

  두 번째로 Condition은 항상 입력해준다.

  첫 번째 원칙은 간단하다. 디버깅이 힘드니까 쓰기 편한 만큼 짧게 짧게 끊어서 스텝 바이 스텝으로 체크해야 한다는 뜻이다. 두 번째 원칙은 Retry Scope에 대한 오해가 잦아서 나온 원칙이다. '에러나면 그냥 다시 해' 라는 식이나 '여기서 얼마나 대기해야 되는지 몰라서 반복해서 기다려'라는 식으로 쓰는 사람도 많기 때문이다. 그러나 그 경우 더 좋은 대체들이 얼마든지 있다. 특히 '반복해서 기다려'는 소스가 비효율적일뿐 원래 의도했던 결과라도 얻을 수 있는데, '에러나면 그냥 다시 해'라는 식으로 쓰게 되면 정작 클릭이 씹히는 경우 에러가 나지 않아 의도했던 결과를 얻지 못하게 된다.

++ 특이한 경우

Try Catch와 Retry Scope의 조합을 통해 For each-Try Catch를 더 간단하게 만들 수도 있다.

Retry Scope은 내부 세부 에러내용을 남기지 않지만 Try Catch를 안에 넣어 Exception 에러 로그를 찍어주고

재시도 하는 사이트도 있다.

이 경우 최종 Exception Message 컨트롤은 어려울 수 있으나 Break를 빼먹는 실수 등을 줄일 수 있다.

또한 로그는 실패하면서 남기 때문에 개발자가 디버그 하는 데는 크게 문제가 없다.

[역으로 현업에 스텝별 에러로그를 정해 보내고 싶다면 적절하지 않을 수 있다.]