Automation Anywhere 설명서 읽기 및 검토

Automation Anywhere

콘텐츠 닫기

콘텐츠

콘텐츠 열기

봇 설계 지침 및 표준

  • 업데이트: 5/10/2019
    • 11.3.x
    • 탐색
    • Enterprise

설계 지침 및 표준

개발을 위한 고급 안내서 및 개발 지침 및 표준입니다.

이 주제에서는 일반적인 설계 지침 및 표준을 제공합니다. 다음과 같은 일반적인 실수를 피하고 설계 표준에 이러한 프로세스 및 고려사항을 반영하면 정돈되고 읽기, 테스트 및 유지 관리가 더 용이하며 안정적인 을 생성할 수 있습니다. 대부분의 지침은 생산 자원의 효율적인 사용을 개선하거나 유지 보수 시간과 오류를 줄입니다.

디자인 고려 사항

  • 우수 사례

    일반적으로 Automation Anywhere 작업 를 500 라인 미만, 바람직하게는 수백 라인 만 유지하십시오.

  • 프로세스를 분할: 초대규모 비즈니스 프로세스 > 초대규모

    성공적인 비즈니스 프로세스 개발의 관건은 상세히 정의되고 충분히 숙고한 전략입니다. 비즈니스 프로세스가 대규모라 8~10개 이상의 하위 작업이 필요한 경우 또는 한 작업이 수천 개 행으로 이루어지는 경우라면 프로세스에 대한 접근법을 재고해야 합니다.

    비즈니스 프로세스를 평가하십시오. 이 이해를 바탕으로 연결된 접근법을 생성하십시오.

    • 비즈니스 프로세스 자체가 간소화될 수 있습니까? 중복 또는 순환 단계가 있는지 파악하십시오.

    • 프로세스에서 포함된 논리적 중단 또는 분할을 식별하십시오.

    • 비즈니스 프로세스의 부분을 별도의 로 분할할 수 있습니까?

  • 반복 축소

    DRY(Don't repeat yourself) 원칙과 Rule of three는 둘 다 기본적으로 반복 축소를 의미합니다.

    소수의 단계를 별도로 호출하는 대신 단일 호출을 포함하는 루프를 생성하십시오.

    적절한 경우 변수를 사용하십시오.

    반복되는 로직 또는 명령을 하위 작업으로 분할하십시오. 한 작업에서 특정 명령 세트가 여러 번 반복될 경우 유지 관리가 어려워집니다. 업데이트가 필요할 경우 모든 인스턴스를 찾아 올바로 업데이트해야 합니다.

  • 유지 관리를 계획

    복제된 작업 세트에 인코딩된 특정 규칙이 변경될 경우 코드를 유지 관리하는 사람은 모든 위치에서 올바로 규칙을 변경해야 합니다. 이 프로세스는 실수가 발생하기 쉽고 종종 문제로 이어집니다.

    명령 및 규칙 세트를 한 위치에 포함시키십시오. 명령 또는 규칙 세트가 한 위치에만 존재할 경우 간편하게 변경할 수 있습니다.

  • 테스트 기반 설계

    작은 규모의 작업은 유닛 테스트 방식으로 간편하게 단독으로 테스트할 수 있습니다. 종속성이 없는 작업은 자동화된 테스트를 사용할 수 있습니다. 별도의 함수에 의해 하위 작업으로 분할된 작업은 시퀀스 시작 시 동시에 수행되는 작업이라 하더라도 유지 관리 및 테스트 용이성이 향상됩니다.

  • 네트워크 장애 처리

    네트워크 연결에 의존하는 을 생성할 때는 네트워크 지연을 깔끔하게 처리하기 위한 단계가 포함되어야 합니다. 예를 들어 이 웹 페이지 응답(예: Save As 대화 상자 열기)을 필요로 하는데 네트워크가 중단되었다면, 이 어떻게 하기를 원합니까? 재시도하겠습니까, 아니면 메시지를 표시하고 종료하겠습니까?

하위 작업 개요

하위 작업은 서비스가 필요한 상위 작업에 의해 호출됩니다. 이들은 호출 작업을 보조하는 역할만 하므로 헬퍼 작업 또는 유틸리티 작업이라고도 합니다.

팁:

하위 작업은 단일 또는 몇 개의 책임만 담당하는 작은 규모이고 집중적이어야 합니다.

Excel 세션, CSV/텍스트 파일 세션 및 브라우저 세션(Web Recorder)은 여러 작업에 걸쳐 공유할 수 없습니다. 그러므로 하위 작업은 이들 세션을 중단하지 않는 방식으로 포함되어야 합니다.

다음과 같은 이점이 있습니다.

  • 운용 작업 코드가 짧아집니다.

  • 변경이 필요할 경우 하위 작업만 찾아서 분석하고 편집하면 됩니다. 따라서 유지 관리가 더 쉬워집니다.

  • 하위 작업을 가능한 한 재사용이 가능하도록 만드십시오.

    적절히 선택할 경우, 하위 작업은 재사용 가능하게 만들어 그 생산성을 더욱 높일 수 있습니다. 하위 작업은 다른 을 포함하여 복수의 다른 작업에 의해 호출될 수 있습니다.

  • 하위 작업을 가능한 한 독립형으로 만드십시오.

    하위 작업은 완전히 독립적일 수 없습니다. 상위 작업에 의해 호출되므로 단독으로 실행될 수 없습니다. 하지만 가능한 한 다른 작업 종속성을 제거하십시오.

하위 작업 고려사항

  • 단일 책임 원칙

    각 하위 작업에 하나의 작업 또는 책임을 할당하십시오.

    대규모 작업을 하위 작업으로 분할하는 것이 유용하지만, 유사하게 관련된 모든 소규모 작업을 하나의 하위 작업으로 모으는 것은 여전히 유지 관리 실수가 발생하기 쉽습니다. 소규모 작업 하나에 대한 변경 사항이 보다 큰 규모의 하위 작업에 포함된 다른 소규모 작업에 영향을 미칠 수 있습니다.

    각각 단일 목적을 갖는 하위 작업을 여러 개 생성하는 것이 좋습니다. 예를 들어 PDF 인쇄, 파일 이동 및 파일 저장을 처리하는 큰 하위 작업이 있을 경우 이들을 하위 작업으로 분할합니다. 각 하위 작업마다 고유한 책임 즉, 첫 번째 하위 작업은 PDF를 인쇄하고, 두 번째 하위 작업은 파일을 이동하고, 세 번째 하위 작업은 파일을 저장하는 책임을 부여합니다.

  • 종속성 분리

    가능할 경우, 하위 작업을 호출 작업이 정보를 제공할 필요가 없도록 정의하십시오. 필요한 정보는 종속성입니다. 종속성을 식별하여 하위 작업에 포함시킵니다. 그러면 하위 작업이 독립형으로 되고, 유닛 테스트가 가능해지고, 추가 종속성 없이 다른 작업에 의해 호출될 수 있습니다.

    예를 들어 로그인 하위 작업이 호출 작업에서 URL을 제공해야만 호출될 수 있다면 이것은 종속성을 갖는 것입니다. 하위 작업을 호출하는 모든 상위 작업은 URL을 제공해야 합니다. URL이 변경될 경우 두 개 이상의 작업을 변경해야 합니다. 로그인 하위 작업이 해당 URL을 포함할 경우 이 하위 작업은 상위 작업과 분리된 것입니다. URL이 변경될 경우 한 하위 작업만 업데이트하면 됩니다.

  • 양방향 종속성

    호출 작업을 변경하지 않으면 하위 작업을 변경할 수 없다면 이러한 하위 작업은 종속적이며 진정으로 분리된 것이 아닙니다. 모든 하위 작업을 변경하지 않으면 호출 작업을 변경할 수 없다면 이들은 진정으로 분리된 것이 아니며 양방향 종속성을 갖는 것입니다. 이러한 상호 종속성은 유닛 테스트를 거의 불가능하게 만듭니다.

  • 하위 작업을 너무 많이 생성하지 않음

    상기 원칙은 모두 설계를 위한 뛰어난 원칙이지만, 하위 작업이 너무 많을 경우 유지 관리가 어렵고 혼란스러울 수 있습니다. 하위 작업 수는 관리 가능한 범위를 유지해야 합니다.

    30개 하위 작업을 포함하거나 하위 작업 없이 수천 개 행으로 작성된 은 아마도 한 으로 처리하기에는 규모가 너무 큰 비즈니스 프로세스일 것입니다. 대규모 프로세스를 세분화한 후, 각 부분을 개별 으로 생성하십시오.

하위 작업 예

예를 들어 이 메모장 문서를 PDF 파일로 인쇄해야 한다고 가정합시다. 이 작업은 다음과 같을 것입니다.

메모장을 PDF 파일로 인쇄.

이 예에서, 파일을 PDF 문서로 세 번 인쇄해야 합니다. 개발 머신 예에서, PDF 인쇄 드라이버는 Pdf995로 부릅니다.

권장 사항:

  • 운용 환경에서는 PDF 인쇄 드라이버의 이름이 다를 수 있으므로, 변수를 사용하는 것이 실용적인지 조사합니다.

  • 이 작업을 운용 버전으로 승격하고 여러 번 반복할 가능성이 있으므로 권장 사항은 이 작업을 하위 작업으로 만드는 것입니다.

하위 작업 예:

PDF 파일 생성을 위한 헬퍼 작업.

이 특정 명령 세트를 변경해야 할 경우 이 헬퍼 작업만 편집하고 이 헬퍼 작업만 다시 테스트하면 됩니다.

피드백을 보내주십시오