본문으로 건너뛰기
Developers
가이드

업무 프로세스

App 시작과 동작, 사람 태스크 폼, 프로세스 템플릿을 타입 있는 SDK 계약으로 Nexia Business Process에 노출합니다.

App 업무를 Nexia BPMN 런타임에서 실행합니다. App은 수행할 동작과 핸들러를 제공하고, Core는 태스크 실행 순서와 대기·재개를 관리합니다.

작업 동작 하나부터 연결

  1. App Resource와 권한 검사가 있는 업무 동작을 준비합니다. AppDescriptorContribution에 ProcessWorkActionDescriptor를 공개하고 topic, 입력, 출력을 명시합니다.
  2. ProcessWorkActionHandler를 구현한 뒤 App 서비스 프로바이더에서 ProcessWorkActionRegistrar에 팩토리를 등록합니다. App/action 쌍은 descriptor와 같아야 합니다. 쓰기 전에 복원된 사용자·테넌트·조직, 레코드 상태, 재시도 식별자를 검사하세요.
  3. App Process 템플릿 또는 테넌트 BPMN에서 이 동작을 참조합니다. 정의를 저장하고 발행한 뒤 실행하세요. App에서 시작할 때는 start binding을 공개하고 ProcessStarter::start(BoundProcessStart)를 호출합니다. 완전한 시작·호출·반환 형식은 업무 프로세스 계약에 있습니다.
  4. 인스턴스 하나를 시작해 업무 처리와 태스크 결과를 확인합니다. 같은 작업이 재전달되어도 효과는 반복되지 않아야 합니다.

아래는 packages/people/src/Descriptors/PeopleOnboardingProcessDescriptors.php의 실제 descriptor 팩토리입니다. $actionKey에는 People이 등록한 동작 키가 들어갑니다.

코드 예시
PHP
private static function service(string $actionKey): ProcessWorkActionDescriptor
{
    return new ProcessWorkActionDescriptor(
        kind: 'serviceTask',
        appKey: 'people',
        actionKey: $actionKey,
        labelKey: 'people.process_actions.'.$actionKey.'.label',
        topic: 'people.'.$actionKey,
    );
}

대응하는 핸들러 팩토리는 packages/people/src/PeopleCoreServiceProvider.php에서 등록합니다. 자신의 App에는 이 연결 방식을 적용하고 People 모델을 가져오지 마세요. 외부 효과를 전달하는 내구성 경계는 이벤트와 비동기 작업 처리하기를 따릅니다.

결과 확인

운영 가능한 App의 발행된 정의가 권한 있는 사용자에게 시작되고, 핸들러가 지정한 동작과 범위만 처리해야 합니다. 출력은 descriptor와 일치해야 하며 바인딩 누락, 권한 회수, 오래된 레코드 버전은 쓰기 전에 거절되어야 합니다. 업무 프로세스 계약의 conformance helper를 App 테스트하기 절차로 실행합니다.

폼·판단·대기 추가

필요한 기능App 연결점
사용자 입력ProcessUserTaskFormDescriptor와 ProcessUserTaskSubmissionHandler; ProcessUserTaskSubmissionRegistrar로 등록
App에서 시작ProcessStartBindingDescriptor, BoundProcessStart, ProcessStarter
재사용 BPMNProcessTemplateDescriptor; 선택하면 저장 전 편집기 문서를 구성
판단 결과 형식버전이 있는 decision descriptor와 출력 계약
내부 결재ProcessApprovalTaskConfiguration과 전자 결재 연결
서명 완료 대기전자 서명에서 수락한 정확한 요청에 대한 내구성 있는 대기

폼의 allowedResourceActions는 요청 가능한 동작을 제한합니다. 실제 App API도 각 동작을 검사해야 합니다. 상관관계와 멱등성은 대기 중인 태스크 및 수락한 요청에 묶으세요. 다른 대상의 이벤트로 대기를 완료해서는 안 됩니다.

버전과 발행

템플릿 선택은 저장이 아닙니다. 정의 저장·발행 과정이 BPMN과 연결된 decision 배포를 수행합니다. 외부 태스크는 work action의 App·키·topic·버전을 고정하며, 실행기는 descriptor가 일치하지 않으면 처리를 거부합니다. source_template_keys를 전달해 저장하면 Core는 준비한 템플릿 중 정의 키와 일치하는 항목의 source_template_key·source_template_version을 기록합니다. 기본 설치도 이 출처를 기록하며 같은 정의의 후속 버전은 이를 보존합니다. 선택만으로 저장되지는 않고, 다른 템플릿의 일부를 복사했다고 하나의 출처가 자동 지정되는 것도 아닙니다. App을 갱신할 때 이미 공개한 동작 버전의 의미를 유지하세요. 기존 기능은 먼저 사용 중단 상태로 전환한 후 제거합니다.

작업 스키마, 대기·재시도 결과, 사용자 태스크 전달, decision 출력, 결재·서명 대기의 정확한 계약은 업무 프로세스 계약에 모았습니다. 레코드를 보드로 표시하는 목적이라면 Resource Projection을 사용하세요.

설정을 바꾸며 구매 흐름 따라가기

아래는 설치된 Supply Planning·Procurement 구현을 사용하는 확장 예입니다. 기본 제공 절차는 구매 요청 초안 생성까지입니다. 뒤의 전자결재 단계는 작성자가 추가합니다. 앞의 Workshop 노트 보관 예제에 결재 기능이 자동으로 생기는 것은 아닙니다.

구매 제안에서 Process 시작
  → [선택] 사람이 구매 요청 입력 검토
  → 구매 요청 초안 생성
  → [작성자가 추가] 구매 요청 제출
      ├ 결재 불필요: App 직접 처리 → not_required
      └ 결재 필수: [필요 시 결재선 준비] → 상신·대기 → 결재 결과

1. App에서 공개하는 것

packages/supply-planning/src/Contribution/PurchaseProposalProcess.php는 시작 바인딩 supply-planning.purchase_proposal, 작업 purchase_proposal.create_request, 입력 폼 supply-planning.purchase_proposal.inputs, 기본 설치 템플릿을 제공합니다. 기본 절차는 자동 작업만 있으므로 담당 그룹 없이 실행할 수 있습니다.

Procurement는 별도로 purchase_request.submit_approval 작업을 제공합니다. ProcurementProcessDescriptors의 resourceInputs·targetResourceInput은 후속 작업이 생성된 구매 요청을 대상으로 삼게 하고, approvalTask의 supportsLinePreparation: true는 결재선 준비를 허용합니다. ProcurementApprovalWorkActionHandler는 기존 SubmitProcurementApproval을 호출합니다. 결재 필수 여부는 handler에 복제하지 않고 App의 공통 업무 처리 경로에서 판단합니다.

2. 관리자가 준비하는 것

  1. 전자결재 → 결재 양식에서 procurement.purchase_request.submit에 연결된 업무 양식을 만들고, 지정 결재선 또는 상신자 선택 방식을 정해 게시합니다.
  2. 전자결재 → 업무별 결재 설정에서 Procurement의 구매 요청 제출을 기업 공통 또는 해당 법인 범위로 설정합니다. 필수 여부와 결재선은 서로 다른 설정입니다. 자세한 설정 순서는 전자 결재를 참고하세요.
  3. 업무 프로세스 정의에서 기본 구매 제안 절차를 편집합니다. 해당 법인에서 사용할 양식이 법인 전용이면 정의도 그 법인 범위로 작성합니다. 기업 공통 정의에는 특정 법인 전용 양식·결재선을 정적으로 연결하지 않습니다.

3. 입력과 다음 업무 연결

자동 경로를 유지하려면 입력 검토 Task를 추가하지 않습니다. 사람이 확인해야 하면 초안 생성 앞에 공개된 입력 폼을 넣고 실제 담당자를 지정합니다. 번호·요청일·재고 관리 여부의 초기값을 연결하고, editableFields로 수정할 필드를 정합니다. 읽기 전용 필드는 서버에서도 변경을 거부합니다. 입력 Task를 완료했다고 전자결재가 승인되는 것은 아닙니다.

초안 생성 작업의 result_reference를 variables.purchase_request에 연결합니다. 기본 템플릿에는 이 매핑이 있습니다. 뒤에 구매 요청 제출 작업을 추가하고 그 작업의 resource_ref 입력에 이 참조를 연결한 뒤 호환되는 게시 양식을 선택합니다. 최초 Process 대상은 구매 제안으로 유지되고, 제출 작업의 대상만 구매 요청이 됩니다. status가 rejected이거나 참조가 없으면 제출로 보내지 않도록 결과 분기를 구성하세요.

4. 설정별 실행 결과

설정실행 중 일어나는 일확인할 결과
입력 검토 없음기본값·자동 매핑으로 생성 작업 실행구매 요청 초안과 result_reference
입력 검토 있음입력 완료 전에는 생성하지 않음입력 대기 후 생성, 수정 허용 필드만 반영
결재 불필요같은 제출 작업이 App의 직접 처리 경로 실행결재 case 없이 approval_outcome=not_required
결재 필수 + 해석 가능한 지정 결재선handler가 상신하고 같은 작업에서 결과 대기case 식별자, 결재 진행 상태
결재 필수 + 상신자 선택, 아직 결재선 없음실행자에게 결재선 준비 Task를 제공하고 원래 작업 재개준비 완료 후 별도의 실제 전자결재 대기
필요한 양식·권한·준비 담당자가 없음발행 또는 실행을 거부하고 문제 표시결재를 생략하거나 다음 작업으로 성공 처리하지 않음

제출 작업 뒤에는 approval_outcome으로 분기합니다. approved와 not_required만 업무의 성공 경로로 보내고 rejected·recalled·cancelled는 회사의 후속 절차로 연결합니다. 결재 결과를 App에 반영하는 처리와 Process 대기 해제는 중복 재처리에도 안전해야 합니다.

5. 기본안 수정과 업데이트

installByDefault: true는 사용 가능한 법인에 기본 절차를 설치하도록 하는 선언입니다. 설치 시 의존성을 확인하고, 발행 조건이 부족하면 편집 가능한 초안으로 남깁니다. 담당자·결재 구성을 임의로 만들어 채우지 않습니다. 회사가 수정하거나 중단한 정의를 반복 설치로 덮어쓰거나 다시 활성화하지 않습니다.

새 App 템플릿 버전은 업데이트 가능 상태로 표시합니다. 관리자가 검토해 새 정의 버전을 저장·발행하며, 기존 인스턴스는 시작한 정의 버전으로 계속 실행합니다. 템플릿 출처 기록과 Work Action 실행 계약의 버전 고정은 별개입니다.

원본 위치: docs/developers/content/ko/platform-extensions/process.md