BPM 스타일 통합

, 안녕 하브 르!

우리 회사는 ERP급 소프트웨어 솔루션 개발을 전문으로 하며, EDMS와 같은 엄청난 양의 비즈니스 로직과 워크플로를 갖춘 트랜잭션 시스템이 가장 큰 비중을 차지하고 있습니다. 우리 제품의 최신 버전은 JavaEE 기술을 기반으로 하지만 우리는 또한 마이크로서비스를 적극적으로 실험하고 있습니다. 이러한 솔루션의 가장 문제가 되는 영역 중 하나는 인접 도메인과 관련된 다양한 하위 시스템의 통합입니다. 통합 작업은 우리가 사용하는 아키텍처 스타일, 기술 스택 및 프레임워크에 관계없이 항상 큰 골칫거리였지만 최근에는 이러한 문제를 해결하는 데 진전이 있었습니다.

여러분의 관심을 끈 기사에서는 지정된 지역에서 NPO Krista의 경험과 건축 연구에 대해 이야기하겠습니다. 또한 응용 프로그램 개발자의 관점에서 통합 문제에 대한 간단한 솔루션의 예를 고려하고 이러한 단순성 뒤에 숨겨진 것이 무엇인지 알아봅니다.

부인 성명

이 기사에 설명된 아키텍처 및 기술 솔루션은 특정 작업의 맥락에서 개인적인 경험을 바탕으로 제공됩니다. 이러한 솔루션은 보편적이라고 주장하지 않으며 다른 사용 조건에서는 최적이 아닐 수 있습니다.

BPM이 그것과 무슨 관련이 있습니까?

이 질문에 답하기 위해 솔루션의 적용 문제에 대한 세부 사항을 조금 파고들 필요가 있습니다. 일반적인 트랜잭션 시스템에서 비즈니스 논리의 주요 부분은 사용자 인터페이스를 통해 데이터베이스에 데이터를 입력하고, 이 데이터를 수동 및 자동으로 확인하고, 일부 워크플로를 통과하고, 다른 시스템/분석 데이터베이스/아카이브에 게시하고, 보고서를 생성하는 것입니다. 따라서 고객을 위한 시스템의 핵심 기능은 내부 비즈니스 프로세스의 자동화입니다.

편의상 통신에서 "문서"라는 용어는 특정 워크플로를 "연결"할 수 있는 공통 키로 통합된 데이터 집합의 일부 추상화로 사용합니다.
그러나 통합 논리는 어떻습니까? 결국 통합 작업은 고객의 요청이 아니라 완전히 다른 요인의 영향을 받아 부품으로 "절단"되는 시스템 아키텍처에 의해 생성됩니다.

• Conway의 법칙의 영향으로;
• 이전에 다른 제품용으로 개발된 하위 시스템을 재사용한 결과
• 비기능적 요구 사항을 기반으로 설계자가 결정한 대로.

통합 아티팩트로 비즈니스 로직을 오염시키지 않고 애플리케이션 개발자가 시스템의 아키텍처 환경의 특성을 조사하지 않아도 되도록 기본 워크플로의 비즈니스 로직에서 통합 로직을 분리하려는 유혹이 큽니다. 이 접근 방식에는 여러 가지 장점이 있지만 실제로는 비효율적입니다.

• 통합 문제 해결은 일반적으로 기본 워크플로 구현의 제한된 확장 지점으로 인해 동기식 호출 형태의 가장 간단한 옵션으로 내려갑니다(동기식 통합의 단점에 대한 자세한 내용은 아래 참조).
• 통합 아티팩트는 다른 하위 시스템의 피드백이 필요할 때 여전히 주요 비즈니스 로직에 침투합니다.
• 애플리케이션 개발자는 통합을 무시하고 워크플로를 변경하여 쉽게 중단할 수 있습니다.
• 시스템은 사용자의 관점에서 더 이상 하나의 전체가 아니며, 하위 시스템 간의 "이음새"가 눈에 띄고, 한 하위 시스템에서 다른 하위 시스템으로 데이터 전송을 시작하는 중복 사용자 작업이 나타납니다.

또 다른 접근 방식은 통합 상호 작용을 핵심 비즈니스 논리 및 워크플로의 필수적인 부분으로 간주하는 것입니다. 애플리케이션 개발자의 기술 요구 사항이 급증하는 것을 방지하려면 솔루션 선택을 위한 최소한의 옵션으로 쉽고 자연스럽게 새로운 통합 상호 작용을 생성해야 합니다. 이것은 보이는 것보다 더 어렵습니다. 도구는 사용자에게 필요한 다양한 옵션을 제공할 수 있을 만큼 충분히 강력해야 하며 동시에 발에 총을 맞을 수 없어야 합니다. 엔지니어가 통합 작업의 맥락에서 대답해야 하지만 애플리케이션 개발자가 일상 작업에서 생각해서는 안 되는 많은 질문이 있습니다. 전파 및 컨텍스트 전환 등 이러한 모든 질문에 대한 답변이 이미 숨겨져 있는 매우 간단한 결정 템플릿을 애플리케이션 개발자에게 제공하는 것이 필요합니다. 이러한 패턴은 충분히 안전해야 합니다. 비즈니스 논리가 매우 자주 변경되어 오류가 발생할 위험이 증가하고 오류 비용은 상당히 낮은 수준으로 유지되어야 합니다.

그러나 여전히 BPM이 그것과 무슨 관련이 있습니까? 워크플로우 구현을 위한 많은 옵션이 있습니다...
실제로 비즈니스 프로세스의 또 다른 구현은 상태 전환 다이어그램의 선언적 설정과 전환에 대한 비즈니스 논리가 있는 핸들러 연결을 통해 솔루션에서 매우 인기가 있습니다. 동시에 비즈니스 프로세스에서 "문서"의 현재 위치를 결정하는 상태는 "문서" 자체의 속성입니다.

이것이 프로젝트 시작 시 프로세스의 모습입니다.

이러한 구현의 인기는 선형 비즈니스 프로세스 생성의 상대적 단순성과 속도 때문입니다. 그러나 소프트웨어 시스템이 더욱 복잡해짐에 따라 비즈니스 프로세스의 자동화된 부분이 커지고 복잡해집니다. 각 분기가 병렬로 실행되도록 분해, 프로세스 일부의 재사용 및 분기 프로세스가 필요합니다. 이러한 조건에서 도구는 불편해지고 상태 전이 다이어그램은 정보 콘텐츠를 잃습니다(통합 상호 작용은 다이어그램에 전혀 반영되지 않음).

이것은 요구 사항을 명확히 하는 몇 번의 반복 후 프로세스의 모습입니다.

이 상황에서 벗어나는 방법은 엔진의 통합이었습니다. jBPM 가장 복잡한 비즈니스 프로세스가 있는 일부 제품에 적용할 수 있습니다. 단기적으로 이 솔루션은 약간의 성공을 거두었습니다. 표기법에서 상당히 유익하고 최신 다이어그램을 유지하면서 복잡한 비즈니스 프로세스를 구현할 수 있게 되었습니다. BPMN2.

복잡한 비즈니스 프로세스의 작은 부분

장기적으로 솔루션은 기대에 부응하지 못했습니다. 시각적 도구를 통해 비즈니스 프로세스를 생성하는 높은 노동 강도로 인해 수용 가능한 생산성 지표를 달성할 수 없었고 도구 자체가 개발자들 사이에서 가장 싫어하는 도구 중 하나가 되었습니다. 엔진의 내부 구조에 대한 불만도 있었고 이로 인해 많은 "패치"와 "목발"이 등장했습니다.

jBPM 사용의 가장 긍정적인 측면은 비즈니스 프로세스 인스턴스에 대해 자체적인 지속 상태를 가지는 것의 이점과 해로움을 깨닫는 것입니다. 또한 신호와 메시지를 통한 비동기 상호 작용을 사용하여 서로 다른 응용 프로그램 간에 복잡한 통합 프로토콜을 구현하기 위해 프로세스 접근 방식을 사용할 가능성을 확인했습니다. 지속 상태의 존재는 여기서 결정적인 역할을 합니다.

위의 내용을 바탕으로 다음과 같은 결론을 내릴 수 있습니다. BPM 스타일의 프로세스 접근 방식을 통해 우리는 점점 더 복잡한 비즈니스 프로세스를 자동화하기 위한 광범위한 작업을 해결할 수 있고 통합 활동을 이러한 프로세스에 조화롭게 맞출 수 있으며 구현된 프로세스를 적절한 표기법으로 시각적으로 표시할 수 있는 기능을 유지할 수 있습니다.

통합 패턴으로서 동기 호출의 단점

동기식 통합은 가장 단순한 차단 호출을 의미합니다. 하나의 하위 시스템은 서버 측 역할을 하며 원하는 메서드로 API를 노출합니다. 또 다른 하위 시스템은 클라이언트 측 역할을 하며 적시에 결과를 예상하여 호출합니다. 시스템의 아키텍처에 따라 클라이언트와 서버 측은 동일한 애플리케이션 및 프로세스 또는 다른 프로세스에서 호스팅될 수 있습니다. 두 번째 경우에는 일부 RPC 구현을 적용하고 매개변수 마샬링과 호출 결과를 제공해야 합니다.

이러한 통합 패턴에는 상당히 큰 단점이 있지만 단순성으로 인해 실제로 매우 널리 사용됩니다. 구현 속도는 기한을 "소모"하는 조건에서 솔루션을 기술 부채에 작성하는 조건에서 계속해서 적용하고 적용하게 만듭니다. 그러나 경험이 부족한 개발자가 부정적인 결과를 깨닫지 못하고 무의식적으로 사용하는 경우도 있습니다.

하위 시스템의 연결성이 가장 눈에 띄게 증가하는 것 외에도 "확산" 및 "스트레칭" 트랜잭션과 관련된 덜 분명한 문제가 있습니다. 실제로 비즈니스 로직이 변경되면 트랜잭션은 필수불가결하며 트랜잭션은 이러한 변경의 영향을 받는 특정 애플리케이션 리소스를 잠급니다. 즉, 한 하위 시스템이 다른 하위 시스템의 응답을 기다릴 때까지 트랜잭션을 완료하고 잠금을 해제할 수 없습니다. 이는 다양한 영향의 위험을 크게 증가시킵니다.

• 시스템 응답성이 손실되고 사용자는 요청에 대한 응답을 오래 기다립니다.
• 서버는 일반적으로 오버플로된 스레드 풀로 인해 사용자 요청에 대한 응답을 중지합니다. 대부분의 스레드는 트랜잭션이 차지하는 리소스의 잠금에 "대기"합니다.
• 교착 상태가 나타나기 시작합니다. 교착 상태가 발생할 확률은 트랜잭션 기간, 트랜잭션과 관련된 비즈니스 논리 및 잠금의 양에 따라 크게 달라집니다.
• 트랜잭션 시간 초과 만료 오류가 나타납니다.
• 작업에 많은 양의 데이터를 처리하고 변경해야 하는 경우 서버는 OutOfMemory에 "떨어집니다". 동기식 통합의 존재로 인해 처리를 "가벼운" 트랜잭션으로 분할하기가 매우 어렵습니다.

아키텍처 관점에서 볼 때 통합 중에 차단 호출을 사용하면 개별 하위 시스템의 품질 관리가 손실됩니다. 한 하위 시스템의 품질 목표를 다른 하위 시스템의 품질 목표와 분리하여 보장하는 것은 불가능합니다. 하위 시스템이 다른 팀에서 개발되면 큰 문제가 됩니다.

통합 중인 하위 시스템이 서로 다른 응용 프로그램에 있고 양쪽에서 동시에 변경해야 하는 경우 상황이 더욱 흥미로워집니다. 이러한 변경 사항을 트랜잭션으로 만드는 방법은 무엇입니까?

별도의 트랜잭션에서 변경 사항이 발생하면 강력한 예외 처리 및 보상이 제공되어야 하며 이는 동기식 통합의 주요 이점인 단순성을 완전히 제거합니다.

분산 트랜잭션도 생각나지만 우리 솔루션에서는 사용하지 않습니다. 안정성을 보장하기 어렵습니다.

거래의 문제에 대한 해결책으로 "사가"

마이크로 서비스의 인기가 높아짐에 따라 이에 대한 수요가 증가하고 있습니다. 사가 패턴.

이 패턴은 위의 긴 트랜잭션 문제를 완벽하게 해결하고 비즈니스 로직 측면에서 시스템 상태를 관리할 수 있는 가능성을 확장합니다. 실패한 트랜잭션 후 보상은 시스템을 원래 상태로 롤백하지 않을 수 있지만 대안을 제공합니다. 데이터 처리 경로. 또한 프로세스를 "좋은" 엔딩으로 가져오려고 할 때 성공적으로 완료된 데이터 처리 단계를 반복하지 않도록 합니다.

흥미롭게도 모놀리식 시스템에서 이 패턴은 느슨하게 결합된 하위 시스템의 통합과 관련이 있으며 긴 트랜잭션 및 해당 리소스 잠금으로 인한 부정적인 영향이 있습니다.

BPM 스타일의 비즈니스 프로세스와 관련하여 Sagas를 구현하는 것은 매우 쉬운 것으로 나타났습니다. Sagas의 개별 단계는 비즈니스 프로세스 내의 활동으로 설정할 수 있으며 비즈니스 프로세스의 지속적인 상태는 다음 중에서 결정합니다. 다른 것, Sagas의 내부 상태. 즉, 추가적인 조정 메커니즘이 필요하지 않습니다. 필요한 것은 "적어도 한 번" 전송을 보장하는 메시지 브로커입니다.

그러나 이러한 솔루션에는 자체 "가격"도 있습니다.

• 비즈니스 로직이 더욱 복잡해집니다. 보상을 해결해야 합니다.
• 모놀리식 시스템에 특히 민감할 수 있는 완전한 일관성을 포기해야 합니다.
• 아키텍처가 조금 더 복잡해지고 메시지 브로커가 추가로 필요합니다.
• 추가 모니터링 및 관리 도구가 필요할 것입니다(일반적으로 이 방법도 좋지만 시스템 서비스 품질이 향상됩니다).

모놀리식 시스템의 경우 "Sags"를 사용하는 이유가 명확하지 않습니다. 이미 브로커가 있고 프로젝트 시작 시 완전한 일관성이 희생된 마이크로 서비스 및 기타 SOA의 경우, 특히 편리한 API가 있는 경우 이 패턴을 사용하는 이점이 단점보다 훨씬 클 수 있습니다. 비즈니스 논리 수준.

마이크로서비스의 비즈니스 로직 캡슐화

우리가 마이크로서비스 실험을 시작했을 때 합리적인 질문이 생겼습니다. 도메인 데이터 지속성을 제공하는 서비스와 관련하여 도메인 비즈니스 로직을 어디에 둘 것인가?

다양한 BPMS의 아키텍처를 볼 때 비즈니스 로직을 지속성에서 분리하는 것이 합리적으로 보일 수 있습니다. 도메인 비즈니스 로직을 실행하기 위한 환경 및 컨테이너를 형성하는 플랫폼 및 도메인 독립적 마이크로 서비스 계층을 만들고 도메인 데이터 지속성을 별도의 매우 간단하고 가벼운 마이크로 서비스 계층. 이 경우 비즈니스 프로세스는 지속성 계층의 서비스를 오케스트레이션합니다.

이 접근 방식에는 매우 큰 장점이 있습니다. 플랫폼의 기능을 원하는 만큼 늘릴 수 있으며 이에 따라 플랫폼 마이크로 서비스의 해당 계층만 "뚱뚱해집니다". 모든 도메인의 비즈니스 프로세스는 플랫폼이 업데이트되는 즉시 플랫폼의 새로운 기능을 사용할 수 있는 기회를 얻습니다.

보다 자세한 연구에서는 이 접근 방식의 중요한 단점을 밝혔습니다.

• 여러 도메인의 비즈니스 로직을 한 번에 실행하는 플랫폼 서비스는 단일 실패 지점으로 큰 위험을 안고 있습니다. 비즈니스 로직을 자주 변경하면 시스템 전반의 오류로 이어지는 버그 위험이 증가합니다.
• 성능 문제: 비즈니스 로직은 좁고 느린 인터페이스를 통해 데이터와 함께 작동합니다.
  • 데이터는 다시 한 번 마샬링되고 네트워크 스택을 통해 펌핑됩니다.
  • 도메인 서비스는 서비스의 외부 API 수준에서 쿼리 매개 변수화 기능이 충분하지 않기 때문에 처리에 필요한 비즈니스 논리보다 더 많은 데이터를 반환하는 경우가 많습니다.
  • 비즈니스 로직의 여러 독립적인 부분은 처리를 위해 동일한 데이터를 반복적으로 다시 요청할 수 있습니다(데이터를 캐시하는 세션 빈을 추가하여 이 문제를 완화할 수 있지만 이는 아키텍처를 더욱 복잡하게 만들고 데이터 신선도 및 캐시 무효화 문제를 생성합니다).
• 트랜잭션 문제:
  • 플랫폼 서비스에 의해 저장된 영구 상태의 비즈니스 프로세스는 도메인 데이터와 일치하지 않으며 이 문제를 쉽게 해결할 수 있는 방법이 없습니다.
  • 트랜잭션에서 도메인 데이터 잠금 이동: 도메인 비즈니스 로직을 변경해야 하는 경우 먼저 실제 데이터의 정확성을 확인한 후 처리된 데이터에서 경쟁적 변경 가능성을 배제해야 합니다. 데이터의 외부 차단은 문제를 해결하는 데 도움이 될 수 있지만 이러한 솔루션은 추가적인 위험을 수반하고 시스템의 전반적인 안정성을 감소시킵니다.
• 업데이트 시 추가 복잡성: 경우에 따라 지속성 서비스 및 비즈니스 논리를 동기식으로 또는 엄격한 순서로 업데이트해야 합니다.

결국 도메인 데이터와 도메인 비즈니스 로직을 하나의 마이크로서비스로 캡슐화하는 기본으로 돌아가야 했습니다. 이 접근 방식은 마이크로 서비스를 시스템의 통합 구성 요소로 인식하는 것을 단순화하고 위의 문제를 일으키지 않습니다. 이것은 또한 무료가 아닙니다:

• 비즈니스 로직(특히 비즈니스 프로세스의 일부로 사용자 활동을 제공하기 위해) 및 API 플랫폼 서비스와의 상호 작용을 위해 API 표준화가 필요합니다. API 변경에 대한 보다 세심한 주의, 전방 및 후방 호환성이 필요합니다.
• 이러한 각 마이크로 서비스의 일부로 비즈니스 로직의 기능을 보장하기 위해 추가 런타임 라이브러리를 추가해야 하며, 이로 인해 이러한 라이브러리에 대한 새로운 요구 사항이 발생합니다.
• 비즈니스 로직 개발자는 라이브러리 버전을 추적해야 합니다. 마이크로서비스가 오랫동안 마무리되지 않은 경우 오래된 버전의 라이브러리가 포함될 가능성이 큽니다. 이것은 새 기능을 추가하는 데 예상치 못한 장애물이 될 수 있으며 버전 간에 호환되지 않는 변경 사항이 있는 경우 해당 서비스의 이전 비즈니스 로직을 새 버전의 라이브러리로 마이그레이션해야 할 수 있습니다.

이러한 아키텍처에는 플랫폼 서비스 계층도 존재하지만 이 계층은 더 이상 도메인 비즈니스 논리를 실행하기 위한 컨테이너를 형성하지 않고 보조 "플랫폼" 기능을 제공하는 환경만 형성합니다. 이러한 계층은 도메인 마이크로 서비스의 경량성을 유지하는 것뿐만 아니라 관리를 중앙 집중화하는 데도 필요합니다.

예를 들어 비즈니스 프로세스의 사용자 활동은 작업을 생성합니다. 그러나 작업을 수행할 때 사용자는 일반 목록에서 모든 도메인의 작업을 확인해야 합니다. 즉, 도메인 비즈니스 논리가 제거된 적절한 작업 등록 플랫폼 서비스가 있어야 합니다. 이 컨텍스트에서 비즈니스 로직의 캡슐화를 유지하는 것은 상당히 문제가 있으며 이것은 이 아키텍처의 또 다른 절충안입니다.

애플리케이션 개발자의 관점에서 비즈니스 프로세스 통합

위에서 이미 언급했듯이 애플리케이션 개발자는 우수한 개발 생산성을 기대할 수 있도록 여러 애플리케이션의 상호 작용을 구현하는 기술 및 엔지니어링 기능에서 추상화되어야 합니다.

기사를 위해 특별히 고안된 다소 어려운 통합 문제를 해결해 봅시다. 이것은 "app1", "app2", "app3"의 도메인 이름을 각각 정의하는 세 가지 응용 프로그램을 포함하는 "게임" 작업입니다.

각 애플리케이션 내에서 통합 버스를 통해 "플레이 볼"을 시작하는 비즈니스 프로세스가 시작됩니다. "Ball"이라는 이름의 메시지는 공 역할을 합니다.

게임 규칙 :

• 첫 번째 플레이어는 개시자입니다. 그는 다른 플레이어를 게임에 초대하고 게임을 시작하며 언제든지 종료할 수 있습니다.
• 다른 플레이어는 게임 참여를 선언하고 서로 및 첫 번째 플레이어와 "익숙해집니다".
• 공을 받은 후 플레이어는 다른 참여 플레이어를 선택하고 그에게 공을 패스합니다. 총 패스 수가 계산됩니다.
• 각 플레이어는 해당 플레이어가 볼을 패스할 때마다 감소하는 "에너지"를 가지고 있습니다. 에너지가 소진되면 플레이어는 은퇴를 선언하고 게임에서 제외됩니다.
• 플레이어가 혼자 남겨지면 즉시 출발을 선언합니다.
• 모든 플레이어가 제거되면 첫 번째 플레이어가 게임 종료를 선언합니다. 그가 게임을 더 일찍 떠났다면 게임을 완료하기 위해 게임을 따라야 합니다.

이 문제를 해결하기 위해 최소한의 상용구를 사용하여 Kotlin의 논리를 간결하게 설명할 수 있는 비즈니스 프로세스용 DSL을 사용하겠습니다.

app1 애플리케이션에서 첫 번째 플레이어(그는 게임의 개시자이기도 함)의 비즈니스 프로세스가 작동합니다.

클래스 InitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

비즈니스 로직을 실행하는 것 외에도 위의 코드는 다이어그램으로 시각화할 수 있는 비즈니스 프로세스의 개체 모델을 생성할 수 있습니다. 우리는 아직 비주얼라이저를 구현하지 않았기 때문에 그림을 그리는 데 시간을 할애해야 했습니다(위 코드와 다이어그램의 일관성을 개선하기 위해 게이트 사용에 관한 BPMN 표기법을 약간 단순화했습니다).

app2는 다른 플레이어의 비즈니스 프로세스를 포함합니다.

클래스 랜덤플레이어

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

도표:

app3 애플리케이션에서 우리는 약간 다른 행동을 하는 플레이어를 만들 것입니다. 다음 플레이어를 무작위로 선택하는 대신 라운드 로빈 알고리즘에 따라 행동합니다.

클래스 RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

그렇지 않으면 플레이어의 동작이 이전 동작과 다르지 않으므로 다이어그램이 변경되지 않습니다.

이제 모든 것을 실행하려면 테스트가 필요합니다. 기사를 상용구로 어지럽히지 않도록 테스트 자체의 코드만 제공하겠습니다(사실 다른 비즈니스 프로세스의 통합을 테스트하기 위해 이전에 만든 테스트 환경을 사용했습니다).

테스트게임()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

테스트를 실행하고 로그를 확인합니다.

콘솔 출력

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

이 모든 것에서 몇 가지 중요한 결론을 도출할 수 있습니다.

• 필요한 도구를 사용할 수 있는 경우 응용 프로그램 개발자는 비즈니스 논리를 벗어나지 않고 응용 프로그램 간의 통합 상호 작용을 만들 수 있습니다.
• 엔지니어링 역량이 필요한 통합 작업의 복잡성(complexity)은 프레임워크의 아키텍처에 초기에 배치되면 프레임워크 내부에 숨길 수 있습니다. 작업의 난이도(난이도)는 숨길 수 없으므로 코드의 어려운 작업에 대한 솔루션이 그에 따라 표시됩니다.
• 통합 로직을 개발할 때 모든 통합 참여자의 상태 변화에 대한 선형성 부족과 궁극적인 일관성을 고려해야 합니다. 이로 인해 외부 이벤트가 발생하는 순서에 둔감하도록 논리를 복잡하게 만들 수 있습니다. 이 예에서 플레이어는 게임 종료를 발표한 후 강제로 게임에 참여해야 합니다. 다른 플레이어는 종료에 대한 정보가 도달하고 모든 참가자가 처리할 때까지 계속해서 그에게 공을 전달합니다. 이 논리는 게임의 규칙을 따르지 않으며 선택한 아키텍처의 프레임워크 내에서 타협 솔루션입니다.

다음으로 솔루션의 다양한 미묘함, 타협 및 기타 사항에 대해 이야기하겠습니다.

하나의 대기열에 있는 모든 메시지

모든 통합 애플리케이션은 외부 브로커로 표시되는 하나의 통합 버스, 메시지용 BPMQueue 하나, 신호(이벤트)용 BPMTopic 주제 하나와 함께 작동합니다. 단일 대기열을 통해 모든 메시지를 전달하는 것은 그 자체로 타협입니다. 비즈니스 논리 수준에서 이제 시스템 구조를 변경하지 않고도 원하는 만큼 새로운 유형의 메시지를 도입할 수 있습니다. 이것은 상당한 단순화이지만 일반적인 작업의 맥락에서 우리에게 그다지 중요하지 않은 것처럼 보이는 특정 위험을 수반합니다.

그러나 여기에는 한 가지 미묘함이 있습니다. 각 응용 프로그램은 도메인 이름별로 입구의 대기열에서 "자기" 메시지를 필터링합니다. 또한 신호의 "범위"를 단일 애플리케이션으로 제한해야 하는 경우 신호에서 도메인을 지정할 수 있습니다. 이것은 버스의 대역폭을 증가시켜야 하지만 비즈니스 로직은 이제 도메인 이름으로 작동해야 합니다. 메시지 주소 지정에는 필수이고 신호에는 바람직합니다.

통합 버스의 신뢰성 보장

신뢰성은 여러 가지로 구성됩니다.

• 선택한 메시지 브로커는 아키텍처의 중요한 구성 요소이자 단일 실패 지점입니다. 충분히 내결함성이 있어야 합니다. 좋은 지원과 대규모 커뮤니티가 있는 오랜 시간 테스트를 거친 구현만 사용해야 합니다.
• 통합 애플리케이션과 물리적으로 분리되어야 하는 메시지 브로커의 고가용성을 보장해야 합니다(비즈니스 로직이 적용된 애플리케이션의 고가용성은 제공하기가 훨씬 더 어렵고 비용이 많이 듭니다).
• 브로커는 "적어도 한 번" 배송 보증을 제공할 의무가 있습니다. 이는 통합 버스의 안정적인 작동을 위한 필수 요구 사항입니다. "정확히 한 번" 수준 보장이 필요하지 않습니다. 비즈니스 프로세스는 일반적으로 메시지 또는 이벤트의 반복 도착에 민감하지 않으며 이것이 중요한 특수 작업에서는 지속적으로 사용하는 것보다 비즈니스 로직에 추가 검사를 추가하는 것이 더 쉽습니다. "비싼" "보증;
• 메시지 및 신호 전송은 비즈니스 프로세스 및 도메인 데이터의 상태 변경과 함께 공통 트랜잭션에 포함되어야 합니다. 선호하는 옵션은 패턴을 사용하는 것입니다. 트랜잭션 보낼 편지함, 하지만 데이터베이스에 추가 테이블과 릴레이가 필요합니다. JEE 애플리케이션에서 이것은 로컬 JTA 관리자를 사용하여 단순화할 수 있지만 선택한 브로커에 대한 연결은 모드에서 작동할 수 있어야 합니다. XA;
• 들어오는 메시지 및 이벤트의 핸들러는 비즈니스 프로세스의 상태를 변경하는 트랜잭션과 함께 작동해야 합니다. 이러한 트랜잭션이 롤백되면 메시지 수신도 취소되어야 합니다.
• 오류로 인해 전달되지 못한 메시지는 별도 저장소에 보관 D.L.Q. (배달 대기열). 이를 위해 우리는 이러한 메시지를 저장소에 저장하고 속성별로 인덱싱하고(빠른 그룹화 및 검색을 위해) 메시지 보기, 대상 주소로 재전송 및 메시지 삭제를 위한 API를 노출하는 별도의 플랫폼 마이크로서비스를 만들었습니다. 시스템 관리자는 웹 인터페이스를 통해 이 서비스를 사용할 수 있습니다.
• 브로커 설정에서 메시지가 DLQ에 들어갈 가능성을 줄이기 위해 배달 재시도 횟수와 배달 사이의 지연을 조정해야 합니다(최적의 매개변수를 계산하는 것은 거의 불가능하지만 경험적으로 행동하고 조정하는 동안 작업);
• DLQ 저장소는 지속적으로 모니터링되어야 하며 모니터링 시스템은 전달되지 않은 메시지가 발생할 때 시스템 관리자가 가능한 한 신속하게 대응할 수 있도록 시스템 관리자에게 알려야 합니다. 이렇게 하면 실패 또는 비즈니스 논리 오류의 "손상 영역"이 줄어듭니다.
• 통합 버스는 애플리케이션의 일시적인 부재에 둔감해야 합니다. 주제 구독은 지속 가능해야 하며 애플리케이션의 도메인 이름은 고유해야 애플리케이션이 없는 동안 다른 사람이 큐에서 메시지를 처리하려고 시도하지 않습니다.

비즈니스 로직의 스레드 안전성 보장

비즈니스 프로세스의 동일한 인스턴스는 한 번에 여러 메시지와 이벤트를 수신할 수 있으며 처리는 병렬로 시작됩니다. 동시에 애플리케이션 개발자에게는 모든 것이 단순하고 스레드로부터 안전해야 합니다.

프로세스 비즈니스 로직은 이 비즈니스 프로세스에 개별적으로 영향을 미치는 각 외부 이벤트를 처리합니다. 이러한 이벤트는 다음과 같습니다.

• 비즈니스 프로세스 인스턴스 시작
• 비즈니스 프로세스 내의 활동과 관련된 사용자 작업
• 비즈니스 프로세스 인스턴스가 등록된 메시지 또는 신호 수신
• 비즈니스 프로세스 인스턴스에 의해 설정된 타이머 만료
• API를 통한 제어 작업(예: 프로세스 중단).

이러한 각 이벤트는 비즈니스 프로세스 인스턴스의 상태를 변경할 수 있습니다. 일부 활동은 종료되고 다른 활동은 시작될 수 있으며 영구 속성의 값이 변경될 수 있습니다. 활동을 종료하면 다음 활동 중 하나 이상이 활성화될 수 있습니다. 그런 다음 다른 이벤트를 기다리지 않거나 추가 데이터가 필요하지 않은 경우 동일한 트랜잭션에서 완료할 수 있습니다. 트랜잭션을 닫기 전에 비즈니스 프로세스의 새로운 상태가 데이터베이스에 저장되어 다음 외부 이벤트를 기다립니다.

관계형 데이터베이스에 저장된 영구 비즈니스 프로세스 데이터는 SELECT FOR UPDATE를 사용할 때 매우 편리한 처리 동기화 지점입니다. 하나의 트랜잭션이 변경을 위해 베이스에서 비즈니스 프로세스의 상태를 가져오면 병렬의 다른 트랜잭션은 다른 변경에 대해 동일한 상태를 가져올 수 없으며 첫 번째 트랜잭션이 완료된 후 두 번째 트랜잭션은 이미 변경된 상태를 수신하도록 보장합니다.

DBMS 측에서 비관적 잠금을 사용하여 필요한 모든 요구 사항을 충족합니다. ACID, 실행 중인 인스턴스의 수를 늘려 비즈니스 로직으로 애플리케이션을 확장하는 기능도 유지합니다.

그러나 비관적 잠금은 교착 상태로 우리를 위협합니다. 즉, SELECT FOR UPDATE는 비즈니스 논리의 심각한 경우에 교착 상태가 발생할 경우 여전히 합리적인 시간 제한으로 제한되어야 합니다.

또 다른 문제는 비즈니스 프로세스 시작 동기화입니다. 비즈니스 프로세스 인스턴스가 없는 동안 데이터베이스에도 상태가 없으므로 설명된 방법이 작동하지 않습니다. 특정 범위에서 비즈니스 프로세스 인스턴스의 고유성을 확인하려면 프로세스 클래스 및 해당 범위와 연결된 일종의 동기화 개체가 필요합니다. 이 문제를 해결하기 위해 외부 서비스를 통해 URI 형식의 키로 지정된 임의의 리소스를 잠글 수 있는 다른 잠금 메커니즘을 사용합니다.

예제에서 InitialPlayer 비즈니스 프로세스에는 선언이 포함되어 있습니다.

uniqueConstraint = UniqueConstraints.singleton

따라서 로그에는 해당 키의 잠금을 취하고 해제하는 메시지가 포함됩니다. 다른 비즈니스 프로세스에 대해서는 이러한 메시지가 없습니다. uniqueConstraint가 설정되지 않았습니다.

지속 상태의 비즈니스 프로세스 문제

때로는 지속적인 상태를 갖는 것이 도움이 될 뿐만 아니라 실제로 개발을 방해하기도 합니다.
문제는 비즈니스 논리 및/또는 비즈니스 프로세스 모델을 변경해야 할 때 시작됩니다. 이러한 변경 사항은 비즈니스 프로세스의 이전 상태와 호환되지 않습니다. 데이터베이스에 많은 "라이브" 인스턴스가 있는 경우 호환되지 않는 변경으로 인해 jBPM을 사용할 때 종종 발생하는 많은 문제가 발생할 수 있습니다.

변화의 깊이에 따라 두 가지 방법으로 행동할 수 있습니다.

1. 기존 비즈니스 프로세스 유형과 호환되지 않는 변경을 수행하지 않도록 새 비즈니스 프로세스 유형을 생성하고 새 인스턴스를 시작할 때 이전 유형 대신 사용하십시오. 이전 인스턴스는 "이전 방식"으로 계속 작동합니다.
2. 비즈니스 로직을 업데이트할 때 비즈니스 프로세스의 지속적인 상태를 마이그레이션합니다.

첫 번째 방법은 더 간단하지만 한계와 단점이 있습니다. 예를 들면 다음과 같습니다.

• 많은 비즈니스 프로세스 모델에서 비즈니스 로직의 복제, 비즈니스 로직의 양 증가;
• 종종 새로운 비즈니스 로직으로의 즉각적인 전환이 필요합니다(거의 항상 통합 작업 측면에서).
• 개발자는 사용하지 않는 모델을 삭제할 수 있는 시점을 알 수 없습니다.

실제로 우리는 두 가지 접근 방식을 모두 사용하지만 삶을 단순화하기 위해 여러 가지 결정을 내렸습니다.

• 데이터베이스에서 비즈니스 프로세스의 지속적인 상태는 쉽게 읽고 쉽게 처리할 수 있는 형식인 JSON 형식 문자열로 저장됩니다. 이를 통해 애플리케이션 내부와 외부 모두에서 마이그레이션을 수행할 수 있습니다. 극단적인 경우에는 핸들을 사용하여 조정할 수도 있습니다(특히 디버깅 중 개발에 유용함).
• 통합 비즈니스 로직은 비즈니스 프로세스의 이름을 사용하지 않으므로 언제든지 참여 프로세스 중 하나의 구현을 새 이름(예: "InitialPlayerV2")으로 대체할 수 있습니다. 바인딩은 메시지 및 신호의 이름을 통해 발생합니다.
• 프로세스 모델에는 버전 번호가 있으며, 이 모델에 호환되지 않는 변경 사항이 있으면 증가하고 이 번호는 프로세스 인스턴스의 상태와 함께 저장됩니다.
• 프로세스의 지속 상태는 모델의 버전 번호가 변경된 경우 마이그레이션 절차가 작업할 수 있는 편리한 개체 모델로 기본에서 먼저 읽혀집니다.
• 마이그레이션 절차는 비즈니스 로직 옆에 배치되며 데이터베이스에서 복원할 때 비즈니스 프로세스의 각 인스턴스에 대해 "지연"이라고 합니다.
• 모든 프로세스 인스턴스의 상태를 신속하고 동기식으로 마이그레이션해야 하는 경우 더 많은 클래식 데이터베이스 마이그레이션 솔루션이 사용되지만 거기에서 JSON으로 작업해야 합니다.

비즈니스 프로세스를 위한 다른 프레임워크가 필요합니까?

기사에 설명된 솔루션을 통해 우리의 삶을 크게 단순화하고, 애플리케이션 개발 수준에서 해결되는 문제의 범위를 확장하고, 비즈니스 로직을 마이크로 서비스로 분리하는 아이디어를 더욱 매력적으로 만들 수 있었습니다. 이를 위해 많은 작업이 수행되었으며 비즈니스 프로세스를 위한 매우 "가벼운" 프레임워크와 다양한 응용 작업의 맥락에서 식별된 문제를 해결하기 위한 서비스 구성 요소가 만들어졌습니다. 우리는 이러한 결과를 공유하고 공통 구성 요소의 개발을 자유 라이선스에 따라 공개 액세스로 가져오고자 합니다. 약간의 노력과 시간이 필요합니다. 그러한 솔루션에 대한 수요를 이해하는 것은 우리에게 추가적인 인센티브가 될 수 있습니다. 제안된 기사에서는 프레임워크 자체의 기능에 거의 주의를 기울이지 않지만 일부는 제시된 예제에서 볼 수 있습니다. 그럼에도 불구하고 프레임워크를 게시하면 별도의 기사가 작성됩니다. 그동안 다음 질문에 답하여 약간의 피드백을 남겨주시면 감사하겠습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

비즈니스 프로세스를 위한 다른 프레임워크가 필요합니까?

• 18,8%예, 저는 오랫동안 이와 같은 것을 찾고 있었습니다.

• 12,5%귀하의 구현에 대해 더 알고 싶습니다. 유용할 수 있습니다.2

• 6,2%기존 프레임워크 중 하나를 사용하지만 교체를 고려하고 있습니다1

• 18,8%우리는 기존 프레임워크 중 하나를 사용하며 모든 것이 적합합니다3

• 18,8%프레임워크 없이 대처하기3

• 25,0%나만의 글 쓰기4

16명의 사용자가 투표했습니다. 7명의 사용자가 기권했습니다.

출처 : habr.com