1) 실행 결과의 상태에 따라 다른 실행 경로를 트리거합니다.
워크 플로를 사용하면 두 작업 간의 실행 관계를 기반으로 두 작업을 추가하고 연결할 수 있습니다. 즉, 이전 태스크의 실행 상태(성공, 에러, 모조건)에 따라 다른 경로의 태스크를 실행할 수 있습니다. 간단한 예를 들어 보겠습니다. [
- on success (녹색 선)
- on failure (빨간 선)
- on completion (파란 선)
2) 선행 작업의 실행 상태에 따라 실행 조건 (제어) 추가
워크 플로를 사용하면 이전 작업의 실행 상태에 따라 모든 작업에 조건부 논리를 추가할 수 있습니다. [
3) 작업을 실행할 때 사용할 동적 변수 전달
데이터플로 패키지와 마찬가지로 워크플로에도 변수 범위가 있습니다. 변수가 데이터플로 패키지 레벨에서 정의된 경우 해당 값이 사용되고 데이터플로 패키지에서 변수 정의를 찾을 수 없는 경우 Xplenty는 워크플로우 레벨 변수를 참조합니다. 이러한 워크 플로 변수는 워크 플로를 만들 때 설정하고 잡이나 스케줄을 통해 실행할 경우는 해당 설정 화면에서 변수를 덮어쓸 수 있습니다. 그러나 워크 플로 변수와 데이터 플로 변수가 모두 같은 이름인 경우 워크 플로의 변수 화면에서 워크 플로 변수에 데이터 플로 변수를 지정해야 합니다. (자세한 내용은 아래에 나오는 [참고: 데이터플로 변수와 데이터플로 변수 간의 관계 이해]를 읽어 보시기 바랍니다) 워크 플로의 SQL 작업은 값(쿼리 결과)을 반환할 수 있고 스칼라 값을 포함해서 워크 플로 변수에 저장할 수 있습니다. 이 값은 후속 SQL 태스크 또는 데이터플로 패키지 태스크로 전달될 수 있습니다. [
- 데이터베이스에서 SQL 쿼리를 실행하여 현재 시작된 캠페인이 있는지 확인합니다. 캠페인 식별자를 워크 플로 변수에 저장합니다.
- 시작된 캠페인이 있는 경우 인게이지 먼트 수치를 수집하기 위한 테이블 만들기, 방문 페이지 CRM의 배너 콘텐츠 업데이트, 기타 부속 서비스(PDP, 고객 등)에 대한 데이터베이스의 업데이트, 일괄 메일 알림 준비 및 제출, 대상 고객에 대한 캐시 워밍 활동과 같은 ETL 작업을 실시합니다. 처음 저장한 캠페인 식별자 변수는 이들 후속 작업으로 전달됩니다.
- 이런 전후 작업은 올바른 순서로 실행되도록 배치됩니다(Bootstrap 데이터 테이블 → 방문 페이지 배너 업데이트 → 캐시 워밍 → 대량 메일 알림 생성). 이러한 태스크들 중 하나가 실패하면 데이터베이스(SQL 쿼리)에 실패 상태를 저장하거나, 태스크를 스케줄링하거나, 진단을 수행하는 API를 호출하는 등의 조치를 실시하는 복구 태스크가 있을 수 있습니다. 그게 아니면 상황을 관련 팀들에 경고 할 수 있습니다. 모든 태스크가 성공적으로 실행되는 경우에도 유사한 조치를 정의할 수 있습니다.
- 워크 플로 내에서 최근에 만료된 캠페인이 있는지 확인하고, 이후에 분석을 위한 지표 집계나 정리를 수행하는 작업을 예약하는 SQL 쿼리 작업을 추가할 수 있습니다. 일단 구축된 워크 플로는 정기적으로(예를 들어, 매일 밤 11:30에) 실행되도록 스케줄링 될 수 있으며, 서로 의존하는 다른 태스크가 수동 실행의 개입 없이 협력하여 실행된다.
- 워크 플로 내에서 사용하는 태스크는 데이터 플로 패키지로서 그 자체로 완료되는 1개의 처리로 정의할 수가 있습니다. 이를 통해 모듈화하고 유지 관리하기 쉬운 작업단위를 수행할 수 있으며, 각 팀과 구성원에게 효율적으로 작업을 할당할 수 있습니다.
- 워크 플로는 구현의 복잡성을 추상화하면서 이런 작업들이 올바른 순서로 실행되도록 배치합니다. 이를 통해 다양한 시스템이 어떻게 상호작용하는지 가시적으로 볼 수 있습니다.
- 버전 관리가 있어서 문제가 발생하면 이전 버전으로 되돌아 갈 수 있습니다.
- Xplenty 대시보드를 사용하면 워크 플로의 실행 상태를 모니터링과 실패 알림의 파악 및 실행 스케줄을 변경할 수 있습니다.
- 이러한 메커니즘을 자체적으로 유지하는 것은 시간과 자원을 많이 소모합니다. 시스템에는 데이터베이스 연결 관리, cron 식 및 다중 프로세스 유지, 전후 관계 설정, 경고 시스템 추가 등이 포함됩니다. Xplenty는 기존 워크 플로에 적절히 녹아들어가는 사용하기 쉬운 로우코드 인터페이스를 통해 이 모든 것을 제공합니다.
예 1: 워크 플로 레벨 변수(워크플로쪽에 설정한 변수)와 데이터 플로 레벨 변수가 같은 변수 이름인 경우
보통 이 경우는 같은 변수라도 워크 플로의 태스크로 사용될 경우와 데이터 플로 단독으로 사용되는 경우의 설정값이 서로 틀릴 경우입니다. 즉, 워크 플로의 태스크로 실행되는 경우에는 상위 레벨인 워크 플로의 값으로 데이터 플로를 실행하지만, 에러 복구의 이유로 데이터 플로를 단독으로 돌려야 할 경우 변수 값은 다르게 설정되는 경우가 그 좋은 예입니다. 테스크에서 워크 플로 변수값을 데이터 플로에 적용할 경우, 워크 플로의 태스크 설정의 변수 설정(태스크로 지정된 데이터 플로의 변수 설정)에서 워크플로 변수를 데이터 플로의 변수로 대입해야 합니다. (워크플로 변수와 데이터플로 변수가 같은 변수 이름인 경우, 워크 플로 변수를 데이터 플로 변수에 할당 할 필요가 있습니다.) 태스크에 지정된 데이터 플로에 데이터 플로 레벨에 변수가 정의되지 않았지만 워크 플로우 레벨에서 정의 된 변수가 데이터 플로 패키지에서 사용된다면, 데이터 플로 태스크는 워크 플로 변수의 값을 사용합니다. [
예 2: 워크 플로 레벨에서만 변수가 정의된 경우
워크 플로의 데이터 플로(태스크)가 해당 데이터 플로에 정의되지 않은 변수를 사용하더라도 워크 플로 레벨에서 값이 설정된 경우 데이터 플로(태스크)는 워크 플로 변수의 값을 사용하여 실행됩니다. 다음과 같은 경우 데이터 플로 레벨 실행은 실패하지만 워크 플로를 실행하면 제대로 작동합니다.-
Dataflow 변수
$today정의 없음 # 하지만, 소스 컴포넌트의 Filter조건에 [CreatedAt > $today]가 존재 -
Workflow 변수
$today정의 있음
- SQL에서 변수를 지정하는 방법 : ${변수이름}
- 일반 패키지의 URL 및 파일 경로 등 : $변수이름