워크 플로우 엔진을 언제 사용해야합니까?

나는 과거에 일부 워크 플로 엔진에서 프로그래머로 일했지만 왜 워크 플로 엔진을 먼저 선택했는지 명확하지 않았습니다. 그리고 프로그래머로서 나는 코드를 작성할 때 적어도 100 가지 방법으로 아무것도 할 수 있지만 최선의 방법은 거의 없다는 것을 알고 있습니다!

좋은 DI 지원 응용 프로그램을 설계하는 것보다 워크 플로 엔진 (또는 개념)이 어떤 사용 사례를 가장 잘 해결하는지 여전히 이해하지 못합니다. 워크 플로 엔진이 최고의 옵션 중 하나 인 도메인 중립적 사용 사례의 일반적인 특성을 찾고 있습니다.

그래서 내 질문은 : 좋은 워크 플로우 엔진을 선택하고 그 주위를 코딩하기위한 신호로 취할 수있는 요구 사항의 일반적인 특성은 무엇입니까?

워크 플로 엔진은 처음부터 끝까지 진행해야하지만 여러 가지 경로 / 논리 / 규칙이있을 때 유용합니다.

예를 들어 콘텐츠를 게시하는 프로그램을 작성한다고 가정 해 봅시다. 따라서 필자의 경우 게시는 검토 프로세스, 법적 및 최종 승인을 거칩니다. 프로세스 로직과 단계를 구현하는 프로그램을 작성합니다. 이제 이것은 나와 내 회사에서 훌륭하게 작동합니다. 그래서 다른 사람들이 내 프로그램을 사용해야한다고 결정합니다.

불행히도 모든 사람이 동일한 프로세스를 사용하여 콘텐츠를 게시하는 것은 아니므로 각 사례마다 별도의 프로세스를 작성하는 대신 작업 흐름 프로세스를 구현하여 프로그램이 모든 사람을 수용 할 수있는 유연성을 갖습니다. 두 지점 사이에 몇 단계 나 규칙 또는 논리가 있더라도 결과는 동일합니다.

따라서 처음부터 끝까지 가변적 인 프로세스가있는 경우 워크 플로우를 사용하십시오. 모든 사람이 동일한 프로세스를 사용할 수 있으면 워크 플로가 필요하지 않습니다.

유스 케이스를 요청했지만 모든 가능한 유스 케이스를 상상하는 것보다 장점을 나열하는 것이 더 쉽다는 것을 알고 있습니다. 물론 장점은 비교하는 엔진과 언어에 따라 다르지만 일반적으로 다음과 같습니다.

1. 규칙을 코드 대신 데이터로 유지하면 다시 컴파일 할 필요가 없으므로 변경 사항을 신속하게 테스트하고 런타임에 변경하는 등의 작업을 수행 할 수 있습니다. 그러나 처음부터 다시 컴파일 할 필요가없는 경우에는 큰 이점이 없습니다.

2. 사용자는 규칙을보다 합리적으로 편집해야합니다. 프로그래머가 코드를 작성할 때 실현할 수없는 방식으로 대화식으로 상호 작용할 수 있습니다.

3. 규칙을 데이터로 유지하면 데이터를 시각화하고 변경할 수있는 도구를 작성할 수 있습니다.

4. 규칙을 데이터로 유지하면 메타 프로그래밍이 더 쉬워집니다. 코드를 작성하여 데이터를 분석하고 복잡한 방식으로 더 삽입 할 수 있으므로 코드가 매우 어려울 수 있습니다.

이러한 모든 작업은 코드로 직접 수행 할 수 있습니다 (예 : 특정 유형의 모든 규칙을 찾아서 더 많은 규칙에 대한 코드를 생성하기 위해 C # 파서 작성, 어셈블리 언로드를 허용하는 방식으로 어셈블리에 동적으로 삽입, 사용자는 비주얼 라이저 및 편집기를 사용하여이 작업을 수행 할 수 있지만 언어에 따라 훨씬 더 어려울 수 있습니다 (Lisp를 사용하는 프로그래머는 항목 1-4를 "프로그래밍"으로 지칭 할 수 있음).

이런 종류의 것을 사용해야하는 유일한 경우는 덜 가치있는 사용자가 구성 할 수있는 경우입니다. 당신이 그들에게 도구를 제공하여 문제를 해결할 수 있다면 더 중요한 무언가에 대한 작업으로 돌아가서 하나를 사용하십시오.

그래도 그것들을 위해 설정해야한다면 익숙한 도구로 동일한 결과를 얻는 10 가지 방법을 생각할 수 있으며 지원하고 사용자 정의하기가 훨씬 쉬울 것입니다.

이것은 오래된 질문처럼 보이지만 야생에서 여러 번 등장합니다. Jon의 답변에 동의합니다 . 다음 시나리오에서 워크 플로 엔진의 생산성이 높은 것으로 나타났습니다.

1. 소프트웨어를 통해 표현 / 구현하려는 기본 비즈니스 프로세스가 있습니다.
2. 프로세스의 모든 단계 또는 일부 단계에서 수행되는 단일 (복합) 비즈니스 항목이 있습니다. Jon이 제시 한 예에서이 엔티티 또는 워크 플로우 항목은 컨텐츠 또는 기사입니다. 워크 플로의 또 다른 예로 버그 추적을 고려하십시오. 버그는 사용자가 수행하는 작업에 따라 다양한 상태간에 전환됩니다.
3. 비즈니스 프로세스가 변경 될 것으로 예상되는 경우에만 워크 플로를 사용하여 프로세스를 모델링하십시오. 변경으로 사용자 작업 또는 전환의 결과로 수행되는 시퀀스 또는 작업을 의미합니다.

문제 도메인 / 요구 사항에 비즈니스 프로세스가 있는지 확인하기 위해 매우 신중하고 중요합니다. 워크 플로우에 "적합"시키려고하지 마십시오.

워크 플로 엔진을 제안하는 데 사용하는 몇 가지 지침이 있습니다.

1) 비즈니스 분석가가 코딩 배경이 없지만 다이어그램을 그릴 수있는 경우

최신 워크 플로 엔진은 비즈니스 프로세스 모델링 표기법 또는 SharePoint 및 유사한 시스템에서 사용할 수있는 성능이 낮은 버전을 사용합니다. 이를 통해 기술적으로 유능하지만 코딩에 어려움을 겪고있는 팀원은 많은 작업 흐름을 설계하고 개발할 수 있습니다.

2) 작업 진행 상황을 모니터링해야 할 경우, 에스컬레이션을 수행하고 컴퓨터 제어 프로세스와 인간 제어 프로세스 사이를 전환합니다.

모니터링 및 자체 참조는 최신 작업 흐름 엔진의 특징입니다.

HR 비즈니스 관점에서 작업 흐름 엔진은 매우 중요합니다.

1. 매번 동일하더라도 구조화 된 프로세스를 제공합니다.

2. 그들은 투명성을 제공합니다

   • 누가 변경을 요청했는지
   • 언제 요청 받았습니까?
   • 등을 승인 한 사람

   이 투명성은 프로세스를 추진하고 소유권을 증진시킵니다.

양식이 통합되고 지능적이며 비즈니스 논리를 지원한다고 가정하면 타임 라인, 처리 효율성 및 데이터 품질에 큰 영향을 미칩니다. 보안 또한 고려해야 할 사항이며 보안 시스템에 민감한 정보를 포함하는 것이 서명을 기다리는 종이 양식이있는 것보다 훨씬 바람직합니다. 또한 훨씬 더 모바일입니다. 최근에 시행 한 한 관리자는 많은 여행을하면서 서명을 위해 물건을 게시하는 것이 번거 로움을 덜 었다고 말했습니다.

HR 대신 : 긴 라이브 워크 플로우 !!!