1. 탄력적인 비동기 통합을 구축하기 위한 모범 사례
  2. Oracle Integration을 사용한 복원력 설계

Oracle Integration을 사용한 복원력 설계

탄력적인 통합을 설계할 때는 다음 모범 사례를 사용하십시오.

설계 통합

다음은 REST API를 통해 업스트림 애플리케이션의 요청을 수신하고, 구문 분석하고, 검증하고, 다운스트림 애플리케이션으로 전송하는 기본 인바운드 통합 플로우입니다.

업스트림 애플리케이션이 요청을 전송할 때 다운스트림 애플리케이션이 응답하지 않는 경우가 있을 수 있습니다. 이러한 요청은 다운스트림에서 확인되지 않습니다. 일괄 처리, 복잡한 메시지 상관 관계/플로우, 스로틀과 같은 많은 처리 문제가 발생할 것입니다.

REST API를 사용하여 Oracle Financials 클라우드에서 엔티티를 생성하는 예를 살펴보겠습니다. 통합 REST 엔드포인트에서 요청을 수신해야 합니다. Financials Cloud에 도달한 요청을 동적으로 제한하고 요청 상태를 추적하고 실패한 요청을 다시 제출할 수 있어야 합니다. 이 솔루션의 경우 세 가지 통합과 Autonomous Transaction Processing 데이터베이스가 표시됩니다. 주차장의 구현은 데이터베이스 또는 Coherence와 같은 다양한 저장 기술을 사용하여 수행 할 수 있습니다. 그러나 단순성을 위해 Autonomous Transaction Processing 데이터베이스 테이블을 사용하고 있습니다.

다음은 oic_extended_parkinglot_eh.png에 대한 설명입니다.
그림 oic_extended_parkinglot_eh.png에 대한 설명

표시된 이미지에서 업스트림 응용 프로그램이 요청을 보낼 때 Request Persister 통합이 해당 요청을 데이터베이스로 보내고 업스트림 응용 프로그램을 확인합니다. 데이터베이스에서 주차장 패턴은 요청 메타데이터 및 상태 정보를 저장하고 들어오는 순서에 따라 입력 요청을 처리합니다. 각 메시지는 x분(주차 시간) 동안 스토리지에 보관되므로 통합 흐름에서 동시에 처리되는 메시지 수를 제한할 수 있습니다.

조정된 스케줄 작업 할당자 통합은 스케줄에 의해 트리거됩니다. 선택한 날짜와 시간에 데이터베이스에서 요청을 복사하도록 이 통합 실행의 일정을 잡을 수 있습니다. 통합 빈도를 정의할 수도 있습니다. 이러한 요청은 비동기 프로세서 통합으로 전달됩니다. 비동기 프로세서 통합은 수신 요청을 처리하고 다운스트림 애플리케이션으로 전송합니다.

설계 구성요소

고급 설계에는 세 가지 통합과 데이터베이스가 있습니다. 계정 생성을 예로 들지만 실제로는 Oracle SaaS REST API로 노출되는 비즈니스 객체가 있을 수 있습니다.

POST 요청

요청 지속 통합은 REST 트리거 엔드포인트를 노출합니다. 이 엔드포인트는 업스트림 애플리케이션(클라이언트)에서 호출하여 계정 생성 요청을 게시할 수 있습니다.

이 영구 통합은 클라이언트 애플리케이션에서 수신되는 즉시 계정 생성 요청을 Autonomous Transaction Processing 데이터베이스로 로드하고 HTTP 202/Accepted로 수신을 확인합니다. 계정 ID 및 전체 페이로드는 후속 처리를 위해 주차장 테이블에 보관됩니다.

주차장 테이블로 요청 로드

Autonomous Transaction Processing 데이터베이스에는 처리 전에 수신된 모든 요청이 보관되는 주차장 테이블이 포함됩니다. 단순성을 위해 페이로드를 지속하고 요청 상태 및 오류 정보를 추적하는 간단한 테이블이 표시됩니다.

계정 생성 JSON 요청 페이로드는 주차장 테이블에 완전히 문자열로 저장됩니다. 테이블에 페이로드를 표시하는 것이 바람직하지 않은 CLOB 또는 인코딩된 문자열로 저장하는 사용 사례가 있을 수 있습니다. 그러나 페이로드를 json으로 저장하면 오류 다시 제출 중 페이로드를 변경할 수 있습니다.

원하는 경우 전체 JSON 요청을 테이블에 저장할 수 있습니다. 이 작업은 다음 두 단계로 수행할 수 있습니다.
  • 스키마 파일 생성을 위해 요청 페이로드의 JSON 샘플을 사용하는 단계 Write입니다.
  • 불투명 스키마를 사용하는 단계 Read Entire File 작업입니다.

    JSON 페이로드 문자열의 base64 인코딩 값을 제공합니다. 그런 다음 내장 함수 decodebase64(opaqueElement)를 mapper(또는 assign)에 사용하여 JSON 문자열 값 !을 가져올 수 있습니다. 단계 읽기 중에 사용되는 불투명 스키마 xsd 파일은 GitHub에서 사용할 수 있습니다. 이 파일은 이 해답의 뒷부분에서 설명합니다.

스케줄에 따른 발송 요청

일정이 잡힌 통합은 필요한 빈도로 실행되도록 일정이 잡혀 있습니다. 실행 시마다 각 요청을 처리할 비동기 프로세서 통합으로 전달하여 구성된 개수의 요청 및 루프를 인출합니다.

많은 요청을 스케줄링된 매개변수로 인출하여 요청 처리를 제한하거나 가속화하고 값을 동적으로 변경하도록 구성할 수 있습니다. 예를 들어, 주차장 테이블의 요청이 요청 상태에 따라 인출되는 방식으로 테이블을 설정할 수 있습니다. NEW 및 ERROR_RETRY 상태 요청을 인출하고 처리를 위해 전달할 수 있습니다.

그런 다음 이 예약된 디스패처는 인출된 요청 수를 루프 처리하고 계정 생성을 위해 각 요청을 비동기 프로세서로 전달합니다. Scheduler(상위) 흐름이 한 가지 방법으로 Asynchronous Integration(하위) 흐름을 호출하는지 확인합니다. 비동기 프로세서는 응답을 반환하지 않으므로 스케줄러 스레드는 해제되어 나머지 요청을 반복하여 전달합니다. 이렇게 하면 특별한 스케줄링 사용 사례에 사용되는 스케줄러 스레드가 장기 처리에서 유지되지 않습니다. 요청 처리 자체의 업무 논리는 Oracle Integrations에서 사용할 수 있는 비동기 처리 리소스에 의해 처리됩니다.

스케줄링된 통합관리에 대한 몇 가지 모범 사례는 다음과 같습니다. 스케줄링된 통합에서 비동기 핸드오프를 사용하여 비즈니스 로직과 스케줄링 논리를 항상 분리하십시오. 이렇게 하면 스케줄러 스레드가 계정 생성에 사용되지 않습니다.
  • 일정이 잡힌 조정은 일정 잡기 플로우의 특정 요구사항을 충족하기 위한 것이며, 비동기 핸드오프를 사용하여 플로우를 해제하면 많은 수의 요청을 처리할 때 솔루션을 확장 및 수행할 수 있습니다.
  • 일정이 잡힌 조정은 앱 방식 조정의 대체로 사용해서는 안됩니다.

조정된 통합에 작업을 추가할 수 있습니다. for-each 동작을 사용하는 경우 반복 요소를 반복하고 for-each 동작 범위 내에서 하나 이상의 동작을 실행할 수 있습니다. 루프 반복 횟수는 사용자가 선택한 반복 요소를 기반으로 합니다. 예를 들어, 여러 파일을 다운로드했으며 파일 출력을 반복하려는 통합이 있을 수 있습니다. for-each 작업을 통해 이 작업을 수행할 수 있습니다. for-each 루프 중 일부에 대해 Process Items in Parallel을 선택할 수 있습니다. 이렇게 하면 for-each 루프 내의 작업이 통합에 의해 일괄 처리되고 병렬로 실행됩니다. 통합에서 병렬화를 무시하는 특정 조건이 있습니다. 이 경우 동시성 문제를 방지하기 위해 병렬도가 1로 설정됩니다.

계정 생성

비동기 프로세서 통합은 예약된 디스패처에서 들어오는 요청을 처리하고 다운스트림 애플리케이션으로 보냅니다.

비동기 프로세서는 REST 인터페이스를 노출합니다. 이 통합은 스케줄러 통합을 해제하기 위해 단방향 비동기 흐름으로 모델링되어야 합니다. 비동기 통합을 한 가지 방법으로 설정할 때는 REST 트리거가 POST 메소드를 노출하고 REST 플로우가 클라이언트에 응답을 반환하지 않는지 확인하십시오.
  1. REST 끝점 구성 마법사에서 이 두 가지를 구성할 수 있습니다.
    1. REST 어댑터가 아직 나열되지 않은 경우 통합 캔버스의 트리거 창에서 REST를 누릅니다.
    2. 통합 연결을 캔버스의 시작 아래에 있는 더하기 아이콘으로 끕니다. 그러면 REST 끝점 구성 구성 마법사가 표시됩니다.
  2. On the Basic Info page of the wizard, select POST from the drop-down list for What action do you want to perform on the endpoint?
  3. 이 끝점에 대한 요청 페이로드 구성 끝점을 선택합니다.

비동기 흐름은 실제 계정 생성을 수행하므로 주차장 테이블의 요청 상태를 업데이트합니다. 계정 생성에 성공하면 주차장 테이블의 STATUS 열이 PROCESSED로 업데이트됩니다.

실패한 요청 처리

실패한 요청의 다시 제출은 주차장 테이블에서 제어할 수 있습니다. 범위 레벨 오류 처리기는 계정 생성 중 오류를 처리하고 오류에 대해 상태를 ERRORED로 업데이트합니다. 사유 및 오류 세부정보도 주차장 테이블에서 업데이트됩니다. 이 기능은 나중에 요청을 다시 제출할 수 있는지 여부를 결정하는 데 유용합니다. 오류 통지 전자메일을 통합 관리자에게 전송할 수도 있습니다.

결함 처리기가 실패한 요청을 주차장 테이블에서 ERRORED 상태로 설정합니다. 이러한 요청은 테이블에서 ERROR_RETRY 상태로 업데이트할 수 있으며, 일정이 잡힌 작업 할당자의 Autonomous Transaction Processing 데이터베이스 호출의 선택 조건으로 인해 재처리를 위한 다음 일정에서 선택됩니다.

이러한 재제출을 트리거하는 다양한 옵션이 있습니다.
  • 관리자가 데이터베이스의 ERROR_RETRY에 대한 ERRORED 요청 업데이트를 수행할 수 있습니다.
  • 일별 또는 원하는 빈도를 실행하는 다시 제출 통합 플로우를 추가하고 모든 ERRORED 레코드를 ERROR_RETRY로 업데이트할 수도 있습니다.
  • 비동기 프로세서 통합의 결함 처리기는 상태를 ERROR_RETRY로 직접 설정할 수 있으므로 모든 실패가 다음 일정에 자동으로 다시 제출됩니다.

페이로드 수정

주차장 테이블에 계정 생성 페이로드를 저장하면 다시 제출하기 전에 데이터 오류의 페이로드를 수정할 수 있습니다. 페이로드를 업데이트하고 상태 열을 ERROR_RETRY로 설정하여 수정된 페이로드가 있는 요청을 다시 제출합니다.