Build File Transfer Into Your Product.
애플리케이션에 API와 SDK로 INNORIX 파일 전송 기능을 추가하세요.
기존 UI와 사용자 경험은 그대로 유지하면서, 파일 전송은 INNORIX가 백그라운드에서 처리합니다.
Python
이미 등록된 두 장비 사이에서, Python 애플리케이션이 API를 호출해 1:1 전송을 생성·모니터링·제어하는 코드를 단계별로 만듭니다.
장비 등록은 끝난 상태(소스·대상 두 장비가 장비 목록에 표시됨)를 전제로 합니다. 엔드포인트의 정확한 스키마는 항상 Swagger 문서를 기준으로 확인하세요.
공통 준비
모든 요청에서 재사용할 세션과 인증 헤더를 먼저 구성합니다.
Base URL과 세션 설정
requests.Session으로 공통 설정을 한 번만 지정해 재사용합니다.
로그인으로 토큰 발급
계정으로 로그인해 액세스 토큰을 받습니다. 응답의 data.user.accessToken을 이후 요청에 사용합니다.
인증 헤더 구성
발급받은 토큰과 워크스페이스 ID를 세션 기본 헤더에 넣으면, 이후 호출마다 헤더를 반복 지정할 필요가 없습니다.
토큰이 만료되면 POST /api/auth/refresh-token(헤더 X-Refresh-Token) 또는 GET /api/auth/get-token으로 새 토큰을 받아 다시 설정하세요.
1:1 전송 만들기
소스 장비의 파일을 대상 장비로 곧바로 보내는 핵심 흐름입니다.
소스·대상 장비 확인
GET /api/device로 장비 목록을 조회해 보낼 장비(source)와 받을 장비(target)의 deviceId를 확인합니다.
연결 상태 확인
전송 전에 소스·대상 두 장비가 모두 온라인인지 확인하면 실패를 줄일 수 있습니다.
소스 경로 탐색
보낼 파일 경로를 코드에서 이미 안다면 건너뜁니다. 동적으로 찾아야 하면 소스 장비의 경로를 탐색합니다.
대상 경로 지정
대상 저장 경로는 대상 장비 기준의 절대 경로를 평문 문자열로 그대로 지정합니다.
Windows 경로는 역슬래시(\) 대신 슬래시(/)로 통일하는 것이 안전합니다.
전송 생성
소스/대상 deviceId, 보낼 파일 경로, 대상 저장 경로(targetPath)로 전송을 만듭니다. 응답의 monitorId는 이후 제어·모니터링에 쓰이므로 저장합니다.
요청 본문 필드: sourceId(보내는 장비), targetId(받는 장비), targetPath(대상 장비의 저장 경로), sourceItem(보낼 파일/폴더 목록 — 폴더 경로를 넣으면 하위 내용이 함께 전송).
전송 상태 확인
monitorId로 진행 상태를 주기적으로 폴링합니다. 완료/실패 상태가 될 때까지 대기합니다.
완료 후 상세 결과는 GET /api/transfer-history/{monitorId}/detail?idType=monitor, 파일 단위 결과는 GET /api/transfer-history/{monitorId}/get-files?idType=monitor로 조회합니다.
상태 문자열(
completed등)의 정확한 값은 환경에 따라 다를 수 있으니, 실제 응답을 로그로 확인한 뒤 종료 조건을 확정하세요.
전송 제어
진행 중인 전송을 monitorId로 제어합니다.
일시중지 · 재개 · 취소
세 동작 모두 PATCH 요청이며 본문이 없습니다.
action에는 pause(일시중지), resume(재개), cancel(취소) 중 하나를 전달합니다.
실패 파일 재시도
전송이 일부 실패했을 때 실패한 파일만 다시 시도합니다.
전체 예제
로그인부터 전송 생성·상태 폴링까지 묶은 최소 실행 예제입니다. 실제 통합 시 토큰 갱신·에러 처리·재시도를 상황에 맞게 보강하세요.
자동화
정해진 시간에 반복 실행되는 예약 전송은 1회성 manualTransfer 대신 자동화(automation) 엔드포인트로 만듭니다. 즉시 전송과 필드 구조가 다르므로 아래 차이부터 확인하세요.
| 항목 | 즉시 전송 (manualTransfer) | 스케줄 전송 (automation) |
|---|---|---|
| 소스·대상 필드 | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (객체 배열) | ["...", "..."] (문자열 배열) |
| 실행 | 즉시 1회 | schedule에 따라 반복 |
스케줄 정보 구성
실행 주기를 정의합니다. hour·minute로 실행 시각을, timezone으로 기준 시간대를, startDate·endDate로 유효 기간을 지정합니다.
type은 day(매일), hour·minute는 실행 시각(예: 09, 30), timezone은 기준 시간대(예: Asia/Seoul), startDate·endDate는 ISO 8601 UTC 형식(예: 2026-01-01T00:00:00.000Z)입니다.
자동화 생성
스케줄과 전송 상세(details)를 담아 자동화를 만듭니다. 응답의 automationId로 이후 수정·삭제·제어합니다.
사용 예:
자동화 이름 자동 생성
이름을 직접 정하지 않으려면 서버가 이름을 생성해 줍니다.
자동화 일시중지 · 재개
pause 값으로 자동화를 멈추거나 다시 시작합니다.
자동화 수정 · 삭제
스케줄이나 전송 상세를 바꾸거나 자동화를 제거합니다.
자동화의 진행률·상태는 GET /api/automation/{automationId}/details로 조회합니다.
자주 겪는 문제
| 증상 | 원인 · 해결 |
|---|---|
401 Unauthorized | 토큰 만료 또는 헤더 누락. refresh-token으로 갱신 후 set_auth() 재호출. |
| 전송이 시작되지 않음 | 소스/대상 장비가 오프라인. connectivity로 두 장비 온라인 여부 확인. |
| 파일이 엉뚱한 위치에 저장됨 | targetPath가 대상 장비 기준 절대 경로인지 확인. |
| 소스 파일을 못 찾음 | sourceItem 경로가 소스 장비 기준 절대 경로가 아님. fileSearchV3로 실제 경로 확인. |
| 일부 파일만 실패 | retry-failed-files로 실패 파일만 재시도. |
개발 리소스 및 예제
전송 연동에 필요한 코드 예제와 문서는 INNORIX GitHub에서, 전체 엔드포인트 명세는 Swagger 문서에서 확인할 수 있습니다.
Node.js
이미 등록된 두 장비 사이에서, Node.js 애플리케이션이 API를 호출해 1:1 전송을 생성·모니터링·제어하는 코드를 단계별로 만듭니다.
장비 등록은 끝난 상태(소스·대상 두 장비가 장비 목록에 표시됨)를 전제로 합니다. 엔드포인트의 정확한 스키마는 항상 Swagger 문서를 기준으로 확인하세요.
Node.js 18 이상이면 내장 fetch를 그대로 사용합니다(별도 설치 불필요).
공통 준비
모든 요청에서 재사용할 상수와 인증 헤더를 먼저 구성합니다.
Base URL과 상수 설정
Base URL·워크스페이스 ID와, 로그인 후 채워질 토큰 변수를 선언합니다.
로그인으로 토큰 발급
계정으로 로그인해 액세스 토큰을 받습니다. 응답의 data.user.accessToken을 이후 요청에 사용합니다.
인증 헤더 구성
토큰과 워크스페이스 ID를 담은 헤더를 함수로 만들어 이후 호출에서 재사용합니다.
토큰이 만료되면 POST /api/auth/refresh-token(헤더 X-Refresh-Token) 또는 GET /api/auth/get-token으로 새 토큰을 받아 다시 설정하세요.
1:1 전송 만들기
소스 장비의 파일을 대상 장비로 곧바로 보내는 핵심 흐름입니다.
소스·대상 장비 확인
GET /api/device로 장비 목록을 조회해 보낼 장비(source)와 받을 장비(target)의 deviceId를 확인합니다.
연결 상태 확인
전송 전에 소스·대상 두 장비가 모두 온라인인지 확인하면 실패를 줄일 수 있습니다.
소스 경로 탐색
보낼 파일 경로를 코드에서 이미 안다면 건너뜁니다. 동적으로 찾아야 하면 소스 장비의 경로를 탐색합니다.
대상 경로 지정
대상 저장 경로는 대상 장비 기준의 절대 경로를 평문 문자열로 그대로 지정합니다.
Windows 경로는 역슬래시(\) 대신 슬래시(/)로 통일하는 것이 안전합니다.
전송 생성
소스/대상 deviceId, 보낼 파일 경로, 대상 저장 경로(targetPath)로 전송을 만듭니다. 응답의 monitorId는 이후 제어·모니터링에 쓰이므로 저장합니다.
요청 본문 필드: sourceId(보내는 장비), targetId(받는 장비), targetPath(대상 장비의 저장 경로), sourceItem(보낼 파일/폴더 목록 — 폴더 경로를 넣으면 하위 내용이 함께 전송).
전송 상태 확인
monitorId로 진행 상태를 주기적으로 폴링합니다. 완료/실패 상태가 될 때까지 대기합니다.
완료 후 상세 결과는 GET /api/transfer-history/{monitorId}/detail?idType=monitor, 파일 단위 결과는 GET /api/transfer-history/{monitorId}/get-files?idType=monitor로 조회합니다.
상태 문자열(
completed등)의 정확한 값은 환경에 따라 다를 수 있으니, 실제 응답을 로그로 확인한 뒤 종료 조건을 확정하세요.
전송 제어
진행 중인 전송을 monitorId로 제어합니다.
일시중지 · 재개 · 취소
세 동작 모두 PATCH 요청이며 본문이 없습니다.
action에는 pause(일시중지), resume(재개), cancel(취소) 중 하나를 전달합니다.
실패 파일 재시도
전송이 일부 실패했을 때 실패한 파일만 다시 시도합니다.
전체 예제
로그인부터 전송 생성·상태 폴링까지 묶은 최소 실행 예제입니다. 실제 통합 시 토큰 갱신·에러 처리·재시도를 상황에 맞게 보강하세요.
자동화
정해진 시간에 반복 실행되는 예약 전송은 1회성 manualTransfer 대신 자동화(automation) 엔드포인트로 만듭니다. 즉시 전송과 필드 구조가 다르므로 아래 차이부터 확인하세요.
| 항목 | 즉시 전송 (manualTransfer) | 스케줄 전송 (automation) |
|---|---|---|
| 소스·대상 필드 | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (객체 배열) | ["...", "..."] (문자열 배열) |
| 실행 | 즉시 1회 | schedule에 따라 반복 |
스케줄 정보 구성
실행 주기를 정의합니다. hour·minute로 실행 시각을, timezone으로 기준 시간대를, startDate·endDate로 유효 기간을 지정합니다.
type은 day(매일), hour·minute는 실행 시각(예: 09, 30), timezone은 기준 시간대(예: Asia/Seoul), startDate·endDate는 ISO 8601 UTC 형식(예: 2026-01-01T00:00:00.000Z)입니다.
자동화 생성
스케줄과 전송 상세(details)를 담아 자동화를 만듭니다. 응답의 automationId로 이후 수정·삭제·제어합니다.
사용 예:
자동화 이름 자동 생성
이름을 직접 정하지 않으려면 서버가 이름을 생성해 줍니다.
자동화 일시중지 · 재개
pause 값으로 자동화를 멈추거나 다시 시작합니다.
자동화 수정 · 삭제
스케줄이나 전송 상세를 바꾸거나 자동화를 제거합니다.
자동화의 진행률·상태는 GET /api/automation/{automationId}/details로 조회합니다.
자주 겪는 문제
| 증상 | 원인 · 해결 |
|---|---|
401 Unauthorized | 토큰 만료 또는 헤더 누락. refresh-token으로 갱신 후 accessToken 재설정. |
| 전송이 시작되지 않음 | 소스/대상 장비가 오프라인. connectivity로 두 장비 온라인 여부 확인. |
| 파일이 엉뚱한 위치에 저장됨 | targetPath가 대상 장비 기준 절대 경로인지 확인. |
| 소스 파일을 못 찾음 | sourceItem 경로가 소스 장비 기준 절대 경로가 아님. fileSearchV3로 실제 경로 확인. |
| 일부 파일만 실패 | retry-failed-files로 실패 파일만 재시도. |
개발 리소스 및 예제
전송 연동에 필요한 코드 예제와 문서는 INNORIX GitHub에서, 전체 엔드포인트 명세는 Swagger 문서에서 확인할 수 있습니다.
Java
이미 등록된 두 장비 사이에서, Java 애플리케이션이 API를 호출해 1:1 전송을 생성·모니터링·제어하는 코드를 단계별로 만듭니다.
장비 등록은 끝난 상태(소스·대상 두 장비가 장비 목록에 표시됨)를 전제로 합니다. 엔드포인트의 정확한 스키마는 항상 Swagger 문서를 기준으로 확인하세요.
Java 11+ 의 내장 HttpClient(java.net.http)를 사용하고, JSON 처리는 Jackson을 사용합니다(Maven 의존성).
공통 준비
모든 요청에서 재사용할 클라이언트와 인증 헤더를 먼저 구성합니다. 이후 각 단계의 메서드는 이 ExacoolaClient 클래스에 속합니다.
Base URL과 클라이언트 설정
HttpClient와 Jackson ObjectMapper를 한 번만 만들어 재사용합니다.
로그인으로 토큰 발급
계정으로 로그인해 액세스 토큰을 받습니다. 응답의 data.user.accessToken을 이후 요청에 사용합니다.
인증 헤더 구성
토큰과 워크스페이스 ID가 담긴 요청 빌더를 만드는 헬퍼입니다. 이후 모든 호출에서 재사용합니다.
토큰이 만료되면 POST /api/auth/refresh-token(헤더 X-Refresh-Token) 또는 GET /api/auth/get-token으로 새 토큰을 받아 다시 설정하세요.
1:1 전송 만들기
소스 장비의 파일을 대상 장비로 곧바로 보내는 핵심 흐름입니다.
소스·대상 장비 확인
GET /api/device로 장비 목록을 조회해 보낼 장비(source)와 받을 장비(target)의 deviceId를 확인합니다.
연결 상태 확인
전송 전에 소스·대상 두 장비가 모두 온라인인지 확인하면 실패를 줄일 수 있습니다.
소스 경로 탐색
보낼 파일 경로를 코드에서 이미 안다면 건너뜁니다. 동적으로 찾아야 하면 소스 장비의 경로를 탐색합니다.
대상 경로 지정
대상 저장 경로는 대상 장비 기준의 절대 경로를 평문 문자열로 그대로 지정합니다.
Windows 경로는 역슬래시(\) 대신 슬래시(/)로 통일하는 것이 안전합니다.
전송 생성
소스/대상 deviceId, 보낼 파일 경로, 대상 저장 경로(targetPath)로 전송을 만듭니다. 응답의 monitorId는 이후 제어·모니터링에 쓰이므로 저장합니다.
요청 본문 필드: sourceId(보내는 장비), targetId(받는 장비), targetPath(대상 장비의 저장 경로), sourceItem(보낼 파일/폴더 목록 — 폴더 경로를 넣으면 하위 내용이 함께 전송).
전송 상태 확인
monitorId로 진행 상태를 주기적으로 폴링합니다. 완료/실패 상태가 될 때까지 대기합니다.
완료 후 상세 결과는 GET /api/transfer-history/{monitorId}/detail?idType=monitor, 파일 단위 결과는 GET /api/transfer-history/{monitorId}/get-files?idType=monitor로 조회합니다.
상태 문자열(
completed등)의 정확한 값은 환경에 따라 다를 수 있으니, 실제 응답을 로그로 확인한 뒤 종료 조건을 확정하세요.
전송 제어
진행 중인 전송을 monitorId로 제어합니다.
일시중지 · 재개 · 취소
세 동작 모두 PATCH 요청이며 본문이 없습니다.
action에는 pause(일시중지), resume(재개), cancel(취소) 중 하나를 전달합니다.
실패 파일 재시도
전송이 일부 실패했을 때 실패한 파일만 다시 시도합니다.
전체 예제
로그인부터 전송 생성·상태 폴링까지 묶은 최소 실행 예제입니다. 실제 통합 시 토큰 갱신·에러 처리·재시도를 상황에 맞게 보강하세요.
자동화
정해진 시간에 반복 실행되는 예약 전송은 1회성 manualTransfer 대신 자동화(automation) 엔드포인트로 만듭니다. 즉시 전송과 필드 구조가 다르므로 아래 차이부터 확인하세요.
| 항목 | 즉시 전송 (manualTransfer) | 스케줄 전송 (automation) |
|---|---|---|
| 소스·대상 필드 | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (객체 배열) | ["...", "..."] (문자열 배열) |
| 실행 | 즉시 1회 | schedule에 따라 반복 |
스케줄 정보 구성
실행 주기를 정의합니다. hour·minute로 실행 시각을, timezone으로 기준 시간대를, startDate·endDate로 유효 기간을 지정합니다.
type은 day(매일), hour·minute는 실행 시각(예: 09, 30), timezone은 기준 시간대(예: Asia/Seoul), startDate·endDate는 ISO 8601 UTC 형식(예: 2026-01-01T00:00:00.000Z)입니다.
자동화 생성
스케줄과 전송 상세(details)를 담아 자동화를 만듭니다. 응답의 automationId로 이후 수정·삭제·제어합니다.
사용 예:
자동화 이름 자동 생성
이름을 직접 정하지 않으려면 서버가 이름을 생성해 줍니다.
자동화 일시중지 · 재개
pause 값으로 자동화를 멈추거나 다시 시작합니다.
자동화 수정 · 삭제
스케줄이나 전송 상세를 바꾸거나 자동화를 제거합니다.
자동화의 진행률·상태는 GET /api/automation/{automationId}/details로 조회합니다.
자주 겪는 문제
| 증상 | 원인 · 해결 |
|---|---|
401 Unauthorized | 토큰 만료 또는 헤더 누락. refresh-token으로 갱신 후 accessToken 재설정. |
| 전송이 시작되지 않음 | 소스/대상 장비가 오프라인. connectivity로 두 장비 온라인 여부 확인. |
| 파일이 엉뚱한 위치에 저장됨 | targetPath가 대상 장비 기준 절대 경로인지 확인. |
| 소스 파일을 못 찾음 | sourceItem 경로가 소스 장비 기준 절대 경로가 아님. fileSearchV3로 실제 경로 확인. |
| 일부 파일만 실패 | retry-failed-files로 실패 파일만 재시도. |
개발 리소스 및 예제
전송 연동에 필요한 코드 예제와 문서는 INNORIX GitHub에서, 전체 엔드포인트 명세는 Swagger 문서에서 확인할 수 있습니다.
C#
이미 등록된 두 장비 사이에서, C#/.NET 애플리케이션이 API를 호출해 1:1 전송을 생성·모니터링·제어하는 코드를 단계별로 만듭니다.
장비 등록은 끝난 상태(소스·대상 두 장비가 장비 목록에 표시됨)를 전제로 합니다. 엔드포인트의 정확한 스키마는 항상 Swagger 문서를 기준으로 확인하세요.
.NET 8 기준이며 HttpClient와 내장 System.Net.Http.Json을 사용합니다. PatchAsJsonAsync는 .NET 7 이상에서 제공됩니다.
공통 준비
모든 요청에서 재사용할 클라이언트와 인증 헤더를 먼저 구성합니다. 이후 각 단계의 메서드는 이 ExacoolaClient 클래스에 속합니다.
Base URL과 클라이언트 설정
HttpClient를 BaseAddress와 함께 한 번만 만들어 재사용합니다.
로그인으로 토큰 발급
계정으로 로그인해 액세스 토큰을 받습니다. 응답의 data.user.accessToken을 이후 요청에 사용합니다.
인증 헤더 구성
토큰과 워크스페이스 ID를 HttpClient 기본 헤더에 넣으면, 이후 호출마다 헤더를 반복 지정할 필요가 없습니다.
토큰이 만료되면 POST /api/auth/refresh-token(헤더 X-Refresh-Token) 또는 GET /api/auth/get-token으로 새 토큰을 받아 다시 설정하세요.
1:1 전송 만들기
소스 장비의 파일을 대상 장비로 곧바로 보내는 핵심 흐름입니다.
소스·대상 장비 확인
GET /api/device로 장비 목록을 조회해 보낼 장비(source)와 받을 장비(target)의 deviceId를 확인합니다.
연결 상태 확인
전송 전에 소스·대상 두 장비가 모두 온라인인지 확인하면 실패를 줄일 수 있습니다.
소스 경로 탐색
보낼 파일 경로를 코드에서 이미 안다면 건너뜁니다. 동적으로 찾아야 하면 소스 장비의 경로를 탐색합니다.
대상 경로 지정
대상 저장 경로는 대상 장비 기준의 절대 경로를 평문 문자열로 그대로 지정합니다.
Windows 경로는 역슬래시(\) 대신 슬래시(/)로 통일하는 것이 안전합니다.
전송 생성
소스/대상 deviceId, 보낼 파일 경로, 대상 저장 경로(targetPath)로 전송을 만듭니다. 응답의 monitorId는 이후 제어·모니터링에 쓰이므로 저장합니다.
요청 본문 필드: sourceId(보내는 장비), targetId(받는 장비), targetPath(대상 장비의 저장 경로), sourceItem(보낼 파일/폴더 목록 — 폴더 경로를 넣으면 하위 내용이 함께 전송).
전송 상태 확인
monitorId로 진행 상태를 주기적으로 폴링합니다. 완료/실패 상태가 될 때까지 대기합니다.
완료 후 상세 결과는 GET /api/transfer-history/{monitorId}/detail?idType=monitor, 파일 단위 결과는 GET /api/transfer-history/{monitorId}/get-files?idType=monitor로 조회합니다.
상태 문자열(
completed등)의 정확한 값은 환경에 따라 다를 수 있으니, 실제 응답을 로그로 확인한 뒤 종료 조건을 확정하세요.
전송 제어
진행 중인 전송을 monitorId로 제어합니다.
일시중지 · 재개 · 취소
세 동작 모두 PATCH 요청이며 본문이 없습니다.
action에는 pause(일시중지), resume(재개), cancel(취소) 중 하나를 전달합니다.
실패 파일 재시도
전송이 일부 실패했을 때 실패한 파일만 다시 시도합니다.
전체 예제
로그인부터 전송 생성·상태 폴링까지 묶은 최소 실행 예제입니다. 실제 통합 시 토큰 갱신·에러 처리·재시도를 상황에 맞게 보강하세요.
자동화
정해진 시간에 반복 실행되는 예약 전송은 1회성 manualTransfer 대신 자동화(automation) 엔드포인트로 만듭니다. 즉시 전송과 필드 구조가 다르므로 아래 차이부터 확인하세요.
| 항목 | 즉시 전송 (manualTransfer) | 스케줄 전송 (automation) |
|---|---|---|
| 소스·대상 필드 | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (객체 배열) | ["...", "..."] (문자열 배열) |
| 실행 | 즉시 1회 | schedule에 따라 반복 |
스케줄 정보 구성
실행 주기를 정의합니다. hour·minute로 실행 시각을, timezone으로 기준 시간대를, startDate·endDate로 유효 기간을 지정합니다.
type은 day(매일), hour·minute는 실행 시각(예: 09, 30), timezone은 기준 시간대(예: Asia/Seoul), startDate·endDate는 ISO 8601 UTC 형식(예: 2026-01-01T00:00:00.000Z)입니다.
자동화 생성
스케줄과 전송 상세(details)를 담아 자동화를 만듭니다. 응답의 automationId로 이후 수정·삭제·제어합니다.
사용 예:
자동화 이름 자동 생성
이름을 직접 정하지 않으려면 서버가 이름을 생성해 줍니다.
자동화 일시중지 · 재개
pause 값으로 자동화를 멈추거나 다시 시작합니다.
자동화 수정 · 삭제
스케줄이나 전송 상세를 바꾸거나 자동화를 제거합니다.
자동화의 진행률·상태는 GET /api/automation/{automationId}/details로 조회합니다.
자주 겪는 문제
| 증상 | 원인 · 해결 |
|---|---|
401 Unauthorized | 토큰 만료 또는 헤더 누락. refresh-token으로 갱신 후 SetAuth() 재호출. |
| 전송이 시작되지 않음 | 소스/대상 장비가 오프라인. connectivity로 두 장비 온라인 여부 확인. |
| 파일이 엉뚱한 위치에 저장됨 | targetPath가 대상 장비 기준 절대 경로인지 확인. |
| 소스 파일을 못 찾음 | sourceItem 경로가 소스 장비 기준 절대 경로가 아님. fileSearchV3로 실제 경로 확인. |
| 일부 파일만 실패 | retry-failed-files로 실패 파일만 재시도. |
개발 리소스 및 예제
전송 연동에 필요한 코드 예제와 문서는 INNORIX GitHub에서, 전체 엔드포인트 명세는 Swagger 문서에서 확인할 수 있습니다.
curl
이미 등록된 두 장비 사이에서, curl로 API를 호출해 1:1 전송을 생성·모니터링·제어하는 방법을 단계별로 정리합니다.
장비 등록은 끝난 상태(소스·대상 두 장비가 장비 목록에 표시됨)를 전제로 합니다. 엔드포인트의 정확한 스키마는 항상 Swagger 문서를 기준으로 확인하세요.
curl은 대부분의 환경에 기본 제공됩니다. 전체 예제 스크립트는 JSON 파싱에 jq가 필요합니다(sudo apt install jq 또는 brew install jq).
공통 준비
이후 모든 요청에서 재사용할 변수와 인증 헤더를 먼저 구성합니다. (아래 예시는 하나의 셸 세션에서 실행한다고 가정합니다.)
Base URL과 변수 설정
Base URL과 워크스페이스 ID를 셸 변수로 지정합니다.
로그인으로 토큰 발급
계정으로 로그인해 액세스 토큰을 받습니다. 응답의 data.user.accessToken을 변수에 저장해 이후 요청에 사용합니다.
인증 헤더 구성
인증 헤더를 배열로 만들어두면 이후 모든 요청에서 "${AUTH[@]}"로 재사용할 수 있습니다.
토큰이 만료되면 POST /api/auth/refresh-token(헤더 X-Refresh-Token) 또는 GET /api/auth/get-token으로 새 토큰을 받아 다시 설정하세요.
1:1 전송 만들기
소스 장비의 파일을 대상 장비로 곧바로 보내는 핵심 흐름입니다.
소스·대상 장비 확인
GET /api/device로 장비 목록을 조회해 보낼 장비(source)와 받을 장비(target)의 deviceId를 확인합니다.
연결 상태 확인
전송 전에 소스·대상 두 장비가 모두 온라인인지 확인하면 실패를 줄일 수 있습니다.
소스 경로 탐색
보낼 파일 경로를 이미 안다면 건너뜁니다. 동적으로 찾아야 하면 소스 장비의 경로를 탐색합니다.
대상 경로 지정
대상 저장 경로는 대상 장비 기준의 절대 경로를 평문 문자열로 그대로 지정합니다.
Windows 경로는 역슬래시(\) 대신 슬래시(/)로 통일하는 것이 안전합니다.
전송 생성
소스/대상 deviceId, 보낼 파일 경로, 대상 저장 경로(targetPath)로 전송을 만듭니다. 응답의 monitorId는 이후 제어·모니터링에 쓰이므로 저장합니다.
요청 본문 필드: sourceId(보내는 장비), targetId(받는 장비), targetPath(대상 장비의 저장 경로), sourceItem(보낼 파일/폴더 목록 — 폴더 경로를 넣으면 하위 내용이 함께 전송).
전송 상태 확인
monitorId로 진행 상태를 조회합니다. 완료/실패가 될 때까지 주기적으로 폴링합니다.
완료 후 상세 결과는 GET /api/transfer-history/{monitorId}/detail?idType=monitor, 파일 단위 결과는 GET /api/transfer-history/{monitorId}/get-files?idType=monitor로 조회합니다.
상태 문자열(
completed등)의 정확한 값은 환경에 따라 다를 수 있으니, 실제 응답을 확인한 뒤 종료 조건을 확정하세요.
전송 제어
진행 중인 전송을 monitorId로 제어합니다.
일시중지 · 재개 · 취소
세 동작 모두 PATCH 요청이며 본문이 없습니다.
action에는 pause(일시중지), resume(재개), cancel(취소) 중 하나를 전달합니다.
실패 파일 재시도
전송이 일부 실패했을 때 실패한 파일만 다시 시도합니다.
전체 예제
로그인부터 전송 생성·상태 폴링까지 묶은 최소 실행 스크립트입니다. 실제 통합 시 토큰 갱신·에러 처리·재시도를 상황에 맞게 보강하세요. (JSON 파싱에 jq가 필요합니다.)
자동화
정해진 시간에 반복 실행되는 예약 전송은 1회성 manualTransfer 대신 자동화(automation) 엔드포인트로 만듭니다. 즉시 전송과 필드 구조가 다르므로 아래 차이부터 확인하세요.
| 항목 | 즉시 전송 (manualTransfer) | 스케줄 전송 (automation) |
|---|---|---|
| 소스·대상 필드 | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (객체 배열) | ["...", "..."] (문자열 배열) |
| 실행 | 즉시 1회 | schedule에 따라 반복 |
스케줄 정보 구성
schedule 객체로 실행 주기를 정의합니다. hour·minute로 실행 시각을, timezone으로 기준 시간대를, startDate·endDate로 유효 기간을 지정합니다.
자동화 생성
스케줄과 전송 상세(details)를 담아 자동화를 만듭니다. 응답의 automationId로 이후 수정·삭제·제어합니다.
자동화 이름 자동 생성
이름을 직접 정하지 않으려면 서버가 이름을 생성해 줍니다.
자동화 일시중지 · 재개
pause 값으로 자동화를 멈추거나 다시 시작합니다.
자동화 수정 · 삭제
스케줄이나 전송 상세를 바꾸거나 자동화를 제거합니다.
자동화의 진행률·상태는 GET /api/automation/{automationId}/details로 조회합니다.
자주 겪는 문제
| 증상 | 원인 · 해결 |
|---|---|
401 Unauthorized | 토큰 만료 또는 헤더 누락. 로그인 단계를 다시 실행해 ACCESS_TOKEN·AUTH를 갱신. |
| 전송이 시작되지 않음 | 소스/대상 장비가 오프라인. connectivity로 두 장비 온라인 여부 확인. |
| 파일이 엉뚱한 위치에 저장됨 | targetPath가 대상 장비 기준 절대 경로인지 확인. |
| 소스 파일을 못 찾음 | sourceItem 경로가 소스 장비 기준 절대 경로가 아님. fileSearchV3로 실제 경로 확인. |
| 일부 파일만 실패 | retry-failed-files로 실패 파일만 재시도. |
개발 리소스 및 예제
전송 연동에 필요한 코드 예제와 문서는 INNORIX GitHub에서, 전체 엔드포인트 명세는 Swagger 문서에서 확인할 수 있습니다.