여러분이 워크 플로 엔진을 사용하여 해결 한 특정 문제 (SO 독자)와 직접 롤링하지 않은 경우 사용한 라이브러리 / 프레임 워크에 대해 알고 싶습니다. 또한 Workflow Engine이 최선의 선택이 아닌 경우와 상태 머신을 사용하는 TaskList / WorkList / Task-Management 유형 응용 프로그램과 같이 더 간단한 것을 선택했는지 여부와 방법을 알고 싶습니다.
질문 :
직접 경험을 찾고 있습니다.
내가 확인한 리소스 중 일부 :
답변:
나는 StonePath 의 주요 저자이기 때문에 편견이 있습니다.
저는 미국 국무부, 제네바 인도 주의적 퇴치 센터, 포춘 500 대 고객, 그리고 가장 최근에는 워싱턴 DC 공립학교 시스템을위한 워크 플로우 애플리케이션을 개발했습니다. 비즈니스 프로세스에 대한 하나의 마스터 참조가 되려고하는 '워크 플로 엔진'을 볼 때마다 도구를 해결하기 위해 스스로 싸우는 조직을 보았습니다. 이는 이러한 솔루션이 항상 공급 업체 / 제품 중심의 솔루션이었고, 결국 '컨설턴트'로 구성된 전술 팀이 지속적으로 앱을 제공한다는 사실 때문일 수 있지만, 이로 인해 나는 '워크 플로 정의를 한 곳에서 중앙 집중화하고 반복 가능하게 만드는'프로세스 기반 도구의 이점.
즉, 나는 Ruote를 매우 좋아합니다. 저는 그 프로젝트를 한동안 지켜 왔고 그런 종류의 해결책이 필요하다면 이것이 제가 기꺼이 시도 할 다음 도구가 될 것입니다. StonePath는 ruote와는 매우 다른 목적을 가지고 있습니다. Ruote는 일반적으로 Ruby에 유용하고 StonePath는 Ruby로 작성된 웹 프레임 워크 인 Rails를 대상으로합니다. Ruote는 수명이 긴 비즈니스 프로세스 및 관련 정의에 관한 것이지만 StonePath는 상태 기반 워크 플로 및 작업 관리에 관한 것입니다. 솔직히, 외부와의 차이가 미묘 할 수 있다고 생각합니다. 같은 종류의 비즈니스 프로세스가 어느 쪽이든 표현 될 수있는 경우가 많습니다.하지만 상태 및 작업 기반 모델은 내 정신 모델에 매핑되는 경향이 있습니다.
상태 기반 워크 플로의 하이라이트를 설명하겠습니다. 간단히 말해, 모기지 론 또는 여권 갱신과 같은 처리를 중심으로하는 워크 플로를 상상해보십시오. 문서가 '사무실 주변'으로 이동함에 따라 주에서 주로 이동합니다. 문서에 대한 책임이 있고 상사가 몇 시간마다 상태 업데이트를 요청하고 간단한 답변을 원한다고 가정 해보십시오. "데이터 입력 중입니다"... "확인 중입니다. 지금 신청자의 자격 증명 "..."품질 검토를 기다리고 있습니다 "..."완료되었습니다 "... 등등. 상태 기반 워크 플로의 상태입니다. "approve", "apply", kickback ","deny "등과 같은 전환을 통해 상태에서 상태로 이동합니다. 이들은 동작 동사 인 경향이 있습니다.
상태 / 작업 기반 워크 플로의 다음 부분은 작업 생성입니다. 태스크는 작업 항목 (예 : 대출 신청 또는 여권 갱신)을 "박스 내"사용자에게 연결하는 작업 단위로, 일반적으로 기한 및 처리 지침이 있습니다. 작업은 서로 병렬로 또는 순차적으로 발생할 수 있으며, 상태에 진입하면 자동으로 작업을 생성하고, 사람들이 작업을 완료해야 함을 인식함에 따라 수동으로 작업을 생성하고, 새로운 상태로 이동하기 전에 작업을 완료하도록 요구할 수 있습니다. 이러한 모든 종류의 동작은 선택 사항이며 워크 플로 정의의 일부입니다.
토끼 구멍은 이것보다 훨씬 더 깊어 질 수 있으며, 나는 Pragmatic Programmer 's Magazine 인 PragPub의 Issue # 4에 대한 기사를 썼습니다. 해당 기사의 업데이트 된 PDF는 위의 reo 링크를 확인하십시오.
지난 몇 달 동안 StonePath로 작업하면서 상태 기반 모델이 편안한 웹 아키텍처에 정말 잘 매핑된다는 것을 발견했습니다. 특히 작업과 상태 전환은 중첩 된 리소스로 잘 매핑됩니다. 이 주제에 대한 저의 미래 글을 기대하십시오.
나는 편견이 있고, ruote 의 저자 중 한 명입니다 .
변형 1) 리소스 (문서, 주문, 송장, 책, 가구)에 연결된 상태 머신.
변형 2) 작업이라는 가상 리소스에 연결된 상태 머신
변형 3) 워크 플로 정의를 해석하는 워크 플로 엔진
이제 질문에 "BPM"태그가 지정되어 "비즈니스 프로세스 관리"로 확장 할 수 있습니다. 이러한 종류의 관리는 각 변형에서 어떻게 발생합니까?
변형 1에서는 비즈니스 프로세스 (또는 워크 플로)가 응용 프로그램에 흩어져 있습니다. 리소스에 연결된 상태 시스템은 워크 플로의 일부 측면을 적용하지만 리소스와 관련된 측면 만 적용합니다. 동일한 비즈니스 프로세스를 따르는 자체 상태 머신이있는 다른 리소스가있을 수 있습니다.
변형 2에서 워크 플로는 작업 리소스에 집중 될 수 있으며 해당 리소스 주변의 상태 시스템으로 표시됩니다.
변형 3에서는 워크 플로 정의 (또는 비즈니스 프로세스 정의)라는 리소스를 해석하여 워크 플로를 제정합니다.
비즈니스 프로세스가 변경되면 어떻게됩니까? 비즈니스 프로세스가 관리 가능한 리소스 인 워크 플로 엔진을 갖는 것이 가치가 있습니까?
대부분의 상태 머신 라이브러리에는 1 개의 세트 상태 + 전환이 있습니다. 워크 플로 엔진은 대부분 워크 플로 정의 인터프리터이며 여러 다른 워크 플로를 함께 실행할 수 있습니다.
워크 플로우를 변경하는 데 드는 비용은 얼마입니까?
변형은 상호 배타적이지 않습니다. 워크 플로 엔진이 상태 시스템에 의해 보호되는 여러 리소스의 상태를 변경하는 많은 예를 보았습니다.
또한 휴먼 태스크에 대해 변형 3 + 2를 많이 사용합니다. 워크 플로 엔진은 프로세스 인스턴스를 실행할 때 일부 지점에서 인간 참여자에게 태스크 (작업 항목)를 전달합니다 (리소스 태스크가 생성되고 '준비'상태로 배치됨). .
변형 2 (작업 관리자 변형)만으로도 먼 길을 갈 수 있습니다.
또한 상태 시스템이없고 워크 플로 엔진이 없으며 비즈니스 프로세스가 애플리케이션에 분산 및 / 또는 하드 코딩되는 변형 0)을 언급 할 수도 있습니다.
많은 질문을 할 수 있지만 답을 읽는 데 시간이 걸리지 않고 시험 해보고 실험하는 데 시간이 걸리지 않으면 멀리 가지 않고 언제 사용할 지에 대한 감각을 얻지 못할 것입니다. 이 또는 저 도구.
이전 프로젝트에서 저는 Healhcare 산업의 정부 양식 세트에 몇 가지 워크 플로우 유형 규칙을 추가했습니다.
최종 사용자가 양식을 작성해야했으며 일부 답변에 따라 다른 양식이 나중에 작성 될 예정이었습니다. 예정된 양식을 취소하거나 새 양식을 예약하는 외부 이벤트도있었습니다.
샘플 흐름 :
입원 환자-> 초기 평가 양식 예약-> 분기 별 검토 양식 예약-> 환자 사망-> 검토 취소-> 퇴원 평가 양식 예약
다른 많은 규칙은 환자 연령, 입원 장소 등을 기반으로했습니다.
이것은 ASP.NET 앱이었고 규칙은 기본적으로 데이터베이스의 테이블이었습니다. 스크립팅을 추가 했으므로 다음에 수행 할 작업을 결정하기 위해 양식 완성시 스크립트가 실행됩니다. 이것은 끔찍한 디자인이었고 적절한 Workflow 엔진에 완벽했을 것입니다.
저는 Uber에서 개발 한 Cadence Workflow Engine 의 저자 중 한 명입니다 . Cadence와 기존 워크 플로 엔진의 대부분의 차이점은 개발자 중심이며 매우 유연하고 확장 가능하다는 것입니다 (초당 수만 개의 업데이트 및 최대 수십억 개의 개방형 워크 플로). 워크 플로우는 객체 지향 프로그램으로 작성되며 엔진은 호스트 장애시 스레드 스택 및 로컬 변수를 포함한 워크 플로우 객체의 상태가 완전히 보존되도록합니다.
워크 플로우 엔진을 사용하여 해결 한 문제는 무엇입니까? Cadence는 단일 요청 응답을 넘어서는 거의 모든 백엔드 애플리케이션에 사용됩니다. 사용 예는 다음과 같습니다.
그리고 많은 다른 사람들
다른 사용 사례 세트는 기존 워크 플로 엔진을 Cadence에서 실행하도록 이식하는 것입니다. 실제로 기존 엔진 워크 플로 사양 언어를 Cadence에서 실행하도록 이식 할 수 있습니다. 이식 된 내부 Uber 시스템이 여러 개 있습니다. 이러한 방식으로 단일 백엔드 서비스가 여러 도메인 별 워크 플로우 시스템을 구동 할 수 있습니다.
어떤 라이브러리 / 프레임 워크를 사용 했습니까?
Cadence는 Go 및 Java 클라이언트 측 라이브러리 와 함께 Go로 작성된 자체 포함 서비스입니다 . 유일한 외부 종속성은 스토리지입니다. Cassandra 및 SQL 데이터베이스가 지원됩니다.
Cadence는 또한 비동기 교차 리전 (AWS 용어 사용) 복제를 지원합니다.
시스템과 같은 더 간단한 상태 머신 / 태스크 관리는 언제 충분 했습니까?
Uber 내부에서 Cadence 서비스는 저희 팀에서 관리합니다. 따라서 사용자 지정 상태 시스템 / 작업 관리를 구축하는 데 드는 오버 헤드는 항상 Cadence를 사용하는 것보다 높습니다. 회사 외부에서 서비스 및 스토리지를 설정해야합니다. 이미 SQL 데이터베이스가있는 경우 서비스 배포는 도커 이미지를 통해 간단합니다. 도커는 개인용 컴퓨터 또는 랩톱에서 개발하기 위해 로컬 Cadence 서비스를 실행하는데도 사용됩니다.
rails_workflow gem을 확인하십시오 -이것이 당신이 검색하는 것과 비슷하다고 생각합니다.
저는 Imixs-Workflow 의 저자 중 한 명입니다 . Imixs-Workflow는 BPMN 2.0을 기반으로하는 오픈 소스 워크 플로우 엔진이며 Java EE 기술 스택에 완전히 통합됩니다.
저는 10 년 넘게 워크 플로우 엔진을 스스로 개발했습니다. 나는 귀하의 질문에 간단히 대답하려고 노력할 것입니다.
> 워크 플로우 엔진을 사용하여 해결 한 문제는 무엇입니까?
워크 플로 엔진에 대해 생각하기 시작했을 때의 개인적인 목표는 애플리케이션 내에서 비즈니스 로직을 하드 코딩하지 않는 것이 었습니다. 비즈니스 애플리케이션의 많은 항목을 재사용 할 수 있으므로 구성 가능한 상태로 유지하는 것이 좋습니다. 예를 들면 :
이 기능 목록에서 내가 인간 중심의 워크 플로우에 대해 이야기하고 있음을 알 수 있습니다. 요컨대 : 인간 중심의 워크 플로우 엔진은 다음 질문에 답합니다. 작업을 담당하는 사람은 누구이며 다음에 누구에게 알려야합니까? 그리고 이것은 비즈니스 요구 사항의 일반적인 질문입니다.
> 어떤 라이브러리 / 프레임 워크를 사용 했습니까?
5 년 전 우리는 BPMN 2.0에 중점을 둔 Imixs-Workflow 엔진을 다시 구현하기 시작했습니다 . BPMN은 프로세스 모델링을위한 공통 표준입니다. 저에게 놀라운 것은 시각화 및 실행이 가능한 매우 복잡한 비즈니스 프로세스도 갑자기 설명 할 수 있다는 것입니다. 모든 사람이 비즈니스 프로세스를 모델링하기 위해 BPMN을 사용하는 것이 좋습니다.
> 시스템과 같은 더 간단한 상태 머신 / 태스크 관리는 언제 충분 했습니까?
비즈니스 오브젝트의 상태를 추적하려는 경우 단순한 상태 머신이면 충분합니다. 객체 모델에 'status'속성을 도입하기 시작하는 경우입니다. 그러나 책임, 로깅 및 흐름 제어가있는 비즈니스 프로세스가 필요한 경우 상태 시스템으로는 더 이상 충분하지 않습니다.
> 보너스 : 작업 관리와 워크 플로 엔진을 어떻게 구분 했습니까?
여기에 언급 된 많은 워크 플로 엔진이 다른 점이 바로 여기에 있습니다. 인간 중심 워크 플로의 경우 일반적으로 인간 행위자간에 작업을 배포하기위한 작업 관리가 필요합니다. 프로세스 자동화의 경우이 점은 그다지 관련이 없습니다. 엔진이 특정 작업을 수행하면 충분합니다. 작업 관리는 항상 워크 플로 엔진의 기능이기 때문에 작업 관리와 워크 플로 엔진을 비교할 수 없습니다.
저는 네트워크 노드 인프라에서 고성능 및 고 처리량 데이터 전송 프로세스를 처리하기 위해 Activiti BPMN 2.0 엔진을 사용한 경험 이 있습니다. 기본 작업은 이러한 전송 프로세스의 구성 및 모니터링을 허용하고 각 네트워크 노드를 제어하는 것입니다 (즉, 특정 전송 계층을 통해 node2에 데이터 파일을 전송하도록 node1 요청).
한 번에 수천 개의 프로세스가 실행되고 하루에 전체적으로 수만 개 또는 수십만 개의 프로세스가 실행될 수 있습니다.
다양한 프로세스 정의가 있었지만 반드시 시스템 운영자가 사용자 지정 워크 플로를 만들 수 있어야하는 것은 아닙니다. 따라서 BPM 엔진 자체의 주요 사용 사례는 견고하고 확장 가능하며 각 프로세스 흐름을 모니터링 할 수 있도록하는 것이 었습니다.
결국 그것은 기본적으로 작동했지만 우리가 그 프로젝트에서 배운 것은 BPMN 플랫폼 또는 특히 Activiti 엔진이 그러한 높은 처리량 시스템에 대한 최선의 선택이 아니라는 것입니다.
주요 과제는 작업 실행 우선 순위 지정, DB 잠금, BPM 자체와 관련된 몇 가지 실행 재 시도였습니다. 그래서 우리는 이것들에 대한 커스텀 핸들링을 개발해야했습니다. 예를 들면 :
다른 BPMN 엔진이 이러한 시나리오에 더 적합한 지 모르겠습니다. BPMN은 주로 성능이 우리의 경우와 동일한 문제가 아닌 사용자 상호 작용과 관련된 장기 실행 비즈니스 작업을위한 것이기 때문입니다.