플로우, 하위 플로우 및 작업에 대한 워크플로우 스튜디오 일반 지침

워크플로우 스튜디오 개요

워크플로우 생성, 구성 및 모니터링을 단일 페이지 환경으로 통합합니다. Playbook, 플로우, 작업, 결정 테이블 및 통합을 하나의 설계 환경으로 통합합니다.

애플리케이션 개발

작업 또는 플로우를 설계할 때 다음과 같은 일반 가이드라인을 사용합니다.

표준 Now Platform 애플리케이션 개발 기능을 사용하여 콘텐츠를 생성, 관리, 보호 및 배포 워크플로우 스튜디오 합니다. 플로우 디자이너와 작업 디자이너는 일반적으로 다음과 같은 애플리케이션 개발 작업을 수행합니다.

플로우와 작업을 저장할 사용자 지정 애플리케이션을 만듭니다.
애플리케이션 권한을 설정하여 애플리케이션 데이터에 대한 액세스를 공유하거나 제한합니다.
애플리케이션 개발자에게 에 대한 액세스 권한을 부여합니다 워크플로우 스튜디오.
사용자 지정 애플리케이션을 애플리케이션 리포지토리에 게시하여 다른 인스턴스에 플로우와 작업을 배포합니다.

플로우

플로우는 짧고 모듈식이며 재사용 가능한 작업 컬렉션이어야 합니다. 실행하는 데 한 시간 이상 걸리는 경우 시간이 너무 길고 더 효율적일 수 있습니다.

플로우에 적용되는 일반 가이드라인 은 하위 플로우에도 적용됩니다.

상충 또는 중복된 비즈니스 논리 방지

자동화는 Flow Designer, 비즈니스 규칙, 워크플로우, Integration Hub를 사용하여 생성할 수 있습니다. 사용을 워크플로우 스튜디오 시작하기 전에 기존 Now Platform 자동화의 작동 방식을 이해해야 합니다. 자동화를 플로우 및 작업으로 워크플로우 스튜디오 대체하기 전에 비활성화합니다. 에서 Now Platform어떻게 작동하는지 알아보려면 워크플로우 스튜디오 를 아키텍처 개요 참조하십시오.

필요한 경우 플로우, 하위 플로우 및 작업 설명서를 검토합니다.

플로우에 트리거 또는 변수 입력이 필요한지 여부를 결정합니다.

플로우는 항상 트리거 조건이 충족될 때 실행되며, 트리거는 항상 플로우에 대한 입력과 동일한 데이터를 제공합니다. 대신 플로우를 시작하기 위해 변수 입력이 필요한 경우 하위 플로우를 생성합니다.

비즈니스 논리 재사용

재사용 가능한 작업 집합을 여러 흐름에서 사용할 수 있는 하위 흐름으로 만듭니다.

역할로 보호된 데이터에 액세스하고 사용자 정보를 보존할 수 있는 플로우 역할 부여

플로우 역할은 플로우에 대한 권한을 단순하게 유지하는 데 도움이 됩니다. 시스템 사용자로 플로우를 실행하는 대신 플로우 역할을 사용하여 사용자 정보를 보존하고 데이터에 대한 액세스 권한을 부여합니다. 플로우 역할을 추가하면 사용자가 시작한 플로우에 일반적으로 없는 추가 데이터에 액세스할 수도 있습니다. 부여된 역할은 플로우에만 적용됩니다. 플로우를 시작한 사용자에게는 적용되지 않습니다.

플로우 로직 또는 일정 기반 트리거를 사용하여 플로우 타이밍 제어

플로우 로직 또는 일정 기반 트리거는 플로우의 성능을 최적화하는 데 도움이 됩니다. gs.sleep() 메서드를 사용하여 흐름 내에서 대기하지 마십시오. gs.sleep()메소드는 스레드가 다른 작업을 수행하지 못하게합니다. 특정 시간에 흐름을 실행하려면 일정 기반 트리거를 사용합니다. 특정 기간 동안 플로우를 일시 중지하려면 기간 대기 또는 조건 대기 플로우 로직을 사용합니다.

의존성 방지

서로 종속된 병렬 분기는 분기가 다른 분기의 출력을 기다려야 할 때 흐름을 중단합니다. 플로우 내에 병렬 분기를 만드는 대신 하위 플로우를 호출하고 결과를 메인 플로우로 반환합니다.

범위 루프 카운터

스크립트 루프에는 최대 반복 횟수가 없으므로 유효한 종료 조건이 없을 때 루프가 무한히 실행됩니다.

유효한 종료 조건이 있는지 확인하려면 인라인 스크립트나 동작 내 스크립트 단계에 루프 카운터의 범위를 지정하십시오.for (i=0; i< length; i++) :for (var i=0; i< length; i++)에var을 추가합니다.

For Each 및 Do Until 루프를 1,000회 반복으로 제한

1,000개 이상의 루프가 있는 반복은 실행 세부 정보 및 컨텍스트 레코드를 저장해야 하는 메모리 문제로 이어질 수 있습니다.

기록 조회에서 최대 기록을 설정합니다.
기본값이 1000인 sn_flow_designer.max_iterations 속성을 변경하지 마십시오.
중첩 루프의 경우 각 루프에는 고유한 최대 반복 횟수가 있습니다.
많은 양의 데이터를 처리하려면 더 작은 일괄 처리로 일괄 처리하는 것이 좋습니다.
대량 임포트의 경우 동시 임포트를 고려하십시오.

QuickAPI를 사용하여 실행 속도 향상(비즈니스 규칙 대안)

QuickAPI 실행은 훨씬 빠르지만 디버깅 기능은 적습니다.
포그라운드 QuickAPI 실행은 플로우를 호출한 사용자로 사용자 세션에서 실행됩니다.
백그라운드 QuickAPI 실행은 백그라운드 스레드에서 실행되며 '시스템' 사용자 세션에서 실행됩니다.

자체에서 흐름을 호출하는 대신 Do Until 루프를 사용합니다.

플로우가 자신을 호출하고 오류가 발생하는 직접 재귀입니다. 흐름 A가 흐름 B를 호출하는 간접 재귀로, 흐름 A를 호출하는 경우 최대 3번까지 허용됩니다. 플로우를 재귀적으로 호출하는 대신, 종료 시점 플로우 논리를 사용하여 특정 조건이 충족될 때까지 기록 작업을 계속합니다.

백그라운드에서 플로우 실행

백그라운드 에서 플로우를 실행하면 플로우 실행이 완료될 때까지 사용자 세션을 일시 중지하는 대신 UI 스레드 를 해제할 수 있습니다. 기본적으로 플로우는 백그라운드에서 비동기식으로 실행됩니다. 백그라운드에서 플로우를 실행하면 플로우가 실행되는 동안 사용자가 UI에서 작업을 계속할 수 있습니다.

큰 출력을 수집한 후 대기하는 플로우 논리를 방지합니다.

큰 페이로드를 검색된 직후에 사용하면 메모리 문제를 방지할 수 있습니다. 메모리에 큰 페이로드를 저장하는 대신 페이로드를 처리하는 작업을 추가합니다. 검색된 페이로드를 빨리 처리할수록 시스템에서 다른 작업을 처리하기 위해 메모리를 더 빨리 확보할 수 있습니다.

환경 간 S 위칭 최소화

플로우에서 인스턴스와 MID 서버 단계 사이를 계속 전환하면 처리가 지연될 수 있습니다. 지연 위험을 최소화하려면 인스턴스와 MID 간 전환을 한 번만 제한하십시오.

플로우에 의해 생성된 sys_complex_object 기록을 업데이트 세트에 포함

복잡한 데이터 스키마가 누락되면 실행 문제가 발생할 수 있습니다. 플로우에 의해 생성된 sys_complex_object 기록을 업데이트 세트에 포함시켜야 합니다. 업데이트 세트를 수동으로 빌드하는 대신, 애플리케이션 리포지토리를 사용하여 한 인스턴스에서 다른 인스턴스로 플로우를 전송하는 것이 좋습니다.

사용자 지정 트리거가 필요한 경우 스크립트에서 플로우 호출

비즈니스 요구에 맞는 기존 트리거가 없는 경우 사용자 지정 트리거 조건이 충족될 때 플로우를 시작하는 스크립트를 만들 수 있습니다. 불필요한 트리거가 있는 플로우를 생성하는 대신 트리거가 없는 하위 플로우를 생성하는 것이 좋습니다. 스크립트를 사용하여 스크립트 조건이 충족되는 경우에만 필요한 하위 플로우 입력을 제공합니다. 플로우가 아닌 하위 플로우를 호출하면 플로우 트리거 조건이 충족되어 플로우가 예기치 않게 실행될 가능성을 방지할 수 있습니다.

최신 릴리스 플로우를 이전 릴리스의 인스턴스에 배포하지 않도록 합니다.

워크플로우 스튜디오 는 이전 릴리스에서 실행되는 인스턴스에 플로우를 배포하는 것을 지원하지 않습니다. 경우에 따라 플로우의 데이터 모델이 릴리스 간에 변경되어 플로우가 실행되지 않거나 예기치 않은 결과가 발생할 수 있습니다.

프로덕션에서 플로우 보고 끄기

플로우 보고를 사용하지 않도록 설정하여 플로우를 실행하는 데 필요한 메모리 양을 최소화합니다. 플로우 보고는 실행 상세 정보 페이지에 대한 구성 및 런타임 정보를 저장합니다. 이러한 보고서는 문제 해결에 유용하지만 메모리와 데이터베이스 모두에 많은 양의 데이터를 보존해야 합니다. 기본적으로 플로우 보고는 비활성화되어 있으며, 플로우 또는 작업을 수동으로 테스트할 때만 실행 세부 정보가 시스템에서 생성됩니다. 대신 보고가 꺼져 있어도 사용할 수 있는 로그 파일을 사용할 수 있습니다.

중첩 루핑이 있는 플로우에서 사용되는 메모리 양 감소

보고가 활성화되면 com.snc.process_flow.reporting.iteration.lastn 값을 "1"로 설정하여 이전 루프 반복에서 사용하는 메모리 양을 줄입니다. 보고하는 반복이 많을수록 더 많은 메모리가 필요합니다.

하위 플로우

플로우에 적용되는 일반 가이드라인은 하위 플로우에도 적용됩니다.

플로우 대신 하위 플로우를 사용하는 이유는 다음과 같습니다.

플로우에 트리거 또는 변수 입력이 필요한지 여부를 결정합니다.

플로우는 항상 트리거 조건이 충족될 때 실행됩니다. 트리거는 항상 플로우에 대한 입력과 동일한 데이터를 제공합니다. 대신 플로우를 시작하기 위해 변수 입력이 필요한 경우 하위 플로우를 생성합니다.

비즈니스 논리 재사용

재사용 가능한 작업 집합을 여러 흐름에서 사용할 수 있는 하위 흐름으로 만듭니다.

각 호출에 대해 서로 다른 입력 값을 구성합니다

하위 플로우의 입력 값은 호출할 때마다 다르게 구성됩니다. 예를 들어, 다른 기록 유형을 입력 실행으로 허용하도록 하위 플로우를 설계합니다. 각 기록 유형에 대해 특정 플로우를 작성하는 대신 이 일반 기록 하위 플로우를 재사용합니다.

대규모 플로우의 성능 및 가독성 향상

플로우가 25개 작업을 초과하면 하위 플로우를 사용합니다. 50은 sn_flow_designer.max_actions 시스템 속성에 의해 지정되는 최대 작업 수이지만 최상의 성능을 위해 플로우를 25개 작업으로 제한합니다.

하위 플로우를 사용하여 입력 및 출력 전달

입력과 출력을 전달하려면 하위 플로우를 호출합니다. 하위 플로우가 시작될 때 사용할 수 있는 입력을 지정하거나 하위 플로우가 종료된 후 상위 플로우에서 사용할 수 있는 출력을 지정하려는 경우 하위 플로우를 사용합니다.

병렬 하위 플로우를 사용할 때와 비교하여 단일 이벤트에서 여러 플로우를 트리거합니다.

상호 관련된 출력이 있거나 모두 사용할 수 있는 경우 일부 작업을 수행해야 하는 경우 병렬 하위 플로우를 사용합니다. 그렇지 않은 경우 여러 플로우를 트리거하는 것이 더 간단합니다.
병렬 하위 플로우를 구성하려면 대기 없이 각 하위 플로우를 시작한 다음 대기 조건을 사용하여 각 하위 플로우가 종료(완료, 오류, 취소됨)가 될 때까지 기다립니다.

유사한 기능을 가진 여러 하위 플로우가 있는 경우 동적 플로우를 사용합니다.

동적 플로우를 사용하면 템플릿을 적용하여 유사한 하위 플로우의 입력을 처리함으로써 프로세스를 구분할 수 있습니다. 구획화를 통해 통합 허브 스포크에 대한 하위 플로우와 같은 유사한 기능을 수행하는 하위 플로우를 구별할 수 있습니다.

오류 처리 프로세스에서 10개 항목 제한을 방지하십시오.

오류 처리 프로세스를 10개 항목 제한 내에 맞추도록 강제하는 대신, 더 많은 항목을 포함할 수 있는 하위 플로우를 호출하십시오. 하위 플로우 출력을 사용하여 다른 플로우에서 자동화를 트리거할 수도 있습니다.

수정 조치 수행

여러 플로우에서 동일한 작업 시퀀스를 다시 만드는 대신 재사용 가능한 하위 플로우를 만들어 기록 데이터의 오류를 수정합니다. 플로우 오류로 인해 기록 데이터가 원치 않는 상태가 되면 하위 플로우를 사용하여 이러한 기록을 수정합니다. 오류 핸들러를 사용하여 하위 플로우 출력과 같은 기록 데이터를 식별할 수 있습니다.

트리거

기록 트리거를 만들 때 다음과 같은 일반 가이드라인을 따르십시오.

플로우에 트리거 또는 변수 입력이 필요한지 여부를 결정합니다.: 플로우는 항상 트리거 조건이 충족될 때 실행됩니다. 트리거는 항상 플로우에 대한 입력과 동일한 데이터를 제공합니다. 대신 플로우를 시작하기 위해 변수 입력이 필요한 경우 하위 플로우를 생성합니다.
플로우를 시작할 기록 값을 지정하는 조건 추가: 필요할 때만 플로우를 시작하면 플로우를 시작하고, 일시 중지하고, 특정 기록 조건이 적용될 때까지 플로우 재개를 기다리는 것보다 시스템 자원이 적게 소비됩니다. 조건 대기 동작으로 시작하는 플로우를 생성하는 대신, 대기 조건을 기록 트리거의 일부로 포함하도록 플로우를 다시 설계하십시오.
같은 테이블에서 기록 트리거에 대한 고유 조건 생성: 플로우가 서로 덮어쓰지 않도록 하려면 동일한 테이블에서 실행 중인 각 플로우에 대해 고유한 조건을 생성하십시오. 같은 테이블의 여러 플로우가 동일한 필터인 경우 플로우가 실행되는 순서를 알 수 없습니다. 또한 조건을 사용하면 보다 정확하고 더 작은 기록 세트를 반환하여 플로우 성능을 최적화하는 데 도움이 됩니다.
임포트 및 업데이트 세트에 의해 추가되거나 업데이트된 기록 무시: 기록 트리거는 업데이트 세트를 적용하거나 XML 파일을 가져와서 추가되거나 업데이트된 기록을 무시합니다. 이러한 작업은 개별 기록이 아닌 전체 애플리케이션 또는 테이블에 적용됩니다.
Service Catalog 테이블의 기록 트리거를 Service Catalog 애플리케이션 트리거로 교체: Flow Designer는 더 이상 Service Catalog 테이블을 기록 트리거에 대한 옵션으로 표시하지 않습니다. 대신 Service Catalog 애플리케이션 트리거 유형을 사용하는 플로우를 만드십시오.

대기 조건

조건을 기다리는 플로우를 생성할 때 다음과 같은 일반 가이드라인을 따르십시오.

대기 조건 대신 기록 트리거를 사용하여 플로우 시작: 특정 기록 조건이 충족될 때만 플로우가 실행되도록 하려면 플로우를 시작하고 일시 중지하는 대신 기록 트리거를 사용하여 플로우를 생성합니다. 대기 중인 플로우는 플로우 트리거보다 시스템 자원을 더 많이 사용합니다.
재개 조건이 발생할 수 없는 플로우 취소: 를 사용하여 End Flow 플로우 로직플로우 중지 조건을 지정하여 플로우가 무기한 대기하지 않도록 합니다. 시스템 자원을 확보하기 위해 재개 조건을 충족할 수 없는 플로우를 취소할 수도 있습니다. 예를 들어 관련 인시던트가 종결되어 인시던트 기록 업데이트를 기다리는 플로우를 취소할 수 있습니다.
대기 조건을 현재 테이블에 있는 필드로 제한: 조건 대기 동작은 기록이 속한 테이블의 필드에 대한 변경만 모니터링할 수 있습니다. 이 작업은 관련 기록 또는 카탈로그 변수의 필드에 대한 변경 내용을 감지할 수 없습니다. 예를 들어 작업이 인시던트 기록에 대한 변경 내용을 기다리는 경우 카탈로그 항목 또는 변경 작업 기록과 같은 관련 기록에 대한 변경 내용을 감지할 수 없습니다. 다른 기록으로 닷워킹하는 대기 조건을 작성하지 마십시오. 이 필드는 실제로 관련 기록에 속합니다. 카탈로그 변수에 의존하는 대기 조건을 작성하지 마십시오.

스테이지가 있는 플로우 또는 하위 플로우

스테이지가 있는 플로우 또는 하위 플로우를 만들 때 다음과 같은 일반 가이드라인을 따르십시오.

For Each 플로우 논리에 의존하는 스테이지 정의 방지: Flow Designer를 사용하면 For Each 블록 내에 스테이지를 추가할 수 없습니다. For Each 블록 앞이나 뒤에만 스테이지를 추가할 수 있습니다.
다른 플로우 또는 하위 플로우에서 동일한 기록에 대한 스테이지를 생성하지 마십시오.: 스테이지 필드에는 항상 테이블의 기록에서 실행할 마지막 플로우 또는 하위 플로우에서 제공하는 스테이지 정보가 표시됩니다. 여러 플로우 또는 하위 플로우가 동일한 기록에서 실행되는 경우 이론적으로 한 플로우 또는 하위 플로우에 정의된 스테이지가 다른 플로우 또는 하위 플로우의 스테이지를 덮어쓸 수 있습니다. 여러 플로우 또는 하위 플로우가 서로의 스테이지를 덮어쓰지 않도록 하려면 각 플로우 또는 하위 플로우에 대해 고유한 트리거 또는 시작 조건을 정의합니다.
플로우 또는 하위 플로우 외부에서 스테이지 필드를 업데이트하지 마십시오.: 플로우 또는 하위 플로우로 스테이지를 관리하는 경우 플로우 또는 하위 플로우 외부에서 기록 스테이지 필드를 직접 업데이트하지 마십시오. 스테이지 필드의 값을 수동으로 업데이트하면 예기치 않거나 원치 않는 결과가 발생할 수 있습니다.
테이블의 각 플로우에 고유한 트리거 조건이 있는지 확인합니다.: 각 플로우에 고유한 트리거 조건을 추가하면 플로우가 해당 조건에서만 실행되고 한 플로우가 다른 플로우의 스테이지를 덮어쓰는 것을 방지할 수 있습니다. 고유한 트리거 조건을 지정하면 기록 변경을 생성할 수 있는 플로우 실행 횟수를 제한하여 플로우 문제를 보다 쉽게 해결할 수 있습니다.
오류 스테이지를 사용하여 사용자와 커뮤니케이션: 플로우 오류 상태는 플로우 실행에 영향을 주지 않습니다. 플로우는 오류 스테이지에 도달해도 계속 실행됩니다. 조건부 플로우 로직 블록을 사용하여 오류 스테이지를 설정하고 현재 스테이지의 상태가 오류임을 사용자에게 알립니다. 예를 들어, 필요한 한도 내에서 승인이 승인되지 않은 경우 사용자에게 오류를 알릴 수 있습니다.
오류 스테이지를 사용하여 플로우 처리 중지: 조건부 플로우 로직 블록을 사용하여 플로우가 오류 단계에 진입하는 시점을 식별합니다. 플로우 로직을 사용하여 플로우 처리를 중지하거나 일종의 정정 작업을 수행합니다. 예를 들어, 플로우가 오류 상태에 도달하면 기록 상태 또는 할당을 변경할 수 있습니다.

병렬 플로우 논리에서 다음을 수행합니다

경로 간에 데이터 종속성을 생성하지 않도록 합니다.: 흐름은 어떤 순서로든 경로를 실행할 수 있으므로 개별 경로 간에 데이터 종속성을 생성하지 마십시오. 예를 들어 레코드를 만드는 경로와 동일한 레코드를 업데이트하는 다른 경로가 없어야 합니다. 기록 업데이트 경로는 기록 생성 경로보다 먼저 실행될 수 있습니다.
경로 간에 데이터를 공유하지 마십시오.: 워크플로우 스튜디오 시스템은 출력 값 제공을 위해 어떤 경로가 먼저 완료될지 결정할 수 없으므로 경로 간에 데이터 알약을 끌 수 없습니다.

동적 플로우 플로우 논리

유사한 기능을 가진 여러 하위 플로우가 있는 경우 동적 플로우를 사용합니다.: 동적 플로우를 사용하면 템플릿을 적용하여 유사한 하위 플로우의 입력을 처리함으로써 프로세스를 구분할 수 있습니다. 구획화를 통해 통합 허브 스포크에 대한 하위 플로우와 같은 유사한 기능을 수행하는 하위 플로우를 구별할 수 있습니다.
동적으로 호출된 하위 플로우 입력이 템플릿 플로우 입력과 일치하는지 확인: 동적 플로우 및 플로우 템플릿의 입력이 일치하지 않으면 시스템에서 오류가 발생하고 메인 플로우가 제대로 실행될 수 없습니다.
플로우 출력을 가져올 때 올바른 컨텍스트 사용: 컨텍스트 기록은 플로우 실행을 고유하게 식별합니다. 동적 플로우를 여러 번 실행하는 경우 선택할 수 있는 컨텍스트 기록이 여러 개 있습니다. 플로우 내에서 동적 플로우를 여러 번 사용하는 경우 플로우 출력을 가져올 때마다 올바른 실행에서 올바른 컨텍스트 기록을 선택해야 합니다.

Password2 데이터 알약

암호(2단계 암호화됨) 데이터가 포함된 플로우를 설계할 때 다음과 같은 일반 가이드라인을 따르십시오.

기존 암호(2단계 암호화됨) 데이터 알약을 사용하여 값을 할당합니다.

기존 password2 데이터 정제를 선택해야만 password2 변수에 값을 할당할 수 있습니다. 다른 필드 유형에서 값을 선택할 수 없습니다. 워크플로우 스튜디오 잘못된 데이터 알약 유형을 선택한 경우 경고 메시지를 표시합니다.

password2가 아닌 데이터 알약을 password2 필드로 끌어다 놓을 때 표시되는 경고 메시지입니다.

주:

암호(2단계 암호화) 값을 수동으로 입력할 수 없습니다.

유효한 필드 유형에 대해서만 암호(2단계 암호화) 변수를 사용하십시오.

워크플로우 스튜디오 잘못된 필드 유형의 값으로 Password2 데이터 정제를 선택할 수 없도록 합니다. 필드가 호환되지 않는 유형일 경우 시스템은 경고 메시지를 표시합니다.

password2 필드를 허용되지 않는 필드로 끌 때 표시되는 경고입니다.

워크플로우 스튜디오 Password2 데이터 알약은 다음 필드 유형으로만 끌어다 놓을 수 있습니다.

이메일 본문 필드
HTML 필드
암호 2 필드
PowerShell 입력 변수
REST 필드
- 변수
- REST 페이로드 본문
- 쿼리 매개변수
- 머리글
- REST 다중 파트 양식 값
- 양식 URL 인코딩 값
SOAP 필드
- 머리글
- 봉투

주:

암호(2단계 암호화됨) 변수를 조건으로 사용할 수 없습니다.

Flow Designer는 사용자가 작업과 플로우를 저장, 게시 또는 테스트할 때 유효성 검사를 수행합니다. 이 검사는 제한된 필드 유형에 드롭된 데이터 알약에 대한 경보가 표시되어 작업 또는 플로우가 실행되지 않도록 합니다. 작업 또는 플로우를 업데이트하여 잘못된 데이터 정제를 제거한 다음 작업을 다시 시도합니다.

암호 해독을 위한 암호화 모듈 설정

유효한 암호화 모듈 접근 권한이 있는 사용자만 password2 변수의 내용을 해독하고 볼 수 있습니다. 암호화 알고리즘 및 암호화된 데이터에 액세스할 수 있는 역할을 지정하려면 KMF를 사용한 Password2 암호화 를 참조하십시오.

SLA 백분율 타이머 작업

서비스 수준 계약(SLA) 백분율 타이머 작업이 포함된 플로우를 생성할 때 다음 일반 가이드라인을 따르십시오.

SLA 백분율 타이머 작업을 SLA 작업 트리거가 있는 플로우에만 추가: SLA 백분율 타이머 작업은 플로우가 SLA 작업 트리거에서 시작될 때만 실행할 수 있습니다. SLA 백분율 타이머 동작이 포함된 하위 플로우는 활성화할 수 없습니다.
예상 상태 값에 대한 조건부 플로우 논리 생성: 상태 필드의 값을 플로우 로직의 조건으로 사용합니다. 완료됨, 복구 및 건너뜀과 같은 예상 상태 값에 대한 플로우 논리를 빌드합니다. 예를 들어, SLA 백분율 타이머의 상태가 완료일 때 알림을 보내려면 If 플로우 로직 블록을 추가합니다.
각 SLA 백분율 타이머 작업에 고유한 누적 백분율 값 대기 할당: 각 SLA 백분율 타이머 작업은 백분율 대기 값을 사용하여 자체 예약된 종료 날짜/시간을 계산합니다. 여러 SLA 백분율 타이머 작업을 만드는 경우 각 작업에 고유한 누적 백분율 대기 값을 지정합니다. 예를 들어, 25%, 50%, 75% 완료와 같이 서로 다른 완료율 값을 사용하여 세 개의 개별 작업을 생성합니다. 세 가지 작업을 모두 동일한 완료율 값(예: 25%)으로 설정하면 타이머가 동시에 완료됩니다.
기존 플로우를 복사하여 사용자 지정: 기본 SLA 플로우를 복사하고 자체 논리로 복사본을 사용자 지정하여 개발 시간을 단축합니다. SLA 정의에서 실행할 사용자 지정 플로우를 선택합니다. SLA 정의 작성을 참조하십시오 .

동적 입력

외부 공급업체 통합을 위한 동적 입력 고려: 동적 입력을 사용하면 외부 소스에서 데이터를 동적으로 가져오는 플로우를 생성할 수 있습니다. 외부 공급업체 통합에서 동적 입력은 특정 엔드포인트와 관련된 데이터 값을 제공할 수 있습니다. 를 사용하여 워크플로우 스튜디오외부 공급업체 통합을 설정하는 방법에 대한 자세한 내용은 통합 허브를 참조하십시오.
많은 양의 데이터를 검색하는 데 필요한 시간에 유의하십시오: 기본적으로 동적 입력은 시간이 초과되기 전에 데이터를 수집하는 데 최대 300초가 있습니다. 데이터 수집 작업에서 데이터를 수집하는 데 더 많은 시간이 필요한 경우 시스템 속성을 더 높은 값으로 설정합니다 sn_flow_designer.sync_action_execution_timeout_in_seconds . 그러나 최종 사용자가 값을 입력하거나 선택해야 하는 대화형 흐름에는 긴 시간 제한 값을 사용하지 마세요.
스크립팅 오류 주의: 모든 데이터 수집 동작이 스크립트 단계를 사용하기 때문에 스크립팅에서 잠재적 오류가 발생할 수 있습니다. 스크립트를 사용하여 동적 입력에 대한 JSON 변수를 출력할 때 입력이 필요한 JSON 값을 수신하지 못하게 하는 오류가 발생할 수 있습니다. 동적 입력 스크립팅 오류가 발생하면 다음과 같은 경고 메시지가 나타날 수 있습니다.
그림 1. 스크립팅 오류에 대해 표시되는 메시지
동적 입력 유형 입력을 40개의 입력 값으로 제한: 동적 입력 유형 입력은 JSON 개체가 메모리에 저장할 수 없을 정도로 커지기 전에 특정 수의 입력만 렌더링할 수 있습니다. 동적 입력을 40개의 입력 값으로 제한하면 메모리가 부족해지고 렌더링 오류 또는 데이터 잘림과 같은 예기치 않은 동작이 발생할 가능성이 최소화됩니다.
동적 템플릿 및 동적 선택 항목을 위한 JSON 출력을 5,000개의 배열 항목으로 제한: 동적 선택 및 동적 템플릿 입력은 최대 5,000개의 배열 항목만 표시할 수 있습니다. 동적 선택은 최대 5,000개의 선택 목록 옵션만 표시할 수 있으며 동적 템플릿은 최대 5,000개의 필드 템플릿 값만 표시할 수 있습니다. 데이터 수집 작업이 동적 템플릿 또는 동적 선택에 대한 데이터를 수집하는 경우 반환되는 최대 배열 항목 수를 5000개로 제한합니다. 5,000개 배열 항목 제한을 사용하면 선택 항목 또는 필드 값을 렌더링할 때 인스턴스에 성능 문제가 발생하지 않습니다.

동적 출력

외부 공급업체 통합에 동적 출력 사용: 동적 출력을 사용하여 플로우 설계 중에 외부 시스템에서 데이터를 검사 하고 가져옵니다. 예를 들어 서비스 끝점을 지정하거나 특정 끝점 API와 상호 작용하는 작업을 호출할 수 있습니다. 를 사용하여 워크플로우 스튜디오외부 공급업체 통합을 설정하는 방법에 대한 자세한 내용은 통합 허브를 참조하십시오.
많은 양의 데이터를 검색하는 데 필요한 시간을 확인합니다.: 기본적으로 동적 출력은 시스템이 중지하기 전에 데이터를 수집하는 데 최대 300초가 있습니다. 데이터 수집 작업에서 데이터를 수집하는 데 더 많은 시간이 필요한 경우 시스템 속성을 더 큰 값으로 설정합니다 sn_flow_designer.sync_action_execution_timeout_in_seconds . 최종 사용자가 값을 입력하거나 선택해야 하는 대화형 플로우의 경우 시간 제한 값을 길게 하지 마십시오.
스크립팅 오류 주의: 모든 데이터 수집 동작이 스크립트 단계를 사용하기 때문에 스크립팅에서 잠재적 오류가 발생할 수 있습니다. 스크립트 오류로 인해 출력에서 필요한 JSON 값을 받지 못할 수 있으므로 JSON 변수를 출력하는 데 사용되는 스크립트를 검토합니다. 동적 출력 스크립팅 오류가 발생하면 다음과 같은 경고 메시지가 나타날 수 있습니다.
그림 2. 스크립팅 오류에 대해 표시되는 메시지

목록. [테이블] 데이터

참조 한정자를 추가하여 목록 기록 필터링: 참조 한정자를 추가하여 목록 변수가 유효한 옵션으로 표시하는 기록을 필터링합니다. 참조 한정자는 필수 목록 필터로 작동하며 목록 변수가 참조 한정자 조건과 일치하는 레코드만 표시하도록 합니다. 예를 들어 활성 인시던트 기록만 표시하려면 참조 한정자 조건 [Active][is][true]를 추가합니다.
ServiceNow Store용 작업에 대한 기본 기록 선택 방지: 모든 인스턴스가 선택한 기록에 액세스할 수 있다는 것을 알고 있지 않는 한 목록에 대한 기본 기록을 선택하지 마십시오. 일반적으로 스포크 개발자는 사용자 지정 작업을 설치하는 고객의 데이터에 액세스할 수 없습니다. ServiceNow Store에 사용자 지정 작업을 게시하려면 기본 기록을 데모 데이터로 제공해야 할 수 있습니다.
For Each 플로우 논리에서 목록 변수 사용: 목록 변수를 사용하여 For Each 플로우 논리 내에서 처리할 기록을 지정할 수 있습니다. For Each 플로우 논리는 데이터에 있는 기록 이 아닌 sys_id 무시합니다. 예를 들어 목록 변수에 이메일 주소가 포함되어 있으면 플로우 로직은 이를 무시합니다.

승인 규칙

기본값 제공: 승인 규칙을 기본값으로 만들거나 선택합니다.

변환 함수

입력에 유효한 데이터 알약 유형에 변환 함수 적용: 변환 함수를 적용하기 전에 입력에 대한 데이터 정제 유형을 확인하십시오. 잘못된 데이터 알약 유형에 변환 함수를 적용하면 시스템에서 변환을 건너뛰게 됩니다. 변환 함수가 시스템에서 구문 분석할 수 없는 결과를 생성하는 경우에도 오류가 발생합니다. 예를 들어, 문자열을 날짜로 변환할 때 변환 시 유효한 날짜가 생성되지 않으면 시스템에서 오류가 발생합니다.
동일한 데이터 알약을 사용하여 여러 입력에 대해 적용된 변환 함수 확인: 변환 함수는 런타임에 특정 입력에 대해 새 값을 작성하고 원래 데이터 정제를 변경하지 않습니다. 따라서 여러 작업 또는 단계에서 동일한 데이터 정제를 사용하는 경우 변환 함수를 각 개별 인푸t에 적용해야 합니다.
플로우 실행 상세 정보에서 최종 변환 값 보기: 적용된 각 변환의 값이 아닌 최종 변환 값만 플로우 실행 세부 정보에 나타납니다.
변환 함수를 테스트하여 예상 결과를 생성하는지 확인: 변환 함수가 데이터 알약에 대한 예상 런타임 값을 생성하는지 확인합니다. 자세한 내용은 흐름 테스트 및 작업 테스트를 참조하십시오.

인라인 스크립트

다음과 같은 일반 지침에 따라 재사용 및 유지 관리 가능한 인라인 스크립트를 만듭니다.

재사용할 수 없는 작은 논리에 대한 인라인 스크립트 작성Write inline script for small non-reusable logic

인라인 스크립트 형식을 사용하거나 특정 입력 및 사용 사례에 맞게 데이터를 수정합니다. 재사용 가능한 논리의 경우 작업 또는 하위 플로우를 대신 생성합니다.

사용 가능한 변환 함수 검토

워크플로우 스튜디오 데이터 변환 및 서식 지정 작업을 위한 표준 변환 함수 목록을 제공합니다. 사용자 지정 스크립트 솔루션을 작성하고 유지관리하는 대신, 기존 변환 함수가 있는 경우 이를 선택합니다.

인라인 스크립트에서 스크립트 포함 호출

인라인 스크립트에서 스크립트 포함을 호출하여 작성하는 코드의 양을 줄이고 공통 코드를 단일 위치에서 유지 관리합니다. 클래스 생성자를 사용하여 스크립트 포함을 호출합니다. 스크립트 포함을 만드는 방법에 대한 자세한 내용은 을 참조하십시오 Script includes.

var si = new MyScriptInclude();
si.functionOne();

인라인 스크립트가 아닌 재사용 가능한 코드에 대한 사용자 지정 작업 또는 하위 플로우 생성

재사용 가능하거나 복잡한 데이터 논리에 대한 사용자 지정 작업 또는 하위 플로우를 생성합니다(예: 소스 데이터의 데이터 유형 변경). 코드에 익숙하지 않은 플로우 디자이너를 위해 사용자 지정 동작 또는 하위 플로우를 제공할 수도 있습니다.

동작 및 플로우 기능의 중복 방지

작업 및 플로우 기능을 중복하는 인라인 스크립트를 작성하지 마십시오. 예를 들어, 인라인 스크립트를 작성하여 기록 작업을 수행하는 대신, 기록 베이스라인 작업 만들기 및 업데이트를 사용합니다.

데이터 형식 변경 방지

인라인 스크립트가 입력 또는 출력이 예상하는 것과 동일한 데이터 유형으로 정보를 제공하는지 확인하여 런타임 오류를 방지합니다.

var 키워드로 변수를 선언하여 변수 만들기

var 키워드를 사용하여 변수를 선언하여 적절한 JavaScript 범위 내에 유지되도록 합니다. 변수에 값을 할당하여 변수를 만들면 JavaScript가 전역 객체에 연결할 수 있으며, 이로 인해 변수 값이 로컬 범위 밖에서 유지되어 오류가 발생할 수 있습니다.

프로세스 기록: For Each 플로우 로직 및 플로우 데이터 객체로 출력 기록

인라인 스크립트는 For Each 플로우 논리에서 기록 조회 작업의 기록 출력에만 액세스할 수 있습니다. 플로우에 기록 조회 작업을 추가하여 기록 출력을 생성합니다. 플로우에 For Each 플로우 논리를 추가하여 기록 출력의 각 기록을 처리합니다. fd_data 및 항목 객체를 사용하여 For Each 플로우 논리에 대한 인라인 스크립트 참조를 만듭니다. 예를 들어 이 참조에서는 For Each 플로우 로직이 플로우 개요 fd_data._2__for_each.item의 두 번째 항목이라고 가정합니다.

자동 완성 제안을 사용하여 플로우 및 작업 데이터에 대한 참조를 생성합니다.

fd_data 객체를 사용하여 플로우 및 작업 데이터에 대한 참조를 생성합니다. fd_data 입력할 때 스크립트 편집기에 기존 플로우 및 작업 데이터에 대한 자동 완성 제안이 표시됩니다. 플로우 및 작업 데이터에 대한 참조를 빌드할 제안을 선택합니다.

주:

항목 객체를 사용하는 For Each 플로우 논리의 기록 데이터를 참조하십시오.

범위 루프 카운터

스크립트 루프에는 최대 반복 횟수가 없으므로 유효한 종료 조건이 없을 때 루프가 무한히 실행됩니다.

유효한 종료 조건이 있는지 확인하려면 인라인 스크립트나 동작 내의 스크립트 단계에서 범위 루프 카운터를 사용하십시오.for (i=0; i< length; i++) 에 var을 추가하고 for (var i=0; i< length; i++)를 얻습니다.

복잡한 데이터

이러한 일반 지침에 따라 재사용 및 유지 관리 가능한 데이터 구조를 만듭니다.

계층 구조의 하위 수준 수 최소화: 데이터 구조의 하위 수준이 많을수록 계층 구조에서 데이터 변수를 보고 선택하기가 더 어려워집니다. 자식 수준 개수에 관계없이 데이터 구조를 작성할 수 있지만 자식 수준이 7개를 초과하는 데이터 구조를 탐색하고 이해하기는 어려워집니다. 최상의 사용자 환경을 위해 자식 수준이 너무 많아 가로로 스크롤하여 보고 채워야 하는 데이터 구조를 만들지 마십시오.
각 기록 데이터 유형에 대해 별도의 객체 만들기: 대부분의 워크플로우 스튜디오 데이터는 인스턴스에서 가져온 데이터인지 외부 시스템에서 가져온 데이터인지 여부에 관계없이 기록 데이터입니다. 이 디자인 방법을 사용하면 개체에 포함된 내용과 데이터의 출처를 알 수 있습니다.
기록 데이터 구조 다시 만들기: 레코드 데이터를 수신하거나 전송하는 개체를 빌드할 때 이러한 레코드에 대한 데이터베이스 사전 항목을 검토하고 일치하는 개체 데이터 구조를 만듭니다. 예를 들어, 인시던트 및 구성 항목 테이블의 데이터를 포함하려는 개체를 가정해 보겠습니다. 인시던트 테이블의 간단한 설명 필드에 대한 문자열 요소와 구성 항목 테이블의 클래스 필드에 대한 문자열 배열 요소를 만들 수 있습니다.
객체를 생성하여 다양한 유형의 기록을 결합합니다.: 여러 유형의 레코드에서 정보가 필요한 경우 필요한 모든 정보가 포함된 개체를 만듭니다. 그런 다음 개체를 사용하여 의 데이터 워크플로우 스튜디오형식을 지정하거나 구문 분석할 수 있습니다.

복잡한 데이터를 사용한 스크립팅

복잡한 데이터로 스크립팅할 때는 다음과 같은 일반적인 지침을 염두에 두어야 합니다.

문자열 입력을 사용하여 복잡한 데이터를 JSON 문자열로 변환: 복잡한 데이터를 문자열 입력에 매핑하면 에서 워크플로우 스튜디오 JSON 문자열로 자동 변환합니다. 스크립트를 작성하는 대신 REST 단계에 문자열 입력을 추가하고 이전 작업 또는 단계의 복잡한 데이터에 매핑할 수 있습니다.
객체를 템플릿으로 저장: 객체를 템플릿으로 저장하여 다른 작업, 플로우 및 스크립트 단계에서 다시 사용할 수 있습니다.
이전 데이터에 액세스하기 위한 스크립트 입력 변수 생성: 작업 입력 또는 이전 단계에서 액세스하려는 데이터에 대한 스크립트 입력 변수를 생성합니다. 스크립트 입력 변수를 입력 또는 단계 데이터 정제에 매핑합니다. 예를 들어, 스크립트 입력 변수를 이전 단계에서 조회한 사용자 기록 목록에 매핑합니다.
복잡한 데이터를 저장할 스크립트 출력 변수를 만듭니다: 스크립트에서 만드는 복잡한 데이터를 저장하는 스크립트 출력 변수를 만듭니다. 스크립트 출력 변수는 스크립트에 정의된 값과 일치해야 합니다. 예를 들어, 여러 contact 객체를 저장할 객체로 구성된 contacts 배열을 만들어 보겠습니다. 연락처 개체를 다시 사용할 수 있도록 템플릿으로 저장합니다.
작업 출력을 스크립트 출력 변수에 매핑합니다.: 사용자 지정 작업으로 복잡한 데이터를 출력하려면 작업 출력을 추가하고 이를 스크립트 단계 출력 변수의 데이터 알약에 매핑합니다. 예를 들어, contacts 배열을 만들고 이전에 저장한 contact 개체 템플릿을 불러옵니다. 작업 출력을 스크립트 단계에서 생성된 contacts 배열에 매핑합니다.

Flow Designer 및 도메인 분리

과 함께 워크플로우 스튜디오도메인 분리를 사용할 때 다음과 같은 일반 지침을 따르십시오.

도메인에 대해 테넌트 플로우, 작업 및 하위 플로우가 제대로 실행되는지 확인: 테넌트는 콘텐츠를 재정의 워크플로우 스튜디오 할 수 없으므로 TOP 도메인의 SP(서비스 공급자) 관리자가 콘텐츠를 작성하고 관리하여 도메인에 대해 제대로 실행되도록 해야 합니다. 도메인별 플로우를 생성할 수 있지만 계층 구조의 상위 도메인에서 작업하는 사용자는 여러 하위 도메인 플로우를 트리거할 수 있습니다. 예를 들어 TOP 도메인에서 작업하는 사용자는 ACME 및 INITECH와 같은 하위 도메인에서 플로우를 트리거할 수 있습니다.
주:
플로우 작성자는 현재 도메인과 계층 구조의 모든 상위 도메인에서 사용할 수 있는 콘텐츠만 워크플로우 스튜디오 볼 수 있습니다. 워크플로우 스튜디오 에서 볼 수 있는 콘텐츠를 표시하지 않습니다. 도메인을 포함합니다.
각 플로우, 작업 및 하위 플로우에 고유한 이름을 제공합니다.: 모든 도메인이 컨텐츠를 공유 워크플로우 스튜디오 하므로 TOP 도메인의 SP 관리자가 각 플로우, 작업 및 하위 플로우의 이름을 고유하게 지정하도록 합니다. 이렇게 하면 한 도메인으로 향하는 플로우가 다른 도메인의 플로우 이름을 중복하지 않습니다. 예를 들어 인시던트 확인 - TOP, 인시던트 확인 - ACME 및 인시던트 확인 - INITECH와 같은 플로우 이름에 도메인을 추가합니다.
플로우 및 작업에 현재 또는 상위 도메인의 아티팩트만 포함되어 있는지 확인: 워크플로우 스튜디오 현재 또는 상위 도메인에서 사용할 수 없는 아티팩트가 포함된 플로우가 활성화되지 않도록 차단합니다. 예를 들어 ACME 도메인에 속하는 도메인별 플로우를 생성하는 경우 형제 도메인 INITECH에 속하는 작업이나 하위 플로우는 포함할 수 없습니다.
컨텐츠가 속한 도메인에서 컨텐츠 편집 워크플로우 스튜디오: 상위 도메인의 사용자는 하위 도메인의 플로우, 작업 및 하위 플로우를 볼 수 있지만 자신이 속한 도메인에서 편집해야 합니다. 예를 들어 TOP 도메인의 관리자는 ACME 도메인의 플로우를 볼 수 있지만 편집하려면 ACME 도메인으로 전환해야 합니다.

배치

최신 릴리스 플로우를 이전 릴리스의 인스턴스에 배포하지 않도록 합니다.: 워크플로우 스튜디오 는 이전 릴리스에서 실행되는 인스턴스에 플로우를 배포하는 것을 지원하지 않습니다. 경우에 따라 플로우의 데이터 모델이 릴리스 간에 변경되어 플로우가 실행되지 않거나 예기치 않은 결과가 발생할 수 있습니다.

플로우 오류 처리

다음과 같은 일반 가이드라인에 따라 플로우 오류 처리가 제공하는 이점을 얻을 수 있습니다.

플로우의 메인 섹션에 오류 처리 항목을 추가하지 않도록 합니다.: 플로우는 일반적으로 작업 또는 하위 플로우가 메인 섹션에서 오류를 반환할 때 실행을 중지합니다. 중지된 플로우는 오류를 반환한 지점을 지나서는 작업이나 하위 플로우를 실행할 수 없습니다. 오류 핸들러 섹션에 오류 처리 작업과 하위 플로우를 추가하면 오류 발생 시 실행할 수 있습니다.
오류 상태 정보 캡처: 오류 상태 개체에는 오류를 생성한 작업에 대한 정보가 포함되어 있습니다. 이 정보를 사용하여 오류의 원인을 식별하고 수정이 필요할 수 있는 데이터를 기록할 수 있습니다.
하위 플로우 오류 메시지 억제: 하위 플로우에 오류 핸들러를 활성화하여 오류가 상위 플로우에 연속적으로 전달되지 않도록 할 수 있습니다. 하위 플로우 오류 핸들러 섹션을 비워 두면 항상 완료됨(오류 포착) 상태가 생성됩니다.
하위 플로우를 사용하여 10개 항목 제한을 피하십시오.: 오류 처리 프로세스를 10개 항목 제한 내에 맞추도록 강제하는 대신, 더 많은 항목을 포함할 수 있는 하위 플로우를 호출하십시오. 하위 플로우 출력을 사용하여 다른 플로우에서 자동화를 트리거할 수도 있습니다.
하위 플로우를 사용하여 시정 조치 수행: 여러 플로우에서 동일한 작업 시퀀스를 다시 만드는 대신 재사용 가능한 하위 플로우를 만들어 기록 데이터의 오류를 수정합니다. 플로우 오류로 인해 기록 데이터가 원치 않는 상태가 되면 하위 플로우를 사용하여 이러한 기록을 수정합니다. 오류 핸들러를 사용하여 하위 플로우 출력과 같은 기록 데이터를 식별할 수 있습니다.

작업 오류 평가

다음과 같은 일반 지침을 따라 작업 오류 평가가 제공하는 이점을 얻을 수 있습니다.

독립적인 단계만 계속 실행되도록 허용: 이후 단계에서 필요한 데이터를 반환하지 않는 경우 단계를 계속 실행할 수 있습니다. 단계가 이후 단계에 필요한 데이터를 제공하는 경우 이후 단계를 성공적으로 실행할 수 없다는 것을 알고 있습니다.
10개 이상의 오류 조건 방지: 만들 수 있는 오류 조건의 수에는 제한이 없지만 각 오류 조건에 대한 평가가 필요합니다. 평가해야 하는 작업 오류 조건이 많을수록 작업 실행 속도가 느려질 수 있습니다.
특정 단계 실패 식별: 단계 상태를 사용하여 특정 단계가 실패하는 시기를 식별할 수 있습니다. 특정 단계 식별은 작업에 동일한 유형의 단계 인스턴스가 여러 개 포함되어 있는 경우에 유용할 수 있습니다. 플로우 오류 처리기가 오류에 대해 적절한 정정 작업을 수행할 수 있도록 특정 단계를 식별할 수도 있습니다.
일반 오류 조건 앞에 특정 오류 조건을 넣으십시오.: 작업이 일치하는 오류 조건을 찾으면 오류 평가가 중지됩니다. 일반 오류 조건을 먼저 배치하면 작업이 특정 오류 조건과 일치하지 않을 수 있습니다.
설명이 포함된 오류 조건 레이블 사용: 편집할 필요 없이 오류 조건을 식별합니다. 기본적으로 오류 조건은 편집할 때만 볼 수 있습니다.

플로우 관리자

프로덕션에서 플로우 보고 끄기: 플로우 보고를 사용하지 않도록 설정하여 플로우를 실행하는 데 필요한 메모리 양을 최소화합니다. 플로우 보고는 실행 상세 정보 페이지에 대한 구성 및 런타임 정보를 저장합니다. 이러한 보고서는 문제 해결에 유용하지만 메모리와 데이터베이스 모두에 많은 양의 데이터를 보존해야 합니다. 기본적으로 플로우 보고는 비활성화되어 있으며, 플로우 또는 작업을 수동으로 테스트할 때만 실행 세부 정보가 시스템에서 생성됩니다. 대신 보고가 꺼져 있어도 사용할 수 있는 로그 파일을 사용할 수 있습니다.
중첩 루핑이 있는 플로우에서 사용되는 메모리 양 감소: 보고가 활성화되면 com.snc.process_flow.reporting.iteration.lastn 값을 "1"로 설정하여 이전 루프 반복에서 사용하는 메모리 양을 줄입니다. 보고하는 반복이 많을수록 더 많은 메모리가 필요합니다.
플로우 실행 상세 정보에서 최종 변환 값 보기: 플로우 실행 상세 정보에는 최종 변환된 값만 나타나고 적용된 각 변환의 값은 표시되지 않습니다.

플로우 우선순위

플로우 우선순위를 설정할 때 다음 설계 고려 사항을 따르십시오.

모든 플로우가 높은 우선순위로 실행되도록 설정하지 마십시오.: 모든 플로우를 높은 우선순위로 설정하기보다는 여러 우선순위를 혼합하여 사용합니다. 작업자 스레드는 흐름 간의 상대적 우선 순위를 사용하여 작업을 선택합니다. 모든 플로우가 높은 우선순위로 실행되면 대기할 우선순위가 낮은 플로우가 없습니다.
일시 중지해야 하는 플로우에 대해 플로우 우선순위를 설정하지 않도록 합니다.: 일시 중지된 플로우는 실행을 다시 시작할 때 우선순위 값을 잃게 되므로 일시 중지해야 하는 플로우는 기본 중간 우선순위에서 계속 유지됩니다.
비즈니스 크리티컬 플로우에 높은 우선순위 사용: 비즈니스 가치가 높고, 거의 실행되지 않으며, 런타임이 짧은 플로우로 높은 우선순위를 제한합니다. 대용량 플로우를 높은 우선 순위로 설정하면 다른 플로우를 실행하는 데 사용할 수 있는 작업자 스레드 수가 제한되므로 설정하지 마십시오. 우선 순위가 높은 흐름을 오래 실행하면 다른 흐름을 실행하는 데 사용할 수 있는 작업자 스레드도 줄어들 수 있습니다.
대량 플로우에 낮은 우선순위 사용: 시간에 민감한 다른 플로우를 먼저 실행할 수 있도록 낮은 우선순위로 대용량 플로우를 실행합니다. 우선 순위가 낮은 흐름은 시간에 민감하지 않아야 합니다.
시간에 민감한 플로우에 중간 우선순위 사용: 플로우가 다른 플로우와 비교할 때 어느 정도 시간 긴급도가 있는 경우 기본 플로우 우선순위를 사용합니다.