Uipath에서는 프로젝트내 사용한 소스의 브라우저 변경을 Convert 해주는 툴이 존재한다.

Xaml 파일의 앱정보에 관한 키워드를 일괄적으로 변경한다.

가령 앱정보에 iexplore.exe 키워드가 있으면 chrome.exe로 변경해주는 형식이다.

변경 시 각 프로젝트, Xaml 파일별로 변경점의 수를 알려준다.

 

실제 프로젝트에서 적용할 때의 문제는 크게 2가지이다.

1. File Download 등 중간에 브라우저 객체가 아닌 게 끼는 경우

2. 브라우저별로 Element에 대한 정보를 Export하는 게 다른 경우

1,2의 케이스 때문에 결국은 소스를 흘려보면서 테스트를 해야 한다.

선조치를 함으로써 변경하기 쉬운 상태로 바꿔준다 정도로 이해해야 될 듯 하다.

 

 

+ 일반적으로 내부 개발 소스를 내부에서 특히 개발자 본인이 convert를 하면 상관없는데

보통 브라우저 전환이나 OS 전환이랍시고 다른 회사의 소스를 가져오면

비지니스 로직 자체에 결함이 있는 케이스가 많아 그게 이슈가 되기 십상이다.

따라서 작업 scope를 명확하게 나누어 진행해야 한다. [사실 너무나 기본적인 건데 참....]

과제를 하다보면 시스템에서 조회를 할 때, 로딩 화면이 휙 나왔다가 슉 사라지는 케이스가 많다.

문제는 간헐적으로 오래걸릴 경우 적절히 대기를 해줘야 하는데, 그를 인식할만한 것이 제대로 보이지 않는다.

이미지로 하려고 해도 보통 로딩화면은 GIF로 구성되어 있기 떄문에 인식이 틀어질 가능성이 높다.

그래서 Element Exist를 잡아보면 로딩이 뜨든 말든 항상 그 로딩 Element가 존재하는 경험을 하게 된다.

 

 

보통 로딩 Element를 웹에서 구현할 때는 2가지 방법을 주로 쓴다.

첫째는 Display : none을 On/off 하는 방법,

두 번째는 크기를 0으로 줄여 화면 끝으로 보냈다가 로딩일 때만 화면 중앙으로 불러오는 방법이다.

두 가지 케이스 모두 Element는 항상 존재한다.

첫 번째 방법일 경우 Visibility 같은 속성이 변경되며, 두 번째 방법일 경우 Position이라는 속성이 변경된다.

특히 Position은 Uipath.Core.Rect 라는 Uipath 전용 직사각형 변수에 담기며 메소드를 타고 들어가

rRect.Rectangle.Value.X 혹은 rRect.Rectangle.Value.Width의 값으로 분기할 수 있다.

일반적으로 Try에서 에러가 나면 Catch를 수행한다.

다만 특정 경우 마치 소스 Compile 관련 Validation이 제대로 되지 않은 것처럼 수행되기도 한다.

포럼에서는 pick 같은 액티비티를 썼을 때 일어나는 경향이 있다고 하는데

실제로 여기서 발생한 케이스는 Switch였다. [동시 컨디션 체크라는 공통점]

Try Catch의 Try 안에 Switch가 있고 Switch의 내부에 Try Catch가 또 있는 상태.

디버그로 돌리는 경우 Assign 자체를 들어가지 못 하고 Switch 내부의 Catch에 대한 에러 메세지를 출력했다.

 

실제 에러가 나는 부분은 Switch 내부의 Try Catch 안에 Try에는 Assign쪽이었다.

Switch 컨디션의 변수 상태에 따라 해당 Assign이 에러가 나는 케이스였다.

 

해결은 Assign이 에러나지 않도록 null인 경우 기본값을 가진 string을 부여하도록 변경함.

 

** 개발을 굳이 저렇게 할 필요가 없는데 너무 많이 Try Catch를 겹쳐놓은 소스였음

+ Recent posts