테마
등록부터 전송까지 업무 추적
하나의 workflow ID로 제품 등록 → BOM → PCF 또는 계약 협상 → 별도 데이터 전송을 추적합니다. 각 단계는 기존 도구로 준비하고 소유자가 원래 검토 화면에서 따로 승인합니다. workflow 생성이나 이전 단계 승인은 다음 단계 승인이 아닙니다.
이 가이드는 정식 등록·승인 기반 제조 업무 다음에 사용합니다. 접속 서버의 tools/list에 다섯 workflow 도구가 있는지 확인하세요. 실행 가능한 개발 환경과 필요한 schema·제공자 설정이 준비돼 있어야 하며 운영 MCP·AI A2A 차단은 유지됩니다.
첫 검토 전에 전체 권한 동의
| template | 첫 검토를 준비하기 전에 필요한 scope |
|---|---|
provider_product_lifecycle | workflows:read, workflows:write, products:register, bom:write, pcf:write + 등록 검토 준비의 data:updates |
consumer_contract_transfer | workflows:read, workflows:write, contracts:execute, contracts:dispatch |
원래 source 조회나 자료 준비에는 해당 도구의 추가 읽기·자료 scope도 필요합니다. 모든 workflow 도구는 현재 조직 소유자 전용이며 같은 조직·그룹·소유자·client·grant·resource에 결합됩니다. read와 write는 독립적이고 metadata 권한은 업무 권한을 대체하지 않습니다.
기존 프로그램의 요청 허용 목록이 부족하면 새 프로그램 등록·연결 설정 교체를 먼저 진행합니다. 전체 template scope로 재동의한 현재 grant에서 첫 원래 검토를 새로 준비하세요. 이전 grant의 검토를 새 연결로 자동 이전하거나 붙일 수 없습니다. 뒤늦게 access_denied를 받으면 새 grant에 결합된 원래 검토를 다시 준비하고 별도로 승인합니다. 기존 외부 효과가 있는 업무를 새 키로 다시 실행하지 말고 소유자에게 인계하세요.
예제의 call은 도구 응답 structuredContent.result를 반환하는 클라이언트 함수입니다. ID·digest·키를 응답에서 그대로 사용합니다. 아래 다운로드는 합성 입력의 실행 순서를 담은 모듈이며 자격 증명·자동 승인·자동 단계 반복은 포함하지 않습니다.
제공자: 등록 → BOM → PCF
제공자 등록 → BOM → PCF
- 전체 권한 동의
metadata·등록·BOM·PCF 권한에 동의한 현재 연결에서 첫 검토를 준비합니다.
- 등록 검토와 업무 생성
원래 등록 검토를 연결하고 소유자가 정상 웹에서 별도로 승인합니다.
- 등록 한 동작씩 실행
서버 nextAction의 정확한 단일 동작을 선택하고 원래 영수증과 최종 로컬 게시를 확인합니다.
- BOM 별도 검토
등록 완료 출력에 맞는 BOM을 준비·연결하고 따로 승인한 뒤 한 동작씩 게시합니다.
- PCF 실제 미리보기
BOM 완료 뒤 실제 PCF preview의 digest로 새 검토를 준비·연결합니다. 숫자 BOM revision으로 대체하지 않습니다.
- PCF 별도 승인·게시
소유자가 PCF를 따로 승인하고 각 동작을 선택합니다. 불확실 결과는 원래 기록으로 조사 인계하고 취소 시 외부 효과를 보존합니다.
js
// 동의가 끝난 현재 연결에서 등록 가이드의 실제 draft·정책으로 준비합니다.
const registrationInput = {
draftId: selectedDraftId,
idempotencyKey: crypto.randomUUID(), // 이 검토의 응답 유실 시 같은 키 유지
policies: [{ accessPolicyId: selectedAccessPolicyId,
contractPolicyId: selectedContractPolicyId, edcVersion: "jupiter" }],
};
const first = await call("infirium_create_registration_review_plan", registrationInput);
let workflow = await call("infirium_create_workflow", {
createKey: crypto.randomUUID(),
template: "provider_product_lifecycle",
reviewId: first.id,
});
// workflow.nextAction.kind === "review"
// nextAction.reviewPath를 현재 언어 경로에 붙여 사용자에게 보여줍니다.
// 정상 웹에서 원래 소유자가 승인한 뒤:
workflow = await call("infirium_get_workflow", { workflowId: workflow.workflowId });
if (workflow.nextAction.kind === "execute_step") {
const { kind, ...exactAction } = workflow.nextAction;
workflow = await call("infirium_execute_workflow_step", exactAction);
// 같은 exactAction 재생은 원래 완료 사실만 반환하고 다음 동작을 실행하지 않습니다.
const replay = await call("infirium_execute_workflow_step", exactAction);
}등록의 여러 provider 단계와 최종 로컬 게시마다 현재 nextAction을 읽고 사용자가 선택한 한 동작만 호출합니다. stages의 등록이 completed:true이고 다음 동작이 BOM의 attach_review일 때 원래 BOM 도구로 현재 부모·BOM revision·자식 수량/단위를 준비합니다. 완료 등록의 output.productId, output.assetId, output.publicationId와 실제 source 결합을 서버가 확인합니다. 자식·수량·정책을 AI가 추측하지 않습니다.
js
const bom = await call("infirium_prepare_bom_revision", {
operation: "bom_revision",
createKey: crypto.randomUUID(),
parentAssetId: registeredAssetId, // 완료 등록의 실제 output.assetId
expectedBomRevision: currentBomRevision, // 원래 BOM 조회의 현재 값
children: reviewedChildren, // 사용자가 확인한 자식·수량·단위
});
const { kind, ...attachment } = workflow.nextAction; // attach_review인지 먼저 확인
workflow = await call("infirium_attach_workflow_review", {
...attachment, reviewId: bom.reviewId,
});
// 원래 BOM 검토 페이지에서 별도 승인 → get → 단일 execute를 명시적으로 선택합니다.PCF의 기대 BOM revision은 실제 미리보기에서 받기
BOM의 숫자 business revision을 PCF의 expectedBomRevision으로 변환하지 마세요. PCF 미리보기는 현재 graph·소유권·BOM head·자식 pin을 검사해 불투명한 digest를 계산합니다. 그 응답 값을 그대로 준비 입력에 넣습니다.
PTI에 최초 PCF를 만들 때의 흐름입니다. initialDeclaration은 사용자가 확인한 grouped v9 선언이며 pcfCalculationInputs의 단위·계수·기간·자식 입력도 호출자가 준비해야 합니다. 합계나 임의 fingerprint를 제출하지 않습니다.
js
const previewInput = {
parentAssetId: registeredAssetId,
expectedParentRevision: currentParentUpdatedAt,
initialDeclaration: reviewedInitialDeclaration,
pcfCalculationInputs: reviewedCalculationInputs,
};
const preview = await call("infirium_preview_pcf_initial_calculation", previewInput);
const pcf = await call("infirium_prepare_pcf_initial_calculation", {
...previewInput,
operation: "pcf_initial_calculation",
createKey: crypto.randomUUID(),
expectedBomRevision: preview.expectedBomRevision, // 원래 digest를 변경 없이 보존
});
// workflow.nextAction가 PCF attach_review일 때만 연결하고 원래 PCF 화면에서 별도 승인합니다.이미 PCF가 있는 제품은 infirium_preview_pcf_calculation → infirium_prepare_pcf_calculation_commit을 사용합니다. 해당 schema의 실제 계산 입력과 부모 revision을 확인하고 미리보기의 expectedBomRevision을 그대로 전달합니다. BOM 변경 뒤에는 미리보기를 새로 실행하고 새 검토를 준비해야 합니다.
소비자: 계약 협상 → 별도 전송
제공자 업무에서 게시된 asset 식별자를 사람이 확인해 소비자 담당자에게 전달합니다. 소비자는 자기 조직의 별도 연결·권한·workflow를 사용합니다. 제공자 grant로 소비자 계약을 실행하지 않습니다. infirium_discover_contract_offers로 조회한 제안 중 하나를 선택하고, 조회의 discoveryId와 정확한 정책을 계약 검토에 전달하세요. 서버가 조회 당시 정책·자산·유형 선언을 대조해 검토에 보존하며, 계약 체결은 별도 소유자 승인과 실제 협상이 필요합니다. 조회 기록 없이 직접 제안한 정책은 계속 user_proposed입니다.
소비자 계약 협상 → 별도 전송
- 사람의 조직 간 인계
제공자가 게시한 asset 식별자를 확인해 소비자에게 전달합니다. 소비자는 자기 조직의 별도 연결을 사용합니다.
- 전체 권한·협상 준비
metadata·계약 권한 동의 뒤 선택 asset·상대·정책으로 원래 협상 검토와 consumer workflow를 만듭니다.
- 협상 별도 승인·실행
소유자가 원래 EDC 화면에서 승인한 협상 한 동작만 명시적으로 실행합니다.
- 실제 FINALIZED 확인
observe_original일 때 원래 EDC 상태를 명시적으로 관측합니다. workflow get은 제공자를 조회하지 않습니다.
- 전송 별도 검토·승인
완료된 flow·asset·상대·정책과 결합된 전송 검토를 새로 준비·연결하고 별도로 승인합니다.
- 전송 명시적 실행
단일 전송을 실행하고 원래 영수증을 확인합니다. 불확실하면 소유자에게 인계하며 A2A Task Cancel과 업무 취소를 구분합니다.
js
const negotiationInput = {
operation: "consumer_negotiation",
createKey: crypto.randomUUID(),
partnerId: selectedSavedPartnerId,
assetId: selectedPublishedAssetId,
discoveryId: selectedObservation.discoveryId,
policy: selectedObservation.offers[selectedOfferIndex].policy, // 사람이 선택한 실제 조회 제안
usecaseType: "passport",
};
const negotiation = await call("infirium_prepare_edc_execution", negotiationInput);
let workflow = await call("infirium_create_workflow", {
createKey: crypto.randomUUID(),
template: "consumer_contract_transfer",
reviewId: negotiation.id,
});
// 원래 EDC 화면에서 검토·승인 후 get → execute_step 한 번.
// observe_original이면 infirium_get_edc_execution_job({reviewId: workflow.nextAction.reviewId})로
// 원래 검토의 실행 상태를 명시적으로 관측합니다.
// workflow get 자체는 provider GET을 호출하지 않습니다.
// 협상의 실제 FINALIZED와 완료 출력 flowId·asset·상대·정책을 확인한 뒤:
const transferInput = {
operation: "consumer_transfer",
createKey: crypto.randomUUID(),
flowId: finalizedNegotiationOutput.flowId, // 완료 협상의 실제 output
};
const transfer = await call("infirium_prepare_edc_execution", transferInput);
if (workflow.nextAction.kind === "attach_review" && workflow.nextAction.stageKey === "transfer") {
const { kind, ...attachment } = workflow.nextAction;
workflow = await call("infirium_attach_workflow_review", {
...attachment, reviewId: transfer.id,
});
}
// 전송도 원래 EDC 검토에서 별도로 승인하고 한 동작만 실행합니다.negotiationInput은 operation:"consumer_negotiation"과 실제 선택 asset·provider·정책이며 transferInput은 operation:"consumer_transfer"와 FINALIZED 출력의 실제 flowId입니다. 정확한 필드는 접속 서버의 원래 EDC schema를 사용합니다. 별도 승인 없이 전송을 자동 준비·실행하지 않습니다.
화면·재개·취소
소유자는 AI 연결 설정의 복합 업무 또는 /[lang]/program/workflows/:id에서 실제 3/2단계, 승인 대기·차단 이유·다음 동작을 확인합니다. 원래 승인 링크를 열어 검토하며 workflow 전체를 일괄 승인하는 버튼은 없습니다. 권한이 없는 단계는 원래 review ID·출력·링크를 숨깁니다.

모바일 진행 화면

nextAction.kind | 사용자가 할 일 |
|---|---|
review | 현재 언어를 붙인 원래 reviewPath를 열어 정상 소유자 승인 |
execute_step | kind만 빼고 나머지 필드를 그대로 한 번 실행 |
attach_review | 선행 완료 뒤 원래 도구로 준비한 현재 결합의 검토 연결 |
observe_original | 원래 도메인의 상태 도구를 명시적으로 호출 |
needs_reconciliation | 원래 journal을 소유자에게 인계, 새 키 재전송 금지 |
request_scope | 부족 scope를 확인하고 재동의·새 결합 검토 준비 |
none | 완료·취소 또는 metadata 후속 동작 없음. 실제 상태도 함께 확인 |
get은 로컬 원래 journal만 읽고 provider 요청을 보내지 않습니다. accepted receipt는 이미 수락된 사실입니다. 로컬 게시만 누락돼 execute_step이 반환되면 그 정확한 동작의 명시적 실행이 로컬 게시만 복구하고 추가 POST를 보내지 않습니다. accepted 협상이 기존 flow를 가지지만 FINALIZED가 아니면 observe_original을 반환합니다. in-flight·unknown은 시간 경과·pending·404만으로 재시도 가능해지지 않습니다.
js
workflow = await call("infirium_cancel_workflow", { workflowId: workflow.workflowId });취소는 후속 dispatch와 로컬 게시를 원래 단건 도구에서도 막습니다. 이미 admission된 외부 효과와 영수증은 남으며 원격 undo는 수행하지 않습니다. 원래 source를 읽을 수 없어 취소 응답이 unobserved일 수 있고 이후 엄격 조회가 unavailable일 수도 있습니다. 이를 성공이나 외부 효과 없음으로 표시하지 않습니다. 원래 검토의 교체는 이전 검토가 만료/거절·attempt 0·외부 효과 없음인 경우에만 새로 준비·승인한 검토로 명시적으로 요청합니다.
A2A의 CancelTask는 로컬 task 전달 취소입니다. workflow 취소에는 위 도구가 필요합니다. 중단된 대화에서 재개할 때는 같은 workflow ID로 조회하고 반환된 다음 동작을 사람이 선택합니다. A2A task 완료나 browser 관측 통계가 게시·계약·전송의 권위 있는 완료 기록을 대신하지 않습니다.

