Talk Lowy(kr)

  UiPath 요즘들어 각광 받고 있는 UiPath는 초기 5000억원이라는 경이적인 투자액을 받아 한 번에 이름을 날리며 RPA 시장에 뛰어들어 기존의 Automation Anywhere, WinAutomation이나 WinActor, Control-M등의 강자들을 누르고 세계 RPA 1위에 등극하였습니다. https://www.youtube.com/watch?v=lgiChrgzzoU 이런 UiPath와 아래의 링크들에 있는 이미지들을 봐주시기 바랍니다. 모두 각 회사의 RPA툴입니다. https://docs.microsoft.com/ja-jp/dotnet/framework/windows-workflow-foundation/state-machine-workflows https://docs.uipath.com/studio/lang-ja/v2018.3/docs/state-machines https://akabot.com/wp-content/uploads/guide/jp/jp_akabot_guideline_studio.pdf 너무 같아서 이상하지 않나요? Microsoft는 자체적으로 RPA를 독점 공급하려던 과거의 개념을 버리고 ecosystem(생태계)를 만드는 방향으로 전환 했습니다.  즉, Platform은 누구나 사용가능하도록 오픈을 하고 그 위에 올라간 마켓 플레이스는 반드시 Microsoft의 Marketplace를 사용하게 하여 거기서 이득을 취하는 구조로 간 것이지요. (이렇게 플랫폼 정책을 바꾼 이유는 제 글 중  https://talklowykr.blogspot.com/2015/03/platform.html  에서 알 수 있습니다.) 때문에 WWF의 특징인 State machine이라는 개념이나 Orchestrator를 기반으로 하는 Studio의 개념, 그리고 파일명인 xaml을 그대로 가져가고 있습니다. 현재 UiPath및 Akabot 개발자들을 서포트해 주고 있는 저역시 UiPath등이 이상한 동작을 취하거나 기존엔 잘 되었던 것이 이상

MS의 저주일지도 모르지만,  역시 윈도우에서 발생하는 버그는 상상을 초월한다.  많은 부분을 Exception을 처리해도 알 수 없는 오류가.. 이번에는 Excel을 두 개 열어서 A파일의 S시트를 B파일로 복사해서  데이터를 그 포맷에 Write Range 로 쓰도록 하였다.  A파일의 S시트는 템플릿이 아니고 현재 사용하는 시트이다 보니 데이터가 있다.  그래서 Delete Range를 이용해서 삭제를 하니.. 에러가.. Excel Application Scope를 여러개 열면 뭔가 충돌이 난다.  그래서 이번에는 close workbook을 이용해서 매번 닫도록 해봤다.  그런데도 역시 Delete Range에서 알수없는 오류로 종료... B파일의 Excel Application Scope를 열어서 그 안에서 A파일의 Excel Application Scope를 열고, Copy -> Delete -> Write를 해보았다.  역시 에러.. 이번엔 분기를 해봤다.  Copy하는 경우는 Delete를 하지 않고,  Copy하지 않는 경우는 Delete를 하고..  기존 시트명이 있는 경우만 데이터를 삭제를 하는 방식이다.  이렇게 하니까 Delete Range는 성공 했으나 몇 개 실행하다보니 Excel workbook이 닫히지 않기 시작하면 다음 처리에서 에러가 발생..  두 개이상 workbook이 열리면 Write Range나 Delete Range에서 해당 파일을 찾지 못하는 것 같다.  결국 마지막 부분에 close workbook을 하여 강제로 죽여주니까 성공.. 그냥 놔둬도 닫히지만 안닫힐 때도 있는 경우에 따른 변수가 생겨서 close workbook의 타이밍에 따라서 에러가 나오기도 안나오기도 하네.. 윈도우즈의 버그는 ...  익셉션 처리하는게 코드 짜는 거보다 많은 거 같다.. -------- 추기1.  나중에 해보니 똑같은 에러가 빈도는 줄었지만 또 났다.  그래서 시도한 것이, Excel이 열리지 않은 경우는 workboo

유난히도 요청이 많았던 날이다. 그래서 한 번 요청 오늘 처리한 데이터 추출작업 파일 수를 세어 보았다. 94건... 일반적인 데이터 추출은 추출 조건 및 내용을 보고 요청자와의 커뮤니케이션, 추출 작업, 추출된 결과의 엑셀 정리 작업까지 하면 평균 25분 걸린다. 하루에 8시간 일한다면 쉬지않고 한시간에 3건 정도, 8시간에 24건 추출 가능하다. 정말로 쉬지 않고 말이다. 실제로 이 업무는 세 명이서 했던 것이고, 우연히 이렇게 몰려오면 날짜를 미루거나 해서 처리하는 것 같았는데, 그냥 하다보니 다 처리를 해버렸다. 상담도 들어주고, 휴식도 하곤 했지만, 요청 내용의 변경만 RPA에 적용 시키는데에도 하루 종일 걸렸다. 하다보니 조금 더 개선해야지 하는 내용도 머릿속에 떠올랐으나, 오늘은 정기 점검도 미룰 수 없고, 다른 요청 작업들도 담당자가 미룰 수 없다고 사정하는 바람에 전부 처리를 해주게 되었다. RPA의 파워가 느껴지는 하루였긴 했지만, 회사에서는 이 속도가 기준이 되어 버리지 않을까 하는 불안함이 생긴다. 나를 나가게 했던 모 회사가 나의 자리를 메우기 위해 5년을 사람을 찾다가 결국 타협하고 5명으로 늘린 실제 상황이 있었기 때문에.. 경영자들이 이런 과오를 또 일으키지 않았으면 한다.  Do not login your machine any more! giip :: Free RPA orchestration tool! https://giipasp.azurewebsites.net/

1999년도 부터 서버쪽 일을 계속 하면서 느꼈는데, github등의 공동 작업 서비스들이 발전하면서 엄청난 진화를 했는데, 현재까지도 기존의 방식을 사용하고 있는 기업이 너무 많습니다. 게다가 클라우드면 다되는줄 알고 전부 클라우드에 올렸다가 막대한 비용을 내고 있는 기업들도 있지요.. 규모에 따라 여러가지 어렌지는 필요하지만, 제가 사용하는 방법을 공개합니다. 1. Github계정을 생성, 소스 마스터는 유료 계정으로 설정(월 $7). * 소스 마스터가 유료이면 Contributor를 무제한으로 늘릴 수 있으나 무료 계정이면 2 명까지 밖에 못늘림(언젠가 부터 바뀐 정책). 게다가 워크 그룹이나 오거나이저를 생성하면 계정당 비용을 내야 함. 2. Azure에서 F1(Free) 티어로 App Service등록 * giipasp : 서비스용 App service * giipaspstg01 : 스테이징 1 * giipaspdev01 : 개발 1 3. DB서버 역시 클라우드로 만들어도 되고, 자체 서버에 DB를 설치해도 됨. 이번엔 Azure의 sql cloud 를 사용함. * giipdb DB생성. (10DAU로 설정하면 고정 SQL라이선스를 내지 않아도 됨) * 참고로 S1등의 스탠다드 DB로 만들면 사용을 안해도 1서버당 25만원 정도의 라이선스 비용이 별도로 과금 됨. (처음에 몰랐다가 지불을.....) 4. Github에서 Repository를 Dev, Real 두 개를 생성 * Real은 위의 유료 계정이 아닌 다른 관리 계정으로 만듬.   유료 계정은 개발 및 기타 여러가지 Repository를 잔뜩 만들기 때문에 나중에 deploy관리시 아주 많이 어려움. Deploy는 Contributor가 필요 없으니 차라리 새로 생성해서 Deploy전용 repository만 관리. * Dev : https://github.com/LowyShin/giipasp.git * Stg : https://github.com/