SAP 연동 Logic Apps Agent 워크플로 – 2부: AI 에이전트

2부에서는 대상 워크플로 중 AI가 구현된 부분에 중점을 둡니다. Logic Apps 에이전트가 어떻게 구성되고, SharePoint에서 비즈니스 규칙을 어떻게 가져오며, 그 출력이 어떻게 구체적인 워크플로 아티팩트로 변환되는지를 다룹니다. 대상 워크플로 #1에서 에이전트는 세 가지 구조화된 출력(HTML 유효성 검사 요약, InvalidOrderIds의 CSV 목록, 유효하지 않은 CSV 페이로드)을 생성합니다. 이 출력은 (1) 확인 이메일, (2) 실패한 행을 IDoc으로 유지하기 위한 선택적 RFC 호출, (3) SAP로 분석 결과(또는 오류)만 반환하는 별도의 분석 단계에 사용되는 필터링된 데이터셋으로 이어집니다. 대상 워크플로 #2에서는 동일한 접근 방식이 인바운드 IDoc에 적용됩니다. 이 워크플로는 사용자 지정 세그먼트에서 CSV를 재구성하고, 동일한 SharePoint 규칙에 대해 AI 유효성 검사를 실행하며, 동시성 처리를 위해 리스 기반 쓰기 패턴을 사용하여 결과를 안전하게 추가 Blob에 추가합니다.

1. 서론

1부에서는 통합을 결정론적으로 만드는 것이 목표였습니다. 즉, 안정적인 페이로드 형태, 안정적인 응답 형태, SAP와 Logic Apps 전반에 걸친 예측 가능한 오류 전파를 확립했습니다. 구체적으로 1부에서 다룬 내용은 다음과 같습니다.

• SAP가 Logic Apps에 연결하는 방법 (게이트웨이/프로그램 ID 기반 설정)
• RFC 계약 (IT_CSV, 응답 엔벨로프, RETURN/MESSAGE, EXCEPTIONMSG)
• 소스 워크플로가 RFC 응답을 해석하는 방법 (성공 vs 오류)
• 유효하지 않은 행을 사용자 지정 IDoc으로 SAP에 유지하는 방법 (Z_CREATE_ONLINEORDER_IDOC)
• 두 번째 대상 워크플로가 해당 IDoc을 비동기적으로 수신하는 방법

이러한 기반을 바탕으로 2부는 단순히 기반 설정에 그치지 않는 부분에 초점을 맞춥니다. 즉, AI 결과를 "여전히 해석해야 하는 생성된 텍스트"가 아닌, 워크플로 내에서 사용할 수 있도록 만드는 에이전트 루프, 도구 경계, 출력 스키마에 집중합니다.

아래 다이어그램은 AI가 실제 작업을 수행하는 대상 워크플로의 부분을 강조합니다. 빨간색 원으로 표시된 섹션은 유효성 검사 에이전트 루프(규칙 입력, 구조화된 유효성 검사 출력)이며, 이는 이메일 알림, 선택적 IDoc 유지, 분석 단계 필터링과 같은 운영 작업으로 이어집니다.

여기서 중요한 것은 에이전트 출력의 형태와 나머지 워크플로에서 어떻게 소비되는지입니다. 에이전트는 블랙박스로 취급되지 않습니다. 대신 유형화되고 워크플로 친화적인 아티팩트(요약 + 유효하지 않은 ID + 필터링된 CSV)를 강제로 생성하도록 합니다. 이러한 아티팩트는 결정론적으로 사용됩니다. 즉, 유효하지 않은 행은 보고되고(선택적으로 IDoc으로 유지), 유효한 행은 분석 단계로 흘러 궁극적으로 SAP로 다시 전달됩니다.

이 게시물에서 다루는 내용

이 게시물에서는 다섯 가지 실용적인 주제에 중점을 둡니다.

• Logic Apps의 에이전트 루프 설계: 에이전트 결과를 자동화하기에 충분히 결정론적으로 만드는 도구, 메시지 설계 및 출력 스키마.
• 외부 규칙 검색: SharePoint에서 유효성 검사 규칙을 가져와 수신 페이로드에 일관되게 적용.
• 구조화된 유효성 검사 출력 → 워크플로 작업: 알림 및 SAP 교정을 직접적으로 유도하는 InvalidOrderIds 및 필터링된 CSV 페이로드 생성.
• 두 가지 모델 패턴: 유효성 검사(에이전트)를 위한 전문화된 모델과 분석을 위한 별도의 모델 호출, 두 모델 간의 명확한 인계.
• 소비를 위한 출력 형태화: AI 출력을 이메일용 HTML로 변환하고 SAP 응답 엔벨로프(분석/오류만 해당)로 변환.

(그 외 모든 것 – SAP 기반 설정, RFC 연결, 응답/예외 패턴 –은 1부에서 다루었으며 여기서는 해당 지식을 전제로 합니다.)

다음으로, 에이전트 루프 자체(도구 시퀀스, 필수 출력 필드, 워크플로가 AI 출력을 변수, 이메일, SAP 작업으로 전환하는 정확한 지점)를 자세히 살펴보겠습니다.

KentWeareMSFT​가 에이전트 루프를 이해하고 유효성 검사 에이전트 구조를 설계하는 데 도움을 주신 점에 대해 진심으로 감사드립니다. 또한 🤖 Agent Loop Demos 🤖 | Microsoft Community Hub 에 훌륭한 자료를 제공해주신 모든 분들께 감사드립니다.

2. 유효성 검사 에이전트 루프

이 솔루션에서 데이터 유효성 검사 에이전트는 인바운드 SAP 페이로드가 단일 CSV 문자열로 정규화된 후 대상 워크플로 내에서 실행됩니다. 에이전트는 Azure OpenAI 배포 및 짧은 지침 세트로 구성된 단일 Logic Apps Agent 작업으로 호출됩니다. 이 단계에서 입력은 의도적으로 간단합니다.

• CSV 페이로드(유효성 검사할 데이터셋) 및
• `ValidationRules` 참조(규칙 문서가 있는 위치), 지침에서 매개변수 토큰으로 표시됩니다.

아래 그림은 대상 워크플로에 사용된 유효성 검사 에이전트 구성을 보여줍니다. 상단 절반은 에이전트 작업 구성(모델 + 지침)이고, 하단 절반은 에이전트가 사용할 수 있는 도구 세트를 보여줍니다. 핵심 설계 선택은 에이전트가 "자유로운 채팅"이 아니라는 것입니다. 즉, 소수의 도구와 워크플로 친화적인 출력 계약에 의해 제약을 받습니다.

이 구성에서 가장 중요한 것은 지침과 도구의 분리입니다. 지침은 에이전트에게 무엇을 해야 하는지("비즈니스 프로세스 단계 1-3을 따르라")를 알려주는 반면, 도구는 에이전트가 외부 시스템 및 워크플로 상태와 어떻게 상호 작용할 수 있는지를 정의합니다. 이를 통해 에이전트를 모듈화할 수 있습니다. 즉, 전체 SAP 통합 메커니즘을 다시 작성하지 않고도 SharePoint에서 규칙을 변경하거나 요약 기대치를 수정할 수 있습니다.

목적

이 에이전트의 작업은 범위가 좁고 명확하게 지정됩니다. SAP에서 받은 CSV 페이로드를 외부 저장된 비즈니스 규칙에 대해 유효성을 검사하고 워크플로가 결정론적으로 사용할 수 있는 출력을 생성하는 것입니다. 즉, "추론으로서의 유효성 검사"를 워크플로 아티팩트(요약 + 유효하지 않은 ID + 유효하지 않은 페이로드)로 전환하여 유효성 검사를 비구조화된 산문으로 남기지 않습니다.

Azure Logic Apps 용어로, 이는 에이전트 루프입니다. LLM이 지침을 따르고 사용 가능한 도구 중에서 선택하여 다단계 작업을 완료하는 반복 프로세스입니다. Logic Apps 에이전트 워크플로는 이 "에이전트가 작업을 완료하기 위해 도구를 선택하는" 모델을 명시적으로 지원합니다 (자세한 내용은 Agent Workflows Concepts 참조).

도구

Logic Apps 에이전트 워크플로에서 도구는 에이전트가 작업의 일부를 수행하기 위해 호출할 수 있는 하나 이상의 작업이 포함된 명명된 시퀀스입니다 (자세한 내용은 Agent Workflows Concepts 참조).

스크린샷에서 에이전트는 Get validation rules(유효성 검사 규칙 가져오기), Get CSV payload(CSV 페이로드 가져오기), Summarize CSV payload review(CSV 페이로드 검토 요약)으로 명시적으로 레이블이 지정된 세 가지 도구로 구성되어 있습니다. 이 도구 이름은 "에이전트 지침" 상자의 비즈니스 프로세스(단계 1-3)와 일치합니다. 게시물의 다음 섹션에서는 각 도구가 내부적으로 수행하는 작업을 자세히 다룹니다. 이 수준에서 중요한 점은 에이전트가 작고 명시적인 도구 세트로 제한된다는 것입니다.

에이전트 실행

스크린샷은 다음과 같이 구성된 에이전트를 보여줍니다.

• AI 모델: gpt-5-3 (gpt-5)
• 연결 라인: "Connected to … (Azure OpenAI)"
• 에이전트의 역할과 3단계 비즈니스 프로세스를 정의하는 에이전트 지침:
  1. 유효성 검사 규칙 가져오기 (ValidationRules 참조를 통해)
  2. CSV 페이로드 가져오기
  3. 유효성 검사 문서를 사용하여 CSV 페이로드 검토 요약

이 패턴은 의도적입니다.

• 지침은 에이전트의 "운영 절차"를 평이한 언어로 제공합니다.
• 도구는 에이전트에게 규칙 문서를 가져오고, CSV 입력에 액세스하며, 구조화된 결과를 반환하는 제어된 방법을 제공합니다.
• 워크플로가 에이전트의 출력을 다운스트림에서 소비하기 때문에, 지침 텍스트는 효과적으로 워크플로 계약의 일부입니다 (나중에 작업에서 출력 형태를 신뢰할 수 있을 만큼 안정적으로 유지되어야 합니다).

2.1 도구 1: 유효성 검사 규칙 가져오기

유효성 검사 에이전트 루프의 첫 번째 도구는 유효성 검사 규칙 가져오기입니다. 이 도구의 역할은 SAP에서 수신되는 CSV 페이로드에 적용될 비즈니스 유효성 검사 규칙을 로드하는 것입니다. 이러한 규칙은 Logic App을 재배포하지 않고도 업데이트할 수 있도록 워크플로 외부에(문서로) 유지합니다. 이 예에서는 규칙이 SharePoint에 저장되어 있으며, 도구는 런타임에 문서 내용을 검색하기만 합니다.

유효성 검사 규칙 가져오기는 유효성 검사 문서 가져오기라는 단일 작업으로 구현됩니다. 디자이너에서 다음을 확인할 수 있습니다.

• SharePoint Online 연결을 사용하고 (SharePoint 아이콘 및 커넥터 작업)
• GetFileContentByPath를 호출하며 ("파일 경로" 입력으로 표시됨)
• 구성된 사이트 주소에서 규칙 파일을 읽고
• 파일 경로에 워크플로 매개변수 토큰 ValidationRules를 사용합니다 (따라서 정확한 규칙 파일 위치는 환경별로 구성 가능).

이 도구의 출력은 원시 규칙 문서 콘텐츠이며, 데이터 유효성 검사 에이전트는 다음 단계에서 이를 사용하여 CSV 페이로드의 유효성을 검사합니다.

그림의 하단 절반은 규칙 문서의 일부를 보여줍니다. 형식은 간단하고 의도적으로 사람이 편집할 수 있도록 되어 있습니다. 각 규칙은 FieldName: condition으로 표현됩니다. 예를 들어, 보이는 규칙에는 다음이 포함됩니다.

• PaymentMethod: 값이 존재해야 합니다.
• PaymentMethod: 값은 "Cash"일 수 없습니다.
• OrderStatus: 값은 "Cancelled"와 달라야 합니다.
• CouponCode: 값은 최소 1자 이상이어야 합니다.
• OrderID: 값은 CSV 배열 내에서 고유해야 합니다.
• 범위 참고: "날짜 필드는 유효성 검사를 하지 마십시오."

이러한 규칙은 유효성 검사의 "진실의 원천"입니다. 워크플로는 이러한 규칙을 표현식에 하드코딩하지 않습니다. 대신 SharePoint에서 검색하여 에이전트 루프로 전달하므로 유효성 검사 로직이 구성 가능하고 감사 가능하게 유지됩니다 (특정 실행에 사용된 정확한 규칙 문서를 항상 가리킬 수 있습니다).

문서에 있는 작지만 의도적인 규칙은 "날짜 필드는 유효성 검사를 하지 마십시오."입니다. 이 줄은 실제적인 이유로 거기에 있습니다. 소스 워크플로의 초기 버전에서 CSV 생성 중에 날짜 열이 손상되고 있었습니다. 유효성 검사 에이전트는 날짜 유효성을 계속 검사하려고 시도했고(날짜 유효성 검사가 원래 의도의 일부가 아니었음에도 불구하고), 그 결과는 예측 가능했습니다. 모든 행이 유효성 검사에 실패하여 분석할 내용이 남지 않았습니다. 상위 문제는 이제 해결되었지만, 중요한 요점을 설명하기 위해 이 규칙을 데모에 유지했습니다. 유효성 검사는 파이프라인의 해당 지점에서 실제로 보장할 수 있는 데이터 계약과 일치할 때만 유용합니다.

규칙이 로드되면 다음 도구는 에이전트가 필요로 하는 두 번째 입력, 즉 이 문서에 대해 유효성 검사를 수행할 CSV 페이로드를 제공합니다.

2.2 도구 2: CSV 페이로드 가져오기

유효성 검사 에이전트 루프의 두 번째 도구는 CSV 페이로드 가져오기입니다. 이 도구의 목적은 유효성 검사할 데이터셋을 명시적으로 만드는 것입니다. 즉, 에이전트가 "CSV 페이로드"로 정확히 무엇을 처리해야 하는지를 정의하며, 암시적인 워크플로 컨텍스트에 의존하지 않습니다. 이 워크플로에서 CSV는 이미 이전에 (Create_CSV_payload로) 구성되어 있으며, 이 도구는 준비된 문자열과 에이전트의 유효성 검사 단계 사이의 좁은 다리 역할을 합니다.

그림: 도구 #2 ("CSV 페이로드 가져오기")는 단일 에이전트 매개변수를 정의하고 이를 워크플로에서 생성된 CSV에 바인딩합니다.

이 그림은 두 가지 중요한 부분을 보여줍니다.

- 도구 매개변수 계약 ("에이전트 매개변수")
오른쪽에, 이 도구는 CSV 페이로드라는 이름의 에이전트 매개변수를 문자열 유형으로 정의하며, 설명(노란색으로 강조 표시됨)은 의도를 명확히 합니다: "SAP에서 수신되었으며 유효성 검사 규칙에 따라 유효성을 검사하는 CSV 페이로드."

이 매개변수는 도구의 인터페이스입니다. 에이전트가 이 도구를 사용할 때 제공/소비해야 하는 것을 문서화하며, 나머지 유효성 검사 프로세스를 단일하고 잘 정의된 입력에 고정합니다. Logic Apps 에이전트 워크플로의 도구는 에이전트가 수행할 수 있는 작업과 작동하는 데이터를 특별히 제한하고 구조화하기 위해 존재합니다 (자세한 내용은 Agent Workflows Concepts 참조).

- 명시적인 Compose 작업("CSV 페이로드")이 있는 이유
오른쪽 하단 "코드 보기"에서 도구의 내부 작업은 표준 Compose로 표시됩니다.

이는 의도적입니다. CSV가 워크플로에 이미 존재하더라도, 도구는 에이전트에 반환하는 값을 생성하는 구체적인 작업이 여전히 필요합니다. Compose 단계는:

• • 도구 출력을 단일 진실 공급원(Create_CSV_payload)에 고정하고,
  • 다른 워크플로 상태와 독립적으로 "이것은 에이전트가 유효성을 검사하는 정확한 CSV 문자열"이라는 안정적인 경계를 생성합니다.

간단히 말해, Compose 작업은 Logic Apps가 CSV에 액세스할 수 없어서 있는 것이 아니라, 에이전트/도구 인터페이스를 명확하고 반복 가능하며 문제 해결이 용이하도록 만들기 위해 있습니다.

도구 #1이 규칙 문서를 제공하고 도구 #2가 CSV 데이터셋을 제공하므로, 도구 #3은 에이전트가 다운스트림 단계에서 작업을 수행할 수 있는 워크플로 준비 출력(요약 + 유효하지 않은 ID + 필터링된 페이로드)을 생성하는 곳입니다.

2.3 도구 3: CSV 페이로드 검토 요약

세 번째 도구인 CSV 페이로드 검토 요약은 에이전트가 "평가자" 역할을 멈추고 워크플로에서 바로 사용할 수 있는 결과물을 생성하는 주체로 바뀌는 곳입니다. 이 도구는 대부분의 작업을 수행하므로 자세히 살펴보겠습니다.

하나의 산문 덩어리를 반환하는 대신, 이 도구는 세 가지 명시적인 에이전트 매개변수를 정의하며, 각 매개변수는 특정 형식과 목적을 가집니다. 이를 통해 워크플로는 다운스트림 작업에서 결과를 안정적으로 소비할 수 있습니다. Logic Apps 에이전트 워크플로에서 도구는 에이전트가 수행할 수 있는 명시적으로 정의된 작업이며, 각 도구는 루프를 예측 가능하게 유지하는 작업 및 스키마를 중심으로 구성될 수 있습니다 (자세한 내용은 Agent Workflows Concepts 참조).

그림: 도구 #3 ("CSV 페이로드 검토 요약")은 세 가지 구조화된 에이전트 출력을 정의합니다.

설명은 단순히 문서화가 아닙니다. 이는 모델이 충족해야 하는 계약이며, 에이전트가 출력을 생성할 때 "관련성"을 고려하는 방식을 강력하게 형성합니다. 매개변수는 다음과 같습니다.

여기서 "에이전트 매개변수"가 하는 일 (그리고 왜 중요한지)

에이전트 매개변수에 대해 유용하게 생각하는 방법은 다음과 같습니다. 즉, 도구의 "형식화된 반환 값"입니다. 에이전트 워크플로의 도구는 에이전트가 수행할 수 있는 경계가 있는 작업으로 작업을 구조화하기 위해 존재하며, 스키마/매개변수 계약은 나머지 워크플로에서 결과를 소비할 수 있도록 만듭니다 (자세한 내용은 Agent Workflows Concepts 참조).

이 도구에서 매개변수는 동시에 두 가지 목적을 수행합니다.

1. 에이전트를 주요 출력으로 안내합니다.
   설명은 중요한 내용을 명시적으로 명명합니다: "실패한 orderids", "HTML 테이블", "CSV 형식", "한 줄에 한 행", "헤더 행 규칙". 이러한 표현은 모델이 관련 없는 해설로 "방황"하는 것을 훨씬 더 어렵게 만듭니다.
2. 워크플로가 결과를 구문 분석하고 사용하는 방식과 일치합니다.
   "InvalidOrderIds는 CSV입니다."라고 명시함으로써 구문 분석이 간단해지고(split), "유효하지 않은 CSV 페이로드는 한 줄에 한 행입니다."라고 명시함으로써 나중에 변환으로 쉽게 전달할 수 있습니다.

문구가 효과적인 이유 (그리고 어떤 문구가 가장 효과적인 경향이 있는지)

매개변수 설명이 흥미로운 점은 세 가지 종류의 제약을 결합한다는 것입니다.

• 출력 형식 제약 조건 (구문 분석을 결정론적으로 만듭니다.)

• • "예상 형식은 HTML 테이블입니다."
  • "형식은 CSV입니다."
  • "각 행은 별도의 줄에 있어야 합니다."

이러한 형식 단서는 에이전트가 무엇을 생성할지 결정하는 데 도움이 되고, 나중에 취약한 구문 분석을 피하는 데 도움이 됩니다.

• 출력 선택 제약 조건 (관련성을 강제합니다.)

• • "유효성 검사에 실패한 orderid 값에 대해서만"
  • "실패한 모든 orderid 목록을 생성합니다."

이는 에이전트에게 무엇을 유지하고 무엇을 무시할지 알려줍니다.

• 출력 운영 제약 조건 (출력을 다운스트림 작업과 연결합니다.)

• • "이메일 본문에만 제목 행을 포함합니다."
  • "그 외에는 제거합니다."

이는 다운스트림 사용(이메일 vs 교정)을 명시적으로 예상하는 것으로, 모델이 종종 놓치는 종류의 세부 정보입니다.

이 매개변수들이 다운스트림 작업과 직접 연결되는 방법

다음 그림은 설계 의도를 매우 명확하게 보여줍니다. 각 매개변수는 Compose 작업을 통해 즉시 일반 워크플로 값에 "바인딩"된 다음 나중에 단계에서 사용됩니다. 이것이 우리가 원하는 패턴입니다. 에이전트 출력 → Compose → (선택적) 정규화 → 결정론적 워크플로 작업에 재사용. 이는 "모델 출력을 읽고 희망하는" 것과는 반대입니다.

이것은 재사용 가능한 패턴입니다.

• 워크플로에 필요한 최소한의 출력 세트를 결정합니다.
• 구문 분석하기 쉬운 형식을 지정합니다.
• 선택 및 서식 제약 조건을 모두 인코딩하는 매개변수 설명을 작성합니다.
• Compose/SetVariable 작업을 통해 출력을 워크플로 변수에 즉시 바인딩합니다.

이 도구의 핵심은 에이전트가 구조화된 계약으로 강제된다는 것입니다. 즉, 명시적인 형식과 명확한 의도를 가진 세 가지 출력입니다. 이 계약은 나머지 워크플로를 결정론적으로 만듭니다. Compose 작업은 @agentParameters(...)를 안전하게 읽을 수 있고, 워크플로는 유효하지 않은 ID를 안전하게 split(...)할 수 있으며, 다운스트림 작업은 "유효하지 않은 페이로드"를 서술이 아닌 실제 데이터로 처리할 수 있습니다.

나중에 이 동일한 "매개변수 우선" 설계가 다른 에이전트 도구로 확장되는 방법을 보여드리겠습니다.

2.4 에이전트 출력을 확인 이메일로 전환

에이전트가 구조화된 출력(유효성 검사 요약, InvalidOrderIds 및 유효하지 않은 CSV 페이로드)을 생성하면, 다음 목표는 이러한 출력을 운영 가능하게 만드는 것입니다. 즉, 사람들은 무엇이 실패했는지에 대한 빠른 요약을 필요로 하고, 워크플로는 다운스트림에서 재사용할 수 있는 기계 친화적인 값을 필요로 합니다.

여기서의 설계는 의도적으로 간단합니다. 워크플로는 각 에이전트 매개변수를 일급 워크플로 출력으로 변환한 다음(Compose 작업 및 하나의 변수 할당을 통해), 해당 값을 Office 365 이메일 본문에 직접 바인딩합니다. 결과적으로 실행 기록을 열어볼 필요 없이 읽기 쉽고 실행 가능한 이메일이 생성됩니다.

아래 그림은 Summarize CSV payload review의 출력이 확인 이메일에 어떻게 매핑되는지를 보여줍니다. 왼쪽에, 도구는 후속 작업(요약, 유효하지 않은 주문 ID 및 유효하지 않은 CSV 페이로드)을 통해 세 가지 값을 생성하고, 워크플로는 유효하지 않은 ID를 배열(ArrayOfInvalidOrderIDs)로 정규화하여 나중에 필터링 및 분석 단계에 사용합니다. 오른쪽에, Send verification summary(확인 요약 보내기) 작업은 이러한 동일한 값을 동적 콘텐츠 토큰으로 사용하여 이메일 본문을 구성합니다.

그림: 에이전트 출력을 확인 이메일에 매핑.

이메일이 "다시 프롬프트"하거나 "다시 요약"하여 구성되지 않는다는 점이 중요합니다. 이미 구조화된 출력으로 조립됩니다. 이 매핑은 의도적으로 직접적입니다. 즉, 이메일의 각 부분은 에이전트 도구의 하나의 명시적 출력에 해당합니다. 워크플로는 기본 서식 외에 요약을 해석하거나 변환하지 않습니다. 워크플로의 역할은 에이전트의 구조화된 출력을 보존하고 일관되게 표시하는 것입니다. 유일한 정규화 단계는 InvalidOrderIds에 대해 발생하며, 여기서 워크플로는 CSV 문자열을 배열(ArrayOfInvalidOrderIDs)로 변환하여 나중에 필터링 및 분석 단계에 사용합니다.

다음 그림은 이 파이프라인에서 생성된 샘플 확인 이메일을 보여줍니다. HTML 유효성 검사 요약 테이블, 원시 유효하지 않은 주문 ID 목록, 추출된 유효하지 않은 CSV 행의 세 부분 구조를 보여줍니다.

그림: 샘플 확인 이메일 — 유효성 검사 요약 테이블 + 유효하지 않은 주문 ID + 유효하지 않은 CSV 행.

추출된 아티팩트인 InvalidOrderIds 및 유효하지 않은 CSV 페이로드는 나중에 처리를 위해 실패한 행을 IDoc으로 유지하는 다운스트림 작업에 사용되며, 이는 1부에서 소개되었습니다. 유효성 검사 에이전트 재사용에 대해 이야기하기 위해 나중에 다시 다루겠습니다. 하지만 다음으로 AI 통합의 데이터 분석 부분을 살펴보겠습니다.

3. 분석 단계: 유효성 검사된 데이터셋에서 HTML 출력으로

유효성 검사 에이전트 루프가 완료되면 워크플로는 두 번째 AI 단계인 분석 단계에 진입합니다. 유효성 검사 단계는 의도적으로 정확성(무엇을 제외하고 왜 제외하는지)에 중점을 둡니다. 분석 단계는 통찰력에 관한 것이며, 유효하지 않은 행이 필터링된 후 남은 데이터셋에서 실행됩니다.

높은 수준에서, 이 단계는 세 가지 단계로 구성됩니다.

1. Azure OpenAI를 호출하여 CSV 데이터셋을 분석하되, 유효하지 않은 OrderIDs는 명시적으로 제외합니다.
2. OpenAI 응답 개체에서 모델의 텍스트 출력을 추출합니다.
3. 모델의 마크다운 출력을 HTML로 변환하여 이메일(및 SAP 응답 엔벨로프)에서 깔끔하게 렌더링되도록 합니다.

3.1 OpenAI 구성 요소: "데이터 분석" 호출

아래 그림은 분석 단계를 주도하는 데이터 분석 작업을 보여줍니다. 이 작업은 데이터 유효성 검사 에이전트가 완료된 후에 실행되며, 세 가지 메시지를 사용합니다. 즉, 작업을 정의하는 시스템 지침, CSV 데이터셋을 입력으로, 그리고 제외할 OrderIDs(유효성 검사에서 생성된 유효하지 않은 ID)를 열거하는 두 번째 사용자 메시지입니다.

그림: Azure OpenAI 분석 호출.

분석 호출은 다음과 같이 구성됩니다.

• 시스템: 작업 및 제약 조건 정의
• 사용자: 데이터셋 제공
• 사용자: 유효성 검사에서 파생된 제외 사항 제공

여기서 대부분의 작업을 수행하는 두 가지 설계 선택 사항이 있습니다.

• 모델에는 데이터셋과 제외 사항이 별도로 제공됩니다. 이는 모호성을 피합니다. 데이터셋은 하나의 메시지이고, "이러한 OrderIDs를 포함하지 마십시오."라는 제약 조건은 다른 메시지입니다.
• 제외 목록은 유효성 검사 출력에서 파생되며, 분석 중에 다시 발견되지 않습니다. 분석 단계는 재유효성 검사를 수행하지 않습니다. 대신 유효성 검사 단계의 결과를 소비하고 순수하게 추세/예측에 집중합니다.

3.2 응답 처리

다음 그림은 워크플로가 Azure OpenAI 응답을 이메일 및 SAP 응답을 위해 재사용할 수 있는 단일 문자열로 전환하는 방법을 보여줍니다. 워크플로는 순서대로 세 가지 작업을 수행합니다. 즉, 응답 JSON을 구문 분석하고, 모델의 텍스트 콘텐츠를 추출한 다음, 해당 텍스트를 HTML 포매터로 전달합니다.

그림: OpenAI 응답 처리.

이 워크플로에 대해 이해해야 할 OpenAI 응답의 유일한 부분은 다음과 같습니다.

OpenAI 응답의 다른 모든 것(필터, 인덱스, 메타데이터)은 감사에 유용하지만 최종 사용자에게 표시되는 출력을 구축하는 데 필요하지는 않습니다.

3.3 출력을 HTML로 만들기

모델의 출력은 일반 텍스트이며 종종 경량 마크다운 구조(제목, 목록, 구분 기호)를 포함합니다. 분석을 이메일에서 읽을 수 있고 SAP 응답 엔벨로프에 안전하게 포함할 수 있도록 워크플로는 마크다운을 HTML로 변환합니다. 스크립트는 Copilot으로 생성되었습니다. 소스 코드 스니펫은 1부에서 찾을 수 있습니다. 다음 그림은 서식 지정 후 렌더링된 분석 결과를 보여줍니다. 제외된 OrderIDs에 대한 명시적인 참조와 추세 관찰을 나열하기 전 나머지 데이터셋 요약을 주목하십시오.

그림: 서식 지정 후 분석 출력 예시.

4. 루프 닫기: 유효하지 않은 행을 IDoc으로 유지

1부에서는 선택적 교정 분기를 소개했습니다. 유효성 검사에서 잘못된 행을 발견하면 워크플로는 나중에 처리하기 위해 해당 행을 사용자 지정 IDoc으로 SAP에 유지할 수 있습니다. 2부에서는 에이전트 루프를 자세히 살펴본 후, 해당 부분을 다시 연결하여 "이야기의 끝"을 보여드리겠습니다. 즉, 대상 워크플로는 유효하지 않은 데이터에 대한 IDoc을 생성하고, 두 번째 대상 워크플로는 해당 IDoc을 수신하여 Blob Storage에 통합된 감사 추적을 생성합니다.

이 마지막 섹션은 의도적으로 실용적입니다. 다음을 보여줍니다.

• IDoc 생성 호출이 발생하는 위치,
• 생성된 IDoc이 다운스트림으로 도착하는 방법,
• 그리고 동일한 스토리지 아티팩트에 쓰는 많은 동시 워크플로 인스턴스(IDoc당 하나의 인스턴스)를 안전하게 처리하는 방법.

4.1 "확인 요약"에서 "모든 IDoc 생성"으로

아래 그림은 확인 요약 흐름의 마지막 부분을 보여줍니다. 에이전트가 구조화된 유효성 검사 출력을 생성하면, 워크플로는 먼저 사람이 읽을 수 있는 요약을 이메일로 보내고, 유효하지 않은 CSV 행을 SAP 친화적인 XML 형태로 변환한 다음, 해당 행에서 IDoc을 생성하는 RFC를 호출합니다.

그림: 유효성 검사/교정 분기의 끝.

이것은 의도적으로 "인계 지점"입니다. 이 단계 이후에는 유효하지 않은 행이 더 이상 이메일의 텍스트가 아닙니다. 대신 원본 워크플로 실행과 독립적으로 라우팅, 재시도 및 처리될 수 있는 내구성 있는 SAP 아티팩트(IDoc)가 됩니다.

4.2 Z_CREATE_ONLINEORDER_IDOC 및 다운스트림 수신기

다음 그림은 1부의 동일한 개요입니다. 전체 루프를 포착하기 때문에 여기에서 다시 사용합니다. 즉, 워크플로는 Z_CREATE_ONLINEORDER_IDOC을 호출하고, SAP는 유효하지 않은 행을 사용자 지정 IDoc으로 변환하며, 대상 워크플로 #2는 해당 IDoc을 비동기적으로 수신합니다(IDoc당 하나의 워크플로 실행).

그림 2: 사용자 지정 IDoc으로 유지된 유효하지 않은 행.

이 패턴은 의도적으로 모듈화되어 있습니다.

• 대상 워크플로 #1은 어떤 행이 유효하지 않은지 결정하고 선택적으로 유지합니다.
• SAP는 안정적인 RFC (Z_CREATE_ONLINEORDER_IDOC) 뒤에 IDoc 생성 메커니즘을 캡슐화합니다.
• 대상 워크플로 #2는 들어오는 각 IDoc을 독립적으로 처리하며, 이는 IDoc 기반 통합이 일반적으로 프로덕션에서 작동하는 방식과 일치합니다.

4.3 대상 워크플로 #2의 두 단계: AI 에이전트 + Blob Storage 로깅

수신기 워크플로에는 두 가지 다른 단계가 있습니다.

1. AI 에이전트 단계 (IDoc당): 들어오는 IDoc 페이로드에서 CSV 뷰를 재구성하고 (선택적으로) 동일한 유효성 검사 로직을 실행합니다.
2. Blob 저장소 단계 (공유 출력): 정규화된 "확인 라인"을 동시성 안전한 방식으로 공유 Blob에 추가합니다.

주목할 점은 이 데모에서 수신되는 IDoc이 이미 상위에서 유효성 검사된 출력에서 생성되었으므로, 두 번째 유효성 검사는 불필요하다고 주장할 수 있습니다. 그럼에도 불구하고 두 가지 이유로 유지합니다.

• 에이전트 도구가 최소한의 변경으로 재사용 가능하다는 것을 보여주고,
• 일반적인 통합에서 대상 워크플로 #2는 이 파이프라인뿐만 아니라 여러 소스에서 IDoc을 수신할 수 있으므로, "수신 시 유효성 검사"는 여전히 가치 있을 수 있습니다.

4.3.1 AI 에이전트 단계

아래 그림은 대상 워크플로 #2에 사용된 유효성 검사 에이전트를 보여줍니다. 이전 에이전트 루프와의 주요 차이점은 출력 형식입니다. HTML 요약 + 유효하지 않은 목록을 생성하는 대신, 이 에이전트는 IDoc 상관 관계 키(DOCNUM), 주문 ID 및 실패한 규칙을 포함하는 단일 "감사 라인"을 작성합니다.

그림: 대상 워크플로 #2 에이전트 구성.

여기서 재사용 가능한 부분은 도구 구조입니다. 규칙은 여전히 동일한 유효성 검사 문서에서 오고, 데이터셋은 여전히 CSV로 제공되며, 요약 도구는 워크플로가 결정론적으로 소비할 수 있는 구조화된 값을 출력합니다. 유일한 의미 있는 변경 사항은 "출력이 어떤 형태를 취하기를 원하는가"이며, 이는 에이전트 매개변수 설명이 정확히 제어하는 부분입니다.

다음 그림은 대상 워크플로 #2의 요약 도구 매개변수를 확대합니다. 세 가지 출력 대신, 이 도구는 DOCNUM을 기준으로 하는 일관된 라인 형식을 강제하는 단일 매개변수(VerificationInfo)를 사용합니다.

그림 4: VerificationInfo 매개변수.

이것은 첫 번째 대상 워크플로의 도구 #3과 동일한 설계 원칙입니다. 즉, 출력을 모호한 요청이 아닌 계약으로 설명합니다. 매개변수 설명은 에이전트에게 무엇이 존재해야 하는지(DOCNUM + OrderId + 실패한 규칙) 정확히 알려주므로 추가 구문 분석 없이 출력을 공유 로그에 추가하기 쉽습니다.

흥미로운 스니펫

IDoc 제어 레코드에서 DOCNUM을 추출하여 실행 전반에 걸쳐 전달합니다.

4.3.2 Blob Storage 단계

대상 워크플로 #2는 인바운드 IDoc당 하나의 인스턴스를 실행합니다. 이는 여러 인스턴스가 동시에 실행되어 동일한 "ValidationErrorsYYYYMMDD.txt" 아티팩트에 쓰려고 시도할 수 있음을 의미합니다. 아래 그림은 결과적으로 추가된 출력을 보여줍니다. 즉, IDoc당 한 줄이며, 각 줄은 DOCNUM으로 시작하여 안정적인 상관 관계 키가 됩니다.

주목할 점은 이 데모에서 수신되는 IDoc이 이미 상위에서 유효성 검사된 출력에서 생성되었으므로, 두 번째 유효성 검사는 불필요하다고 주장할 수 있습니다. 그럼에도 불구하고 두 가지 이유로 유지합니다.

• 에이전트 도구가 최소한의 변경으로 재사용 가능하다는 것을 보여주고,
• 일반적인 통합에서 대상 워크플로 #2는 이 파이프라인뿐만 아니라 여러 소스에서 IDoc을 수신할 수 있으므로, "수신 시 유효성 검사"는 여전히 가치 있을 수 있습니다.

4.3.1 AI 에이전트 단계

아래 그림은 대상 워크플로 #2에 사용된 유효성 검사 에이전트를 보여줍니다. 이전 에이전트 루프와의 주요 차이점은 출력 형식입니다. HTML 요약 + 유효하지 않은 목록을 생성하는 대신, 이 에이전트는 IDoc 상관 관계 키(DOCNUM), 주문 ID 및 실패한 규칙을 포함하는 단일 "감사 라인"을 작성합니다.

그림: 대상 워크플로 #2 에이전트 구성.

여기서 재사용 가능한 부분은 도구 구조입니다. 규칙은 여전히 동일한 유효성 검사 문서에서 오고, 데이터셋은 여전히 CSV로 제공되며, 요약 도구는 워크플로가 결정론적으로 소비할 수 있는 구조화된 값을 출력합니다. 유일한 의미 있는 변경 사항은 "출력이 어떤 형태를 취하기를 원하는가"이며, 이는 에이전트 매개변수 설명이 정확히 제어하는 부분입니다.

다음 그림은 대상 워크플로 #2의 요약 도구 매개변수를 확대합니다. 세 가지 출력 대신, 이 도구는 DOCNUM을 기준으로 하는 일관된 라인 형식을 강제하는 단일 매개변수(VerificationInfo)를 사용합니다.

그림 4: VerificationInfo 매개변수.

이것은 첫 번째 대상 워크플로의 도구 #3과 동일한 설계 원칙입니다. 즉, 출력을 모호한 요청이 아닌 계약으로 설명합니다. 매개변수 설명은 에이전트에게 무엇이 존재해야 하는지(DOCNUM + OrderId + 실패한 규칙) 정확히 알려주므로 추가 구문 분석 없이 출력을 공유 로그에 추가하기 쉽습니다.

흥미로운 스니펫

IDoc 제어 레코드에서 DOCNUM을 추출하여 실행 전반에 걸쳐 전달합니다.

4.3.2 Blob Storage 단계

대상 워크플로 #2는 인바운드 IDoc당 하나의 인스턴스를 실행합니다. 이는 여러 인스턴스가 동시에 실행되어 동일한 "ValidationErrorsYYYYMMDD.txt" 아티팩트에 쓰려고 시도할 수 있음을 의미합니다. 아래 그림은 결과적으로 추가된 출력을 보여줍니다. 즉, IDoc당 한 줄이며, 각 줄은 DOCNUM으로 시작하여 안정적인 상관 관계 키가 됩니다.

• # 다음 폭발: 데스 스트랜딩 2 오프닝 컷신을 감상하세요 2025-03-30
• 굿데이 코쿤 핑크 체크 남방 패션 분석 : 코드쿤스트와 함께한 핑크빛 케미! 2025-01-12
• 책소공의 AI 추천: 듀얼 브레인 - 인간과 AI의 협력, 새로운 시대의 경쟁력 2025-01-30
• PS5에서 크림슨 데저트 그래픽이 엉망으로 보인다고요? 해결 방법은 여기 있습니다. 2026-03-20
• 마인크래프트 영화 리뷰 - 예상 그대로, 좋든 싫든 2025-02-19