과제 개발 시 Combo box는 다양하게 나타나지만 결국 값을 입력하기 위한 input element이다.

Select Item으로 선택되지 않는 combox의 값을 select하는 방법을 3가지로 나눠봤다.

[Select Item은 무조건 먼저 해보길 권장한다. 리스트형인 모든 element에 이것 먼저 해보도록 하자]

 

1. (Click) + Type into

- Type into는 옵션을 어떻게 선택하느냐에 따라 기능이 깡패기 때문에 AlterIfDisable, Empty Filed, Simulate Type을 선택하면 그냥 선택하는 거든, 쓰는 게 막혀있는 거든 웬만해선 다 적어버린다.

- inner text를 주입하는 수준이기 때문에 딱 봐도 안 될 거 같다면 이 방식부터 쓰길 권장한다.

- 다만 몇몇 콤보박스의 경우 click을 Trigger로 값이 로딩되는 경우가 있으므로 click 추가 후 after delay를 주기 바란다.

 

2. (click) + Set Text

- 태그에 inner text를 주입하는 원리에 가까움 

- 다만 Type into는 키별 주입을 한다면 Set text는 String값 자체를 한번에 주입하는 느낌[그래봤자 비슷하다]

- 1번을 우선 해보고 안 될 때 시도

 

3. (click) + click

- 될 거 같은데? 하는 콤보박스라면 이거부터 시도하길 바람

- 뒤쪽의 클릭은 simulate type을 걸어두어야 스크롤이 생겨도 문제가 없음

  => 다만 제대로 submit 되는지 필히 체크해야 함. simulate 방식 특성상 값이 들어간 것처럼만 보이고 실제론 container에 들어가지 않았다든가 하는 경우가 있을 수 있음. 다만 한번 제대로 성공한 걸 확인했다면, 그 후론 헛클릭, 헛타이핑하지 않음. (simulate를 쓰는 이유. Default나 SendwindowsMsg는 그런 케이스가 1000번하면 대략 3~4번쯤 존재)

- 다른 방식은 값이 없어도 에러가 안 나기도 하는데, click은 높은 확률로 없으면 에러가 남 [정합성 검사 유리]

- 스크롤을 해야만 클릭이 되는 케이스도 있으므로 그 경우는 스크롤을 하면서 에러가 나지 않을 때까지 반복시키는 형태로 구성해야 함.

 

4. click + double click

- 클릭을 제대로 했음에도 불구하고 값이 default로 다시 바뀌는 현상(iframe환경)

- 클릭 후 더블클릭(simulate)하여 해결되었다고 함(before delay도 추가)

- 추정으로는 Selector가 실제 submit되는 값의 바깥쪽으로 잡혀서 제대로 Trigger가 되지 않은 것으로 보임

- 이 경우 첫번째 클릭이 일종의 그 dropdown list를 선택하는 형태가 되므로 default로 변경되는 것도 설명할 수 있음

- 비슷한 증상이라면 시도해볼만함

크로미움 엔진이 캐시를 랜더마이즈하게 저장하여 제대로 안 지워진다는 말을 듣고 수정함

방법1. 크롬을 아무 사이트로나 켜고 ctrl+shift+del을 눌러줌 => 캐시 삭제 클릭

방법2. 크롬을 켤 때 캐시 저장할 target 폴더를 파라미터로 지정 [invoke code나 start process 등 이용]

 

 

 

++ 추가 확인 이슈 : 간헐적으로 쿠키가 제대로 지워지지 않는 케이스를 발견함

++ 하위 폴더까지 강제 삭제 하도록 -recurse -force 옵션 추가

++ Sessions, Session Storage, Network 폴더 추가[각주:1]

 

보통 세션, 쿠키가 꼬이는 경우 프레임워크의 init단에 끼워넣을 수 있다.

최근 프로젝트 사이트에서 IE의 EOM종료로 인해 크롬으로 많이 갈아타는 추세기 때문에

크롬을 사용하는 사이트에서는 프레임워크의 killprocess 하는 소스 다음 부분에 쓰길 권장한다.

Powershell 코드를 쓰는 게 가장 베스트로 보여 갈무리 한다.

 

원본 코드 : https://forum.uipath.com/t/clear-cache-in-chrome-powershell-or-cmd-prompt/195110

 

Clear Cache in Chrome - Powershell or Cmd Prompt

Gurus, I have a process that runs for a bit and unfortunately I see chrome crashing with “Aw Snap”. In order to overcome this issue I am trying to clear the cache periodically via a Powershell or cmd line. I don’t want to use the screen so it appears

forum.uipath.com

 

1. Invoke PowerShell Activity를 가져옴

 

2. IsScript 체크

 

3. Type Argument를 String으로 변경

 

4. 스크립트에 다음과 같은 코드를 넣어줌 [각각 다른 액티비티로]

"taskkill.exe /im chrome.exe /f"+Environment.NewLine+"Start-Sleep -Seconds 2"

"$Items = @('Archived History','Cache\*','Network\*','Cookies-Journal\*','Cookies','History','Login Data','Top Sites','Visited Links','Web Data','Sessions\*','Session Storage\*')"+Environment.NewLine+"$Folder = ""$($env:LOCALAPPDATA)\Google\Chrome\User Data\Default"""+Environment.NewLine+"$Items | % { if (Test-Path ""$Folder\$_"") {Remove-Item ""$Folder\$_"" -Recurse -Force}}"

 

[내용을 보면 크롬 기본 유저의 쿠키 및 캐시, 방문기록들을 지워주는 코드이다. 멀티 프로필을 쓴다면 Default 부분을 변수로 사용해 지우면 된다.]

invoke powershell을 하면 크롬이 안 켜져 있는 경우 taskkill에 대해 에러로 인식하기 때문에 그냥 kill은 따로 앞쪽에 하도록 하자.

아니면 가운데 Environment.NewLine 넣고 하나의 액티비티로 하고 Continue On Error만 체크해주자.

[테스트 해보니 앞에서 에러가 나더라도 뒤에 코드는 실행을 한다.]

 

  1. Network 폴더가 쿠키, 세션 저장 폴더로 변경돼서 여태 제대로 안 지워졌던 걸로 보임 [본문으로]

과제정의서 체크리스트

- [Required] 과제명, 프로세스명, DL, (현업에 Confirm 받은) 결과메일 양식, 선호 스케쥴
- [Required] 과제 진행을 위한 권한 확보[ex. 외부 파일 반출, 시스템 접근 등]
- [Required] 요청 파일 양식[마스터, 템플릿 파일 등] 확인 및 가이드
 * 미팅 후 +n일까지 준비되지 않을 시 홀드 후 다른 과제 진행하는 것으로 사전 협의 필요
- [Required] 실패 시 처리[Step별로 다르다면 그 부분도 작성. 특히 소급가능하지 않은 Step이 있다면 꼭 명시돼야 함.]

* 특히 시스템에 입력하는 과제중 중복이 일어나면 안 되는 과제들에는 중요

- [Required] 현업이 실패 리스크에 대한 인지를 하고 있는지, 로직상 이중 대책이 필요한지 체크

- [Required] 메일 요청 키워드, 작업 파일 키워드

- [Required] (기존 과제 수정이나 이관인 경우) 기존 성공 수행 이력

- [Required] 필요앱 설치 가이드 및 설치 파일

- [Optional] 요청 파일별 메일 키워드[제목 혹은 첨부파일명]
- [Optional] 해당 프로세스에 대한 예외 사항 명시
 * 미리 수동으로 진행해 봤을 때 3 Cases 이상 발견되는 경우엔 공수를 추가하는 형태로 협의

- 외부메일이 필요한지. 필요하다면 허가 진행 가능한지? [사이트 특이사항]

- 파일 개수 10개 limit이 있는데 zip으로 진행해도 되는지? [사이트 특이사항]

- 외부 메일링 시(Big File이 아님) 용량제한(현재 30MB)에 문제없는지? [사이트 특이사항]

보통 Main RPA들이 MS SQL DB를 쓰기 때문에 한글 관련한 이슈가 있다.

쿼리 날릴 때 Where 절이든 Value든 한글이 들어가면 인코딩 에러가 날 수 있는데 앞에 대문자 N을 붙이면 해결된다.

 

EX) ~~~ Where [Description] Like N'%검색%'

 

- 소문자로 하면 에러가 난다.

- 유니코드 인코딩을 해서 쿼리를 날린다.

 

이 방법이 최적이라고 말하긴 어렵지만

공수 측면에서 패턴을 만들어 두고자 쓴다.

Case는 DT1과 DT2를 비교해 일치하는 건에 대해 DT3를 만들어 Result로 남기거나

또 다른 작업을 하는 경우이다.

 

1번 방법 : DT1,DT2 모두 컬럼이 많고 복잡한 경우, DT2로만 Output을 뽑고 싶을 때 유용

DT3 = DT2.copy
Clear DataTable DT3

For each row DT1

  Filter DT => Tgt Column = item [input : DT2 / Output : dtContainer]
  dtContainer Merge to DT3

end for each row DT1

 

2번 방법 : DT1, DT2 중 한 쪽이 컬럼이 별로 없어서 손으로 필터링할 컬럼 쓸만할 때

Join DataTable => DT1 column = DT2 column [input1 : DT1, input2 : DT2 / Output : dtResult]

Filter DataTable => 필요없는 열 제거

 

 

업무할 때는 보통 2번 방법이 많이 쓰이지 않을까 싶다.

1번은 보통 Excel의 VLOOKUP으로 값을 거르고 하게 마련이기 때문.

 

 

작년에 RPA의 흐름에 대한 글을 갈무리하고 1년이 넘어서야 새롭게 글을 쓰게 됐다.

그 사이에 상당히 많은 흐름의 변화가 생겼다.

 

i) AI 도입 OCR이 서서히 도입되는 중

작년만 해도 아직 정식 도입되기에는 시기상조일 수 있다고 썼으나, 지금은 서서히 도입 가능할 정도로 올라왔다. 역시나 UP가 가장 빠르게 진행하고 있는 것으로 보이고 늦어도 올해 말엽부터 시작되는 프로젝트들은 Document Understanding 기술이 들어가는 과제를 최소 하나 이상 끼고 있지 않을까 예상해본다.

 

ii) Portal을 따로 도입하기에는 솔루션의 중앙통제 아키텍쳐들이 사용하기 쉽도록 잘 개선되고 있음

작년엔 포탈에 대해 갈팡질팡하는 곳이 많았다면 지금은 아주 가격이 싸지 않는 이상 안 하겠다는 분위기가 있지 않나 싶다. UP, AA, BW 등등 각 툴들도 관련한 권한 분할을 더 세련되게 개선하고, 일반 User가 접근해 디자인하거나 참여하는 형태의 기능을 도입하고 있다. 포탈 제공 업체 입장들은 관련 Swagger API가 아닌 이상 따로 Custom하는 공수가 꽤나 필요하므로 Swagger API만 적용한 기본 포탈을 일종의 미끼상품(?)처럼 Standard 형태로 무상제공 하는 전략을 보이고 있다.

 

iii) 재택근무 시스템 정비로 인한 본격적인 수요 증가세

재택근무를 경험한 대기업들의 만족도가 생각보다 높아지면서 시스템 연결 관련 단순 작업에 대해 RPA 수요가 커졌다. RPA 개발자 입장에서는 굉장히 반가운 소식이다. 단순히 수요가 늘었다는 측면뿐만 아니라 정말 'RPA가 수행해야 되는 과제'일 확률이 높아졌기 떄문이다. 정합성과 권한 관련한 의심, 절차 정비가 많이 누그러졌고 재택 관련한 시스템 정비가 많이 이뤄졌기 때문에 RPA 수요 증가세가 가파르다. 

iv) 개발 공수 관련 혼잡성은 여전

RPA 비지니스 측면에서 어려운 것이 과제개수 X 난이도 => 공수 산정 얼마나 해야 적당한가이다. 영업 입장에서는 최대한 줄이고 싶겠으나 결국 적당한 선에서 주어져야 하는데, 각 프로젝트 사이트마다, 사용하는 시스템의 안정성마다, 과제의 복잡성에 대한 판단 기준에 따라 실제 공수는 달라진다. (역으로 프로젝트 경험이 없거나 실제 업무를 잘 모를수록 과제 개수만 따지는 경향이 있다.) 그나마 서로 변수를 줄이기 위해선 프로젝트 계약 이전에 구축사에서 공수산정을 위한 인터뷰, 테스트를 진행해보는 것이 베스트이다. 어중간하게 내부 담당자가 대충 산정했다가 1차 구축에서 곤혹을 치르는 경우가 많다.

 

v) 시장 점유율 변화

작년에도 이미 많은 변화가 있었으나 지금은 거의 결정됐다고 봐도 되지않을까 싶다. 결정적인 레퍼런스가 됐던 곳들에서 연이어 전환하고 공공쪽에서 수요가 시작되면서 조정이 되고 있다. 구체적인 부분은 민감한 사안이므로 따로 언급은 안 하겠지만 실제 시장 상황을 알아본 담당자라면 알고 있으리라 생각한다. 개발자 입장에서는 느끼는 것은, 결국 전체 아키텍쳐 수준에서 좋은 것은 각 회사의 개발자들도 알게 된다는 점이다. 영업전략이나 가격 모두 중요하지만 장기적으로는 그런 근본적인 변수들이 영향을 미친다.

+ Recent posts