Flow Designer 및 IntegrationHub

새로운 프로세스 흐름 요구 사항의 경우 ServiceNow는 거의 모든 상황에서 레거시 워크플로우보다 Flow Designer를 사용할 것을 권장합니다.

Flow Designer 및 비즈니스 규칙

다음의 경우를 제외하고는 비즈니스 규칙 대신 Flow Designer를 사용해야 합니다.

• 비즈니스 논리는 다른 비즈니스 규칙과 함께 특정한 순서로 실행되어야 합니다. 예를 들어, 새 비즈니스 논리는 하나의 비즈니스 규칙 이후, 다른 비즈니스 규칙보다 먼저 실행되어야 합니다.
• 논리는 동일한 스레드의 데이터베이스에 쓰기 직전 또는 직후에 실행되어야 합니다.
• 논리는 스크립트 포함만 호출합니다.

플로우를 디자인할 때는 다음 디자인 원칙을 따르십시오.

• 단일 목적: 각 플로우에는 단일 목표가 있어야 합니다.
• 재사용성: 재사용 가능한 하위 플로우를 염두에 두고 설계합니다(승인이 좋은 예입니다).
• 명확성: 플로우의 언어와 레이아웃은 각 작업의 목적을 명확하게 해야 합니다.

비즈니스 흐름에 대한 화이트 보드 설계로 시작합니다. 그런 다음 프로세스에 맞게 작업별로 플로우 작업을 빌드합니다. 단일 프로세스가 설계 원칙을 준수하기 위해 두 개 이상의 플로우가 필요할 수 있습니다.

Flow Designer로 작업할 때 다음 방법을 사용합니다.

• SysID가 아닌 기록을 사용합니다. 인라인 설명서를 사용하여 안내 환경을 제공합니다.
• 템플릿 객체를 사용하여 정적 입력과 동적 입력을 모두 사용하는 방법을 알아봅니다.
• 반드시 필요한 경우가 아니면 데이터 Blob을 전달하지 마세요.
• 플로우에서 사용할 정보만 전달합니다.

Flow Designer 작업을 수행할 때는 다음 방법을 사용합니다.

• 해당하는 경우 항상 애플리케이션의 스포크 범위에서 작업을 생성합니다.
• 접근 권한을 작업의 모든 범위에서 접근 가능으로 설정하면 나중에 다른 앱과 범위에서 작업을 재사용할 수 있습니다.
• 보호를 읽기 전용으로 설정하여 사용자가 작업을 원치 않게 편집하지 못하도록 합니다.
• 입력에 특정 유형이 있는지 확인합니다.
• 필요한 경우 필수 가 선택되어 있는지 확인합니다.
• 선택 입력 유형을 사용하는 경우 기본값을 사용합니다.

통합 허브로 작업할 때 다음 프랙티스를 사용합니다.

• 통합 시스템당 하나의 스포크를 생성합니다. 스포크에는 단일 시스템에 대한 작업만 배치합니다.
• 스포크에 대한 범위가 지정된 앱을 만들 때 적합한 버전 명명 규칙을 사용합니다.
• 인라인 연결 대신 연결 별칭을 사용합니다. 기본 URL이 자동으로 추출됩니다.
• 별칭 아래의 연결 속성을 사용하여 REST 단계에서 버전을 전달하면 자원 경로에서 향후 버전 관리에 유연성을 제공할 수 있습니다.
• 데이터를 저장하는 다른 단계를 생성하는 대신 첨부 파일로 저장을 사용하여 응답에 콘텐츠를 저장합니다.
• 별칭이 동적이면 별칭을 입력 중 하나로 만들고 데이터 정제를 사용하여 별칭을 제공합니다.

오류 처리를 위해 플로우 디자이너 및 통합 허브에서 다음 방법을 사용합니다.

• 스크립트 포함을 작성하여 오류 처리
• 짧고 이해하기 쉬운 오류 메시지를 작성하십시오.
• API가 반환할 수 있는 모든 오류 메시지를 통합합니다.
• 통합 단계의 출력을 사용하기 전에 해당 출력의 유효성을 검사해야 합니다.
• 조기 실패: 입력을 사용할 수 없는 경우 통합을 호출하지 않습니다.

자율 학습식 교육: Flow Designer

자율 학습식 교육: IntegrationHub