SFTP 중심 FEP의 API 경로 확장

파일 경로를 없애지 않고 API를 더했습니다

FEP는 금융기관에서 파일을 내려받아 SAP로 전달하고, SAP가 만든 파일을 다시 올리는 SFTP 중심 애플리케이션이었습니다. 이 흐름을 유지하면서 SAP의 조회 요청을 금융기관 HTTP API로 보내고 결과를 바로 돌려주는 경로를 추가했습니다.

SFTP는 scheduler가 파일을 주고받는 비동기 처리였고, API는 SAP RFC 요청 안에서 외부 조회와 응답 변환을 끝내야 했습니다. 같은 금융 연동이어도 실행 시점과 데이터 계약이 달랐습니다.

첫 API 경로와 SAP 중계

API 요청과 응답은 타입이 있는 DTO로 정의하고 OpenFeign Client와 Service를 별도 패키지에 뒀습니다. Service가 요청 시각·식별자·거래 코드를 채우고 설정에 따라 호출 대상을 선택했습니다.

SAP RFC Handler는 SAP의 조회 조건을 API 요청으로 바꾸고, 여러 페이지를 끝까지 조회한 뒤 결과를 SAP 테이블과 응답 헤더로 변환했습니다. 무한 반복을 피하려고 페이지 수에 상한도 뒀습니다.

API 전용 기관을 SFTP 작업에서 제외

API만 사용하는 기관이 기존 SFTP scheduler에 들어가면 접속 정보가 없는 파일 작업이 반복해서 실패할 수 있었습니다. 기관별 SFTP 활성화 조건을 추가해 파일 처리 대상을 분리했습니다.

복수 SAP 채널에서는 채널과 기관의 허용 조합을 설정으로 관리했습니다. SAP 요청을 받은 Handler는 실제 API를 호출하기 전에 이 조합을 검사합니다.

두 번째 API 기관의 다른 인증·조회 절차

후속 API 기관은 OAuth 인증과 토큰 갱신이 필요했고, 조회도 보고서 생성 요청·상태 확인·파일 다운로드 순서로 진행됐습니다. 인증 Client, 토큰 갱신, 보고서 Client와 SAP RFC Handler를 별도 경계로 추가했습니다.

401 응답 뒤 토큰 갱신은 동시에 중복 실행되지 않게 직렬화했습니다. 보고서 식별자는 정해진 형식인지 확인하고, 다운로드는 설정된 크기를 넘으면 중단하도록 했습니다.

코드와 이력으로 확인한 범위

Git 이력에는 SFTP 중심 초기 구현 뒤 첫 API Client·Service, SAP RFC 중계, OAuth 기반 두 번째 API 기관이 순서대로 추가돼 있습니다. 첫 API Client·Service를 추가한 커밋은 기존 SFTP Java 코드를 수정하지 않았지만, SAP 중계까지 연결할 때는 기관 설정과 SFTP scheduler, Handler 등록부도 함께 변경했습니다.

저장소에는 호출 대상 선택, 페이지 수집, 채널·기관 허용 규칙, OAuth 흐름과 응답 변환을 검사하는 테스트가 있습니다. 두 API 경로는 실제 고객 환경에 배포돼 SAP와 금융기관 사이의 연동에 사용 중입니다.