PXFLOW Studio에서 Flow 만들기
Project Home에서 PXFLOW를 열고 새 Flow를 만드세요. 첫 예제에 필요한 공유 Function과 public Flow input을 사용해 Function Node를 연결하고 Validate·Save·Run 순서로 진행합니다.
현재 Component surface 경계
이 페이지의 Components dock과 Components → Installed 이미지는 계획된 prototype입니다. 현재 V1의 기존 presentation·settings wire는 호환을 위해 보존하고 production Flow reader는 exact 7-field ComponentRef, raw settings와 usage-derived partial ports만 유지한 채 저장된 Component target을 read-only unsupported로 표시합니다. original package bytes는 package artifact owner가 실제로 보존한 경우에만 exact bytes로 복구합니다. 후속 V2 Canvas는 package UI를 마운트하지 않고 host-owned component.declarative@2만 사용하며, settings는 component-declared-settings@1로 선언당 최대 8개까지 받고 host control registry가 그립니다. rich surface는 RFC-016이 소유하는 component-rich-surface-declaration@1 범위이고, bridge는 Node context 읽기와 settings 제안까지만 허용합니다. 안전한 inactive quarantine은 installer가 먼저 갖춰야 할 선행 조건입니다. exact ProjectScope data-path isolation은 구현됐지만 Project authorization과 execution-trust closure가 닫힐 때까지 production third-party Component install admission과 activation을 열지 않습니다. 현재 동작을 따라 할 때는 Function Reference Node와 public Flow input을 사용하세요. Python 예제의 px.input·px.result는 current marker이며, port의 type은 일반 parameter annotation과 px.Results annotated field가 정합니다.
Report에서 연결한 Flow를 확인할 때는 Report Workbench의 연결 Overview → Open in PXFLOW Studio를 선택합니다. 같은 Flow가 열리며 public input부터 내부 Node 연결을 거쳐 public result까지의 경로를 편집할 수 있습니다.
처음에는 세 이름만 구분하면 됩니다.
| 이름 | 쉬운 뜻 | 이 예제에서 하는 일 |
|---|---|---|
| Function | 여러 Flow에서 다시 쓰는 계산 기능 | Definitions → Functions에서 준비된 기능을 선택 |
| Component | Components dock에서 고르는 설치 기능 카드이자, V1 wire가 exact ref로 보존하는 확장 target | 현재 Canvas에서는 unsupported; install·dock 배치는 post-closure 계획 |
| Flow key | Project 안에서 이 Flow만 가리키는 고유한 이름. 나중에 Report 연결과 코드·CLI·AI 자동화가 이 이름으로 이 Flow를 찾습니다 | 이름을 입력하면 자동으로 채워지므로 그대로 두기 |
Function을 Flow에 놓으면 계산 코드를 복사하는 대신 그 Function을 가리키는 Function Reference Node가 생깁니다. 기존 V1 Component placement는 exact 7-field target을 보존하고 현재 Canvas에서는 unsupported 상태로 보여 줍니다. 새 production third-party placement는 열지 않습니다.
PXFLOW Studio UI
| 시작·이동 | UI 위치 | 이어지는 제품 |
|---|---|---|
| Flow 열기·만들기 | Project Home의 PXFLOW, .pxflow, New Flow | PXFLOW Studio Canvas |
| Report가 사용하는 Flow 열기 | Report Workbench 연결 Overview → Open in PXFLOW Studio | 같은 Flow의 Canvas와 public port |
| 계산 기능 배치 | Definitions → Functions | Canvas Node와 Node modal |
| Component 배치 · post-closure 계획 | 아래 Components dock | 향후 host-owned Component Node surface |
| Run·Result 확인 | 상단 Validate / Run, Run·Result와 Project Activity | Run 상태와 Result 영역 |
| V2 Component 상세 확인 · post-closure 계획 | Components → Installed에서 Component 배치·연결 | host-owned Node의 exact identity·Port |
| 사용자 앱 만들기 | 상단 Builder (문서명: App Builder) | Build·Preview·Deployment |
| 읽기 전용 전달 | 상단 Share → Publish / Embed | Viewer·외부 HTML |
Flow를 만들고 저장하면 Canvas에 Node와 연결이 남고, Run·Result 영역에서 계산 상태와 결과, 생성 근거를 확인할 수 있습니다.
Report의 input/result mapping은 .pxreport가 소유하며 px.Report 또는 Report Workbench에서 편집합니다. Studio는 public Flow input/result와 내부 Node 연결을 편집하고, public port를 바꿀 때 연결된 Report의 영향 범위를 함께 보여 줍니다.
입력과 저장된 결과를 읽는 뷰어
저장된 Report와 같은 Project·Flow 리비전으로 연결된 스냅샷 화면에는 공개 입력과 결과 표가 별도 뷰어로 표시됩니다. Data에서 보고서에 저장된 입력값을, Results에서 결과 값과 표 미리보기·전체 행 수·기준 보고서 저장본을 확인하세요. 긴 표는 최대 64행을 표시합니다. 입력값은 해당 Run에 사용한 입력 기록과 다를 수 있고, 결과는 보고서에 이미 반영된 값입니다.
입력·결과 뷰어는 계산을 실행하는 Node 수에 포함되지 않으며 .pxflow에 추가 저장되지 않습니다. 계산 Function은 소스 미리보기가 없어도 제목·입출력 포트·참조를 표시합니다. 포트 이름은 제목 아래에서 항상 보이고, 더블클릭하면 전체 타입과 연결을 확인할 수 있습니다. 전체 흐름은 Canvas의 Fit View, 세부 내용은 확대 또는 Results에서 확인하세요.
저장된 Flow 실행과 선택 Run 조회
실행·조회 서비스가 연결된 배포에서는 상단 **실행…**에서 Data를 열고 입력을 확인한 뒤 실행을 누릅니다. 입력 타입과 단위는 현재 열린 Flow의 저장된 리비전을 따릅니다. Data의 수정은 실행용 초안이며 Flow 문서를 다시 저장하지 않습니다. 정수·고정소수점 값은 숫자 문자열의 정밀도를 유지하고, 복합 타입은 선언에 맞는 JSON 값을 입력합니다.
접수된 Run은 Results에서 확인합니다. 접수 성공과 계산 성공은 별개이며, 계산 중에는 상태를 갱신합니다. 응답이 끊기면 같은 요청 재시도로 접수 여부를 확인하세요. 이 동작은 처음 캡처한 입력과 요청 ID를 유지합니다.
Run ID → Run 열기로 현재 Project·Flow 리비전의 이전 Run도 읽을 수 있습니다. 이전 결과를 선택해도 현재 입력 초안은 유지됩니다. 제출 당시 입력을 가져오려면 이 입력 사용을 누릅니다. 현재 초안이 다르면 다른 입력으로 실행한 결과라는 안내가 표시됩니다. 다른 리비전의 Run을 열려면 먼저 그 Run의 Flow 리비전을 열어야 합니다.
Report의 같은 Run을 Flow에서 열기는 실행 당시 Flow 리비전과 Run을 함께 엽니다. 조회 서비스가 연결되어 있으면 새 실행 기능이 활성화되지 않은 배포에서도 사용할 수 있습니다. 이 이동은 계산을 다시 제출하지 않으며, 해당 Flow와 Run을 읽을 권한은 계속 필요합니다. 서비스에 연결된 Report에서는 배포 목록에 Flow가 없어도 저장된 연결의 정확한 Flow 리비전을 열 수 있습니다. Flow 원본과 Run이 서로 다른 Project에 속해 있어도 각각의 소속을 유지합니다. 주소를 공유받은 사용자의 읽기 권한은 서버가 다시 확인합니다.
결과 목록에서 값·표·PNG를 선택합니다. 표 미리보기는 최대 50행·16열이며, 긴 내용은 일부만 표시했다는 안내와 원본 다운로드를 제공합니다. PNG를 누르면 크게 볼 수 있습니다. 이 화면의 결과 읽기 한도는 8 MiB입니다. 더 큰 결과는 SDK Run 조회를 사용하세요. 8 MiB 이하 PNG라도 8,388,608픽셀을 넘으면 자동 미리보기를 생략하고 원본 다운로드를 제공합니다. 이 픽셀 한도는 Flow 뷰어와 Report 실행 패널에 공통 적용됩니다. Run이나 화면을 바꾸면 이전 그림의 임시 표시 자원을 해제하며 저장된 원본은 지우지 않습니다. 뷰어가 화면 밖으로 나가거나 닫히면 그 뷰어의 파일 읽기도 중단합니다. 같은 결과를 보는 다른 뷰어가 남아 있으면 공유 읽기는 계속됩니다. 다시 열 때는 저장 결과를 다시 읽으며 계산을 취소하거나 새로 실행하지 않습니다.
Report connection으로 만든 Run은 계산 상태와 Report의 대기·반영·거절 상태를 따로 표시합니다. 직접 실행한 Run을 임의의 Report에 자동 반영하지 않습니다. 서비스가 연결되지 않은 배포에는 사용 불가 이유가 표시되며, 정적 스냅샷이 실행 권한을 제공하지는 않습니다.
캔버스의 저장된 결과 뷰어
Flow에 SDK로 저장한 결과 뷰어가 있으면 Flow 화면에서 표·그림을 함께 볼 수 있습니다. 뷰어의 위치와 출력 목록은 저장된 Flow를 따르고, 내용은 Data/Results에서 선택한 같은 Run을 사용합니다. 뷰어 안의 결과 목록은 해당 뷰어에 연결된 출력만 보여 줍니다. 계산 노드에서 뷰어로 이어지는 점선은 결과의 출처를 표시합니다. 계산 순서는 기존 Flow 연결을 따릅니다.
PNG를 누르면 원본을 크게 열 수 있고, 미리보기 본문을 스크롤하면 원본 다운로드도 사용할 수 있습니다. 화면 밖의 뷰어는 표시할 때 파일을 읽습니다. 다른 Run을 선택하면 모든 뷰어가 함께 전환되며, 뷰어를 보는 것만으로 계산을 다시 실행하지 않습니다.
저장 서비스가 연결된 화면에서는 상단 공개 결과 → 뷰어 추가로 뷰어를 만들 수 있습니다. 각 뷰어의 뷰어 편집을 열어 출력 목록과 X/Y 위치를 바꾸거나 복제·삭제합니다. 헤더를 드래그해 위치를 옮길 수도 있습니다. 변경 내용을 검토한 다음 변경 적용을 눌러 저장합니다. 복제·삭제는 계산을 다시 실행하거나 원본 결과 파일을 지우지 않습니다.
뷰어 편집 되돌리기 / 다시 실행은 한 번의 편집을 기준으로 동작합니다. 다른 곳에서 Flow를 수정했다면 최신 버전을 열고 다시 판단해야 합니다. 저장 응답이 끊기면 같은 요청 확인으로 저장 여부를 확인하세요. 인증 사용자 확인과 브라우저 복구 저장소가 연결된 경우, 미확정 뷰어 저장은 새로고침 후 같은 사용자·Project에서 다시 확인할 수 있습니다. 전체 편집 이력과 폼의 미저장 입력은 세션 범위입니다. SDK의 원래 Plan과 command ID로도 receipt를 재조회할 수 있습니다.
뷰어 변경을 저장하면 Flow revision이 바뀝니다. 이전 실행 결과는 실행 당시 리비전에 연결됩니다. 실행 당시 버전 열기로 해당 Run과 정확한 Flow 리비전을 다시 엽니다. 동일 Flow에서 입력 이름·타입·단위가 유지되는 동안 입력 초안은 보존됩니다. Project나 입력 계약이 달라지면 초안이 초기화되며, 접속 세션이 바뀌거나 화면을 닫아도 보존을 보장하지 않습니다. 저장된 변경은 기존 SDK의 Flow Plan/Apply 경계를 사용합니다. 실제 배포의 저장·조회·실행 서비스 연결 여부는 해당 화면의 안내에서 확인하세요.
화면으로 만들든 코드로 만들든 같은 Flow입니다
이 페이지의 각 절 끝에는 SDK/API 기술 참고 블록이 있습니다. 방금 화면에서 한 동작이 Python SDK에서는 어떤 코드인지 짝지어 두는 부분입니다. 화면만 사용할 때는 건너뛰어도 됩니다.
| 궁금한 점 | 답 |
|---|---|
| SDK로도 같은 Flow를 만들 수 있나요 | 만들 수 있습니다. px.Flow(...)로 작성한 input·Node·연결·result가 Canvas의 같은 요소가 됩니다 |
| 화면에서 만든 Flow와 코드로 만든 Flow를 함께 써도 되나요 | 같은 Project에서 함께 열립니다. 화면에서 시작한 Flow는 .pxflow가 편집 원본이고, 코드에서 시작한 Flow는 Python source가 편집 원본입니다 |
| 코드로 만들면 뭐가 좋나요 | 같은 구성을 반복해서 만들 때, 변경 내용을 코드 diff로 검토할 때, 여러 입력을 한 번에 실행할 때 유리합니다 |
편집 원본이 어느 쪽인지에 따라 저장 방법이 갈립니다. 화면에서 만든 Flow는 저장 종류가 pxflowNative이고 .pxflow를 그대로 저장합니다. 코드에서 만든 sdkLinked Flow는 Python source가 원본이므로, Studio에서 바꾼 내용을 source diff로 검토한 뒤 Apply합니다.
첫 Flow만 따라갈 때는 건너뛰세요
pxflowNative와 sdkLinked는 작성 원본을 구분하는 개발자 용어입니다. 첫 Flow는 화면 용어인 Function, Component와 Flow key만으로 만듭니다.
전체 대응 관계는 Flow 코드와 PXFLOW Studio의 관계에서 확인합니다.
첫 Flow 따라 만들기
이 예제에서는 미리 준비된 공유 Function girder_utilization · v1.0.0을 선택합니다. Function을 Girder utilization Flow에 utilization_check Function Reference Node로 배치하고, 두 public Flow input을 연결한 뒤 검증·저장·실행합니다.
1. Project Home에서 PXFLOW 열기
시작 화면의 My projects가 Project Home입니다. 첫 Flow를 둘 Project를 고르고 오른쪽 위의 PXFLOW를 선택합니다.
2. Flow 이름과 설명 입력하기
New Flow를 누르고 다음 값을 입력한 뒤 Create Flow를 선택합니다.
- 이름:
Girder utilization - 설명:
Checks utilization from span and design moment. - Flow key: 이름을 입력하면
girder_utilization_flow가 자동으로 채워집니다. 그대로 둡니다.
Create Flow를 선택하면 입력한 정보로 .pxflow Flow가 생성되고 Canvas가 열립니다.
Flow key는 Project 안에서 이 Flow만 가리키는 고유한 이름입니다. 나중에 이 Flow를 자동으로 불러 쓰는 쪽이 모두 이 이름으로 Flow를 찾습니다. 화면 이름 Girder utilization은 사람이 읽는 표시일 뿐이고, 찾을 때 쓰는 값은 Flow key입니다.
| 이 이름으로 Flow를 찾는 곳 | 실제로 쓰이는 모습 |
|---|---|
| Report에 이 Flow를 연결할 때 | Report가 girder_utilization_flow로 이 Flow를 기억합니다 |
| 코드·CLI로 실행할 때 | pxlab studio open --flow girder_utilization_flow |
| AI·MCP로 요청할 때 | "flowKey": "girder_utilization_flow" |
이름은 나중에 바꿔도 위 연결이 그대로 유지됩니다. Flow key를 바꿀 때는 이 Flow를 가리키던 Report 연결과 다른 Flow의 영향을 먼저 검토합니다.
3. 공유 Function 선택하기
Main toolbar에서 Definitions → Functions를 열고 girder_utilization · v1.0.0을 선택합니다. Function 설명이 Calculates girder utilization from span and design moment.인지 확인합니다.
4. input과 result 확인하기
Contract & usage에서 다음 계약을 확인합니다.
- input
span:float · m - input
design_moment:float · kN.m - result
utilization:float · 1
Function Reference에서는 공유 계약인 버전, input 두 개와 result 하나를 확인합니다. Component V2 settings를 component-declared-settings@1로 선언당 최대 8개까지 받고 host control registry가 그립니다.
Function을 배치하기 전에 이름·type·unit·version과 package 정보를 확인합니다.
5. Function Reference Node로 배치하기
Place Node를 누르고 현재 문서가 girder_utilization.pxflow인지 확인합니다. 이 Flow에서 사용할 Node 이름을 utilization_check로 입력한 뒤 Place on canvas를 선택합니다. Canvas에는 선택한 Function의 exact version을 가리키는 Function Reference Node가 생깁니다.
배치 미리 보기에서 같은 Function을 가리키는 utilization_check Function Reference Node와 저장될 target·Node key를 확인합니다.
Node 이름을 배치할 때 입력하는 이유
Node 이름은 한 Flow 안에서 그 Node를 가리키는 고유한 주소입니다. 연결선, Report의 결과 위치, 저장 파일과 실행 진단이 모두 이 이름으로 Node를 찾습니다. 주소는 이 이름 하나이므로 Node를 옮기거나 다른 Node를 지워도 나머지 연결이 그대로 유지됩니다.
같은 Function을 여러 번 배치하는 것도 이름으로 구분합니다. girder_resistance 하나를 uls_check와 sls_check로 두 번 놓으면 Node가 두 개 생기고, 각각 입력값을 따로 받아 결과도 따로 냅니다.
| 이때 | 이렇게 합니다 |
|---|---|
| Node를 하나만 놓고 이름을 정할 것이 마땅치 않을 때 | 미리 채워진 이름을 그대로 두고 Place on canvas |
| 같은 Function을 여러 번 놓을 때 | uls_check, sls_check처럼 쓰임이 드러나는 이름으로 바꿉니다 |
| 나중에 이름을 바꿀 때 | RenameSemanticKey가 이름과 그 이름을 가리키는 참조를 함께 바꿉니다 |
6. 호환되는 input과 result 연결하기
span과 design_moment public Flow input을 만든 뒤 각각 utilization_check.span과 utilization_check.design_moment input으로 연결합니다. 연결이 확정되기 전에 Studio가 type과 unit을 확인합니다.
7. Validate → Save → Run 순서 확인하기
- Validate를 눌러
Validated · 0 issues를 확인합니다. - Save를 눌러 저장된 Flow revision을 확인합니다.
- Run을 눌러 Flow를 실행합니다.
다음: 같은 첫 Flow의 Run·Result 화면 확인하기 →
SDK/API 기술 참고 · 위 첫 Flow를 코드로 쓰면
1~7단계에서 화면으로 만든 것과 같은 계산을 Python SDK로 쓰면 아래와 같습니다. 화면에서 입력한 Flow 이름, Node 이름과 input·result 이름이 코드에 그대로 나타납니다. 화면만 사용할 때는 읽지 않아도 됩니다.
from pipelinexlab import px
from structural_checks import girder_utilization
flow = px.Flow(
"girder_utilization_flow",
label="Girder utilization",
description="Checks utilization from span and design moment.",
)
span = flow.input("span", float, unit="m", description="Clear span.")
design_moment = flow.input(
"design_moment",
float,
unit="kN.m",
description="Factored design bending moment.",
)
utilization_check = flow.node("utilization_check", girder_utilization)
flow.connect(span, utilization_check.inputs.span)
flow.connect(design_moment, utilization_check.inputs.design_moment)
flow.result("utilization", utilization_check.results.utilization)| 화면에서 한 단계 | 같은 일을 하는 코드 |
|---|---|
| 2단계 · New Flow에서 이름과 Flow key 입력 | px.Flow("girder_utilization_flow", label=..., description=...) |
| 3단계 · Definitions → Functions에서 Function 선택 | from structural_checks import girder_utilization |
5단계 · Place Node에서 Node 이름 utilization_check 입력 | flow.node("utilization_check", girder_utilization) |
| 6단계 · 연결선 끌어 놓기 | flow.connect(span, utilization_check.inputs.span) |
| result를 Flow 밖으로 공개 | flow.result("utilization", ...) |
화면에서 만든 두 public input이 코드의 flow.input(...) 두 호출과 대응합니다.
Component로 시작하는 경우 · 계획
exact ProjectScope data-path isolation은 구현됐습니다. Project authorization과 execution-trust closure 이후에는 3단계에서 공유 Function 대신 아래 Components dock을 열어 admitted Component를 선택할 수 있습니다. 카드에서 이름, 설명, input과 result를 확인하고 Add를 누른 뒤에는 5단계와 같은 방법으로 Node 이름을 정하고 연결·검증·저장 순서를 따릅니다.
SDK/API 기술 참고 · 계획된 dock에서 고른 Component를 코드로 쓰면
바로 위에서 화면으로 하는 동작(dock에서 Component를 고르고 Canvas에 놓은 뒤 연결)을 Python SDK로 쓰면 아래와 같습니다. 화면만 사용할 때는 읽지 않아도 됩니다. 아래는 계획된 dock 흐름과 Python placement 계약의 대응이며, 현재 production Canvas는 저장된 Component target을 unsupported로 표시합니다.
| 화면에서 한 동작 | 코드에서 쓰는 것 |
|---|---|
| dock에서 Component 고르기 | 그 Component가 들어 있는 package를 import |
| Canvas에 놓고 Node 이름 정하기 | flow.node("model_view", model_viewer) |
| V2 settings | px.Settings subclass의 px.setting(...) field |
| 연결선 끌어 놓기 | flow.connect(...) |
| 결과를 Flow 밖으로 공개하기 | flow.result(...) |
아래 예제는 post-closure successor에서 admitted midas_civil package의 model_viewer Component를 배치하는 contract 예입니다. 실행 가능한 절차는 두 P0 closure를 닫은 successor에서 엽니다.
from pipelinexlab import px
from midas_civil.components import model_viewer
flow = px.Flow(
"model_review",
label="Model review",
description="Displays a structural model and exposes the selected objects.",
)
model = flow.input("model", ModelRef, description="Model to display.")
view = flow.node(
"model_view",
model_viewer,
)
flow.connect(model, view.inputs.model)
flow.result(
"selection",
view.results.selection,
description="Objects selected in the model viewer.",
)model_viewer는 future admitted resolver가 찾을 Component companion target이고 model_view는 Flow에 저장되는 Node key입니다. 현재 production Canvas에서는 기존 V1 Node가 unsupported로 표시됩니다. @px.component가 portable declaration·executor package를 자동 생성하지는 않습니다. Project 계산은 explicit key를 가진 @px.function으로 등록하고 Definitions → Functions에서 선택합니다. 배치한 Node modal에서는 Function source를 읽기 전용으로 확인합니다. @px.function을 붙인 함수와 그 안에서 호출하는 일반 Python 함수의 차이, 중간값을 화면에 내보내는 기준은 @px.function을 붙인 함수와 그냥 Python 함수에서 확인합니다.
Flow key의 SDK/API 기술 이름은 flowKey, Node 이름의 기술 이름은 nodeKey입니다.
post-closure 계획 prototype — Components dock에서 admitted Component를 골라 Canvas에 배치하는 목표 동작입니다.
화면의 주요 영역
| 영역 | 역할 |
|---|---|
| Main toolbar | Flow 전환, Project Definitions, Source map, Validate와 Run을 엽니다. |
| Canvas | Node와 연결을 배치하고 전체 계산 흐름을 확인합니다. |
| Components dock · post-closure 계획 | 향후 화면 아래의 접을 수 있는 도구 상자에서 admitted Component를 찾아 배치합니다. |
| Run·Result | 검증 상태, 실행 진행, 오류와 결과 이력을 확인합니다. |
Project Definitions는 Project 전체에서 공유하는 Function·Value·Source를 관리하는 별도 workspace입니다. 계획된 Components dock은 admitted Component를 찾아 host-owned component.declarative@2으로 배치하고, Node 상세·편집은 중앙 modal에서 엽니다. Source map은 Canvas의 Node와 연결이 Flow source의 어느 선언에서 왔는지 찾아보는 sidebar이며, Canvas를 가리지 않고 옆에 열립니다. 패널을 닫아도 Flow 내용은 그대로 유지됩니다.
계획 prototype — Source map sidebar와 Components dock을 함께 사용하는 목표 layout입니다. 현재 공유 Function 목록은 Definitions → Functions에서 확인합니다.
계산 단계를 Flow에 놓기
- 현재는 Definitions → Functions에서 공유 Function을 선택합니다. Components dock에서 설치한 Component를 검색하는 흐름은 두 closure 이후의 계획입니다. 이미 만들어 둔 다른 Flow를 통째로 쓸 때는 Flow 목록에서 External reference로 고릅니다(Subflow로 놓입니다).
- 이름, 설명, input, result와 exact target을 확인합니다. V2 settings를
component-declared-settings@1로 선언당 최대 8개까지 받고 host control registry가 그립니다. - Add to canvas를 누르거나 캔버스로 끌어 놓습니다.
- 이 Flow에서 구분할 수 있는 Node 이름을 정합니다.
배치가 끝나면 Canvas에 Node 하나가 나타나고, 왼쪽 input과 오른쪽 result를 다른 Node와 연결할 수 있습니다.
SDK/API 기술 참고 · Node와 target
방금 화면에서 한 배치를 코드와 저장 파일에서 뭐라고 부르는지 정리합니다.
앞 단계에서 두 가지를 정했습니다. 각각에 이름이 붙어 있습니다.
- target — Node가 실행할 계산. 2단계에서 고른 그 Function이나 Component입니다.
- nodeKey — 배치한 Node의 이름. 4단계에서 입력한 그 이름이고, 한 Flow 안에서 겹치지 않는 고유한 주소입니다. 코드와 저장 파일이 이 이름으로 Node를 찾습니다.
uls_check처럼 소문자와 밑줄로 씁니다. 고유해야 하는 범위는 그 Flow 하나이므로, 다른 Flow에 같은 이름의 Node를 둘 수 있습니다.
코드 한 줄이 이 둘을 그대로 담습니다.
uls_check = flow.node("uls_check", girder_resistance)
# ↑ nodeKey ↑ target고르는 곳에 따라 target과 Canvas에 생기는 Node가 달라집니다.
| 화면에서 고른 것 | 코드에서 쓰는 target | Canvas에 생기는 Node | 계산 내용을 고칠 때 |
|---|---|---|---|
| Definitions → Functions의 공유 Function | @px.function(key=...)을 붙인 함수 | Function Reference Node | Project Definitions에서 사용처와 영향을 확인한 뒤 Function source를 편집합니다 |
| Components dock의 admitted Component · post-closure 계획 | admitted package에서 import한 @px.component | 현재 unsupported; 향후 host-owned Component Node | package가 source를 소유합니다. V2는 component.declarative@2; rich editor는 RFC-016의 component-rich-surface-declaration@1 |
| Flow 목록의 다른 Flow | flow.subflow("subflow_key", imported_flow) | 읽기 전용 External reference | 원본 Flow에서 편집합니다 |
목록에 기능이 올라가는 것과 Canvas에 Node가 생기는 것은 별개입니다. 정의·import·설치는 고를 수 있는 목록을 늘리고, 배치가 Canvas Node를 만듭니다. 현재 Function은 정의·import·설치 뒤 목록에서 고르고 배치할 수 있고, third-party Component 목록과 배치는 두 closure 이후에만 엽니다. decorator를 붙이지 않은 일반 def는 위 target의 구현 안에서 호출하는 helper이며, Canvas에는 그 helper를 호출하는 target의 Node가 나타납니다.
예를 들어 girder_resistance Function을 ULS와 SLS에 각각 사용한다면 다음처럼 구분합니다.
Node의 영구 주소는 입력한 nodeKey 하나입니다. 화면 위치나 추가한 순서를 바꿔도 연결과 Report 결과 위치는 같은 Node를 계속 가리킵니다.
다른 사용자가 만든 Function package를 설치하면 현재 Function 목록에서 그 기능을 고를 수 있고, Canvas에 배치하면 현재 Flow의 Node가 됩니다. input과 result, 단위는 package가 공개한 계약대로 만들어집니다. Component V1 reader는 exact declaration과 ref를 보존하고 production install admission은 차단합니다. 현재 Flow reader는 saved target을 unsupported로 표시합니다. 후속 V2는 declaration의 input/result를 host-owned component.declarative@2으로만 투영하며 package settings schema나 전용 UI를 만들지 않습니다.
커스텀 Function의 배포는 커스텀 Function 배포와 사용, Component의 선언·현재 차단선·복구는 Component 작성과 container 계약을 참고하세요.
Node와 Subflow 열기
Canvas의 상자 대부분은 계산 한 단계인 Node입니다. 그중에는 열면 그 안에 또 Node와 연결이 들어 있는 상자가 있는데, 이런 상자를 Subflow라고 합니다. 계산 단계가 많아졌을 때 관련된 Node를 하나로 접어 두거나, 이미 만들어 둔 다른 Flow를 통째로 가져다 쓸 때 생깁니다.
| 종류 | 언제 생기나 | 더블클릭해서 열면 |
|---|---|---|
| Subflow · Group | 이 Flow의 Node 여러 개를 하나로 묶었을 때 | 그 자리에서 안의 Node를 그대로 편집합니다 |
| Subflow · External reference | 다른 Flow 하나를 이 Flow에 놓았을 때 | 읽기 전용으로 열리고, 편집은 원본 Flow에서 합니다 |
만드는 방법과 차이는 두 종류의 Subflow 구분하기에 있습니다.
- 일반 Node를 한 번 누르면 선택합니다. 더블클릭하거나 선택한 상태에서
Enter를 누르면 화면 중앙에 Node 상세·편집 modal이 열립니다. - 공유 Function을 쓰는 Node에서는 Open Function으로 Project Definitions의 해당 Function을 엽니다. Function을 바꾸기 전에는 사용 중인 모든 Node의 영향을 보여 줍니다.
- 특정 Node만 다른 계산을 사용해야 하면 Duplicate / Branch Function으로 새 Function을 만든 뒤 그 Node의 target만 바꿉니다. 현재 production Canvas에서는 Component target을
unsupported로 표시하고, 후속 V2에서도 host-owned declaration projection만 엽니다. rich editor의 동작과 entry·message shape는 RFC-016의component-rich-surface-declaration@1이 정의합니다. - Node 상자의 좌우에 붙은 작은 점이 **연결점(port)**입니다. 왼쪽은 값을 받는 input, 오른쪽은 값을 내보내는 result이고, 연결선은 한 Node의 result 연결점에서 다음 Node의 input 연결점으로 끌어 놓습니다. 연결점 위에 마우스를 올리거나 선택·연결하는 동안에는 그 연결점 이름(
span,utilization같은 값)이 Node 바깥쪽에 표시됩니다.
같은 Flow 안에서 Node 묶기
Node 둘 이상을 drag-select하고 우클릭한 뒤 Group selection을 선택하세요. 묶음 이름을 정하면 Canvas에 Subflow · Group으로 나타납니다. 더블클릭하면 구분된 배경 안에서 묶인 Node와 연결을 계속 편집할 수 있습니다.
이 Group은 현재 Flow의 editable visual membership입니다. member Node와 기존 연결, 실행 순서는 그대로 유지됩니다.
SDK/API 기술 참고 · flow.group
SDK/API 기술 이름은 FlowGroup입니다. 같은 Flow에 이미 배치한 Node handle을 flow.group(...)의 members에 넣습니다. Studio의 Group selection도 같은 membership을 저장합니다.
from pipelinexlab import px
class LoadEffectResults(px.Results):
effect: float
@px.function(
key="combine_loads",
version="1.0.0",
description="Combines the member design loads.",
)
def combine_loads(loads: float) -> LoadEffectResults:
return LoadEffectResults(effect=loads * 1.2)
class CapacityCheckResults(px.Results):
utilization: float
@px.function(
key="check_capacity",
version="1.0.0",
description="Checks the combined load effect against member capacity.",
)
def check_capacity(effect: float) -> CapacityCheckResults:
return CapacityCheckResults(utilization=effect / 500.0)
flow = px.Flow(
"member_review",
label="부재 검토",
description="하중 효과와 내력을 검토합니다.",
)
loads = flow.input("loads", float, unit="kN", description="검토 하중입니다.")
load_effect = flow.node("load_effect", combine_loads)
capacity_check = flow.node("capacity_check", check_capacity)
flow.connect(loads, load_effect.inputs.loads)
flow.connect(load_effect.results.effect, capacity_check.inputs.effect)
flow.group(
"member_check",
members=[load_effect, capacity_check],
label="Member check",
)
flow.result(
"utilization",
capacity_check.results.utilization,
description="Member capacity utilization.",
)위 코드의 member_check은 Canvas에서 Subflow · Group으로 보입니다. 편집 원본은 현재 Flow의 SDK source 또는 .pxflow이며, input/result와 Run도 현재 Flow와 member Node가 계속 소유합니다.
두 종류의 Subflow 구분하기
두 종류의 Subflow는 열리는 모습은 비슷해도 의미가 다릅니다.
| 관계 | 만드는 방법 | 더블클릭했을 때 | 편집 위치 |
|---|---|---|---|
Subflow · Group | 같은 Flow에서 Node 둘 이상을 drag-select → 우클릭 → Group selection | 현재 Flow 안의 묶음을 엶 | 구분된 배경의 nested Canvas에서 바로 편집 |
Subflow · External reference | import한 별도 Flow를 flow.subflow(...)로 배치 | 별도 Flow를 읽기 전용으로 엶 | Edit source Flow로 원본 Flow를 연 뒤 편집 |
breadcrumb와 Editable 표시로 같은 Flow 안의 Group임을 확인하고 내부 Node를 편집합니다.
Read-only 표시로 별도 Flow를 참조하고 있음을 확인합니다. 편집할 때는 Edit source Flow로 원본 Flow를 엽니다.
둘 다 breadcrumb, Back과 Escape로 상위 Flow에 돌아갑니다. Group의 계산과 Run은 현재 Flow가 계속 맡습니다. SDK/API에서는 Group selection 확인 화면의 안정적인 groupKey와 표시 label을 저장하며, 이후 label을 바꿔도 member identity는 유지됩니다. External reference는 별도 Flow의 revisionRef를 target으로 배치하고 원본 Flow에서 편집합니다.
입력과 결과 연결하기
Node의 왼쪽에는 input, 오른쪽에는 이름 있는 result가 보입니다.
- 결과 연결점에서 다음 Node의 호환되는 input으로 끌어 놓습니다.
- Studio가 type, shape와 unit 호환성을 즉시 확인합니다.
- 자동 단위 변환이 필요한 경우 변환 내용을 연결 위에 표시합니다.
- 호환되지 않으면 draft를 연결 전 상태로 유지하고 이유와 가능한 대상을 보여 줍니다.
result가 여러 개인 target에서는 정확한 result 이름을 선택하세요. Studio는 type과 unit이 호환되는 연결만 확정합니다.
왼쪽 Flow input을 Node input에 연결하고, Node result를 오른쪽 Flow result에 연결합니다. 확정된 연결은 Flow binding으로 저장됩니다.
SDK/API 기술 참고 · 연결과 binding
SDK/API에서 input에 result를 대입해 저장하는 기술 이름은 binding입니다. 아래 combine_loads와 check_capacity는 앞 예제에서 explicit key로 선언한 @px.function target입니다.
load_effect = flow.node("load_effect", combine_loads)
capacity_check = flow.node("capacity_check", check_capacity)
flow.connect(loads, load_effect.inputs.loads)
flow.connect(load_effect.results.effect, capacity_check.inputs.effect)마지막 flow.connect(...)는 Canvas의 load_effect.effect result → capacity_check.effect input 연결입니다. SDK-linked Flow는 이 binding을 Python source가 소유하므로 Canvas 변경을 source diff로 확인한 뒤 Apply합니다. PXFLOW-native Flow는 .pxflow가 연결 원본입니다. 기존 V1 settings는 저장 wire 그대로 보존하지만 후속 V2는 settings를 component-declared-settings@1로 선언당 최대 8개까지 받고 host control registry가 그립니다. px.setting 문법이나 Settings UI는 이 문서에서 미리 정의하지 않습니다.
Flow 입력 만들기
Project 또는 다른 Flow에서 값을 받을 Node input을 선택하고 Create Flow input을 사용합니다. Studio는 같은 값 종류, 단위와 설명을 가진 Flow input을 만들어 해당 Node input에 직접 연결합니다.
사용자는 다음 항목을 확인합니다.
- 외부에 보일 input 이름과 설명
- 필수 여부와 기본값
- 값 종류, 모양과 기준 단위
- AI와 외부 연결 후보에 보일지 여부
적용하면 Canvas 왼쪽에 Flow input이 나타나고 외부 문서나 다른 Flow에서 연결할 수 있습니다.
SDK/API 기술 참고 · Flow input에 저장되는 설정
Flow input은 Flow 저장 객체의 typed interface와 binding으로 저장됩니다. SDK/API에는 required, nullable, default, type, shape, canonical unit과 connection 노출 설정이 포함됩니다.
Flow 결과 만들기
외부에서 사용할 Node result를 선택하고 Create Flow result를 사용합니다. 적용하면 Canvas 오른쪽에 같은 이름의 Flow result가 나타납니다.
결과가 여러 개라면 필요한 result를 각각 공개합니다. 다른 Flow나 AI에서 필요한 결과가 resistance_summary라면 그 이름을 정확히 선택합니다.
SDK/API 기술 참고 · result를 밖에서 연결하게 할지
외부 연결 목록 노출 여부의 SDK/API 기술 이름은 connection입니다. 개발자가 connection=False로 지정한 result는 같은 Flow 안에서만 명시적으로 연결할 수 있고, 일반 외부 연결 후보에는 connection=True인 input과 result가 표시됩니다.
Node 상세 열기
Node를 더블클릭하면 target에 맞는 상세 modal이 열립니다. 모든 Node에서 화면 label, typed input·result와 현재 연결을 확인하고, 편집할 내용은 Node 종류에 따라 달라집니다.
| Node 종류 | modal에서 하는 일 |
|---|---|
| Function Reference Node | Function source와 계약을 읽기 전용으로 확인하고 Open Function으로 Definitions 이동·사용처 영향 검토 |
| Component Node | 현재 unsupported; 후속 V2는 host-owned component.declarative@2의 exact identity·Port만 확인 |
target이나 exact version을 바꾸는 작업은 새 input/result와 기존 연결의 차이를 먼저 보여 줍니다.
Function 수정은 기존 version을 보존하고 새 version 후보를 만듭니다. Definitions는 현재 version을 참조하는 모든 Node·Flow와 연결된 Report 영향을 보여 주며, 승인한 사용처를 새 version으로 함께 갱신합니다. 현재 Node만 다르게 만들려면 Duplicate / Branch Function으로 새 stable key의 Function을 만든 뒤 이 Node의 target을 교체합니다.
Studio는 호환되는 input/result 후보와 영향을 표시합니다. 사용자가 변경 내용을 확인하고 Apply하면 버전과 선택한 연결이 함께 바뀝니다.
SDK/API 기술 참고 · Node가 저장하는 항목
Node를 가리키는 key는 nodeKey, 사용하는 계산 기능 참조는 target, input 연결은 inputBindings로 저장됩니다. 기존 V1 settings member는 호환을 위해 보존합니다. 후속 V2는 settings를 component-declared-settings@1로 선언당 최대 8개까지 받고 host control registry가 그립니다. Function version은 Definitions의 영향 검토에서, 외부 Flow revision은 source Flow 변경 절차에서 갱신하며 두 경우 모두 연결 호환성을 함께 검사합니다.
Table과 반복 계산 구성하기
표 전체를 받는 Flow input에 표를 연결하면 표 하나를 typed 값 하나로 사용해 Run 한 번을 시작합니다. 숫자 한 개를 받는 scalar input에는 scalar result 또는 숫자 셀을 연결합니다.
같은 Flow를 입력값만 바꿔 여러 번 실행하려면 Run → New batch에서 실행할 행 또는 입력 목록을 고릅니다. 이렇게 만든 실행 묶음을 Batch Run이라고 하며, 그 안에서 각 실행의 진행 상태와 Result를 따로 확인합니다. Canvas 구성은 바뀌지 않고, 실행 횟수는 이 화면에서 고른 입력 세트 수만큼입니다.
연결 확인 화면에서 선택한 영역 모양과 받을 input 모양을 함께 보여 줍니다. 서로 맞지 않으면 연결하지 않고 표 전체, 열 또는 셀 중 맞는 범위를 다시 선택하도록 안내합니다.
SDK/API 기술 참고 · Table input과 Batch Run
표 전체 input의 SDK/API 기술 이름은 px.Table[RecordType]입니다. 반복 실행은 Flow 문법의 암묵적 변환이 아니라 Batch Run이 소유합니다. 각 batch item은 Flow input contract와 맞는 완전한 input set을 가지며, scalar, list[T]와 px.Table[RecordType] 중 선언된 type과 shape가 정확히 맞아야 합니다.
검증하기
Studio는 편집 중 가벼운 검사를 수행하고, Validate를 누르면 Flow 전체를 검사합니다.
- 필수 input이 모두 연결되었는지
- 값 종류, 모양과 단위가 맞는지
- 같은 Flow 안에서 Node 이름이 중복되지 않는지
- 순환 연결이 없는지
- 필요한 Function·Component·다른 Flow를 사용할 수 있는지
- 표 연결이 같은 행 이름을 사용하는지
- Run 권한이나 추가 기능이 필요한지
오류는 Node 또는 연결 위치에 표시됩니다. 오류 목록을 선택하면 해당 위치로 이동하고, 가능한 경우 Connect input, Choose compatible result, Review update처럼 다음 동작을 제공합니다.
SDK/API 기술 참고 · Validate가 검사하는 것
Validate는 required input, type, shape, unit, key 중복, 순환 연결, exact target dependency, Table row identity, Run 권한과 capability를 검사합니다. 구조화된 오류의 기술 이름은 Diagnostic입니다.
저장과 Draft
캔버스 변경은 저장 전 Draft입니다.
- Save는 현재 Flow의 새 revision(변경되지 않는 저장 상태)을 만듭니다.
- 저장할 때마다 이전 revision을 보존합니다.
- 화면 위치만 바꾼 변경과 계산 의미가 바뀐 변경을 구분합니다.
- 다른 사용자가 먼저 저장했다면 최신 상태와 차이를 보여 주고 다시 적용하도록 합니다.
저장이 완료되면 새 Flow revision과 저장 시각이 표시됩니다.
작성 상태에 따라 저장되는 곳
| 작성 상태 | Save·Apply 결과 |
|---|---|
| 화면에서 만든 PXFLOW-native Flow | Local Project는 .pxflow, Cloud Project는 managed Flow revision에 typed 변경을 저장 |
| SDK에서 연 SDK-linked Flow | 검토한 diff를 Python source에 적용한 뒤, 그 source로 Flow를 다시 만들어(materialize) 저장 |
| Node 위치·pan·zoom 같은 presentation 변경 | 계산 source와 분리된 presentation state에 저장 |
SDK-linked와 PXFLOW-native의 선택 기준, 코드 preview와 역방향 반영 범위는 Studio에서 편집한 내용을 저장하는 방법에서 확인합니다.
SDK/API 기술 참고 · revisionRef와 .pxflow
Flow의 exact revision을 가리키는 SDK/API 기술 이름은 revisionRef입니다. Local .pxflow는 한 Flow를 담은 deterministic JSON이며, Cloud Project에서도 같은 Flow 의미와 Node, input/result 이름을 유지합니다.
실행하고 결과 확인하기
검증을 통과한 Flow에서 Run을 누르고 다음 화면 순서를 확인합니다.
- 사용할 Flow revision과 입력을 확인합니다.
- 외부 프로그램이나 권한 승인이 필요하면 Run 전에 확인합니다.
- Run·Result 영역에서 Run 상태를 확인합니다.
- 진행 상태는 Node와 Run·Result 영역에 표시됩니다.
- 성공하면 이름 있는 Result와 생성 정보를 확인합니다.
Run이 시작되면 고정한 Flow revision으로 계산하고, 완료된 이름 있는 결과를 Result 영역과 Run 이력에 저장합니다.
현재 입력과 실행 결과 비교
Run 조회 서비스가 연결된 화면에서는 Data/Results와 캔버스 결과 뷰어가 같은 Run을 선택하고, 현재 입력 초안이 그 Run의 제출 입력과 같은지 표시합니다. 입력을 편집해도 기존 결과는 유지되며 새 계산은 실행 명령으로 시작합니다. 8과 8.0 같은 숫자 표기 차이는 선언된 타입의 값으로 비교합니다.
과거 Run을 열어도 초안을 자동으로 바꾸지 않습니다. 이 입력 사용으로 실행 당시 값을 가져올 수 있습니다. 제출 입력을 읽지 못하면 비교 불가 안내를 표시합니다. 같은 입력 계약의 레이아웃 저장은 초안을 유지하지만, 다른 Project나 입력 계약으로 전환하면 초기화됩니다. 브라우저 새로고침 후의 초안 복구는 아직 지원하지 않습니다.
SDK/API 기술 참고 · Run이 고정하는 것
Run은 시작할 때 고정한 Flow revisionRef와 input을 사용합니다. 저장 뒤 Canvas를 편집하면 기존 Run은 그대로 두고, 새 변경을 Save한 뒤 새 Run을 시작합니다. 성공한 Run의 저장된 결과 기술 이름은 ResultSnapshot입니다.
SDK로 만든 Flow 열기
SDK package directory에서 다음 명령을 사용할 수 있습니다.
pxlab studio open . --flow girder_review이 Flow는 SDK-linked 상태로 열립니다. Python source가 작성 원본이므로 Studio는 지원되는 시각 변경을 source-safe code action과 diff로 바꿔 먼저 보여 줍니다.
- Apply: source를 수정하고 다시 만든 Flow의 input/result, Node, exact target, 연결과 Group이 검토한 변경과 같을 때 반영합니다. 기존 V1 setting을 다룰 때만 보존된 V1 member도 비교합니다.
- Cancel: source와 화면을 모두 원래 상태로 유지합니다.
- Open source: 변경을 소유한 Python module, shared Function 또는 external Flow를 엽니다.
- 편집 가능한 PXFLOW 사본 만들기: 새 PXFLOW-native Flow로 분리해 화면에서 계속 편집합니다.
Apply 결과는 source에서 다시 만든 Flow가 사용자가 검토한 candidate Flow와 의미상 일치할 때 저장됩니다. 전체 Python 파일을 재생성하지 않는 이유와 source-safe 범위는 Studio→SDK 반영 가이드를 따릅니다.
SDK/API 기술 참고 · sdkLinked Flow
SDK/API 기술 이름은 sdkLinked입니다. Python source가 원본이고 PXFLOW Studio는 source에서 만든 같은 Flow를 표시합니다. 시각 변경은 source diff를 검토한 뒤 Apply합니다.
사용자용 앱 화면 만들기 · V2 계획
V2 제품 계획
Builder는 같은 Flow의 입력과 결과로 사용자용 앱을 구성하고 배포하는 V2 기능입니다. 제공 범위와 도입 순서는 제품 로드맵에서 확인하세요.
Studio 상단의 Builder를 선택하면 App Builder로 이동합니다. App Builder는 같은 Flow input과 result로 사용자용 화면을 구성합니다.
- Build에서 페이지와 input·result 배치를 구성합니다.
- Preview에서 Desktop·Tablet·Mobile 화면을 확인합니다.
- Deploy에서 배포할 앱 상태와 필요한 승인을 확인합니다.
전체 화면 순서와 배포 계약은 App Builder와 배포를 따릅니다.
SDK/API 기술 참고 · @px.app
SDK에서는 @px.app으로 같은 Flow input/result projection을 담은 App surface definition을 등록합니다. Canvas Node placement는 owning Flow가 소유합니다. 배포 요청의 기술 이름은 DeploymentRequest이며 검토한 App Candidate를 대상으로 합니다.
읽기 전용으로 공유하거나 웹페이지에 넣기 · V2 계획
V2 제품 계획
Share의 People & link, Publish와 Embed는 V2 공유·전달 기능입니다. 제공 범위와 도입 순서는 제품 로드맵에서 확인하세요.
V2에서는 Studio 상단의 Share에서 목적에 맞는 전달 방법을 선택합니다.
- People & link는 권한이 있는 사람에게 같은 Flow의 최신 저장 상태를 보여 줍니다.
- Publish는 선택한 Flow revision을 고정한 읽기 전용 PXFLOW Viewer를 만듭니다.
- Embed → PXFLOW View는 게시한 읽기 전용 버전을 외부 HTML에 넣습니다.
- Embed → PXFLOW App은 Active 상태의 App Deployment를 외부 HTML에 넣습니다.
자세한 절차는 PXFLOW 공유·게시·HTML 삽입을 확인하세요.
SDK/API 기술 참고 · Publication과 Deployment
읽기 전용 게시 버전의 기술 이름은 PublicationVersion, 실행 가능한 앱의 활성 배포 기술 이름은 DeploymentRevision입니다. 둘은 같은 Flow를 사용해도 읽기 전용 전달과 실행 가능한 앱 전달이라는 목적이 다릅니다.
자주 만나는 상태
| 상태 | 의미 | 다음 동작 |
|---|---|---|
| Unbound input | required input이 연결되지 않음 | Flow input 또는 이전 result 연결 |
| Type mismatch | 값의 종류나 모양이 다름 | 호환되는 input/result 선택 |
| Unit mismatch | 물리 차원이 다르거나 변환할 수 없음 | 올바른 단위의 input/result 선택 |
| Function unavailable | 선택한 Function 버전을 찾을 수 없음 | package 설치 또는 버전 검토 |
| Component dependency required | exact 7-field ref의 package를 resolve할 수 없음 | 현재 read-only unsupported; Add required package는 post-closure successor |
| Component package version mismatch | exact ref와 available release가 다름 | 현재 원본 ref/settings 보존; Install required version은 post-closure successor |
| Package information unavailable | catalog를 조회할 수 없음 | Retry 또는 Locate package |
| Unknown component | 원래 Component를 식별할 정보가 없음 | 원본 정보 복구 또는 정확한 package 직접 지정 |
| Project source required | Project가 소유한 Node의 원본을 찾을 수 없음 | Locate project source 또는 해당 Project 열기 |
| Source changed | SDK-linked Flow를 연 뒤 source가 달라짐 | 최신 source를 읽고 변경 재검토 |
| Stale result | Result 생성 뒤 입력이나 Flow가 달라짐 | 저장한 뒤 새 Run 시작 |
| Permission required | 실행이나 resource 접근 승인이 필요함 | 영향 확인 후 승인 요청 |
상태를 선택하면 현재 지원되는 Function package·source·Run 복구로 이동합니다. Component의 Add/Install action은 구현된 exact ProjectScope data-path isolation에 Project authorization과 execution-trust closure를 더한 뒤에만 활성화합니다.
다음 단계
첫 Flow의 Validate·Save·Run을 완료했다면 Run 상태와 Result가 표시되는 영역을 확인하세요.
필요할 때 보는 문서
- 처음 시작하기
- SDK와 PXFLOW Studio 연결 방식
- Component 현재 차단선·배치 계약·복구
- App Builder와 배포
- Extensions와 Integrations
- PXFLOW direct 저장 형식
소스 발췌가 없는 계산 노드
저장된 Flow가 함수 소스 발췌를 포함하지 않아도, 계산 노드에서 실제 target과 입력·출력 이름, 타입·단위를 확인할 수 있습니다. 포트 수에 맞춰 카드 높이를 확보하고 긴 본문은 카드 안에서 스크롤합니다. 노드 상세 열기는 기존 동작을 사용하며, 소스 표시 여부가 실행 권한을 바꾸지는 않습니다.
결과 뷰어는 선택한 Run의 저장 결과를 읽습니다. 입력 초안 수정·뷰어 이동·결과 조회만으로 새 계산을 시작하지 않으며, 과거 결과는 실행 당시 입력과 함께 구분합니다.
저장 응답을 확인하지 못한 뷰어 편집
뷰어 저장 뒤 서버·중계 구간에서 오류가 나면 이미 저장됐을 수 있어 결과 미확정으로 표시합니다. 같은 요청 확인으로 기존 요청의 결과를 확인하세요. 이 확인이 권한 거절을 받더라도 최초 저장이 실패했다는 뜻은 아니므로 요청을 취소하거나 새 편집으로 바꾸지 않습니다. 성공 응답을 확인하면 저장된 리비전을 열고 한 번의 Undo로 편집을 되돌릴 수 있습니다. 인증된 서버와 브라우저 저장소·Web Locks를 사용할 수 있으면 미확정 뷰어 요청을 이 브라우저에 보관합니다. 새로고침 후 같은 사용자·Project에서 같은 요청 확인을 누르세요. 자동 적용하지 않습니다. 성공은 확인했지만 열지 못했다면 저장된 버전 열기로 확정 리비전만 읽습니다. 복구된 한 편집은 Undo할 수 있습니다. 전체 편집 이력은 원래 세션에만 남습니다. 복구 범위는 기록이 남아 있는 동일 브라우저·기기입니다. 브라우저 데이터를 삭제하면 복구 기록도 함께 삭제됩니다.
Component 배치와 연결선 편집도 결과 미확정 뒤 확인이 거절되면 기존 요청을 유지합니다. 같은 요청의 성공 응답을 확인한 뒤 저장된 리비전을 엽니다. 첫 저장 요청 자체가 명확히 거절된 경우에는 기존 오류 안내와 취소를 사용할 수 있습니다. 인증된 서버와 브라우저 복구 저장소가 연결된 경우 Component 배치·연결선도 새로고침 후 원래 요청을 확인할 수 있습니다. 다른 탭의 미확정 변경을 덮어쓰지 않으며, 기록을 읽지 못하면 저장된 Flow 요청 확인으로 다시 확인하세요. 복구 자체가 변경을 자동 적용하지는 않습니다.
저장 성공을 확인했지만 Flow를 다시 열지 못한 경우에는 저장된 Flow 다시 열기를 사용하세요. Component 배치와 연결선 편집 모두 이미 저장된 리비전만 읽으며 편집을 다시 제출하지 않습니다. 안내 닫기는 오류 안내만 닫으며 저장된 변경을 취소하지 않습니다. 아직 읽지 못한 성공 기록은 브라우저에 남아 다시 열 때 확인할 수 있습니다.
정식 서버에서 Flow 편집을 사용할 때는 operation credential과 대상 Workspace membership 외에 Project 권한도 필요합니다. 현재 head 조회에는 읽기 권한, Plan 생성과 Apply에는 읽기·쓰기 권한이 모두 필요합니다. 권한을 회수하면 이전 요청의 receipt 확인도 거절될 수 있습니다. 이 거절은 이전 저장이 실패했다는 뜻이 아니므로 미확정 요청은 그대로 보관해야 합니다.
인증 사용자 확인을 지원하는 서버에 연결하면 편집 연결은 확인된 사용자로 고정됩니다. 그 뒤 다른 계정으로 바뀌면 기존 연결의 편집·요청 확인이 거절됩니다. 기존 미확정 요청을 다른 계정의 새 편집으로 다시 제출하지 마세요. 사용자 확인 정보가 없는 서버에서는 기존 명시적 편집을 유지하지만 사용자별 영속 복구를 제공하지 않습니다. 현재 브라우저 영속 복구는 뷰어 편집·Component 배치·연결선에 연결됐으며 Report 저장 복구는 별도입니다.
Organization을 유지하며 결과 열기
Organization이 지정된 웹 호스트는 Home·Flow·Report 링크에 해당 선택값을 유지합니다. Report에서 같은 Run을 새 탭으로 열거나 주소를 새로고침해도 그 Organization에서 조회합니다. 주소의 선택값은 접근 권한을 부여하지 않으며, 서버에서 현재 소속과 Project 권한을 확인합니다. 잘못되거나 중복된 선택값은 다른 Organization으로 자동 전환하지 않고 거절합니다.
이 연결은 정식 소스에 반영된 상태입니다. 실제 로그인·계정 선택 화면과 서비스 배포는 아직 연결 중이므로 모든 공개 배포에서 사용할 수 있다고 보장하지 않습니다. SDK의 Run·Flow target과 저장 문서 형식은 변경되지 않았습니다.
정식 웹의 로그인 세션과 실행 요청
정식 BFF의 /v1/runtime에 연결한 웹 배포에서는 Home·Flow·Report가 cookie 세션과 CSRF 확인을 거쳐 요청합니다. 화면은 로그인 쿠키와 CSRF 정보를 사용합니다. 로그인 상태가 만료되면 요청이 거절되며 계산·저장 요청을 자동으로 다시 보내지 않습니다. 재시도할 때는 기존 Run과 저장 상태를 먼저 확인하세요. 실제 계정 서비스·로그인 화면·개인 Project 탐색은 배포별 연결이 필요합니다. 현재 이용하는 서비스에서 각 기능의 제공 상태를 확인하세요.







