워크 플로우로 또는 워크 플로우로하지 않습니까?

저는 경량 보험 청구 시스템 개발을 시작할 개발자 팀을 책임지고 있습니다. 이 시스템에는 많은 수동 작업과 비즈니스 워크 플로가 포함되며 Windows Workflow (.NET 4.0) 사용을 고려하고 있습니다.

비즈니스 도메인의 예는 다음과 같습니다. 보험 계약자가 컨택 센터에 전화하여 클레임을 제기합니다. 이 "이벤트"는 수동으로 병렬로 실행되는 두 개의 하위 작업을 실행하며 완료하는 데 시간이 오래 걸릴 수 있습니다.

1. 사기 고객 확인 – 운영자가 여러 신용 회사에 전화하여 사기 고객의 가능성을 확인하고 평가하는 수동 프로세스입니다. 여기에서 하위 작업은 여러 하위 상태 (진행 중 확인, 참조 확인 실패, 참조 확인 통과 등)를 입력 할 수 있습니다.
2. 수리 센터로 품목 보내기 – 보험 계약자가 클레임을 제기 한 품목을 수리 센터로 보내 수리하는 수동 프로세스입니다. 여기에서 하위 작업은 여러 하위 상태 (수리 대기 중, 진행 중, 수리 됨, 게시 됨 등)를 입력 할 수 있습니다. 청구는 각 하위 작업의 상태가 사전 정의 된 상태 (비즈니스 규칙에 따라)에 도달 한 경우에만 진행될 수 있습니다.

표면적으로는 Workflow가 실제로 최고의 기술 선택 인 것 같습니다. 그러나 WF 4.0 사용에 대해 몇 가지 우려 사항이 있습니다.

1. 기술 세트 – 평균 개발자 기술 세트를 보면 워크 플로를 이해하거나 아는 개발자가 많지 않습니다.
2. 유지 보수성 – 커뮤니티 내에서 WF 4.0 프로젝트에 대한 지원이 거의없는 것으로 보이며 이는 기술 세트 부족과 함께 유지 보수 가능성에 대한 우려를 제기합니다.
3. 진입 장벽 – Windows Workflow는 학습 곡선이 가파르 며 항상 쉽게 익힐 수있는 것은 아니라고 생각합니다.
4. 새 제품 – 워크 플로가 .NET 4.0 용으로 완전히 다시 작성되었으므로이 제품은 1 세대 제품으로 간주되며 필요한 안정성이 없을 수 있습니다.
5. 평판 – 이전 버전의 Workflow는 호평을받지 못했으며 개발하기 어려운 것으로 간주되어 비즈니스 이해도가 떨어졌습니다.

제 질문은이 상황에 대해 Windows Workflow (WF) 4.0 을 사용해야합니까, 아니면 사용할 대체 기술 (예 : Simple State Machine 등) 또는 더 나은 워크 플로 엔진이 있습니까?

여러 WF4 프로젝트를 수행 했으므로 다른 답변에 유용한 정보를 추가 할 수 있는지 살펴 보겠습니다.

비즈니스 문제에 대한 설명에서 WF4가 좋은 일치 인 것처럼 들리므로 문제가 없습니다.

당신의 우려에 관해서는 당신이 옳습니다. 기본적으로 WF4는 새로운 제품이며 몇 가지 중요한 기능이 부족하고 약간의 가장자리가 있습니다. 학습 곡선이 있습니다. 몇 가지를 다르게해야합니다. 요점은 장기 실행 및 직렬화입니다. 이는 일반 개발자가 익숙하지 않은 작업이며 사람들이 엔티티 프레임 워크 데이터 컨텍스트를 직렬화하는 데 문제가 있다는 말을 너무 자주 들었 기 때문에 제대로 이해하기 위해 약간의 생각이 필요합니다.

대부분의 경우 IIS / WAS에서 호스팅되는 워크 플로 서비스를 사용하는 것이 이러한 장기 실행 유형의 워크 플로를 수행 할 때 가장 좋은 방법입니다. 따라서 버전 관리 문제를 어렵지 않게 해결할 수 있습니다. 첫 번째 메시지가 워크 플로 버전을 반환하고이를 각 후속 메시지의 일부로 만들기 만하면됩니다. 다음으로 메시지를 버전에 따라 올바른 끝점으로 라우팅하는 사이에 WCF 라우터를 배치합니다. 기본은 기존 워크 플로를 변경하지 않고 항상 새 워크 플로를 만드는 것입니다.

그래서 내가 당신에게 조언하는 것은 무엇입니까? 알려지지 않은 것과 입증되지 않은 기술에 대해 큰 도박을하지 마십시오. WF4를 사용하여 작고 중요하지 않은 응용 프로그램을 수행합니다. 그런 식으로 작동하면 확장 할 수 있지만 실패하면 뜯어 내고보다 전통적인 .NET 코드로 대체 할 수 있습니다. 이렇게하면 중고 정보를 기반으로 결정을 내리는 대신 WF4에 대한 실제 경험을 얻고 그 과정에서 새롭고 강력한 기술을 배울 수 있습니다. 가능한 경우 WF4에 대한 과정을 수강하면 속도를 높이는 데 많은 시간을 절약 할 수 있습니다 ( 여기 뻔뻔한 셀프 플러그 ).

Simple State Machine 정보. 나는 그것을 사용하지 않았지만 단기 실행, 메모리, 상태 머신이라는 인상을 받았습니다. WF4의 주요 이점 중 하나는 장기 실행 측면입니다.

저는이 딜레마에 몇 번 왔고 Work Flow Foundation을 사용하지 않기로 결정했습니다. 일부 고려 사항 (귀하의 것과 유사)은

1. 관련 작업 흐름은 훨씬 더 단순했으며 (상태 시스템과 순차적 작업의 조합) WF에서 수행하는 작업은 관련된 노력에 과도하게 사용되는 것 같습니다.
2. 개발자가 WF를 이해하고 효과적으로 사용하기위한 학습 곡선이 높은 것으로 간주되었습니다. 유효한 전환 및 취해야 할 조치를 설명하는 상태 전환 테이블은 추가적인 유연성을 위해 사용되며 개발자는 개념과 목적을 쉽게 이해하고 이에 익숙해졌습니다.
3. 비즈니스 프로세스 변경의 가능성은 적었고 전환 테이블을 사용하여 기초적인 변경이 쉽게 가능했습니다. 전환의 변경은 데이터베이스 스크립트를 의미하는 반면 작업의 변경은 새로운 릴리스 / 패치로 이어집니다. 그러나 이러한 발생 확률은 낮은 것으로 판단되었다.

13 ~ 14 개월이 지난 후에도 여전히 WF를 사용하지 않은 결정이 옳았다 고 생각합니다. IMO, WF는 작업 흐름이 변경되거나 비즈니스 규칙이 변경 될 수있는 강력한 후드가있는 곳에서 의미가 있습니다. WF를 사용하면 워크 플로를 별도의 파일로 격리 할 수 ​​있으므로 사용자가 구성 할 수 있도록하는 것이 더 간단합니다.

우리는 지난 몇 달 동안 WF 4.0을 사용해 왔습니다. Workflow 방식을 생각하는 것은 어렵습니다. 그러나 그만한 가치가 있다고 말할 수 있습니다. 시작했을 때 우리는 거의 알지 못했습니다. 도움이되는 WF 4.0 용 초보자 및 전문가 용 책을 구입했습니다. 나 자신은 온라인에서 많은 비디오를보고 PDC 2009를 따라 WF 4.0에 대한 속보와 이전 버전과의 차이점을 확인했습니다. 솔루션을 제안해야했던 한 가지 주요 사항은 사용자 지정 활동을 특정 데이터 유형에 제한하지 않고 워크 플로에서 In / Our Arguments를 처리 할 수있는 방법과 활동간에 매개 변수를 전달하는 방법입니다. 나는 그것에 대한 좋은 해결책을 생각 해냈고 지금까지 우리가 가지고있는 워크 플로우 경험은 전혀 나쁘지 않습니다. 사실은, 점점 더 커지고있는 워크 플로 집약적 인 응용 프로그램이 있으며 다른 환경에서이 문제를 해결하는 것은 상상할 수 없습니다. 나는 그것이 가진 시각적 효과를 좋아합니다. if / else 등 구조의 세부 사항에서 멀리 떨어져 있고 무슨 일이 일어나고 있는지 알기 위해 코드 줄에 뛰어 들지 않도록하는 방식으로 비즈니스 규칙을 분명하게 만듭니다. 버그를 수정하는 방법. 그건 그렇고, 우리가 작업 한 프로젝트는 당신이 설명한 것과 매우 유사하며 중간 규모의 프로젝트입니다. 내 말에서 내가 그것을 좋아한다고 말할 수 있고 나는 그것을 추천하지만 그것은 새로운 기술이기 때문에 약간의 위험을 포함하고 있으며 몇 가지 혁신적인 아이디어를 생각해 내야한다. 그것은 내가 if / else 등 구조의 세부 사항에서 멀리 떨어져 있고, 무슨 일이 일어나고 있는지 또는 어떤 버그를 수정하는 방법을 알기 위해 코드 줄을 강요하지 않게하는 방식으로 비즈니스 규칙을 분명하게 만듭니다. 그건 그렇고, 우리가 작업 한 프로젝트는 당신이 설명한 것과 매우 유사하며 중간 규모의 프로젝트입니다. 내 말에서 내가 그것을 좋아한다고 말할 수 있고 나는 그것을 추천하지만 그것은 새로운 기술이기 때문에 약간의 위험을 포함하고 있으며 몇 가지 혁신적인 아이디어를 생각해 내야한다. 그것은 내가 if / else 등 구조의 세부 사항에서 멀리 떨어져 있고, 무슨 일이 일어나고 있는지 또는 어떤 버그를 수정하는 방법을 알기 위해 코드 줄을 강요하지 않게하는 방식으로 비즈니스 규칙을 분명하게 만듭니다. 그건 그렇고, 우리가 작업 한 프로젝트는 당신이 설명한 것과 매우 유사하며 중간 규모의 프로젝트입니다. 내 말에서 내가 그것을 좋아한다고 말할 수 있고 나는 그것을 추천하지만 그것은 새로운 기술이기 때문에 약간의 위험을 포함하고 있으며 몇 가지 혁신적인 아이디어를 생각해 내야한다.

내 2 센트 ...

WF 3.5에서 세 가지 프로젝트를 수행했는데 쉽지 않다고 말해야합니다. 특히 지속성이 사용될 때 완전히 새로운 방식으로 생각하도록 강요합니다. 수백 개의 불완전한 지속 형 워크 플로가 포함 된 애플리케이션을 업데이트하는 것은 어렵습니다. 직렬화의 단일 주요 변경 사항이 모두 충돌합니다. 새롭고 오래된 실행 워크 플로를 지원하기 위해 동일한 라이브러리의 여러 버전을 도입하는 것이 일반적입니다. 도전적이었습니다.

아직 WF 4.0을 사용 해본 적은 없지만 BizTalk와 WF 3.5의 경험을 바탕으로 비슷할 것이라고 생각합니다.

어쨌든 최선의 접근 방식은 개념 증명을 수행하는 것입니다. 요구 사항에서 단일 WF를 가져와 WF 4.0에서 구현해보십시오. 당신은 그것으로 시간을 보낼 것이지만 WF 4.0에서 그렇게 할 수 있는지 그리고 눈에 띄는 이점이 있는지 증명할 것입니다.

WF 4.0을 사용하기로 결정한 경우 Windows AppFabric에서 호스팅되는 WCF 서비스로 WF를 실행할 수 있는지 확인해야합니다. AppFabric은 WF 호스팅을위한 몇 가지 기본 기능을 제공합니다.

저는 오늘날 이러한 종류의 문제에 대한 기술 선택으로 WF4의 워크 플로에 대해 이야기하는 것이 타당하지 않다고 생각합니다. 위에서 Ladislav Mrnka가 언급했듯이 실제로 적절한 것은 AppFabric에서 호스팅되는 WCF WF Services입니다.

이것에 대한 나의 경험은 그것이 큰 배당금을 지불하고 매우 즐겁다는 것입니다. 그러나 많은 프로그래머들에게 이것이 기술 변화보다 방법론 변화라는 것을 제대로 인식하지 못하기 때문에 처음에는 문제가 발생합니다. 다른 한편으로, 제너럴리스트와 문제 해결 마인드를 가진 사람들은 WCF WF AppFabric을 흥미로운 기회의 집합으로 보았다. 따라서 프로젝트에 참여하는 사람들이 일상적인 OO 및 패턴 집합에 연결된 상당히 보수적 인 C # 개발자라면 도입하기 어려울 것입니다. 팀이 더 혁신적이라면 발견 할 때마다 잠재력과 새로운 통로가 배가되기 때문에 채택이 훨씬 쉬워 질 것입니다.

프로그래머가이 기술로 전환하는 데있어 두 가지 주요 개념 문제는 다음과 같습니다. a) 메시지 상관 관계 및 메시지 교환 패턴 b) 워크 플로 및 단위 테스트 예를 들어 C #의 표준 시스템에서 워크 플로는 명시 적이 지 않으므로 단위 테스트가 거의 없습니다. 전체 워크 플로는 수용 시나리오 또는 통합에 의해 테스트를 위해 남겨집니다. 명시적인 WF를 소프트웨어 아티팩트로 도입하면 갑자기 표준 개발자가이를 시도하고 단위 테스트하려고하는데, 이는 일반적으로 할 가치가 없습니다.

그것의 메시지 상관 측면은 메시지 교환 패턴에 익숙하지 않은 사람들에게 약간의 사고 방식 전환입니다. 대부분의 개발자는 프로세스 및 원격 호출, 웹 서비스 및 SOAP를 처리했으며 일반적으로 그중 하나 또는 두 가지에 중점을 둡니다. 무엇보다도 추상화하고 일반적인 메시지 기반 시스템으로 작업하는 것은 처음에는 혼란 스러울 수 있습니다.

긍정적 인 측면에서 최종 결과는 많은 시간을 절약하고 많은 기회를 창출하는 것입니다. 한 가지 중요한 점은 worfklow가 시각적으로 명확하다면 최종 사용자, 개발자 및 분석가가 함께 작업하여 개발 수명주기에서 불필요한 단계를 제거하고 당사자가 하나의 아티팩트에 집중할 수 있다는 것입니다. 또한 비즈니스 도메인 당 WF의 비즈니스 프로세스 제품군을 장려함으로써 전용 글루 레이어를 사용하여 전용 앱의 기능이 분리되는 것을 방지합니다. 또한 AppFabric을 사용하면 지속성, 로깅 및 예약 된 활동 깨우기에 대한 배관이 모두 수행됩니다. WF4 성능도 뛰어납니다.

가장 혁신적이거나 탐구적인 팀원이 까다로운 부분을 발견하고, 핵심 기능이 작동하도록하고, 나머지 작업을 구분할 책임이있는 초기 사람을 찾기 위해 초기 스카우트를 수행하는 것이 좋습니다.

역할 및 "하위 작업"을 포함하는 복잡한 보험 청구 시스템을 수행하려면 워크 플로뿐만 아니라 BPM 솔루션이 필요합니다. Workflow Foundation 4.0은 매끄럽지 만 실제로 BPM 제품의 기능에 가깝지는 않습니다.

Metastorm BPM, Global360 및 K2.NET과 같은 BPM 솔루션은 보험 청구 시스템과 같은 비즈니스 프로세스를 모델링하고 능률화 할 수있는 인간 중심의 워크 플로, 작업, 역할 및 시스템 통합을 제공합니다. 기본 제공 디자이너가 일반적으로 제한되어 있고 일반적으로 ASP.NET 웹 컨트롤만큼 완전한 기능을 제공하지 않는 사용자 지정 빌드 웹 컨트롤을 사용하도록 강제하므로 ASP.NET을 사용하여 BPM 워크 플로 엔진과 통합되는 인터페이스를 빌드합니다.

팀이 알고 있고 편안하다고 느끼는 기술을 사용하십시오. Workflow Foundation은 바로 사용할 수있는 제품이 아닙니다. 워크 플로 시스템을 구축하기 위해 응용 프로그램에 포함 할 수있는 부분 집합입니다. IMHO 워크 플로우 로직은 기술에서 가장 중요하지 않은 부분입니다. 비즈니스 소유자는 GUI 외에는 아무것도 볼 수 없기 때문에 먼저 GUI에 집중해야합니다. 그러나 시스템이 성공하면 끊임없는 변경 요청과 새로운 요구 사항에 대비해야하므로 비즈니스 로직을 구현하여 변경하기 쉽고 다른 사용자 요구에 맞게 별도의 프로세스로 쉽게 분할해야합니다 (때로는 모순됨). . BPM을 사용하면 다양한 비즈니스 요구에 맞는 별도의 여러 버전의 비즈니스 프로세스를 가질 수 있으므로이 작업에 도움이됩니다. 당신은 이를 위해 완전한 BPM 엔진이 필요하지만 버전을 관리하고 개별 비즈니스 프로세스로 나눌 수 있도록 비즈니스 로직을 코딩하는 것이 유용합니다. 최악의 것은 '모든 것'을 처리하는 코드의 관리 불가능하고 얽힌 덩어리입니다. 이해할 수 있습니다. 상태 머신, DSL (도메인 특정 언어), 스크립트 등 많은 아이디어가 있습니다. 구현이 무엇인지 결정합니다. 그러나 항상 비즈니스 프로세스 측면에서 생각하고 그에 따라 논리를 구성하여 이러한 프로세스를 반영해야합니다. 그리고 비즈니스 로직과 데이터 구조의 많은 변형이 공존 할 준비를하십시오. 이것은 가장 어려운 설계 작업입니다. 비즈니스 로직을 코딩하여 개별 비즈니스 프로세스로 나눌 수 있도록하는 데 유용합니다. 최악의 것은 '모든 것'을 처리하고 아무도 이해할 수없는 관리 할 수없고 얽힌 코드 덩어리입니다. 상태 머신, DSL (도메인 특정 언어), 스크립트 등 많은 아이디어가 있습니다. 구현이 무엇인지 결정합니다. 그러나 항상 비즈니스 프로세스 측면에서 생각하고 그에 따라 논리를 구성하여 이러한 프로세스를 반영해야합니다. 그리고 비즈니스 로직과 데이터 구조의 많은 변형이 공존 할 준비를하십시오. 이것은 가장 어려운 설계 작업입니다. 비즈니스 로직을 코딩하여 개별 비즈니스 프로세스로 나눌 수 있도록하는 데 유용합니다. 최악의 것은 '모든 것'을 처리하고 아무도 이해할 수없는 관리 할 수없고 얽힌 코드 덩어리입니다. 상태 머신, DSL (도메인 특정 언어), 스크립트 등 많은 아이디어가 있습니다. 구현이 무엇인지 결정합니다. 그러나 항상 비즈니스 프로세스 측면에서 생각하고 그에 따라 논리를 구성하여 이러한 프로세스를 반영해야합니다. 그리고 비즈니스 로직과 데이터 구조의 많은 변형이 공존 할 준비를하십시오. 이것은 가장 어려운 설계 작업입니다. DSL (도메인 특정 언어), 스크립트 등-구현이 무엇인지 결정합니다. 그러나 항상 비즈니스 프로세스 측면에서 생각하고 그에 따라 논리를 구성하여 이러한 프로세스를 반영해야합니다. 그리고 비즈니스 로직과 데이터 구조의 많은 변형이 공존 할 준비를하십시오. 이것은 가장 어려운 설계 작업입니다. DSL (도메인 특정 언어), 스크립트 등-구현이 무엇인지 결정합니다. 그러나 항상 비즈니스 프로세스 측면에서 생각하고 그에 따라 논리를 구성하여 이러한 프로세스를 반영해야합니다. 그리고 비즈니스 로직과 데이터 구조의 많은 변형이 공존 할 준비를하십시오. 이것은 가장 어려운 설계 작업입니다.

.NET 4.5가 아직 우리의 prod 환경에서 사용하도록 승인되지 않았기 때문에 4.0을 사용해야하는 상황에 있습니다. 저는 일반적으로 우리의 비즈니스 요구에 맞는 장기 실행 워크 플로를 얻는 방법을 이해하는 데 어려움을 겪었지만 결국에는 우아한 솔루션을 찾았습니다. 생각할 것이 너무 많기 때문에 나중에 지원하기 위해 오는 사람 만 쉽게 선택할 수있는 것은 아니지만 WF를 워크 플로 상태를 관리하는 도구로 믿습니다.

내가 WF 4.0에서 가장 큰 문제는 Maurice의 의견입니다.

기본은 기존 워크 플로를 변경하지 않고 항상 새 워크 플로를 만드는 것입니다.

새 버전 만 원하면 좋지만 50,000 개의 지속 형 워크 플로가 있고 어느 시점에서 워크 플로에 버그가 있음을 알게되면 어떻게 될까요? xamlx를 업데이트 할 수 있어야하고 기존 인스턴스에 계속 연결되어 있어야합니다. SQL Server 인스턴스 테이블의 다양한 메타 데이터 열을 압축 해제하여 운이없이 인스턴스를 워크 플로 정의에 연결하는 항목을 찾았습니다.

이전 시스템에서 새로운 WF 4.0 기반 시스템으로 데이터를 가져 오기위한 동기화 응용 프로그램을 작성했습니다. 기본적으로 데이터를 시스템에로드 한 다음 자동으로 워크 플로 단계를 호출하고 유효성 검사 메서드를 호출하는 프로세스를 실행하여 기본적으로 사용자 상호 작용을 조롱합니다. 이것은 우리가 워크 플로 서비스 호스트에 액세스하기 위해 구현 한 아키텍처로 인해 실제로 잘 작동했습니다. 실행 후 데이터 마이그레이션 프로세스의 일관성을 확인하기 위해 검사를 수행 할 수있는 일회성으로 훌륭하지만 시스템이 활성화 된 후 잠재적으로 수십만 건에 대해이 접근 방식을 사용해야하는 것은 실제로 접근 방식이 아닙니다. 이는 통합 프로세스에 대한 자신감을 심어주고 간단한 버그 수정에 부담을줍니다.

내 권장 사항은 WF 4.0을 완전히 피하고 환경이 지원하는 경우 4.5로 바로 이동하는 것입니다. 동적 업데이트 및 병렬 버전 관리는 버그 수정 및 WF 버전 관리를 즉시 제공합니다. 4.5가 여전히 우리 고객이 사용하도록 인증되지 않았기 때문에 아직 정확히 조사하지는 않았지만이 기회를 간절히 기다리고 있습니다.

필자가 간절히 바라는 것은 클라이언트가 정책 변경 (따라서 워크 플로 조정)을 요청하지 않고 현재 워크 플로가 버그없이 유지된다는 것입니다. 후자는 버그가 항상 나타나기 때문에 헛되고 공허한 희망입니다.

버그를 쉽게 수정할 수없는 시스템을 출시하기 위해 WF 개발 팀의 머리를 통해 어떤 일이 벌어지고 있는지 정말 이해할 수 없습니다. 인스턴스를 새 xamlx에 다시 바인딩하는 기술을 개발 했어야합니다.