클래식 비즈니스 규칙

  • 릴리스 버전: Zurich
  • 업데이트 날짜 2025년 07월 31일
  • 소요 시간: 32분
  • 비즈니스 규칙은 기록이 표시, 삽입, 업데이트 또는 삭제되거나 테이블이 쿼리될 때 실행되는 서버 쪽 스크립트입니다.

    비즈니스 규칙은 특정 서버 측 조건이 충족될 때 실행되는 스크립트입니다. 비즈니스 규칙 조건에는 데이터베이스 작업과 관련하여 비즈니스 규칙을 실행할 시기와 비즈니스 규칙이 적용되는 기록 작업이 포함됩니다. 클라이언트 스크립트 및 UI 작업과 같은 클라이언트 측 조건에 대해 플랫폼에서 사용할 수 있는 다른 스크립팅 옵션이 있습니다.
    주:
    비즈니스 규칙은 스크립팅에 의존하는 고전적인 자동화 솔루션입니다. 새 프로세스 자동화에 사용하여 워크플로우 스튜디오 확장, 재사용, 이해 및 업그레이드가 더 쉬운 자동화를 생성합니다. 많은 조직이 프로덕션에 비즈니스 규칙을 가지고 있으므로 이 설명서를 사용하여 기존 비즈니스 규칙을 사용하는 방법을 알아보십시오.

    비즈니스 규칙의 작동 방식

    비즈니스 규칙을 구성하려면 먼저 비즈니스 규칙을 실행해야 하는 시기와 취해야 할 조치를 결정해야 합니다.

    비즈니스 규칙이 실행될 때

    비즈니스 규칙은 두 가지 기준 집합에 따라 실행됩니다.
    • 데이터베이스 작업과 관련하여 비즈니스 규칙을 실행할 시기입니다.
    • 비즈니스 규칙이 적용되는 기록 작업입니다.
    비즈니스 규칙을 실행해야 하는 시기를 결정하기 위해 다음 옵션이 제공됩니다.
    표 1. 비즈니스 규칙을 실행해야 할 때
    옵션 규칙이 실행되는 경우
    이전 사용자가 양식을 제출한 후 데이터베이스의 기록에 대해 조치가 수행되기 전입니다.
    이후 사용자가 양식을 제출하고 데이터베이스의 기록에 대해 작업이 수행된 후입니다.
    비동기 사용자가 양식을 제출한 후 스케줄러가 비즈니스 규칙에서 생성된 예약된 작업을 실행한 후입니다. 시스템은 사용자가 양식을 제출한 후, 데이터베이스의 기록에 대해 조치가 수행되기 전에 비즈니스 규칙에서 예약된 작업을 생성합니다.
    주:
    새로 만든 비즈니스 규칙은 업그레이드 중에 실행됩니다.

    기록에 기록의 데이터를 기반으로 결정을 내리는 비동기 비즈니스 규칙이 있는 경우 기록을 빠르게 연속해서 여러 번 업데이트하면 비즈니스 규칙이 순서대로 잘못 또는 잘못 실행될 수 있습니다.

    여러 비동기 비즈니스 규칙이 동일한 기록을 업데이트하는 경우 한 스크립트에서 수행한 업데이트가 다른 스크립트로 덮어쓰여지거나 실행 순서가 보장되지 않기 때문에 예기치 않은 순서로 이루어질 수 있습니다. 비즈니스 규칙에 대한 후속 옵션을 사용하거나 System Events 이러한 상황에서 대안으로 사용할 수 있습니다.

    표시 양식이 사용자에게 표시되기 전과 데이터베이스에서 데이터를 읽은 직후입니다.
    주:
    • 비동기 비즈니스 규칙은 이전 버전의 기록에 액세스할 수 없습니다. 따라서 changes(), changesTo()changesFrom() GlideElement 메서드는 비동기 규칙 스크립트에서 작동하지 않습니다. 그러나 조건 작성기와 조건 필드(고급 뷰)는 모두 changes(), changesTo()changesFrom() 메서드를 지원합니다.
    • 비즈니스 규칙은 사용자가 ACL을 승인할 때까지 ACL을 승인하지 않습니다. 자세한 내용은 비즈니스 규칙과 접근 통제 규칙(ACL)의 관계를 참조하십시오
    비즈니스 규칙이 적용되는 기록 작업을 결정하기 위해 다음 옵션이 제공됩니다.
    표 2. 비즈니스 규칙이 적용되는 기록 운영
    옵션 규칙이 실행되는 경우
    삽입 사용자가 새 기록을 만들고 시스템에서 데이터베이스에 삽입하는 경우
    업데이트 사용자가 기존 기록을 수정하는 경우.
    쿼리 사용자가 기록 또는 기록 목록에 대한 쿼리를 데이터베이스로 보내는 경우. 일반적으로 이전 비즈니스 규칙에 대한 쿼리 작업을 사용해야 합니다.
    삭제 사용자가 기록을 삭제할 때.
    주:
    비즈니스 규칙은 GlideRecord API에서 호출될 때만 기록 운영을 실행합니다. 일부 애플리케이션은 기록 작업을 직접 수행하기 위해 의도적으로 비즈니스 규칙 처리를 바이패스합니다. 또한 비즈니스 규칙은 setWorkflow() 메서드가 false로 설정된 상태에서 실행되는 API 호출을 무시합니다.
    이 이미지는 다양한 유형의 비즈니스 규칙이 실행되는 때를 보여줍니다.
    그림 1. 비즈니스 규칙 처리 플로우
    주:
    비즈니스 규칙은 양식, 목록 또는 웹 서비스를 통해 액세스하는지 여부에 관계없이 기록에 일관되게 적용됩니다. 이는 양식을 편집할 때만 적용되는 비즈니스 규칙과 클라이언트 스크립트의 주요 차이점 중 하나입니다.

    비즈니스 규칙 작업

    비즈니스 규칙은 다양한 작업을 수행할 수 있습니다. 일반적인 작업 유형은 다음과 같습니다.
    • 사용자가 업데이트 중인 양식의 필드 값을 변경합니다. 필드 값은 해당 필드에 사용할 수 있는 특정 값, 다른 필드에서 복사된 값 및 사용자 역할에 따라 결정되는 상대 값으로 설정할 수 있습니다.
    • 사용자에게 정보 메시지 표시
    • 상위 작업에 대한 변경에 따라 하위 작업의 값을 변경합니다.
    • 사용자가 양식의 특정 필드에 액세스하거나 수정하지 못하도록 합니다.
    • 현재 데이터베이스 트랜잭션을 중단합니다. 예를 들어, 특정 조건이 충족되는 경우 사용자가 데이터베이스에 기록을 저장하지 못하도록 합니다.
    관리자는 스크립트를 작성하지 않고도 필드 값을 설정하고, 정보 메시지를 만들고, 트랜잭션을 중단할 수 있습니다.

    재귀 비즈니스 규칙 방지

    비즈니스 규칙 스크립트에서 current.update() 를 사용하지 마십시오. update() 메서드는 삽입 및 업데이트 작업에 대해 동일한 테이블에서 실행되도록 비즈니스 규칙을 트리거하여 비즈니스 규칙이 계속해서 호출되도록 합니다. 모든 이전 비즈니스 규칙이 완료되고 비즈니스 규칙 이후의 변경 사항은 현재가 아닌 관련 객체를 업데이트하는 데 가장 잘 사용될 때 비즈니스 규칙 이전이 자동으로 저장됩니다. 재귀 비즈니스 규칙이 탐지되면 시스템이 이를 중지하고 시스템 로그에 오류를 기록합니다. 그러나 current.update() 는 시스템 성능 문제를 일으키므로 필요하지 않습니다.

    false 매개 변수와 함께 setWorkflow() 메서드를 사용하여 재귀 비즈니스 규칙을 방지할 수 있습니다. update()setWorkflow() 메서드의 조합은 위에서 언급한 일반적인 전후 지침이 요구 사항을 충족하지 않는 특별한 상황에서만 권장됩니다.

    범위가 지정된 애플리케이션의 비즈니스 규칙

    모든 비즈니스 규칙은 비공개 애플리케이션 범위 또는 전역 범위에 할당됩니다.

    만들 수 있는 비즈니스 규칙의 유형과 이러한 규칙에 액세스하는 방법은 비즈니스 규칙의 범위와 비즈니스 규칙이 실행되는 테이블의 범위에 따라 달라집니다.
    주:
    전역이라는 용어는 비즈니스 규칙의 두 가지 측면, 즉 실행되는 테이블과 실행 범위를 나타낼 수 있습니다. 비즈니스 규칙은 특정 테이블에서 실행되거나 전역으로 실행될 수 있습니다. 또한 전역 범위 또는 비공개 애플리케이션 범위에 있을 수 있습니다.

    특정 테이블의 비즈니스 규칙

    대부분의 비즈니스 규칙은 테이블 필드에 정의된 특정 테이블에서 실행됩니다. 같은 범위의 테이블과 다른 애플리케이션 범위의 구성 기록을 허용하는 테이블에 비즈니스 규칙을 만들 수 있습니다.

    비즈니스 규칙 기록과 범위가 다른 테이블의 경우 규칙 유형이 제한됩니다.

    • 다음 옵션 중 하나를 사용하여 When이 비동기인 규칙을 생성할 수 있습니다.
      • 데이터베이스 삽입, 업데이트삭제 작업. Query(쿼리)를 선택할 수 없습니다.
      • 필드 값 , 작업 및 스크립트( 스크립트 필드)를 설정합니다.
    • 다음 옵션 중 하나를 사용하여 시기가 이전인 규칙을 생성할 수 있습니다.
      • 데이터베이스 삽입, 업데이트삭제 작업. Query(쿼리)를 선택할 수 없습니다.
      • 필드 값 설정 작업만 해당됩니다. 스크립트를 작성할 수 없으며 데이터베이스 트랜잭션을 중단할 수 없습니다.
    • 다른 범위에 있는 테이블에는 다른 유형의 비즈니스 규칙을 만들 수 없습니다.

    특정 테이블의 비즈니스 규칙은 다른 비즈니스 규칙이나 스크립트에서 액세스할 수 없습니다.

    전역 비즈니스 규칙

    경고:
    전역 비즈니스 규칙 대신 스크립트 포함 사용을 고려하십시오. 스크립트 포함은 요청 시에만 로드되고 전역 비즈니스 규칙은 시스템의 모든 페이지에 로드됩니다.

    전역 비즈니스 규칙은 테이블 필드가 전역으로 설정된 비즈니스 규칙입니다. 전역 비즈니스 규칙은 범위 보호에 따라 여러 테이블과 다른 스크립트에서 액세스할 수 있습니다. 전역 비즈니스 규칙의 경우 다음에서 접근 가능 필드를 설정하여 범위 보호를 정의하십시오.

    • 이 애플리케이션 범위만: 비즈니스 규칙과 다른 범위에 있는 애플리케이션이 이 비즈니스 규칙을 호출하지 못하도록 합니다.
    • 모든 애플리케이션 범위: 모든 애플리케이션이 이 비즈니스 규칙을 호출할 수 있도록 허용합니다.
      주:
      전역 비즈니스 규칙은 도메인 분리를 지원하지 않습니다.

    범위가 지정된 비즈니스 규칙의 스크립트

    비즈니스 규칙에서 스크립트를 작성하면 다음에 액세스할 수 있습니다.

    • 비즈니스 규칙과 동일한 범위에 있는 모든 스크립트 포함 및 전역 비즈니스 규칙.
    • 다른 범위의 애플리케이션에서 호출할 수 있도록 하는 스크립트 포함 및 전역 비즈니스 규칙. 다른 범위에서 함수를 호출하려면 함수의 범위를 지정해야 합니다.
    • 고유한 범위에 있는 비즈니스 규칙의 경우 범위가 지정된 시스템 API에만 액세스할 수 있습니다.

    비즈니스 규칙 생성

    기록이 표시, 삽입, 업데이트 또는 삭제되거나 테이블이 쿼리될 때 실행할 모든 유형의 비즈니스 규칙을 만들 수 있습니다.

    이 태스크 정보

    주:
    이러한 지침과 예시는 이 기능을 구현하는 방법에 대한 일반적인 지침을 제공합니다. 고유한 사용 사례에 대한 도움말은 질문을 하고, 다른 개발자와 상호 작용하고, 기존 솔루션을 검색할 수 있는 개발자 커뮤니티 포럼을 참조하십시오.

    프로시저

    1. 다음으로 이동 모두 > 시스템 정의 > 비즈니스 규칙.
    2. 새로 만들기를 클릭합니다.
    3. 필드에 적절한 정보를 입력합니다.
      주:
      양식이 모든 필드를 표시하도록 구성해야 할 수도 있습니다.
      표 3. 비즈니스 규칙 필드
      필드 설명
      이름 비즈니스 규칙의 이름을 입력합니다.
      테이블 비즈니스 규칙이 실행되는 테이블을 선택합니다.
      주:
      목록에는 비즈니스 규칙에 대한 범위 보호를 충족하는 테이블 및 데이터베이스 뷰만 표시됩니다. 데이터베이스 뷰에 대해 정의된 비즈니스 규칙은 쿼리에서만 실행할 수 있습니다. 데이터베이스 뷰에 대한 비즈니스 규칙은 삽입, 업데이트 또는 삭제 시 실행할 수 없습니다.
      애플리케이션 이 비즈니스 규칙이 포함된 애플리케이션입니다.
      다음에서 접근 가능 전역 비즈니스 규칙에 대한 범위 보호.
      주:
      이 필드는 테이블 필드가 전역으로 설정된 경우에만 표시됩니다. 특정 테이블에서 실행되는 규칙에는 적용되지 않습니다.
      활성 비즈니스 규칙을 사용하려면 이 확인란을 선택합니다.
      고급 이 확인란을 선택하면 양식의 고급 버전을 볼 수 있습니다.
      실행 시기
      시기

      [고급] 이 비즈니스 규칙을 실행해야 하는 시기를 표시합니다,이전, 비동기 또는 데이터베이스 작업이 완료된 를 선택합니다.

      주:
      연결된 예약된 작업을 생성할 때 시스템에서 이 값을 사용하므로 비동기 비즈니스 규칙의 순서를 설정하는 것이 좋습니다.

      새로 만든 비동기 비즈니스 규칙은 업그레이드 시 자동으로 실행됩니다.

      기존 비동기 비즈니스 규칙을 마이그레이션하여 새 비동기 동작을 사용할 수 있습니다.

      순서 [고급] 이 비즈니스 규칙이 실행되어야 하는 순서를 나타내는 숫자를 입력합니다. 특정 활동에 대한 규칙이 여러 개 있는 경우 규칙은 가장 낮은 것부터 가장 높은 것 순으로 여기에 지정된 순서대로 실행됩니다.
      삽입 데이터베이스에 기록이 삽입될 때 비즈니스 규칙을 실행하려면 이 확인란을 선택합니다.
      업데이트 기록을 업데이트할 때 비즈니스 규칙을 실행하려면 이 확인란을 선택합니다.
      삭제 [고급] 데이터베이스에서 기록이 삭제될 때 비즈니스 규칙을 실행하려면 이 확인란을 선택합니다.
      쿼리 [고급] 테이블을 쿼리할 때 비즈니스 규칙을 실행하려면 이 확인란을 선택합니다.
      필터 조건 조건 작성기를 사용하여 선택한 테이블의 필드 값에 따라 비즈니스 규칙을 실행해야 하는 시기를 결정합니다. 조건 필드를 사용하여 스크립트로 조건을 작성할 수도 있습니다.
      주:
      문자열 비교를 기반으로 하는 필터는 대/소문자를 구분합니다.
      역할 조건 이 비즈니스 규칙을 실행하기 위해 테이블의 기록을 수정하는 사용자가 가져야 할 역할을 선택합니다.
      작업
      필드 값 설정 선택 목록을 이용해 선택한 테이블의 필드에 값을 설정합니다.
      • 필드
      • 대입 연산자는 다음과 같습니다.
        • 받는 사람: 정확한 값
        • 다음과 같음: 다른 필드의 값
        • 끝(동적): 비즈니스 규칙을 구성하는 사용자나 특정 역할의 사용자에 따른 값입니다
      메시지 추가 이 확인란을 선택하고 이 비즈니스 규칙을 실행할 때 나타나는 메시지를 입력합니다
      작업 중단

      현재 데이터베이스 트랜잭션을 중단하려면 이 확인란을 선택합니다. 예를 들어, 삽입 전 비즈니스 규칙에서 조건이 충족되면 데이터베이스에 기록을 삽입하지 마십시오.

      이 옵션을 선택하면 필드 값 설정 및 스크립트 실행과 같은 기록에 대한 추가 작업을 수행할 수 없습니다. 메시지 추가 확인란을 선택하고 메시지를 작성하여 사용자에게 메시지를 표시할 수도 있습니다.

      고급
      조건 비즈니스 규칙을 실행할 시기를 지정하는 JavaScript 조건문을 만듭니다. 이 필드에 조건문을 추가하면 조건을 별도로 평가하고 조건이 true인 경우에만 비즈니스 규칙을 실행하도록 시스템에 지시할 수 있습니다. 스크립트 필드에 조건문을 포함하기로 결정했거나 조건 작성기를 사용하는 경우 이 필드를 비워 둡니다. 비동기 비즈니스 규칙을 실행하기 전에 인스턴스가 조건문을 다시 평가하도록 하려면 시스템 속성을 glide.businessrule.async_condition_check 추가하고 값을 true로 설정합니다.
      스크립트
      [고급] 정의된 조건이 true일 때 실행되는 스크립트를 만듭니다.
      • onAfter
      • 온어sync
      • onBefore
      • 온디스플레이

      자세한 내용과 예제는 다음 문서를 참조하십시오 예시 비즈니스 규칙 스크립트.

      관련 목록: 버전
      버전 비즈니스 규칙의 모든 버전을 표시합니다. 이 목록을 사용하여 버전을 비교하거나 이전 버전으로 되돌릴 수 있습니다.
    4. 제출을 클릭합니다.
    비즈니스 규칙에 문제가 발생하면 의 Now Support 지식베이스비즈니스 규칙 FAQ [KB0965707] 문서를 참조하십시오.

    비즈니스 규칙의 전역 변수

    미리 정의된 전역 변수를 비즈니스 규칙에 사용할 수 있습니다.

    다음과 같이 미리 정의된 전역 변수를 사용하여 비즈니스 규칙 스크립트에서 시스템을 참조합니다.

    전역 변수 설명
    current 참조되는 기록의 현재 상태입니다. 이 변수를 사용하기 전에 null을 확인하려면 아래의 "null 포인터 예외 방지"를 참조하십시오.
    previous 실행 컨텍스트 중에 수행된 업데이트 이전의 참조 기록의 상태로, 실행 컨텍스트는 첫 번째 업데이트 또는 삭제 작업으로 시작하여 스크립트와 참조된 비즈니스 규칙이 실행된 후에 종료됩니다. 하나의 실행 컨텍스트 내에서 기록이 여러 번 업데이트된 경우 이전 은 첫 번째 업데이트 또는 삭제 작업 전의 기록 상태를 계속 유지합니다. 업데이트 및 삭제 작업에서만 사용할 수 있습니다. 비동기 작업에서는 사용할 수 없습니다. 이 변수를 사용하기 전에 null을 확인하려면 아래의 "null 포인터 예외 방지"를 참조하십시오.
    g_scratchpad 스크래치패드 객체는 표시 규칙에서 사용할 수 있으며 클라이언트 스크립트에서 액세스할 수 있도록 클라이언트에 정보를 전달하는 데 사용됩니다.
    GS GlideSystem 함수에 대한 참조입니다.

    현재, 이전, g_scratchpad 변수는 트랜잭션에 대해 실행되는 모든 비즈니스 규칙에서 전역적입니다.

    null 포인터 예외 방지

    경우에 따라 비즈니스 규칙이 실행될 때 기록의 현재 또는 이전 상태가 없을 수 있으며, 이는 변수가 null이 됨을 의미합니다. 변수를 사용하기 전에 null을 확인하려면 비즈니스 규칙에 다음 코드를 추가합니다.
    if (current == null) // to prevent null pointer exceptions.
    return; 

    변수 정의

    사용자 정의 변수는 기본적으로 전역으로 범위가 지정됩니다. 새 변수가 순서 100 비즈니스 규칙에서 선언되면 순서 200에서 다음에 실행되는 비즈니스 규칙도 변수에 액세스할 수 있습니다. 이로 인해 예기치 않은 동작이 발생할 수 있습니다.

    이러한 예기치 않은 동작을 방지하려면 항상 코드를 함수로 래핑하십시오. 이렇게 하면 함수가 래핑되지 않은 다른 비즈니스 규칙의 시스템 변수 또는 전역 변수와 충돌하지 않도록 변수가 보호됩니다. 또한 current 와 같은 변수는 함수를 호출할 때 사용할 수 있어야 합니다.

    다음 스크립트는 다른 코드와의 충돌에 취약합니다. 변수 now_GR 다른 규칙에서 사용되는 경우 변수 값이 예기치 않게 변경될 수 있습니다.
    var now_GR = new GlideRecord('incident');
    now_GR.query(); 
    while(now_GR.next()) {
     
       //do something
     
    }
    이 스크립트가 함수로 래핑되면 변수는 함수 내에서만 사용할 수 있으며 now_GR라는 변수를 사용하는 다른 함수와 충돌하지 않습니다.
    myFunction();
     
    function myFunction() { 
      var now_GR = new GlideRecord('incident');
      now_GR.query(); 
      while(now_GR.next()) { 
        //do something 
    } }

    비즈니스 규칙 및 클라이언트 스크립트를 사용하여 필드 값 제어

    필드에 대한 비즈니스 규칙과 클라이언트 스크립트를 모두 구현하여 사용자가 양식과 목록을 모두 사용하여 기록 값을 적절히 설정하고 편집 시 양식의 값이 즉시 변경되는 것을 확인할 수 있도록 합니다.

    클라이언트 스크립트나 비즈니스 규칙만 사용하여 필드에 대한 업데이트를 제어할 때의 문제는 양식이나 목록에서 필드를 변경할 수 있다는 것입니다. 클라이언트 스크립트 및 UI 정책은 폼에서만(클라이언트 측) 실행되며 목록 편집에는 적용되지 않습니다. 양식의 필드에서 실행되는 클라이언트 스크립트로 목록 편집을 허용하면 잘못된 데이터가 기록에 저장될 수 있습니다. 클라이언트 스크립트 또는 UI 정책이 양식에 적용되는 시스템의 경우 목록 편집을 사용하지 않도록 설정하거나 적절한 비즈니스 규칙 또는 액세스 제어를 생성하여 목록 편집기에서 값 설정을 제어합니다. 이로 인한 부작용은 클라이언트 스크립트에 구현된 보안 조치가 쉽게 우회할 수 있다는 것입니다. 사용자는 목록에서 필드를 편집하기만 하면 됩니다.

    양식의 비즈니스 규칙은 동적이 아니므로 변경 사항을 표시하려면 사용자가 기록을 업데이트해야 합니다. 따라서 클라이언트 스크립트를 사용하여 양식의 필드 값을 제어하는 데 선호되는 방법이 됩니다.

    비즈니스 규칙과 클라이언트 스크립트를 모두 사용하여 필드 값을 제어하는 경우 업데이트 동작은 시스템 전체에서 동일합니다. 즉, 양식 목록을 사용하여 변경하는지 여부에 따라 업데이트 된 값이 다르지 않습니다. 즉, 클라이언트 스크립트에서 한 번, 비즈니스 규칙이나 액세스 제어에서 한 번, 이렇게 이렇게 동일한 기능을 두 번 구현해야 합니다.

    예: 비즈니스 규칙을 사용하여 사용자 기록을 임포트하는 동안 이메일 주소 만들기

    조직에는 사용자의 이메일 주소를 first.last@company.com 설정하는 클라이언트 스크립트가 있습니다. 관리자는 사용자 정보를 입력하는 즉시 이메일 주소를 볼 수 있도록 이 작업을 수행합니다. 그런 다음 관리자는 사용자의 이름과 성이 포함된 스프레드시트에서 사용자를 대량으로 가져옵니다. 각 사용자의 이메일 주소는 양식을 편집할 때와 마찬가지로 자동으로 설정됩니다. 클라이언트 스크립트는 양식(기록에 대한 인터페이스)에서만 실행되므로 해당 인터페이스 외부에서 기록으로 임포트된 데이터에는 영향을 주지 않으며 이메일 주소가 생성되지 않습니다. 이 문제를 해결하기 위해 관리자는 임포트가 발생할 때 실행되는 비즈니스 규칙을 구현하고 이메일 주소를 만듭니다.

    예: 양식에서 편집할 수 없는 필드에 대한 목록 편집 방지

    할당 그룹이 개발인 경우 조직에서 인시던트 양식에서 우선순위 필드를 숨기려고 합니다. 이를 위해 인시던트 양식에 UI 정책을 생성하지만, 사용자는 여전히 목록 편집기를 사용하여 우선순위 필드를 보고 편집할 수 있습니다. 이를 해결하려면 접근 제어를 적용하여 할당 그룹이 개발일 때 우선순위 필드에 대한 읽기 권한을 차단하십시오.

    NULL을 필드 값으로 사용

    문자열 NULL은 스크립트에서 특정 역할을 하며 예약어입니다.

    예약어는 모두 대문자로 NULL 입니다. 예를 들어 값이 Null 또는 null인 필드를 사용할 수 있습니다. 특정 필드를 지울 때만 NULL을 사용하십시오.

    임포트 세트 데이터 소스에서 가져온 모든 NULL 필드 값은 스테이징 테이블에 빈 필드 값으로 삽입됩니다. 임포트 세트 변환 맵이나 이름 또는 필드의 필드 값으로 NULL이라는 용어를 사용해서는 안 됩니다. 또한 시스템에서는 값을 예약어가 아니라 NULL이라는 단어가 포함된 문자열로 해석하므로 참조 필드에 NULL을 사용하지 마십시오.

    비즈니스 규칙 표시

    표시 규칙은 사용자가 기록 양식을 요청할 때 처리됩니다.

    데이터베이스에서 데이터를 읽고, 표시 규칙이 실행되고, 양식이 사용자에게 표시됩니다. 현재 객체를 사용할 수 있으며 데이터베이스에서 검색된 기록을 나타냅니다. 필드 변경 사항은 아직 데이터베이스에 제출되지 않았기 때문에 일시적입니다. 클라이언트에게 양식 값은 데이터베이스의 값으로 나타납니다. 값이 표시 규칙에서 수정되었다는 표시가 없습니다. 이는 계산된 필드와 유사한 개념입니다.

    표시 규칙의 기본 목적은 공유 스크래치패드 객체인 g_scratchpad를 사용하는 것이며, 이 객체도 양식의 일부로 클라이언트에 전송됩니다. 이 기능은 일반적으로 표시되는 기록에 속하지 않는 서버 데이터를 요구하는 클라이언트 스크립트를 작성해야 할 때 유용할 수 있습니다. 대부분의 경우 이를 위해서는 클라이언트 스크립트가 서버로 콜백해야 합니다. 양식이 표시되기 전에 데이터를 확인할 수 있는 경우 초기 로드 시 클라이언트에 데이터를 제공하는 것이 더 효율적입니다. 양식 스크래치패드 객체는 기본적으로 빈 객체이며, 데이터의 이름:값 쌍을 저장하는 데만 사용됩니다.

    표시 규칙의 데이터로 양식 스크래치패드를 채우려면 다음을 수행합니다.
    // From display business rule
    g_scratchpad.someName = "someValue";
    g_scratchpad.anotherName = "anotherValue";
     
    // If you want the client to have access to record fields not being displayed on the form
    g_scratchpad.created_by = current.sys_created_by; 
     
    // These are simple examples, in most cases you will probably perform some other 
    // queries to test or get data
    클라이언트 스크립트에서 양식 스크래치패드 데이터에 액세스하려면 다음을 수행합니다.
    // From client script 
    if(g_scratchpad.someName == "someValue") { 
      //do something special 
    }

    작업 활성 상태 관리 비즈니스 규칙

    이 비즈니스 규칙은 상태 필드의 변경에 따라 활성 필드 값을 변경해야 하는지 여부를 결정합니다.

    작업 기록의 상태가 변경될 때 작업 활성 상태 관리 비즈니스 규칙이 실행됩니다. 실행 순서는 50이며 대부분의 다른 작업 비즈니스 규칙보다 먼저 실행됩니다.

    현재 작업 테이블에 close_states 해당 테이블에 정의된 속성이 있거나 상위 수준 테이블에서 상속된 경우 규칙은 활성 필드를 변경해야 하는지 여부를 결정합니다. 이 작업은 이전 상태와 현재 상태 값을 비교하여 수행됩니다.
    • 상태가 활성 상태에서 비활성 상태로 변경되면 활성 필드가 false로 설정됩니다.
    • 상태가 비활성 상태에서 활성 상태로 변경되면 활성 필드가 true로 설정되어 작업이 효과적으로 다시 활성화되거나 다시 열립니다.

    각 작업 테이블에서 작업을 비활성 또는 활성으로 표시하는 규칙을 만드는 것과는 반대로 비즈니스 규칙에서 작업을 활용하는 (current.active.changesTo([true/false]) 것이 좋습니다.

    예시 비즈니스 규칙 스크립트

    조직의 요구사항에 도움이 되는 예시 비즈니스 규칙 스크립트를 찾아보십시오.

    주:
    이러한 지침과 예시는 이 기능을 구현하는 방법에 대한 일반적인 지침을 제공합니다. 고유한 사용 사례에 대한 도움말은 질문을 하고, 다른 개발자와 상호 작용하고, 기존 솔루션을 검색할 수 있는 개발자 커뮤니티 포럼을 참조하십시오.

    비즈니스 규칙의 날짜 필드 비교

    비즈니스 규칙에서 두 개의 날짜 필드 또는 두 개의 날짜 및 시간 필드를 비교하고 올바르지 않은 경우 기록 삽입 또는 업데이트를 중단할 수 있습니다.

    예를 들어 시작 날짜를 종료 날짜 이전으로 설정할 수 있습니다. 다음은 예시 스크립트입니다.

    if ((!current.u_date1.nil()) && (!current.u_date2.nil())) { 
      var start = current.u_date1.getGlideObject().getNumericValue(); 
      var end = current.u_date2.getGlideObject().getNumericValue(); 
      if (start > end) {
        gs.addInfoMessage('start must be before end');
        current.u_date1.setError('start must be before end') ;
        current.setAbortAction(true);
     } }

    이 예제는 전역 스크립트에서 테스트되었으며 범위가 지정된 스크립트에서 작동하려면 변경해야 할 수 있습니다. API 변경이 필요할 수 있을 뿐만 아니라 범위가 지정된 스크립트에서는 보안이 더 엄격합니다.

    비즈니스 규칙을 삽입 및 업데이트 작업에 대한 선행 규칙으로 설정하는 것이 좋습니다. 예시 스크립트에서:
    • u_date1u_date2 는 두 날짜 필드의 이름입니다. 이러한 이름을 고유한 필드 이름으로 바꿉니다.
    • 첫 번째 줄은 두 필드에 실제로 값이 있는지 확인합니다.
    • 다음 두 줄은 날짜의 숫자 값을 갖는 변수를 만듭니다.
    • 그 다음 두 줄은 최종 사용자를 위한 서로 다른 경보 메시지를 작성하는데, 하나는 양식 상단에 하나씩, 다른 하나는 양식의 u_date1 필드에 표시됩니다.
    • 마지막 줄은 날짜 필드가 올바르지 않으면 삽입 또는 업데이트를 중단합니다.
    다음은 위의 비교에 대한 더 복잡한 예입니다. 시작 날짜와 종료 날짜가 두 쌍 이상인 경우 표시된 대로 배열을 사용할 수 있습니다. 또한 이 스크립트를 사용하려면 입력 날짜가 특정 범위(이 경우 과거 30일 이내, 미래 365일 이내) 내에 있어야 합니다.
    // Enter all start and end date fields you wish to check, as well as the previous values 
    // Make sure that you keep the placement in the sequence the same for all pairs 
    var startDate = new Array(current.start_date,current.work_start); 
    var prevStartDate = new Array(previous.start_date,previous.work_start); 
    var endDate = new Array(current.end_date,current.work_end); 
    var prevEndDate = new Array(previous.end_date,previous.work_end);
    
    // The text string below is added to the front of ' start must be before end' 
    var userAlert = new Array('Planned','Work');
     
    // Set the number of Previous Days you want to check 
    var pd = 30; 
    // Set the number of Future Days you want to check 
    var fd = 365;
     
    // You shouldn't have to modify anything below this line
     
    var nowdt = new GlideDateTime();
    nowdt.setDisplayValue(gs.nowDateTime()); 
    var nowMs = nowdt.getNumericValue(); 
    var pdms = nowMs; 
    
    // Subtract the product of previous days to get value in milliseconds
    pdms -= pd * 24 * 60 * 60 * 1000; 
    var fdms = nowMs; 
    
    // Add the product of future days to get value in miliseconds
    fdms += fd * 24 * 60 * 60 * 1000; 
    var badDate = false;
     
     // Iterate through all start and end date / time fields 
    for (x = 0; x < startDate.length; x ++) { 
      if ((!startDate[x].nil()) && (!endDate[x].nil())) { 
        var start = startDate[x].getGlideObject().getNumericValue(); 
        var end = endDate[x].getGlideObject().getNumericValue(); 
        if (start > end) {
          gs.addInfoMessage(userAlert[x] + ' start must be before end');
          startDate[x].setError(userAlert[x] + ' start must be before end');
          badDate = true; } 
        else if ((prevStartDate[x]) != (startDate[x])) { 
          if (start < pdms) {
             gs.addInfoMessage(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
             startDate[x].setError(userAlert[x] + ' start must be fewer than ' + pd  + ' days ago');
             badDate = true; } } 
        else if ((prevEndDate[x]) != (endDate[x])) { 
          if (end > fdms) {
             gs.addInfoMessage(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
             endDate[x].setError(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
             badDate  = true ; 
    } } } } 
    if (badDate == true ) {
      current. setAbortAction ( true ) ; }

    XML 페이로드 구문 분석

    XML 형식의 필드는 시스템의 getXMLText 함수를 사용하여 구문 분석할 수 있습니다.

    ecc_event 행의 페이로드와 같이 XML 형식으로 데이터베이스에 삽입되는 필드는 시스템의 getXMLText 함수를 사용하여 구문 분석할 수 있습니다. getXMLText 함수는 문자열과 XPATH 식을 사용합니다. 예:
    var name = gs.getXMLText("<name>joe</name>", "//name");

    문자열 'joe'를 반환합니다.

    "페이로드" 필드에 XML이 포함되어 있다고 가정하면 함수 호출은 다음과 같을 수 있습니다.
    var name = gs.getXMLText(current.payload, "//name");

    XPATH에 대한 자세한 내용은 w3schools를 방문하십시오.

    비즈니스 규칙 이전 데이터베이스 작업 중단

    이전 비즈니스 규칙 스크립트에서 setAbortAction() 메서드를 사용하여 현재 데이터베이스 작업을 취소하거나 중단할 수 있습니다.

    예를 들어, 삽입 동작 중에 이전 비즈니스 규칙이 실행되고 스크립트에 current.setAbortAction(true)을 호출하는 조건이 있는 경우 current에 저장된 새 레코드는 데이터베이스에 생성되지 않습니다. setAbortAction()을 호출한 후에도 비즈니스 규칙이 계속 실행되며 모든 후속 비즈니스 규칙이 정상적으로 실행됩니다. 이 메서드를 호출하면 현재 개체에 대한 데이터베이스 작업만 발생하지 않습니다.

    isActionAborted() 메서드를 사용하여 현재 데이터베이스 동작(삽입, 업데이트, 삭제)이 중단되는지 여부를 판별할 수 있습니다. isActionAborted()는 새 스레드에 대해 초기화되고 next() 메서드는 명시적으로 해당 값을 false로 설정합니다.

    주:
    setAbortAction() 은 작업이 중단되는 기록과 동일한 범위에서만 실행될 수 있습니다. current.setAbortAction 은 다른 범위에 정의된 비즈니스 규칙에서 실행되는 경우 적용되지 않습니다.

    비즈니스 규칙을 트리거한 작업을 결정합니다.

    둘 이상의 데이터베이스 작업에서 트리거되는 비즈니스 규칙에 대한 스크립트를 작성할 수 있습니다.

    이벤트를 트리거한 작업에 따라 비즈니스 규칙 스크립트가 동적으로 분기되도록 하려면 operation() 함수를 사용할 수 있습니다. 예:
    if(current.operation() == "update") {
      current.updates ++; } 
      if(current.operation() == "insert") {
        current.updates = 0; }

    비즈니스 규칙에서 OR 조건 사용

    비즈니스 규칙 내의 모든 쿼리 파트에 OR 조건을 추가할 수 있습니다.

    addOrCondition() 메서드를 사용하여 비즈니스 규칙 내의 쿼리 파트에 OR 조건을 추가할 수 있습니다. 아래 예는 우선순위가 1 또는 2인 모든 인시던트를 찾기 위한 쿼리를 보여줍니다. 첫 번째 addQuery() 조건은 변수로 정의되며 OR 조건에서 사용됩니다.
    var inc = new GlideRecord('incident'); 
    var qc = inc.addQuery('priority','1'); 
    qc.addOrCondition('priority','2');
    inc.query(); 
    while(inc.next()) { 
      // processing for the incident goes here 
    }
    다음 스크립트는 (priority = 1 OR priority = 2) AND (impact = 2 OR impact = 3)에 해당하는 두 개의 쿼리 조건 변수를 사용하는 보다 복잡한 예입니다. OR 조건의 결과는 두 개의 변수 qc1qc2로 실행됩니다. 이렇게 하면 스크립트의 뒷부분에서 쿼리 조건 객체를 조작할 수 있습니다(예: IF 조건 또는 WHILE 루프 내부).
    var inc = new GlideRecord('incident'); 
    var qc1 = inc.addQuery('priority','1');
    qc1.addOrCondition('priority','2'); 
    var qc2 = inc.addQuery('impact','2'); 
    qc2.addOrCondition('impact','3'); 
    inc.query(); 
    while(inc.next()) { 
      // processing for the incident goes here  
    }

    비즈니스 규칙에서 Glide 목록 참조

    Glide 목록으로 정의된 필드는 단일 필드에 저장된 값의 배열입니다.

    다음은 비즈니스 규칙을 작성할 때 glide_list 필드를 처리하는 방법에 대한 몇 가지 예입니다. 일반적으로 glide_list 필드에는 다른 테이블에 대한 참조 값 목록이 포함됩니다.

    예제

    예를 들어 작업 내의 감시 목록 필드는 사용자 기록에 대한 참조를 포함하는 glide_list입니다.

    아래 코드는 필드를 참조하는 방법을 보여줍니다.

    // list will contain a series of reference (sys_id) values separated by a comma
    // array will be a javascript array of reference values
    var list = current.watch_list.toString();
    var array = list.split(",");
    for (var i=0; i < array.length; i++) {
       gs.print("Reference value is: " + array[i]);
    }
    출력:
    *** Script: Reference value is: 62826bf03710200044e0bfc8bcbe5df1
    *** Script: Reference value is: c2826bf03710200044e0bfc8bcbe5d45
    *** Script: Reference value is: 5f74e421c0a8010e01ec0d74a7ee2cc6
    *** Script: Reference value is: 06826bf03710200044e0bfc8bcbe5d57

    아래와 같이 getDisplayValue() 메서드를 사용하여 참조 값과 연결된 표시 값을 가져올 수도 있습니다.

    // list will contain a series of display values separated by a comma
    // array will be a javascript array of display values
    var list = current.watch_list.getDisplayValue();
    var array = list.split(",");
    for (var i=0; i < array.length; i++) {
       gs.print("Display value is: " + array[i]);
    }
    출력:
    *** Script: Display value is: Abel Tuter
    *** Script: Display value is:  Ashley Leonesio
    *** Script: Display value is:  Charles Beckley
    *** Script: Display value is:  Cherie Fuhri

    indexOf("searchString")를 사용하여 Glide 목록에서 문자열 찾기

    감시 목록과 같은 Glide 목록 필드에 하나 이상의 값이 있는 경우 indexOf("searchString")를 사용하여 메서드에 전달된 문자열의 위치를 반환합니다.

    필드가 비어 있으면 undefined를 반환합니다. 정의되지 않은 값을 반환하지 않으려면 다음 중 하나를 수행합니다.

    • 필드를 문자열(예: watch_list.toString().indexOf("searchString")로 강제 적용
    • indexOf()를 사용하기 전에 if (watch_list.nil() || watch_list.indexOf("searchString") == -1)

    사용자 계정 잠금

    사용자가 활성 상태가 아니면 사용자 계정을 잠글 수 있습니다.

    다음 비즈니스 규칙 스크립트는 사용자가 LDAP 디렉터리에서 활성화되어 있지 않거나 인스턴스에 대한 셀프 서비스, itil 또는 관리자 액세스 권한이 없는 경우 사용자 계정을 잠급니다.
    // Lock accounts if bcNetIDStatus != active in LDAP and user does not  
    // have self-service, itil or admin role 
    var rls = current.accumulated_roles.toString(); 
    if(current.u_bcnetidstatus == 'active' && (rls.indexOf(',itil,') > 0 || 
      rls.indexOf(',admin,') > 0 || 
      rls.indexOf(',ess,') > 0 )) { 
      current.locked_out = false; } 
    else { 
      current.locked_out = true; } 
    
    var now_GR = new GlideRecord("sys_user"); 
    now_GR.query(); 
    while(now_GR.next()) { 
      now_GR.update(); 
      gs.info("updating " + gr.getDisplayValue()); 
    }

    기본 쿼리 전 비즈니스 규칙

    데이터베이스 쿼리가 수행되기 전에 실행되는 쿼리 비즈니스 규칙을 사용할 수 있습니다.

    이 쿼리 비즈니스 규칙을 사용하여 사용자가 특정 기록에 액세스하지 못하도록 합니다. 인시던트 기록에 대한 액세스를 제한하는 기본 비즈니스 규칙의 다음 예를 고려하십시오.
    • 이름: incident query
    • 테이블: 인시던트
    • 시기: 전, 쿼리
    • 스크립트:
    if(!gs.hasRole("itil") && gs.isInteractive()) { 
      var u = gs.getUserID(); 
      var qc = current.addQuery("caller_id",u).addOrCondition("opened_by",u).addOrCondition("watch_list","CONTAINS",u);
      gs.print("query restricted to user: " + u); }
    이 예시에서는 사용자가 itil 역할이 있거나 호출 자 또는 오픈한 사람 필드에 나열되지 않은 경우 인시던트 기록에 액세스하지 못하도록 합니다. 예를 들어 셀프 서비스 사용자가 인시던트 목록을 열면 제출한 인시던트만 볼 수 있습니다.
    주:
    액세스 제어를 사용하여 사용자가 볼 수 있는 기록을 제한할 수도 있습니다.