Postman 또는 OpenAPI에서 SAP CPI HTTP 수신기로

SAP CPI에서 연결하는 REST API 대부분에는 OpenAPI 또는 Swagger 파일, Postman 컬렉션, 또는 둘 다 함께 제공됩니다. HTTP 수신기 어댑터에 필요한 모든 것이 거기에 있습니다. 서버, 경로, 파라미터, header, 본문 구조입니다. 해야 할 일은 각 부분을 한 글자도 빠뜨리지 않고 올바른 필드에 옮기는 것입니다.

이 글에서는 OpenAPI 작업과 Postman 요청을 HTTP 수신기에 단계별로 대응시키고, 첫 호출을 실패하게 만드는 경우가 가장 많은 세부 사항을 정리합니다.

HTTP 수신기에 필요한 것

• Address: 작업의 전체 URL입니다. Simple 표현식을 넣을 수 있으며, 예를 들어 경로 파라미터에 ${property.orderId}를 쓸 수 있습니다.
• Query: ?를 뺀 쿼리 문자열입니다. 예: notify=true.
• Method: GET, POST, PUT, PATCH 또는 DELETE.
• Authentication: 없음, Basic, Client Certificate, OAuth2 Client Credentials 등이며, 자격 증명은 tenant에 저장하고 채널에는 절대 적지 않습니다.
• Request Headers: API로 보낼 메시지 header 이름을 |로 구분해 나열합니다.
• 본문: 어댑터에 도착했을 때의 메시지 본문이며, 보통 Content Modifier나 매핑에서 만듭니다.

OpenAPI 또는 Swagger 작업 읽는 법

주문에 대한 배송을 생성하는 다음 OpenAPI 3 작업을 예로 들겠습니다.

openapi: 3.0.3
servers:
  - url: https://api.example.com/v1
paths:
  /orders/{orderId}/shipments:
    post:
      parameters:
        - { name: orderId, in: path, required: true, schema: { type: string } }
        - { name: notify, in: query, schema: { type: boolean } }
        - { name: X-Request-Id, in: header, schema: { type: string } }
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                carrier: { type: string }
                trackingNumber: { type: string }

1. Address: 서버 URL과 경로를 이어 붙입니다. Swagger 2.0에서는 서버가 schemes, host, basePath로 나뉘어 있습니다.
2. {orderId} 같은 경로 파라미터: 각각을 표현식으로 바꿉니다. 예: ${property.orderId}.
3. 쿼리 파라미터(in: query): Query 필드에 넣습니다.
4. header 파라미터(in: header): Content Modifier에서 메시지 header로 설정하고, 그 이름을 Request Headers에 나열합니다.
5. 요청 본문: requestBody의 스키마에 따라 Content Modifier에서 JSON을 만듭니다.
6. 보안 스킴: 해당하는 자격 증명을 tenant에 만들고 Authentication에서 선택합니다.

결과: Content Modifier와 채널

이 작업의 경우, 어댑터 앞의 Content Modifier와 HTTP 수신기 채널은 다음과 같습니다.

Content Modifier
  Header   Content-Type   application/json
  Header   X-Request-Id   ${property.requestId}
  Body     {
             "carrier": "${property.carrier}",
             "trackingNumber": "${property.trackingNumber}"
           }

HTTP receiver
  Address           https://api.example.com/v1/orders/${property.orderId}/shipments
  Query             notify=true
  Method            POST
  Request Headers   Content-Type|X-Request-Id

Content Modifier는 header Content-Type을 application/json으로 설정하고, header X-Request-Id와 JSON 본문을 설정합니다. 값은 플로 앞부분에서 설정한 exchange property에서 가져옵니다. Request Headers에는 API가 받아야 하는 두 header만 정확히 나열하므로, 나머지 header는 모두 tenant에 남습니다.

Postman 요청에서 시작하기

Postman 요청에도 같은 정보가 다른 위치에 들어 있습니다.

• URL은 흔히 {{baseUrl}} 같은 Postman 변수로 시작합니다. SAP CPI에서는 같은 {{…}} 문법이 배포 시 설정하는 외부화된 파라미터를 뜻합니다. 테스트와 운영 환경에서 달라지는 기본 URL을 두기에 딱 맞는 곳입니다.
• 경로 변수(:orderId)와 쿼리 파라미터는 앞에서처럼 Address와 Query 필드로 갑니다.
• Headers 탭은 Content Modifier의 header와, Request Headers에 나열하는 그 이름이 됩니다.
• raw JSON 본문은 Content Modifier 본문이 되며, 각 테스트 값은 표현식으로 바꿉니다.
• Authorization 탭을 보면 어떤 인증을 설정해야 하는지 알 수 있습니다. Postman의 토큰을 iFlow에 복사하지 말고 자격 증명은 tenant에 저장하세요.

첫 호출을 실패하게 만드는 세부 사항

• Request Headers에 *를 쓰면 내부용을 포함한 모든 메시지 header가 API로 전송됩니다. API가 기대하는 header만 나열하세요.
• Content-Type header가 없거나 잘못된 경우: 많은 API가 application/json 없는 JSON 본문을 거부합니다.
• URL 안의 값은 URL에 안전해야 합니다. 공백이나 슬래시가 들어간 ID는 주소에 넣기 전에 인코딩해야 합니다.
• 오류 응답: Throw Exception on Failure를 끄면 플로가 계속 진행되고 ${header.CamelHttpResponseCode}에 상태 코드가 담기므로 Router로 오류를 처리할 수 있습니다.
• 대부분의 API에서 JSON 본문의 필드 이름은 대소문자를 구분합니다. 기억에 의존하지 말고 스키마에서 복사하세요.

OData 서비스를 호출하나요? OData 수신기 글을 참고하세요. 주소와 본문에 쓰는 표현식은 SAP CPI의 Camel Simple 표현식을 참고하세요.

Kitegra가 도와주는 방법

브라우저 확장 프로그램 Kitegra가 API 명세를 대신 처리합니다. JSON 또는 YAML 형식의 OpenAPI나 Swagger 파일, 또는 Postman 컬렉션을 제공하면, SAP Integration Suite 디자이너에서 그 명세의 URL, 경로, 쿼리 파라미터, 요청 header, JSON 본문 예시를 제안합니다.

명세는 브라우저 안에만 머뭅니다. Kitegra는 API 명세를 절대 저장하지 않습니다. 확장 프로그램은 iFlow의 내용을 저장, 배포, 편집하지 않으며, tenant는 이름이 정해진 네 가지 작업 중 하나를 클릭할 때만 바뀝니다. 이 작업들은 끌 수 있습니다.

내 iFlow의 HTTPS 엔드포인트도 같은 방식으로 호출하려면 서비스 키로 HTTPS iFlow 테스트하기를 참고하세요.

Kitegra 계정이 없어도 모듈당 5개 iFlow에서 사용할 수 있습니다. Free 요금제는 50개, Starter는 100개, Pro는 300개까지 지원합니다. 팀 요금제에서는 모든 멤버가 Pro를 받으며, Startup Team은 모듈당 300개 iFlow, Growth Team과 Scale Team은 제한이 없습니다. Kitegra 출시 기간에는 Free 요금제를 포함해 로그인한 모든 사용자가 모든 도구를 쓸 수 있습니다. 요금제 비교하기.

다음 iFlow에서 사용해 보세요

Kitegra가 SAP Integration Suite 디자이너에서 무엇을 하는지 읽어 보거나, Kitegra의 다른 Chrome 확장 프로그램과 함께 살펴보세요.

자주 묻는 질문