재사용 가능한 봇 작성

설계 및 생성부터 재사용까지 재사용 가능한 봇 또는 하위 태스크 개발에 관한 이해를 높이기 위한 지침을 검토합니다.

선행 조건, 입력, 출력 및 변수 정의
재사용을 위한 봇을 작성할 때는 다음 사항이 정의되어 있어야 합니다.
  • 봇 단독으로 또는 하위 태스크로 이용하는 방법에 관해 필요한 모든 선행 조건을 문서화합니다.
  • 봇을 작성할 때는 값을 입력, 출력 또는 로컬로 정의합니다. 입력 및 출력 변수는 봇이 하위 태스크로 이용되도록 설계되어 다른 호출 봇으로부터 값을 수신하고 되돌려 보낼 수 있게 되어 있습니다.
  • 입력 및 출력 변수를 정의할 때 의미 있는 변수 설명을 제공하여 다른 개발자가 귀하의 하위 태스크와 상호작용하는 방법을 알 수 있게 해야 합니다.
  • 변수 이름 지정 지침에 대해 확립된 기준을 준수합니다. 변수 이름 지정 지침에 대한 Automation Anywhere 사용자 정의 변수를 검토합니다. 변수(사용자 정의)
단일 책임 원칙 준수
재사용성을 위해 개발된 Bot은 단일 책임 원칙을 따라야 하는데, 이 원칙은 각 하위 태스크 또는 구성요소가 전체 봇의 기능의 단일 부분에 대한 책임을 가져야 하고, 그 책임은 해당 하위 태스크 또는 구성요소가 전적으로 담당해야 한다는 것으로 설명하고 있습니다.

단일 책임의 다른 예:

  • 단일 트랜잭션을 처리하지만, 목록의 각 트랜잭션에 대해 여러 번 호출될 수 있는 하위 태스크.
  • 웹 사이트의 한 페이지에 화면 표시 데이터를 수집하지만, 봇이 페이지 매김을 진행하는 동안 여러 번 호출될 수 있는 하위 태스크.
Bot 설계 고려 사항
사용을 위해 개발해야 하는 템플릿에 따라 다음 패턴을 고려하십시오.
  1. Primary, Main, Sub 봇
    • Primary 봇: 이 봇은 Control Room 또는 API 호출을 통한 스케줄링을 포함한 메커니즘을 통해 직접 호출되어 프로세스를 시작합니다. TRY 섹션에 다음 주요 프로세스 단계를 포함합니다.
      1. 프로세스의 초기 설정을 완료합니다.
      2. 설정이 성공적이었는지 확인합니다. 예를 들어 모든 필수 파일 및 폴더가 존재하는지 또는 초기 변수 값이 필요에 따라 채워져 있는지 확인합니다.
      3. 데스크톱 프로세스 사전 정리 실행.
      4. Main 봇을 호출하여 프로세스의 비즈니스 로직 실행.

      Finally 섹션에서 데스크톱 프로세스 사후 정리 실행.

    • Main 봇: 이 봇은 필요에 따라 Sub 봇을 호출하여 비즈니스 로직을 실행합니다. TRY 섹션에 다음 주요 프로세스 단계를 포함합니다.
      1. 모든 입력의 유효성 검사를 실행합니다. 예: Primary 봇의 입력 변수 값
      2. Sub 봇을 실행합니다.
      3. 모든 출력의 유효성 검사를 실행합니다.
      4. Main 봇의 실행을 기반으로 출력 변수 값을 채우고, Primary 봇에 반환합니다.

      Catch 섹션에서 오류를 기록하고, 출력 변수 값이 채워졌는지 확인합니다(예: oStrResult가 Primary 봇으로 전달됨).

    • Sub 봇
      • Sub 봇은 Primary 봇 또는 Main 봇의 호출에 따라 자동화에 필요한 실제 비즈니스 로직을 실행합니다. 이들은 태스크 호출을 보조하는 역할만 하므로 헬퍼 태스크 또는 유틸리티 태스크라고도 합니다.
      • 출력 변수를 사용하여 호출한 Main 봇 또는 다른 Sub 봇에 결과 표시기를 반환합니다. 예: outStrResult. 발생한 오류 또는 예외로 인해 처리가 성공하지 못한 경우 값에 오류 메시지가 포함됩니다.
  2. Main 및 Sub 봇: 이 패턴에는 단일 Main 봇에 Primary와 Main 봇이 포함됩니다. Sub 봇의 설계 패턴은 위에서 설명한 설계 패턴과 유사합니다.
애플리케이션 열기 및 닫기
봇 또는 하위 태스크가 여는 모든 애플리케이션, 파일 또는 창은 동일한 봇 또는 하위 태스크에 의해 닫혀야 합니다.
  • 예를 들어, 봇에서 Microsoft Excel을 열어 스프레드시트 작업을 수행할 때는 봇 처리를 마치면 스프레드시트 및 Excel이 닫혔는지 확인합니다.
  • 봇 실행이 성공하거나 실패하면 애플리케이션을 닫습니다.
  • Try/Catch/Finally 작업의 Finally 블록을 이용하여 태스크 처리의 성공 여부에 관계없이 애플리케이션이 닫혔는지 확인합니다.
  • 애플리케이션이 테스트 중에 응답하지 않는 경우, 명령 프롬프트를 이용하여 애플리케이션을 강제로 닫는(종료) 것이 좋습니다. 예를 들어, 파워 포인트를 강제로 닫고자 할 때 커맨드 라인 작업은 다음과 같습니다.
    Taskkill /IM powerpnt.exe /F
오류 처리
태스크를 완료한 후, 봇이 모든 실패 또는 예외를 성공적으로 처리하는지 확인합니다.
  • 각 태스크 또는 하위 태스크는 자체 오류를 처리해야 합니다.
  • 하위 태스크에서 처리되지 않은 예외는 상위 태스크에서 문제를 일으킬 수 있습니다.
  • 모든 봇의 루트 레벨에서 Try/Catch/Finally 블록을 이용합니다.
  • 실패를 보고하기 전에 작업을 여러 번 시도하려면, 루프 내부에서 Try/Catch 블록을 이용하십시오.
이벤트 또는 예외 처리
Try/Catch에 의해 캡처된 작업 오류 외에 이벤트 또는 예외와 같은 다른 프로세스에 대한 코드 검사를 수행해야 합니다. 특정 프로세스 조건이 발생하면 추가 분석을 위해 이러한 조건을 알리거나 기록합니다.
  • 작업 변경 시 코드 변경 필요성을 최소화하는 구성 가능한 이벤트 처리기 Task Bot을 개발합니다. 예를 들어 가능한 모든 이벤트 또는 예외와 해당 이벤트 또는 예외가 발생할 때의 알림 요구 사항에 대한 정의가 포함된 XML 파일을 유지합니다.
  • 코드에서 이러한 이벤트나 예외가 발생하면 정보를 이벤트 로그에 기록합니다. 메모리 사용량을 추가하고 스크린샷을 캡처할 수도 있습니다.
  • 이벤트 처리기 Task Bot을 실행하여 이벤트 또는 예외를 처리합니다. 예를 들어 XML 파일에서 이메일 수신자, 참조 수신자 또는 제목과 같은 매개변수를 사용하여 알림을 발행합니다.
  • 알림 요구 사항이 환경마다 다르거나 시간이 지남에 따라 변경된 경우 코드를 변경할 필요 없이 구성 파일을 업데이트할 수 있습니다.
다른 컴퓨터에서의 봇 실행
봇을 설계할 때는 그 봇이 생성된 컴퓨터가 아닌 다른 컴퓨터에서도 실행되도록 해야 합니다.
  • 다른 컴퓨터에서도 봇이 실행할 수 있도록 로컬 파일 경로, 네트워크 공유 또는 창 제목에 대한 변수를 이용합니다.
  • 다수의 봇이 액세스해야 하는 환경 마커 또는 네트워크 공유에 대해서는 글로벌 값을 이용하는 것을 고려하십시오.
  • 봇이 특정 환경 또는 대상 애플리케이션의 버전에 관계없이 실행되도록 하려면, 적절한 경우 창 제목에 와일드카드 문자를 이용합니다. 예를 들어, 이용하는 대신
    Salesforce - Professional Edition - Internet Explorer
    다음을 사용하십시오.
    Salesforce - * - Internet Explorer
프롬프트, 메시지 상자 및 무한 루프 이용
프롬프트 및 메시지 상자 작업에서 사용자 입력을 기다릴 때는 봇실행이 중지됩니다. 사용자 입력이 필요하지 않다면, 프롬프트 문을 이용하지 않도록 봇을 설계합니다.
  • 루프를 이용할 때는 반복 횟수를 명확히 정해주거나 브레이크 루프 작업이 필요한 위치를 지정하여 모든 루프에 확실한 종료점이 있도록 해야 합니다.
  • 봇을 무인 봇으로 실행하려는 경우, 프롬프트 또는 메시지 상자 작업을 제거하거나 비활성화합니다.
  • 유인 자동화 시나리오를 위해 봇을 작성하는 경우, 봇이 예상대로 실행되게 하려면 메시지 상자와 프롬프트가 합당하거나 요구되는 경우가 많습니다. 메시지 상자를 이용하여 응답, 출력 또는 값과 같은 다양한 변수를 표시합니다.
민감한 데이터를 Credential Vault에 저장하기
Control Room에는 사용자 이름, 비밀번호, API 키 및 토큰과 같은 민감한 정보를 저장하는 데 이용할 수 있는 Credential Vault가 포함되어 있습니다.
  • 봇을 구축할 때는 자격증명을 저장하고 필요 시 자격증명 또는 속성을 참조하면서 검색할 수 있도록 Control Room에서 Credential Vault을 이용하여 로커를 만듭니다. 이렇게 하면 사용자가 봇 빌더가 봇 내에서 필요한 자격증명을 직접 하드 코딩할 필요 없이 API를 이용하거나 로그인을 수행하는 봇을 만들 수 있습니다.
  • 봇 내의 하드 코딩된 스토리지는 보안 위험을 초래하므로 민감한 자격증명을 봇, 또는 하위 태스크에 하드 코딩하지 마십시오.
  • 봇에서 Credential Vault 값을 이용해야 하는 경우, 모든 로커 이름과 자격증명이 Bot 문서에 명확하게 정의되어 있는지 확인하십시오. 필요한 경우 자격증명(예: API 키 또는 토큰)을 획득하는 방법에 대한 세부 정보를 포함합니다.
독립 태스크 테스트
재사용이 가능하도록 봇을 만들 때는 다른 하위 태스크와는 독립적으로 테스트할 수 있도록 설계하십시오.
  • 테스트 중심 개발(TDD) 접근법을 실천해보십시오. 애플리케이션에서 새 봇 또는 새 기능을 추가할 때는 해당 테스트 예시를 작성합니다.
  • 테스트 예시에서, 해당 기능을 검증하는 특정 기능을 정의해둡니다.
  • 단일 책임 원칙 및 재사용 가능성을 위해 독립적으로 테스트할 수 있는 많은 소규모 태스크를 생성합니다.
주석 및 단계 사용
주석을 통해 개발자는 자신의 봇 내에서 설명을 제공할 수 있으므로 봇 다른 봇 개발자들이 각 섹션, 코드 블록 또는 하위 태스크의 설계 용도를 더 잘 이해할 수 있습니다. 개발자가 주어진 코드 블록의 기능의 목적을 이해할 수 있도록 명확한 설명을 포함시킵니다.
  • 봇이 Bot Store에 제출되면, 이 주석은 봇을 사용자 정의하는 방법을 보여줍니다.
  • 주석을 이용하면 섹션 설명을 통해 개발자가 더 빠른 문제 해결을 위해 필요한 변경 사항을 파악할 수 있으므로 코드 유지 관리가 더 쉬워집니다.
  • 진행 중인 작업인 봇의 주석은 향후 작업을 위한 자리 표시자를 만들 때 도움이 될 수 있습니다. TODO 명령을 사용하여 봇에 로직을 추가하도록 상기시키는 것도 좋지만, 작업이 완료되면 주석을 업데이트해야 합니다.
  • Automation 360에는 가독성과 흐름을 개선하기 위해 코드를 논리적 그룹으로 구성하는 기능을 제공하는 단계 작업이 포함되어 있습니다.
  • 공백 상태로 라벨이 부착된 단계(step) 조치를 이용하여 봇의 주요 목표에 대한 개요를 작성합니다. 이 작업이 완료되면, 각 단계로 돌아가서 해당 단계의 로직을 완료합니다.
로깅 파일 만들기
봇이 Bot Runners의 수에 관계없이 무인으로 실행될 때는 로그 없이 문제를 식별하는 것이 어려울 수 있습니다. 소프트웨어 개발자, 지원 팀 및 봇 소유자는 로그에 의존하여 자동화에 문제가 있는 위치와 문제 진단 방법을 파악합니다. Bot은 오류를 기록하여 오류 세부 정보를 갖고 있어야 합니다.
  • 오류 처리 및 화면 캡처를 이용하여 봇 또는 하위 태스크에서 오류가 언제 발생하는지를 더 잘 이해할 수 있습니다.
  • 과거 로그 파일을 유지관리하기 위해 사용자 정의 가능한 루트 로깅 위치와 함께 기본 오류 처리, 로깅, 및 스냅샷 기능이 포함된 A2019 Bot Store 템플릿을 이용합니다.

    Bot Store bot template

  • 필요하다면, 추가 로깅 파일을 생성하고 봇 또는 하위 태스크에서 수행한 모든 작업에 대한 전체 감사 기록을 포함합니다. 추가 로그 파일에는 에 대한 감사, 디버그 및 봇에 대한 성능 정보와 함께 다음 정보를 포함할 수 있습니다.
    • Main 봇 시작 및 종료 시간.
    • 하위 태스크 시작 및 종료 시간.
    • 봇 내에 정의된 특정 이정표의 완료 시간.
    • 입력 파일에 수신된 트랜잭션 수.
    • 성공적으로 처리되었거나 실패한 트랜잭션 수.
See also: Best practices: Building reusable and secure Automation 360 bots and packages