iFlow Timer — Sender 없이 실행 3가지 #shorts #SAP #BTP

1. iFlow는 언제, 어떻게 시작되는가 — 스케줄 실행의 배경

SAP Integration Suite(Cloud Integration 캐패빌리티)에서 Integration Flow(이하 iFlow)를 처음 만들면 반드시 마주치는 질문이 있습니다. "이 iFlow는 무엇이 실행시키는가?"라는 것입니다. 외부 시스템이 메시지를 보내줘야 도는 iFlow도 있고, 아무도 호출하지 않아도 정해진 시각에 스스로 깨어나 일해야 하는 iFlow도 있습니다. 예를 들어 매일 새벽 2시에 ERP의 구매오더(PurchaseOrder)를 협력사 시스템으로 밀어 넣는 배치 인터페이스라면, 누군가 호출해 주기를 기다릴 수 없습니다.

이 글에서는 iFlow를 기동시키는 세 가지 대표 패턴 — (1) Timer Start Event 기반 Scheduler, (2) SOAP/HTTPS 같은 Sender Adapter 인바운드 트리거, (3) Timer와 Poll Enrich(또는 폴링형 어댑터)를 조합한 하이브리드 패턴 — 을 비교하고, PurchaseOrder 자동 전송 시나리오로 실전 구성을 확인합니다. 읽고 나면 다음을 스스로 판단할 수 있게 됩니다.

Timer Start Event의 스케줄 옵션(Run Once / Recur / Cron)을 구분해 설정할 수 있다
푸시(인바운드) 방식과 풀(폴링) 방식의 차이를 설명할 수 있다
시나리오 요건에 맞는 트리거 패턴을 선택할 수 있다

2. 시작하기 전에 알아두면 좋은 것들

이 글은 입문자(beginner) 난이도로 작성되었지만, 최소한의 기반 지식이 있으면 이해가 훨씬 빠릅니다. BPMN 다이어그램에서 Start Event와 End Event의 개념, XML 문서의 기본 구조, 그리고 HTTP 요청/응답의 흐름 정도면 충분합니다. Groovy 스크립트 예제가 한 번 등장하지만 문법을 몰라도 주석을 따라가면 됩니다.

환경 기준은 다음과 같습니다. SAP BTP 상의 SAP Integration Suite(Standard/Premium 에디션, Cloud Foundry 환경)에서 Cloud Integration 캐패빌리티가 활성화되어 있어야 하며, iFlow 설계 권한(예: PI_Integration_Developer 역할 컬렉션)이 필요합니다. Neo 환경의 구 Cloud Platform Integration에서도 대부분 동일하게 동작하지만, Cron 표현식 기반 스케줄 등 일부 기능은 Cloud Foundry 환경의 최신 릴리스에서 제공되는 것이 일반적이므로 테넌트 버전을 먼저 확인하는 것을 권장합니다. 실습에는 무료 평가판(BTP Trial 또는 Free Tier)의 Integration Suite로도 충분합니다.

3. Timer Start Event — 스스로 깨어나는 iFlow의 심장

Timer Start Event는 iFlow 캔버스에서 Sender 참여자 없이 프로세스를 시작하는 유일한 표준 방법입니다. 비유하자면 알람 시계입니다. 외부에서 문을 두드리는 사람(인바운드 메시지)이 없어도, 설정한 시각이 되면 런타임(워커 노드)이 빈 메시지(Exchange)를 하나 만들어 프로세스에 흘려보냅니다. 이때 메시지 바디는 비어 있으므로, 이후 스텝(Request Reply, Content Modifier 등)에서 실제 데이터를 채워 넣는 구조가 됩니다.

Timer의 스케줄 옵션은 크게 세 갈래입니다.

Run Once — 배포 직후 한 번만 실행. 초기 적재(initial load)나 배포 검증에 유용합니다. 다만 재배포할 때마다 다시 실행된다는 점을 잊으면 사고가 납니다.
Schedule on Day / Schedule to Recur — 특정 일자 또는 매일/매주/매월 반복. "매일 02:00", "매 10분마다" 같은 고정 주기를 UI에서 선택합니다. 타임존을 명시적으로 지정할 수 있어 글로벌 운영에서 중요합니다.
Cron 기반 고급 스케줄 — 최근 Integration Suite 릴리스에서는 cron 유사 표현으로 "평일 09~18시 사이 매 15분" 같은 복합 조건을 정의할 수 있습니다. 고정 주기로 표현하기 어려운 업무 캘린더성 요건에 적합합니다.

한 가지 자주 오해하는 동작 원리가 있습니다. Timer는 테넌트의 워커 노드에서 스케줄링되는데, 일반적으로 동일 iFlow의 스케줄 실행이 중복 기동되지 않도록 런타임이 조정합니다. 그러나 이전 실행이 비정상적으로 길어지면 다음 주기와 겹치는 상황을 설계 단계에서 고려해야 하며, 이런 경우 주기를 넉넉히 잡거나 처리 시간을 모니터링하는 것이 권장됩니다.

4. Sender Adapter 트리거 — 문을 두드리면 열리는 방식

두 번째 패턴은 iFlow가 수동적으로 기다리는 구조입니다. HTTPS, SOAP(SAP RM 포함), OData, AS2 같은 Sender Adapter를 Sender 참여자와 Start Message Event 사이에 연결하면, iFlow 배포 시 테넌트에 엔드포인트 URL이 생성됩니다. 외부 시스템(S/4HANA, 서드파티 애플리케이션, API 클라이언트)이 이 URL로 메시지를 보내는 순간 iFlow가 실행됩니다. 알람 시계가 아니라 초인종에 해당합니다.

이 방식의 특징은 다음과 같습니다.

이벤트 실시간성 — 원천 시스템에서 이벤트(오더 생성, 상태 변경)가 발생한 즉시 처리됩니다. 배치 지연이 없습니다.
호출자 책임 — 언제 실행되는지는 전적으로 호출 측이 결정합니다. 원천 시스템에 아웃바운드 설정(예: S/4HANA의 IDoc 파트너 프로파일, 이벤트 메시 구독)이 필요합니다.
인증 필수 — 엔드포인트가 인터넷에 노출되므로 클라이언트 인증서 또는 OAuth 2.0 클라이언트 크리덴셜 기반 인증 구성이 일반적으로 권장됩니다(Basic 인증은 테스트 용도 이상으로는 지양).
동기/비동기 선택 — HTTPS/SOAP는 응답을 되돌려주는 동기 처리도 가능해, 조회형 API 시나리오까지 커버합니다. Timer 패턴으로는 불가능한 영역입니다.

주의할 점은, SFTP·Mail·FTP 같은 일부 Sender Adapter는 겉보기에는 Sender 쪽에 붙지만 실제로는 어댑터 내부에 자체 폴링 스케줄러를 내장하고 있다는 것입니다. 즉 "Sender Adapter = 항상 푸시"가 아니며, 폴링형 어댑터는 사실상 세 번째 패턴과 성격이 가깝습니다.

5. 세 번째 패턴 — Timer + Poll Enrich 하이브리드

세 번째 패턴은 앞의 두 방식을 조합한 형태입니다. Timer Start Event로 iFlow를 깨운 뒤, 플로우 중간에서 Poll Enrich 스텝으로 SFTP/FTP 서버의 파일을 능동적으로 끌어오는 구조입니다. SFTP Sender Adapter의 내장 폴링과 결과는 비슷해 보이지만 결정적 차이가 있습니다. 폴링 "시점"과 "조건"을 iFlow 로직이 완전히 통제한다는 점입니다.

예를 들어 "매일 06:00에 기동하되, 먼저 대상 시스템의 헬스체크 API를 호출해 정상일 때만 파일을 가져온다" 같은 조건부 수집은 Sender Adapter 폴링만으로는 구현하기 어렵습니다. Timer + Poll Enrich라면 Router로 분기한 뒤 필요한 경우에만 파일을 읽으면 됩니다. 또한 Poll Enrich는 가져온 파일을 기존 메시지 바디와 결합(enrich)할 수 있어, "마스터 데이터 조회 결과 + 파일 데이터"를 한 메시지로 합치는 시나리오에도 쓰입니다.

참고로 SAP PI/PO에서 이관하는 프로젝트라면 XI Sender Adapter도 만나게 됩니다. XI 어댑터는 PI/PO 런타임이 XI 3.0 프로토콜로 메시지를 밀어 넣는 인바운드 방식이므로 분류상 두 번째 패턴(푸시)에 속하지만, 신뢰성 보장을 위해 JMS 큐 또는 데이터 스토어 기반의 임시 저장 구성이 함께 필요한 경우가 많아 Standard 에디션 이상에서의 리소스 계획이 필요합니다.

6. 실전 예제 — 매일 새벽 PurchaseOrder를 협력사로 자동 전송하기

시나리오: 매일 02:00(Asia/Seoul)에 Timer가 기동 → OData로 S/4HANA의 미전송 구매오더 조회 → XSLT/Message Mapping으로 협력사 포맷 변환 → SFTP로 업로드. 1단계는 뼈대, 2단계는 에러 처리와 로깅, 3단계는 운영 품질 확보입니다.

1단계 — Timer 스케줄 정의. iFlow를 내보내면 Timer 설정이 BPMN XML에 다음과 같이 표현됩니다(UI에서 설정한 값이 직렬화된 형태이며, 직접 편집보다는 구조 이해용으로 보는 것을 권장합니다).

<bpmn2:startEvent id="StartEvent_Timer" name="DailyPOTimer">
  <bpmn2:extensionElements>
    <ifl:property>
      <key>scheduleKey</key>
      <!-- 매일 02:00, 타임존 Asia/Seoul 반복 실행 -->
      <value>RECURRING::DAILY::02:00::Asia/Seoul</value>
    </ifl:property>
  </bpmn2:extensionElements>
  <bpmn2:timerEventDefinition/>
</bpmn2:startEvent>

2단계 — 조회 결과 변환과 로깅. OData 조회 결과(PurchaseOrder 목록)를 협력사 스키마로 바꾸는 XSLT 예시와, 처리 건수를 남기는 Groovy 스크립트입니다.

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/PurchaseOrders">
    <VendorOrderBatch>
      <xsl:for-each select="PurchaseOrder">
        <Order>
          <OrderNo><xsl:value-of select="PurchaseOrderID"/></OrderNo>
          <Vendor><xsl:value-of select="SupplierID"/></Vendor>
          <Amount currency="{CurrencyCode}">
            <xsl:value-of select="NetAmount"/>
          </Amount>
        </Order>
      </xsl:for-each>
    </VendorOrderBatch>
  </xsl:template>
</xsl:stylesheet>

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def body = message.getBody(String)
    def count = (body =~ /<Order>/).size()
    message.setProperty("SAP_MessageProcessingLogCustomStatus",
        count > 0 ? "PO_SENT" : "PO_EMPTY")
    def log = messageLogFactory.getMessageLog(message)
    log?.addCustomHeaderProperty("POCount", count.toString())
    if (count == 0) {
        message.setProperty("skipSend", "true")
    }
    return message
}

3단계 — 프로덕션 품질. Exception Subprocess를 추가해 OData/SFTP 실패 시 알림 메일 또는 Alert API 호출로 연결하고, SFTP 자격 증명은 Security Material(User Credential 또는 SSH 키)로 관리합니다. 재실행 안전성을 위해 조회 필터에 "전송 플래그 = 미전송" 조건을 걸어 멱등성을 확보하고, 대량 데이터는 OData 어댑터의 페이지 처리와 Splitter/Gather 조합으로 나눠 처리하는 것이 일반적입니다. 배포 전에는 Run Once로 바꿔 1회 검증한 뒤 Recur 스케줄로 되돌리는 절차를 권장합니다.

7. 세 패턴 한눈에 비교 — 무엇을 언제 쓸까

구분	Timer(Scheduler)	Sender Adapter(푸시)	Timer + Poll Enrich
기동 주체	테넌트 런타임	외부 호출자	런타임(수집은 iFlow 로직)
실시간성	주기 의존(지연 존재)	즉시	주기 의존
초기 메시지	빈 바디	호출자가 전달한 페이로드	빈 바디 → 파일로 채움
동기 응답	불가	가능(HTTPS/SOAP)	불가
대표 사례	일 배치, 델타 동기화	이벤트 연동, API 제공	조건부 파일 수집, 데이터 결합

선택 기준을 요약하면 이렇습니다. 원천 시스템이 이벤트를 밀어줄 수 있고 지연이 허용되지 않으면 Sender Adapter 푸시, 원천이 수동적(DB, 파일, 조회 API)이고 주기 처리로 충분하면 Timer, 수집 시점·조건·결합 로직을 세밀하게 통제해야 하면 Timer + Poll Enrich가 일반적으로 적합합니다.

8. 운영 체크리스트와 자주 묻는 질문

운영 단계에서 자주 나오는 질문 세 가지를 정리합니다.

Q1. Timer iFlow를 재배포했더니 예상보다 일찍 실행됐어요. Run Once 설정이 남아 있거나, 배포 시점이 스케줄 경계와 겹친 경우입니다. 배포 후 Monitor에서 다음 실행 예정과 MPL을 확인하는 습관을 권장합니다.
Q2. 스케줄 시각이 됐는데 실행이 안 됩니다. 타임존 설정(UTC vs Asia/Seoul) 불일치가 가장 흔한 원인이고, iFlow가 Started 상태가 아니거나 배포 오류로 런타임에 올라가지 않은 경우도 있습니다.
Q3. HTTPS Sender 엔드포인트 호출 시 401/403이 발생합니다. 호출 클라이언트에 ESBMessaging.send 역할이 부여됐는지, OAuth 토큰의 대상 테넌트가 맞는지 확인하세요. 인증서 인증이라면 서비스 키의 인증서 매핑을 점검합니다.

이후에는 JMS 큐 기반 비동기 디커플링, Exception Subprocess 설계 패턴, Event Mesh와 Cloud Integration 연계 같은 주제로 확장하면 실무 커버리지가 크게 넓어집니다. SAP Help Portal의 Timer Start Event 문서, Poll Enrich 스텝 정의, Sender Adapter 통신 채널 구성 페이지를 참고하고, SAP Community의 Integration Suite 토픽에서 실무 사례를 확인해 보세요. SAP Business Accelerator Hub에서 사전 구성 iFlow 패키지도 내려받아 분석해 보면 패턴을 빠르게 체화할 수 있습니다.

댓글 0