같은 connection을 여러 scalar case로 실행하기
용도
client.run_batch(...)는 client = px.Client(...)로 만든 Client 객체의 메서드입니다. 같은 Report connection을 여러 scalar input 묶음에 반복 적용하며, 각 case는 고유 key로 구분되는 Flow Run 하나가 되며, 이 Run들이 Batch 아래에 모입니다.
이 문법은 인증된 product.report.run_batch 제품 경로를 통해 구현됩니다. 제품 경로는 RunReportFlowBatch 응용 명령에 전체 Batch를 한 번 제출하고 fixed 21-Tool catalog는 늘리지 않습니다.
화면에서 보이는 것
Report Workbench의 Batch Run과 같은 작업입니다. 실행 전에 case 수와 input mapping을 확인하고, Project Activity에서 case별 진행·성공·실패·취소 상태를 확인합니다.
문법
client.run_batch(
connection,
cases,
*,
case_key,
inputs,
result_mapping=None,
)예제
아래 strength_cases는 Report 작성 파일에서 report.connect_flow(...)으로 만든 뒤 report.save()로 저장한 connection입니다. span과 demand는 이 connection의 saved input mapping에 연결하지 않고 각 case가 제공합니다. result table mapping은 case_check_to_results라는 stable mapping key로 미리 저장합니다.
from pipelinexlab import px
from project_flows.girder_check import flow
from project_reports.girder_review import strength_cases
client = px.Client(workspace="engineering", project="bridge_project")
cases = [
{"case_key": "uls_01", "span": 12.0, "demand": 860.0},
{"case_key": "uls_02", "span": 12.0, "demand": 920.0},
{"case_key": "sls_01", "span": 12.0, "demand": 540.0},
]
batch = client.run_batch(
strength_cases,
cases,
case_key="case_key",
inputs={
"span": flow.inputs.span,
"demand": flow.inputs.demand,
},
result_mapping="case_check_to_results",
)매개변수
| 이름 | 설명 |
|---|---|
connection | 각 case에 반복 적용할 저장된 connection |
cases | case마다 scalar input 묶음을 가진 목록 |
case_key | 각 case의 고유값이 들어 있는 field 이름 |
inputs | case field key → 아직 saved mapping이 없는 Flow public input port의 명시적 mapping |
result_mapping | case 결과를 합칠 저장된 reportTableResult mapping key. 생략하면 Result를 Run별로만 보존 |
반환
BatchRun 객체를 반환합니다. batch.batch_key, batch.created, batch.cases(각 원소는 case_key와 Run)를 읽고, 각 Run의 상태와 Result를 case key로 확인합니다. BatchRun은 client.run_batch(...)의 output-only 값이므로 직접 생성할 수 없습니다. 각 child Run의 lifecycle 메서드는 Batch를 만든 원래 Client가 열려 있어야 합니다.
계산 성공과 Report 반영 완료는 별개이며, 각 case의 run.refresh().projection으로 반영 상태를 확인합니다. 반영 후 상태 기록이 중단됐다면 Runtime 재시작 때 기존 영수증을 대조해 그 case가 반영한 revision을 복구합니다. 다른 case나 새 Batch가 이후에 반영됐어도 현재 Report를 이전 revision으로 되돌리거나 계산을 다시 제출하지 않습니다. 기존 방식으로 저장한 영수증도 같은 Report·Batch의 요청과 정확히 일치해야 복구합니다. 반영 대상·Batch 상태·generation 기록이 누락돼도 검증된 영수증이 있으면 그 결과를 복구합니다. 영수증이 없고 현재 반영 조건도 확인할 수 없으면 reportProjectionSuperseded로 거절하며, Run의 계산 결과와 현재 Report는 유지합니다.
저장된 Report를 다시 열었다면 case 입력 mapping은 불러온 connection의 handle을 사용합니다. 예를 들어 inputs={"span": connection.inputs.span}으로 지정합니다. 원래 작성 객체의 flow.inputs.span을 다른 connection에 그대로 전달하지 않습니다. 다른 Project의 Flow 주소를 보존한 Report도 이 방식으로 Batch 실행할 수 있습니다. Flow는 정의가 저장된 Project에서 읽고, Run과 Report 반영은 Report 소유 Project에 기록합니다. 로컬 SDK 실행·재시작과 서버의 PostgreSQL/HTTP 반영·복구 경계를 검증했습니다. 서버 검사는 Worker 프로토콜 fixture를 사용하며, 정식 웹 계정/BFF 연결은 후속 범위입니다.
서버 HTTP 제출은 Report Project의 run.execute와 artifact.read를 확인합니다. result_mapping을 지정하면 artifact.write도 필요합니다. 다른 Project의 Flow를 참조하면 그 Project의 읽기·실행 권한도 필요하며, 같은 Batch 재요청에도 현재 권한을 다시 확인합니다. HTTP의 cases는 현재 inline 배열을 사용합니다. 서버 파일 경로를 전달하는 localFile 형식은 PX_CAPABILITY_DENIED (capability: hostFilesystem)로 거절합니다. 로컬 SDK의 임시 case 파일 처리와는 별개이며, Web 파일 업로드는 후속 기능입니다.
규칙
- N개 case는 N개의 Flow Run을 만듭니다.
- 모든 case는
case_keyfield를 가지며 그 값은 Batch 안에서 중복되지 않아야 합니다. inputs가 지정한 Flow port에는 같은 connection의 saved input mapping이 없어야 합니다. 두 source가 같은 port에 값을 제공하면 Batch를 시작하지 않습니다.result_mapping은 exact connection revision과mappingGeneration에 고정된 Table result mapping만 선택합니다.- Runtime은 Project 실행 한도 안에서 case Run을 병렬로 처리합니다.
batchKey는 exact Report connection, 정렬한 case 내용,case_key,inputs,result_mapping의 RFC 8785 canonical bytes에서 파생됩니다. childrunKey와commandId는(batchKey, caseKey)에서 파생되므로 같은 내용을 다시 제출하면 같은 Batch와 child를 반환합니다.- 한 case라도 제출 전에 거부되면 child Run, Batch generation, case-current 행을 하나도 기록하지 않습니다.
- 완료 순서가 case key나 Result 표시 순서를 바꾸지 않습니다.
list[T]또는px.Table[RecordType]을 Flow input 하나에 전달하면 목록·표 전체를 받는 Run 하나이며 Batch와 구분합니다.- 실패하거나 취소된 case를 개별 Run 단위로 확인하고 재시도할 수 있습니다.
- Batch 결과는 completion order가 아니라 stable
case_key, result field mapping과 target row key로 합칩니다.