일반적으로 Salesforce를 구현할 때 다른 응용 프로그램과 통합해야 합니다. 각 통합 시나리오는 고유하지만 개발자와 설계자가 해결해야 하는 공통 요구 사항 및 문제가 있습니다.

이 문서에서는 이러한 일반적인 통합 시나리오에 대한 전략(패턴 형태)을 설명합니다. 각 패턴은 특정 구현을 자세히 설명하는 대신 특정 시나리오에 대한 설계 및 접근 방식을 설명합니다. 이 문서에서 다음을 찾을 수 있습니다.

• 핵심 "대형" 통합 시나리오를 다루는 여러 패턴
• 시나리오에 가장 적합한 패턴을 결정하는 데 도움이 되는 선택 매트릭스
• 통합 팁 및 모범 사례

목적 및 범위

이 문서는 Salesforce Platform을 엔터프라이즈의 다른 응용 프로그램과 통합해야 하는 디자이너 및 설계자를 위한 것입니다. 이 콘텐츠는 Salesforce 아키텍처 및 파트너가 성공적으로 구현한 수많은 구현 내용의 추출입니다.

대규모 Salesforce 기반 응용 프로그램 채택에 사용할 수 있는 통합 기능 및 옵션을 숙지하려면 패턴 요약 및 패턴 선택 가이드를 참조하십시오. 설계자 및 개발자는 Salesforce 통합 프로젝트의 설계 및 구현 단계에서 해당 패턴 세부 사항 및 성공 사례를 고려해야 합니다.

올바르게 구현되면 해당 패턴을 사용하면 가능한 한 빠르게 프로덕션으로 이동하고 가능한 한 안정적이고 확장 가능하며 유지보수 없이 애플리케이션 집합을 사용할 수 있습니다. Salesforce의 자체 컨설팅 아키텍처는 이러한 패턴을 아키텍처 검토 시 참조 지점으로 사용하고 적극적으로 유지 및 개선합니다.

모든 패턴과 마찬가지로 이 콘텐츠는 대부분의 통합 시나리오에 적용되지만 전부는 적용되지 않습니다. Salesforce는 사용자 인터페이스(UI) 통합을 허용하지만, 예를 들어, 이러한 통합은 이 문서의 범위를 벗어납니다.

패턴 템플릿

각 통합 패턴은 일관된 구조를 따릅니다. 이렇게 하면 각 패턴에 제공되는 정보가 일관되고 패턴을 더 쉽게 비교할 수 있습니다.

이름

패턴에 포함된 통합 유형을 나타내는 패턴 식별자입니다.

컨텍스트

패턴이 해결하는 전체 통합 시나리오입니다. 컨텍스트는 사용자가 달성하려는 작업과 응용 프로그램이 요구 사항을 지원하기 위해 동작하는 방법에 대한 정보를 제공합니다.

문제

패턴이 해결하도록 설계된 시나리오 또는 문제(질문으로 표시)입니다. 패턴을 검토할 때 패턴이 통합 시나리오에 적합한지 빠르게 이해하려면 이 섹션을 읽으십시오.

Forces

설명된 시나리오를 해결하기 어려운 제약 및 상황입니다.

솔루션

통합 시나리오를 해결하는 권장 방법입니다.

스케치

솔루션이 시나리오를 해결하는 방식을 보여주는 UML 순서 다이어그램

결과

통합 시나리오에 솔루션을 적용하는 방법과 해당 시나리오와 관련된 힘을 해결하는 방법에 대한 세부 사항을 설명합니다. 이 섹션에는 패턴 적용으로 인해 발생할 수 있는 새로운 문제도 포함되어 있습니다.

사이드바

주요 기술 문제, 패턴 변형, 패턴별 문제 등을 포함하는 패턴과 관련된 추가 섹션입니다.

예제

설계 패턴이 실제 Salesforce 시나리오에서 사용되는 방식을 설명하는 전체 시나리오입니다. 이 예에서는 통합 목표 및 해당 목표를 달성하기 위해 패턴을 구현하는 방법을 설명합니다.

패턴 요약

다음 표에 이 문서에 포함된 통합 패턴이 나열되어 있습니다.

모형 목록 remote-process-invocation--request-and-reply

모형 접근 방식

이 문서의 통합 패턴은 다음 세 가지 범주로 분류됩니다.

• 데이터 통합 - 이러한 패턴은 두 시스템 모두에 항상 시기적절하고 의미 있는 데이터가 포함되도록 두 시스템 이상에 있는 데이터를 동기화하는 요구 사항을 해결합니다. 데이터 통합은 구현하기 가장 간단한 통합 유형이지만, 솔루션을 지속 가능하고 비용 효율적으로 만들기 위해 적절한 정보 관리 기술이 필요합니다. 해당 기술에는 마스터 데이터 관리(MDM), 데이터 거버넌스, 마스터링, 중복 제거, 데이터 플로 설계 등을 포함하는 경우가 많습니다.

• 프로세스 통합 - 이 범주의 패턴은 비즈니스 프로세스에서 두 개 이상의 응용 프로그램을 활용하여 과업을 완료해야 하는 필요성을 해결합니다. 이 유형의 통합에 대한 솔루션을 구현할 경우 트리거 응용 프로그램이 프로세스 경계를 넘어 다른 응용 프로그램을 호출해야 합니다. 일반적으로 이러한 패턴에는 오케스트레이션(하나의 응용 프로그램이 중앙 "컨트롤러")과 연도(응용 프로그램이 다중 참가자이고 중앙 "컨트롤러"가 없는)이 모두 포함됩니다. 이러한 통합에는 종종 복잡한 설계, 테스트, 예외 처리 요구 사항이 필요합니다. 또한 이러한 복합 응용 프로그램은 종종 장기 실행 트랜잭션을 지원하고 프로세스 상태를 보고하거나 관리할 수 있으므로 기본 시스템에 더 많은 요구 사항을 부여합니다.

• 가상 통합 - 이 범주의 패턴은 사용자가 외부 시스템에 저장된 데이터를 보고 검색하고 수정해야 하는 문제를 해결합니다. 이 유형의 통합에 대한 솔루션을 구현할 경우 트리거 응용 프로그램이 다른 응용 프로그램을 콜아웃하고 데이터와 실시간으로 상호 작용해야 합니다. 이러한 통합 유형을 사용하면 시스템 전체에서 데이터 복제가 필요하지 않으며 사용자가 항상 최신 데이터와 상호 작용합니다.

시스템에 가장 적합한 통합 전략을 선택하는 것은 중요하지 않습니다. 고려해야 할 여러 측면과 사용할 수 있는 도구가 많으며, 일부 도구는 특정 과업에 다른 도구보다 적합합니다. 각 패턴은 각 시스템의 성능, 데이터 용량, 오류 처리, 트랜잭션성 등 특정 중요 영역을 다룹니다.

패턴 선택 가이드

선택 매트릭스 테이블에 패턴 및 주요 측면이 나열되어 통합 요구 사항에 가장 적합한 패턴을 결정할 수 있습니다. 패턴은 다음 차원을 사용하여 분류됩니다.

Salesforce와 다른 시스템 통합

이 표에는 Salesforce에서 다른 시스템으로 통합할 때 요구 사항에 가장 적합한 패턴을 결정하는 데 도움이 되는 패턴 및 주요 측면이 나열되어 있습니다.

Salesforce와 다른 시스템 통합

이 표에는 다른 시스템에서 Salesforce로 통합할 때 요구 사항에 가장 적합한 패턴을 결정하는 데 도움이 되는 패턴 및 주요 측면이 나열되어 있습니다.

Middleware 용어 및 정의

이 표에는 미들웨어와 관련된 몇 가지 주요 용어와 해당 패턴과 관련된 정의가 나열되어 있습니다.

컨텍스트

Salesforce를 사용하여 리드를 추적하고, 파이프라인을 관리하고, 기회를 만들고, 리드를 고객으로 전환하는 주문 세부 사항을 수집합니다. 그러나 Salesforce 시스템은 주문을 포함하거나 처리하지 않습니다. Salesforce에서 주문 세부 사항을 수집하면 주문이 완료될 때까지 주문을 관리하는 원격 시스템에서 생성됩니다.

이 패턴을 구현하면 Salesforce에서 원격 시스템을 호출하여 주문을 만든 다음, 완료를 기다립니다. 성공하면 원격 시스템에서 주문 상태 및 주문 번호와 동기식으로 회신합니다. Salesforce는 같은 트랜잭션의 일부로 내부적으로 주문 번호 및 상태를 업데이트합니다. 주문 번호는 후속으로 원격 시스템을 업데이트하기 위해 외부 키로 사용됩니다.

문제

Salesforce에서 이벤트가 발생하면 원격 시스템에서 프로세스를 시작하고, 해당 프로세스에 필수 정보를 전달하고, 원격 시스템에서 응답을 수신한 다음, 해당 응답 데이터를 사용하여 Salesforce 내에서 업데이트를 수행하는 방법은 무엇입니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 다음의 요인을 고려하십시오.

• 원격 시스템 호출 시 Salesforce가 계속 처리하기 전에 응답을 기다려야 합니까? 원격 시스템에 대한 호출이 동기식 요청 회신인지 비동기식 요청인지 여부
• 원격 시스템에 대한 호출이 동기식일 경우 Salesforce에서 초기 통화와 동일한 트랜잭션의 일부로 응답을 처리해야 합니까?
• 메시지 크기가 작거나 크나요?
• 통합은 Salesforce 사용자 인터페이스에서 버튼 클릭과 같은 특정 이벤트 발생 또는 DML 기반 이벤트를 기반으로 합니까?
• 원격 끝점이 대기 시간이 낮은 경우 요청에 응답할 수 있습니까? 최대 기간 동안 이 트랜잭션을 실행할 가능성이 높은 사용자는 몇 명입니까?

솔루션

이 표에는 이 통합 문제에 대한 솔루션이 포함되어 있습니다.

스케치

이 다이어그램은 Apex 호출을 사용하여 동기식 원격 프로세스 호출을 보여줍니다.

Remote System으로 Salesforce 호출

다운로드 다이어그램

이 시나리오의 경우:

• Lightning 페이지에서 작업이 시작됩니다(예: 버튼 클릭).
• 브라우저(Lightning 구성 요소의 경우 클라이언트측 컨트롤러를 통해)는 HTTP POST를 수행하여 해당 Apex 컨트롤러에서 작업을 수행합니다.
• 컨트롤러가 원격 웹 서비스에 대한 실제 호출을 호출합니다.
• 원격 시스템의 응답이 Apex 컨트롤러로 반환됩니다. 컨트롤러가 응답을 처리하고 필요에 따라 Salesforce의 데이터를 업데이트한 후 페이지를 다시 렌더링합니다.

후속 상태를 추적해야 하는 경우 원격 시스템에서 Salesforce 레코드에 저장된 고유 식별자를 반환합니다.

결과

이 패턴과 관련된 솔루션을 적용하면 Salesforce가 처리를 처리하는 이벤트 시작 원격 프로세스 호출을 사용할 수 있습니다.

통화 기법

호출 메커니즘은 이 패턴을 구현하기 위해 선택한 솔루션에 따라 다릅니다.

오류 처리 및 복구

전체 솔루션의 일부로 오류 처리 및 복구 전략을 포함하는 것이 중요합니다.

• 오류 처리 - 오류가 발생하면(예외 또는 오류 코드가 발신자에게 반환됨) 발신자가 오류 처리를 관리합니다. 예를 들어 최종 사용자의 페이지에 표시되거나 추가 조치가 필요한 테이블에 기록된 오류 메시지가 있습니다.

• 복구 - 발신자가 성공적인 응답을 받을 때까지 변경 사항이 Salesforce에 적용되지 않습니다. 예를 들어, 성공을 나타내는 응답이 수신될 때까지 데이터베이스에서 주문 상태가 업데이트되지 않습니다. 필요한 경우 발신자가 작업을 다시 시도할 수 있습니다.

동임 설계 고려 사항

동일한 기능을 사용하면 반복 호출이 안전합니다. 기울임을 구현하지 않을 경우 동일한 메시지를 반복적으로 호출하면 결과가 다를 수 있으므로 데이터 무결성 문제가 발생할 수 있습니다. 잠재적인 문제는 중복 레코드 생성 또는 트랜잭션의 중복 처리가 포함됩니다.

호출되는 원격 절차가 동일하게 적용되는지 확인해야 합니다. 통화가 사용자 인터페이스를 통해 이루어지는 경우 특히 Salesforce에서 한 번만 통화할 수 있는 보증이 없는 경우 통합 계층의 역능을 관리해야 합니다.

자격 증명 수신기를 구축하는 가장 일반적인 방법은 소비자가 보낸 고유한 메시지 식별자를 기반으로 중복을 추적하는 것입니다. Apex 웹 서비스 또는 REST 호출은 고유한 메시지 ID를 보내도록 사용자 정의해야 합니다.

또한 원격 시스템에서 레코드를 만드는 작업을 삽입하기 전에 중복 항목을 확인해야 합니다. Salesforce에서 고유한 레코드 ID를 전달하여 확인합니다. 레코드가 원격 시스템에 있는 경우 레코드를 업데이트합니다. 대부분의 시스템에서 이 작업을 업서트 작업이라고 합니다.

보안 고려 사항

원격 시스템에 대한 모든 호출은 요청의 기밀성, 무결성, 가용성을 유지해야 합니다. 다음 보안 고려 사항은 이 패턴에서 Apex SOAP 및 HTTP 호출을 사용하는 경우에만 적용됩니다.

• 단방향 SSL은 기본적으로 활성화되지만, 클라이언트와 서버의 인증을 유지하기 위해 자체 서명 및 CA 서명 인증서 모두에서 양방향 SSL이 지원됩니다.

• Apex 코드를 간소화하고 인증된 콜아웃의 설정을 간소화하려면 콜아웃 끝점에 명명된 자격 증명을 지정합니다.

• 외부 시스템과의 통합을 위한 인증 메커니즘으로 OAUTH 2.0을 사용할 것을 고려하십시오.

• 필요한 경우 Apex Crypto 클래스 방법을 사용하여 단방향 해시 또는 디지털 서명을 사용하여 요청 무결성을 보장합니다.

• 적절한 방화벽 메커니즘을 구현하여 원격 시스템을 보호해야 합니다. 보안 고려 사항을 참조하십시오.

• Salesforce는 현재 WS 보안을 지원하지 않습니다. 이러한 복잡한 WS-Security 머리글을 기본적으로 생성하거나 수신 WSDL에서 자동으로 적용하지는 않지만 수동으로 생성하여 사용자 지정 Apex 클래스를 만들어 수신 요청에 대한 SOAP 머리글 및 보안 토큰을 처리할 수 있습니다.

사이드바

없음.

적시성

이 패턴에서 시기는 매우 중요합니다. 일반적으로:

• 일반적으로 요청은 사용자 인터페이스에서 호출되므로 프로세스에서 사용자가 대기하지 않아야 합니다.
• Salesforce에서는 Apex 호출에 대해 구성 가능한 시간 제한이 최대 120초입니다.
• Salesforce 시간 초과 제한 내 및 사용자 기대 내에서 완료되도록 적시에 원격 프로세스 완료가 실행됩니다.
• 외부 호출에는 Apex 동기화 트랜잭션 총괄자 제한이 적용되므로 각각 5초 이상 실행되는 50개 이상의 트랜잭션이 인스턴스화되는 위험을 완화하십시오. 외부 끝점의 성능을 보장하는 것 외에도 시간 초과 위험을 완화하는 옵션은 다음과 같습니다.
  • 외부 콜아웃의 시간 초과를 5초로 설정합니다.
  • Lightning 구성 요소의 연속을 사용하여 장기 실행 트랜잭션 처리

데이터 볼륨

이 패턴은 Apex 호출 솔루션의 시간 초과 값이 작고 요청 또는 응답의 최대 크기 때문에 소량의 실시간 활동에 주로 사용됩니다. 메시지에 데이터 페이로드가 포함된 배치 처리 활동에서는 이 패턴을 사용하지 마십시오.

엔드포인트 기능 및 표준 지원

끝점에 대한 기능 및 표준 지원은 선택한 솔루션에 따라 다릅니다.

국가관리

시스템을 통합할 때 키는 진행 중인 상태 추적에 중요합니다. 두 가지 옵션이 있습니다.

• Salesforce는 원격 레코드에 대한 원격 시스템의 기본 또는 고유 대리 키를 저장합니다.
• 원격 시스템에 Salesforce 고유 레코드 ID 또는 기타 고유한 대리 키가 저장됩니다.

다음 표에 표시된 바와 같이 마스터 레코드가 포함된 시스템에 따라 통합 키를 처리하기 위한 특정 고려 사항이 있습니다.

복잡한 통합 시나리오

특정 사례에서 이 패턴에 따라 규정된 솔루션을 사용하려면 몇 가지 복잡한 통합 시나리오를 구현해야 할 수 있습니다. 미들웨어를 사용하거나 Salesforce에서 복합 서비스를 호출하는 것이 가장 좋습니다. 다음 시나리오는 다음과 같습니다.

• 복잡한 플로 논리와 관련된 비즈니스 프로세스 및 규칙 오케스트레이션
• 다중 시스템 통화 전반의 통화 및 통화 결과 집계
• 인바운드 및 아웃바운드 메시지 모두 변환
• 다중 시스템에 대한 통화 전반의 트랜잭션 무결성 유지

총리 제한

Apex 제한에 대한 자세한 내용은 Apex 개발자 가이드의 실행 총괄자 및 제한을 참조하십시오.

Middleware 기능

다음 표는 이 패턴에 참여하는 미들웨어 시스템의 원하는 속성을 강조 표시합니다.

예제

유틸리티 회사는 Salesforce를 사용하며 고객 청구 정보를 포함하는 별도의 시스템이 있습니다. 주문 프로세스의 일부로 청구 시스템에 새 청구 계정을 만들어야 하며, Salesforce는 주문 활성화 프로세스 내 청구 계정 번호를 반영해야 합니다. 청구 계정을 만들 수 있으며 청구 계정 번호를 응답으로 반환하는 기존 웹 서비스를 보유하고 있습니다.

다음 접근 방식을 사용하여 이 요구 사항을 충족할 수 있습니다.

1. Salesforce는 Apex 프록시 클래스에서 청구 계정 서비스 WSDL을 사용합니다.
2. 사용자 정의 Apex 컨트롤러 또는 외부 서비스에서 외부 웹 서비스에 전달된 고객 정보를 사용하여 Apex 프록시 클래스를 실행합니다.
3. 그런 다음, 사용자 정의 컨트롤러는 Apex 콜아웃에서 반환 값을 구문 분석하고 해당 정보를 salesforce 개체에 저장합니다.

이 예는 다음을 보여줍니다.

• 고객의 상태는 Salesforce 계정 개체에 저장된 계정 번호로 추적됩니다.
• 발신자의 후속 회신 메시지 처리

컨텍스트

Salesforce를 사용하여 리드를 추적하고, 파이프라인을 관리하고, 기회를 만들고, 리드를 고객으로 전환하는 주문 세부 사항을 수집합니다. 그러나 주문 관리 프로세스의 일부로 주문 청구 시스템에서 청구 계정을 만들어야 합니다.

이 패턴을 구현하면 Salesforce에서 원격 시스템을 호출하여 청구 계정을 만들지만 통화가 성공적으로 완료될 때까지 기다리지 않습니다. 경우에 따라 원격 시스템에서 별도의 트랜잭션에서 생성된 새 청구 계정을 사용하여 Salesforce를 업데이트할 수 있습니다.

문제

Salesforce에서 이벤트가 발생하면 원격 시스템에서 프로세스를 시작하고 원격 시스템의 응답을 기다리지 않고 필요한 정보를 해당 프로세스에 전달하는 방법은 무엇입니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 다음의 요인을 고려하십시오.

• 원격 시스템 호출 시 Salesforce가 계속 처리하기 전에 응답을 기다려야 합니까? 원격 시스템에 대한 호출이 동기식이거나 비동기식입니까?
• 원격 시스템에 대한 호출이 동기식일 경우 통화와 동일한 트랜잭션의 일부로 Salesforce에서 응답을 처리해야 합니까?
• 메시지 크기가 작습니까?
• 통합은 Salesforce 사용자 인터페이스에서 버튼 클릭과 같은 특정 이벤트 발생 또는 DML 기반 이벤트를 기반으로 합니까?
• Salesforce에서 원격 시스템으로의 보증된 메시지 전달이 요구 사항입니까?
• 원격 시스템이 Salesforce에서 계약을 지정하는 계약 우선 통합에 참여할 수 있습니까? 일부 솔루션 변형(예: 아웃바운드 메시징)에서 Salesforce는 원격 시스템 끝점에서 구현하는 계약을 지정합니다.
• 끝점 또는 엔터프라이즈 서비스 버스(ESB)가 장기간 폴링을 지원합니까?
• 선언적 구성 방법은 사용자 정의 Apex 개발보다 선호합니까? 이 경우 플랫폼 이벤트와 같은 솔루션이 Apex 콜아웃보다 선호됩니다.

솔루션

다음 표에는 이 통합 문제에 대한 솔루션이 포함되어 있습니다.

스케치

다음 다이어그램은 레코드에 대한 작업을 만들거나 업데이트하면 통화가 트리거되는 Salesforce에서 원격 시스템으로의 통화를 보여줍니다.

다운로드 다이어그램

이 시나리오의 경우:

1. 원격 시스템에서 플랫폼 이벤트를 구독합니다.
2. Salesforce의 지정된 레코드 집합에 업데이트 또는 삽입이 발생합니다.
3. 조건 집합이 충족되면 Salesforce 플로가 트리거됩니다.
4. 이 플로는 플랫폼 이벤트를 만듭니다.
5. 원격 수신기가 이벤트 메시지를 수신하고 메시지를 로컬 대기열에 배치합니다.
6. 대기열 응용 프로그램이 처리를 위해 원격 응용 프로그램에 메시지를 전달합니다.

원격 시스템이 Salesforce에 대한 작업을 수행해야 하는 경우 콜백 작업(옵션)을 구현할 수 있습니다.

결과

이 패턴과 관련된 솔루션을 적용하면 다음이 가능합니다.

• 최종 사용자에게 트랜잭션 결과를 표시할 수 있는 사용자 인터페이스 시작 원격 프로세스 호출
• 통화 프로세스에서 트랜잭션 결과를 처리할 수 있는 DML 이벤트 시작 원격 프로세스 호출

통화 기법

호출 메커니즘은 이 패턴을 구현하기 위해 선택한 솔루션에 따라 다릅니다.

오류 처리 및 복구

오류 처리 및 복구 전략은 전체 솔루션의 일부로 간주해야 합니다. 가장 적합한 방법은 선택한 솔루션에 따라 다릅니다.

동임 설계 고려 사항

플랫폼 이벤트는 버스에 한 번만 게시됩니다. Salesforce 측에서는 재시도하지 않습니다. ESB는 이벤트 재생을 요청할 수 있습니다. 재생 시 플랫폼 이벤트의 재생 ID는 동일하게 유지되며 ESB는 재생 ID를 기반으로 중복 메시지를 시도할 수 있습니다.

아웃바운드 메시징은 비동기식이므로 긍정적인 승인이 수신되지 않으면 재시도가 시작됩니다. 따라서 원격 서비스는 Salesforce의 메시지를 동일한 방식으로 처리할 수 있어야 합니다.

아웃바운드 메시지는 메시지당 고유 ID를 보내며 이 ID는 재시도에 대해 동일하게 유지됩니다. 원격 시스템에서 이 고유 ID를 기반으로 중복 메시지를 추적할 수 있습니다. 업데이트되는 각 레코드의 고유 레코드 ID도 전송되며 중복 레코드 생성을 방지하기 위해 사용할 수 있습니다.

원격 프로세스 호출 - 요청 및 회신 패턴의 일치하는 디자인 고려 사항도 이 패턴에 적용됩니다.

보안 고려 사항

원격 시스템에 대한 모든 호출은 요청의 기밀성, 무결성, 가용성을 유지해야 합니다. 선택한 솔루션에 따라 다양한 보안 고려 사항이 적용됩니다.

보안 고려 사항을 참조하십시오.

사이드바

없음.

적시성

타이밍은 잊혀질 패턴의 요소가 아닙니다. 제어는 즉시 또는 원격 시스템에 성공적으로 전달되었음을 긍정적으로 확인한 후에 클라이언트에게 다시 전달됩니다. Salesforce 아웃바운드 메시지를 사용하면 24시간 이내에 확인이 수행되어야 합니다(7일로 연장 가능). 그렇지 않으면 메시지가 만료됩니다. 플랫폼 이벤트의 경우 Salesforce는 이벤트 버스에 이벤트를 보내고 구독자의 확인 또는 승인을 기다리지 않습니다. 구독자가 메시지를 받지 않을 경우 구독자는 이벤트 회신 ID를 사용하여 이벤트를 재생하도록 요청할 수 있습니다. 대용량 이벤트 메시지는 72시간(3일) 동안 저장됩니다. 지난 이벤트 메시지를 검색하려면 CometD 클라이언트를 사용하여 채널을 구독합니다.

데이터 볼륨

데이터 용량 고려 사항은 선택한 솔루션에 따라 다릅니다. 각 솔루션의 제한 사항은 Salesforce 제한 빠른 참조를 참조하십시오.

엔드포인트 기능 및 표준 지원

끝점에 대한 기능 및 표준 지원은 선택한 솔루션에 따라 다릅니다.

국가관리

시스템을 통합할 때 지속적인 상태 추적에 고유한 레코드 식별자가 중요합니다. 예를 들어, 레코드가 원격 시스템에서 생성된 경우 두 가지 옵션을 사용할 수 있습니다.

• Salesforce는 원격 레코드에 대한 원격 시스템의 기본 또는 고유 대리 키를 저장합니다.
• 원격 시스템에 Salesforce 고유 레코드 ID 또는 기타 고유한 대리 키가 저장됩니다.

다음 표에 이 패턴의 시/도 관리에 대한 고려 사항이 나열되어 있습니다.

복잡한 통합 시나리오

이 패턴의 각 솔루션은 변환 및 프로세스 오케스트레이션과 같은 복잡한 통합 시나리오에 대해 서로 다른 고려 사항을 적용합니다.

총리 제한

Salesforce Platform의 멀티테넌트 특성으로 인해 아웃바운드 콜아웃에 제한이 있습니다. 제한은 아웃바운드 통화 유형 및 통화 시기에 따라 다릅니다.

플랫폼 이벤트에 적용되는 제한 및 할당은 플랫폼 이벤트 개발자 가이드를 참조하십시오.

신뢰할 수 있는 메시징

신뢰할 수 없는 개별 구성 요소가 있는 원격 시스템에 메시지 전달을 보장하는 문제를 해결하기 위해 신뢰할 수 있는 Messaging을 시도합니다. 원격 시스템에서 메시지를 수신하는 방법은 선택한 솔루션에 따라 다릅니다.

Salesforce 변경 데이터 수집 경우 변경 이벤트 유형이 Salesforce 응용 프로그램 서버에서 포착되지 않은 변경 사항 캡처 또는 대량 변경 사항을 처리하는 등 특수 상황을 처리하기 위해 제공됩니다.

경우에 따라 Salesforce가 변경 이벤트 대신 간격 이벤트를 전송하여 구독자에게 오류를 알리거나 변경 이벤트를 생성할 수 없는 경우도 있습니다. 간격 이벤트에는 변경 유형 및 레코드 ID와 같은 머리글의 변경 사항에 대한 정보가 포함됩니다. 레코드 필드 등 변경 사항에 대한 세부 사항은 포함되지 않습니다. 변경 사항을 보다 효율적으로 수집하기 위해 임계값을 초과하는 단일 트랜잭션에 대해 오버플로 이벤트가 생성됩니다. 자세한 내용은 여기를 참조하십시오.

Middleware 기능

다음 표는 이 패턴에 참여하는 미들웨어 시스템의 원하는 속성을 강조 표시합니다.

솔루션 변형—플랫폼 이벤트: 게시 동작 및 트랜잭션

플랫폼 이벤트 메시지가 즉시 게시되면 이벤트 게시가 게시 프로세스의 트랜잭션 경계를 준수하지 않습니다. 트랜잭션이 완료되기 전에 또는 트랜잭션이 실패한 경우에도 이벤트 메시지를 게시할 수 있습니다. 이 동작은 구독자가 게시 트랜잭션이 커밋하는 데이터를 찾을 것으로 예상하는 경우 문제가 발생할 수 있습니다. 구독자가 이벤트 메시지를 수신할 때 데이터가 표시되지 않을 수 있습니다. 이 문제를 해결하려면 이벤트 정의에서 플랫폼 이벤트 게시 동작을 커밋 후 게시로 설정합니다. 플랫폼 이벤트 정의에서 설정할 수 있는 게시 동작은 다음과 같습니다.

• 커밋 후 게시 - 트랜잭션이 성공적으로 커밋된 후에만 이벤트 메시지가 게시됩니다. 구독자가 게시 트랜잭션이 커밋하는 데이터에 의존하는 경우 이 옵션을 선택합니다. 예를 들어 프로세스에서 이벤트 메시지를 게시하고 과업 레코드를 만듭니다. 이벤트를 구독하는 두 번째 프로세스가 실행되고 과업 레코드를 찾을 것으로 예상됩니다. 이 동작을 선택하는 또 다른 이유는 트랜잭션이 실패할 경우 이벤트 메시지를 게시하지 않으려는 경우입니다.
• 즉시 게시 - 게시 호출이 실행되면 이벤트 메시지가 게시됩니다. 트랜잭션 성공 여부에 관계없이 이벤트 메시지를 게시하려는 경우 이 옵션을 선택합니다. 또한 게시자와 구독자가 독립적이고 구독자가 게시자가 커밋한 데이터에 의존하지 않는 경우 이 옵션을 선택합니다. 예를 들어 즉시 게시 동작은 로깅 목적으로 사용되는 이벤트에 적합합니다. 이 옵션을 사용하면 구독자가 게시자 트랜잭션에서 데이터를 커밋하기 전에 이벤트 메시지를 수신할 수 있습니다.

예제

통신 회사에서 Salesforce를 기회 리드 프로세스를 사용하여 계정을 만드는 프런트 엔드로 사용하려고 합니다. 기회가 마감되고 수주되면 Salesforce에 주문이 생성되지만 백엔드 ERP 시스템은 데이터 마스터입니다. 주문을 Salesforce 기회 레코드에 저장해야 하며, 주문이 생성되었음을 나타내기 위해 기회 상태가 변경됩니다.

다음 제약이 적용됩니다.

• 선언적 개발만 구현할 수 있습니다.
• 기회가 주문으로 변환된 후에는 주문 번호에 대한 즉시 알림이 필요하지 않습니다.
• 조직에 CometD 프로토콜을 지원하고 플랫폼 이벤트를 구독할 수 있는 ESB가 있습니다.

이 예는 Salesforce 플랫폼 이벤트를 사용하여 구현하는 것이 가장 좋지만 ESB가 플랫폼 이벤트를 구독해야 합니다.

Salesforce 측:

• 플로를 만들어 플랫폼 이벤트를 시작합니다(예: 기회 상태가 마감-수주로 변경되는 경우).
• 기회 세부 사항을 게시하는 새 플랫폼 이벤트를 만듭니다.

원격 시스템 측:

• ESB가 CometD 프로토콜을 사용하여 Salesforce Platform 이벤트를 구독합니다.
• ESB는 주문으로 기회를 변환하라는 알림을 하나 이상 받습니다.
• ESB가 주문을 만들 수 있도록 백엔드 ERP 시스템에 메시지를 전달합니다.
• ERP 시스템에서 주문이 생성되면 별도의 스레드가 SessionId를 인증 토큰으로 사용하여 Salesforce로 다시 호출합니다. 콜백은 주문 번호 및 상태를 사용하여 기회를 업데이트합니다. Salesforce 플랫폼 이벤트, Salesforce SOAP API, REST API 또는 Apex 웹 서비스와 같은 문서화된 패턴 솔루션을 사용하여 이 콜백을 수행할 수 있습니다.

이 예는 다음을 보여줍니다.

• 비동기식으로 호출된 원격 프로세스 구현
• 종단간 보증 배달
• 레코드 상태를 업데이트하기 위해 Salesforce에 후속 콜백

컨텍스트

CRM 구현을 Salesforce로 이동하고 다음을 수행하려고 합니다.

• 현재 CRM 시스템에서 계정, 연락처, 기회를 추출 및 변환하고 데이터를 Salesforce에 로드합니다(초기 데이터 가져오기).
• 원격 시스템에서 매주 고객 청구 데이터를 추출, 변환, Salesforce에 로드합니다(진행).
• Salesforce에서 고객 활동 정보를 추출하고 매주(진행 중) 온 프레미스 데이터 웨어하우스로 가져옵니다.

문제

데이터를 Salesforce로 가져오고 데이터를 Salesforce에서 내보내는 방법은 이러한 가져오기 및 내보내기가 업무 시간 동안 최종 사용자 작업을 방해하고 대량의 데이터를 포함할 수 있다는 점을 고려하여 무엇입니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 고려해야 할 다양한 요소가 있습니다.

• Salesforce에 데이터를 저장해야 합니까? 그렇지 않은 경우 설계자가 고려할 수 있고 고려해야 하는 기타 통합 옵션이 있습니다(예: 매시업).
• 데이터가 Salesforce에 저장되어야 하는 경우 원격 시스템의 이벤트에 대한 응답으로 데이터를 새로 고쳐야 합니까?
• 데이터를 예약된 대로 새로 고쳐야 합니까?
• 데이터가 기본 비즈니스 프로세스를 지원합니까?
• Salesforce에서 이 데이터의 가용성에 영향을 미치는 분석(보고) 요구 사항이 있습니까?

솔루션

다음 표에는 이 통합 문제에 대한 다양한 솔루션이 포함되어 있습니다.

스케치

다음 다이어그램은 Salesforce가 데이터 마스터인 이 패턴의 이벤트 순서를 보여줍니다.

다운로드 다이어그램

다음 다이어그램은 Salesforce가 데이터 마스터인 이후 이벤트의 거의 실시간 동기화를 보여줍니다.

결과

다음 시나리오에서 외부에서 소싱된 데이터를 Salesforce와 통합할 수 있습니다.

• 외부 시스템은 데이터 마스터 - Salesforce는 단일 소스 시스템 또는 여러 시스템에서 제공하는 데이터의 소비자입니다. 이 시나리오에서는 데이터를 Salesforce로 가져오기 전에 데이터를 집계하는 데이터 웨어하우스 또는 데이터 마트를 보유하는 것이 일반적입니다.
• Salesforce는 데이터 마스터입니다. Salesforce는 특정 엔티티의 레코드 시스템이며 Salesforce 변경 데이터 수집 클라이언트 응용 프로그램은 Salesforce 데이터의 변경 사항을 알 수 있습니다.

일반적인 Salesforce 통합 시나리오에서 구현 팀은 다음 중 하나를 수행합니다.

• 소스 데이터 집합에서 변경 데이터 수집 구현합니다.
• 임시 온 프레미스 데이터베이스에서 제어 테이블이라고 하는 지원 데이터베이스 구조 집합을 구현합니다.

ETL 도구를 사용하여 다음을 수행하는 프로그램을 만듭니다.

1. 제어 테이블을 읽어 작업의 마지막 실행 시간을 결정하고 필요한 기타 제어 값을 추출합니다.
2. 위의 제어 값을 필터로 사용하고 소스 데이터 집합을 쿼리합니다.
3. 확인, 보강 등 사전 정의된 처리 규칙을 적용합니다.
4. ETL 도구의 사용 가능한 커넥터/변환 기능을 사용하여 대상 데이터 집합을 만듭니다.
5. Salesforce 개체에 데이터 집합을 작성합니다.
6. 처리에 성공하면 제어 테이블의 제어 값을 업데이트합니다.
7. 처리에 실패할 경우 재시작 및 종료를 활성화하는 값을 사용하여 제어 테이블을 업데이트합니다.

노트: Salesforce에 액세스할 수 없는 경우에도 ETL 도구가 액세스할 수 있는 환경에서 제어 테이블 및 관련 데이터 구조를 만드는 것이 좋습니다. 이를 통해 충분한 복원 능력을 얻을 수 있습니다. Salesforce는 이 프로세스에서 스포크로 처리되어야 하며 ETL 인프라는 허브입니다.

ETL 도구에서 데이터 동기화 기능을 최대한 활용하려면 다음을 고려하십시오.

• ETL 작업을 연결하고 순서대로 만들어 조화로운 프로세스를 제공합니다.
• 두 시스템의 기본 키를 사용하여 수신 데이터를 일치시킵니다.
• 특정 API 메서드를 사용하여 업데이트된 데이터만 추출합니다.
• 마스터-세부 사항 또는 조회 관계에서 하위 레코드를 가져오는 경우 잠금을 피하기 위해 소스에서 상위 키를 사용하여 가져온 데이터를 그룹화합니다. 예를 들어, 연락처 데이터를 가져오는 경우 하나의 API 호출에서 단일 계정에 대한 최대 연락처 수를 로드할 수 있도록 상위 계정 키별로 연락처 데이터를 그룹화해야 합니다. 가져온 데이터를 그룹화하지 못하면 일반적으로 첫 번째 연락처 레코드가 로드되고 해당 계정에 대한 후속 연락처 레코드가 API 호출 컨텍스트에서 실패합니다.
• 트리거와 같은 가져오기 후 처리는 데이터만 선택적으로 처리해야 합니다.
• 시나리오에 대용량 데이터가 포함된 경우 이 Trailhead 모듈의 모범 사례를 따르십시오. 대용량 데이터의 배포 모범 사례
.

오류 처리 및 복구

오류 처리 및 복구 전략은 전체 솔루션의 일부로 간주해야 합니다. 가장 적합한 방법은 선택한 솔루션에 따라 다릅니다.

보안 고려 사항

원격 시스템에 대한 모든 호출은 요청의 기밀성, 무결성, 가용성을 유지해야 합니다. 선택한 솔루션에 따라 다양한 보안 고려 사항이 적용됩니다.

• Salesforce API에 대한 인증된 API 액세스를 허용하려면 최소한 “API 전용” 사용자 권한이 있는 Lightning Platform 라이센스가 필요합니다.
• 암호 액세스를 안전하게 유지하기 위해 표준 암호화를 사용하는 것이 좋습니다.
• Salesforce API를 호출할 때 HTTPS 프로토콜을 사용합니다. 필요한 경우 온 프레미스 보안 솔루션을 통해 Salesforce API에 트래픽을 프록시할 수도 있습니다.

보안 고려 사항을 참조하십시오.

사이드바

없음.

적시성

이 패턴에서는 시기는 중요하지 않습니다. 그러나 모든 배치 프로세스가 지정된 배치 기간에서 완료되도록 인터페이스를 설계하는 데 주의해야 합니다.

모든 배치 지향 작업과 마찬가지로 배치 처리 기간 동안 소스 및 대상 시스템을 보호하는 것이 좋습니다. 업무 시간 동안 배치를 로드하면 사용자의 업데이트가 실패하거나 더 중요한 것은 배치 로드(또는 부분 배치 로드)가 실패할 수 있는 충돌이 발생할 수 있습니다.

전역 운영이 있는 조직의 경우 시스템이 계속 사용 중일 수 있으므로 모든 배치 프로세스를 동시에 실행할 수 없습니다. 이러한 경우 데이터 충돌을 방지하기 위해 레코드 유형 및 기타 필터링 기준을 사용하는 데이터 세분화 기법을 사용할 수 있습니다.

국가관리

두 시스템 간에 대리 키를 사용하여 상태 관리를 구현할 수 있습니다. Salesforce 엔티티 간에 트랜잭션 관리가 필요한 경우 Apex를 사용하는 원격 호출 패턴을 사용하는 것이 좋습니다.

플랫폼에서 표준 최적의 레코드 잠금이 발생하며, API를 사용하여 업데이트한 경우 레코드를 편집하는 사용자가 레코드를 새로 고치고 트랜잭션을 시작해야 합니다. Salesforce API 컨텍스트에서 낙관적 잠금은 다음과 같은 프로세스를 말합니다.

• Salesforce는 특정 사용자가 편집하는 레코드의 상태를 유지하지 않습니다.
• 읽을 때 데이터가 추출된 시간을 기록합니다.
• 사용자가 레코드를 업데이트하고 저장하면 Salesforce에서 다른 사용자가 중간에 레코드를 업데이트했는지 확인합니다.
• 레코드가 업데이트된 경우 사용자에게 업데이트가 이루어졌음을 알리고 사용자는 업데이트를 진행하기 전에 최신 버전의 레코드를 검색해야 합니다.

Middleware 기능

이 패턴을 구현하는 데 사용되는 가장 효과적인 외부 기술은 기존 ETL 도구입니다. 선택한 미들웨어 도구가 Salesforce 대량 API를 지원하는 것이 중요합니다.

미들웨어 도구가 getUpdated() 함수를 지원하는 것은 유용하지만 중요하지는 않습니다. 이 기능은 Salesforce 플랫폼에서 표준 변경 데이터 수집 기능에 가장 가까운 구현을 제공합니다.

다음 표는 이 패턴에 참여하는 미들웨어 시스템의 원하는 속성을 강조 표시합니다.

예제

유틸리티 회사는 개별 판매 담당자 및 팀에 잠재 고객을 할당하는 메인프레임 기반 배치 프로세스를 사용합니다. 이 정보는 매일 밤 Salesforce로 가져와야 합니다.

고객이 상업적으로 사용할 수 있는 ETL 도구를 사용하여 소스 테이블에서 변경 데이터 수집 구현하기로 결정했습니다. 솔루션은 다음과 같이 작동합니다.

• Cron 유형 스케줄러는 사용자 및 팀에 잠재 고객을 할당하는 배치 작업을 실행합니다.
• 배치 작업이 실행되고 데이터가 업데이트되면 ETL 도구가 변경 데이터 수집 사용하여 이러한 변경 사항을 인식합니다. ETL 도구는 데이터 저장소의 변경 사항을 합산합니다.
• ETL 커넥터는 Salesforce REST API를 사용하여 Salesforce에 변경 사항을 로드합니다.

컨텍스트

Salesforce를 사용하여 리드를 추적하고, 파이프라인을 관리하고, 기회를 만들고, 리드를 고객으로 전환하는 주문 세부 사항을 수집합니다. Salesforce 시스템은 내부적으로 주문을 만든 다음, 프로비저닝 및 활성화를 위해 해당 데이터를 외부 청구 시스템으로 푸시합니다. 청구 주문은 외부(원격) 시스템에서 관리합니다. 청구 시스템 상태의 주문 또는 청구 엔티티가 변경되면 해당 원격 시스템이 Salesforce에서 주문 상태를 업데이트해야 합니다.

문제

원격 시스템이 Salesforce에 연결 및 인증하여 외부 이벤트에 대해 Salesforce에 알리고 레코드를 만들고 기존 레코드를 업데이트하는 방법은 무엇입니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 고려해야 할 다양한 요소가 있습니다.

• Salesforce에 대한 원격 호출의 목적은 이벤트 중심 아키텍처를 사용하여 외부에서 발생한 이벤트를 Salesforce에 알리는 것입니까? 또는 특정 레코드에서 CRUD 작업을 수행하는 목적이 있습니까? 이벤트 중심 아키텍처를 사용하는 경우 이벤트 프로듀서(원격 프로세스)가 Salesforce 이벤트 소비자와 분리됩니다.
• Salesforce에 통화하려면 계속 처리하기 전에 응답을 기다리는 원격 프로세스가 필요합니까? Salesforce에 대한 원격 통화는 항상 동기식 요청-응답이지만 비동기식 통화를 시뮬레이션하는 데 필요하지 않은 경우 원격 프로세스에서 응답을 삭제할 수 있습니다.
• 각 트랜잭션이 단일 Salesforce 개체 또는 여러 관련 개체에 대해 작동합니까?
• 메시지 형식은 무엇입니까(예: SOAP 또는 REST 또는 HTTP를 통해 모두)?
• 메시지 크기가 상대적으로 작거나 크습니까?
• 원격 시스템이 SOAP 지원인 경우 Salesforce가 계약을 지정하는 계약 우선 접근 방식을 사용할 수 있습니까? 이는 사전 정의된 WSDL이 제공되는 SOAP API를 사용하는 경우 필요합니다.
• 트랜잭션 처리가 필요합니까?
• Salesforce에서 사용자 정의를 얼마나 허용합니까?

솔루션

이 표에는 이 통합 문제에 대한 다양한 솔루션이 포함되어 있습니다.

스케치

다음 다이어그램은 외부 이벤트의 알림에 대한 REST API 또는 SOAP API를 사용하여 Salesforce 개체를 쿼리하는 경우 이 패턴을 구현할 때 발생하는 이벤트 순서를 보여줍니다. 이벤트 순서는 REST API를 사용할 때 동일합니다.

SOAP API를 통해 Salesforce를 쿼리하는 원격 시스템

REST API를 통해 Salesforce에 이벤트를 알리는 원격 시스템

결과

이벤트 중심 아키텍처에서 원격 시스템은 SOAP API, REST API 또는 대량 API 2.0을 사용하여 Salesforce 이벤트 버스에 이벤트를 게시하기 위해 Salesforce에 호출합니다. 이벤트를 게시하면 모든 구독자에게 알림이 전송됩니다. 이벤트 구독자는 플로 또는 Lightning 구성 요소, Apex 트리거와 같은 Salesforce Platform에 있을 수 있습니다. 이벤트 구독자는 CometD 구독자와 같은 Salesforce Platform 외부일 수도 있습니다.

Salesforce 개체를 직접 사용하여 작업할 경우 이 패턴과 관련된 솔루션을 통해 다음을 수행할 수 있습니다.

• 원격 시스템에서 Salesforce API를 호출하여 데이터베이스를 쿼리하고 단일 개체 작업(만들기, 업데이트, 삭제 등)을 실행합니다.
• 일련의 개체 작업을 수행하기 위해 Salesforce REST API 복합 리소스를 호출하는 원격 시스템입니다.
• 다중 개체 트랜잭션 작업 및 사용자 정의 사전/후 처리 논리를 지원할 수 있는 사용자 정의 빌드 Salesforce API(서비스)를 호출하는 원격 시스템

통화 기법

호출 메커니즘은 이 패턴을 구현하기 위해 선택한 솔루션에 따라 다릅니다.

오류 처리 및 복구

오류 처리 및 복구 전략은 전체 솔루션의 일부로 간주해야 합니다.

• 오류 처리 - 표준 또는 사용자 정의 API와 같은 모든 원격 콜인 메서드에는 타임아웃 및 재시도 관리와 같은 후속 오류를 처리할 원격 시스템이 필요합니다. 중간웨어를 사용하여 오류 처리 및 복구를 위한 논리를 제공할 수 있습니다.
• 복구 - 서비스 품질 요구 사항에 따라 사용자 정의 재시도 메커니즘을 만들어야 합니다. 이 경우 동일한 디자인 특성을 유지해야 합니다. 플랫폼 이벤트를 사용하면 구독자가 재생 ID를 사용하여 해당 메시지가 게시된 후 특정 기간 내에 메시지를 가져올 수 있습니다.

동임 설계 고려 사항

동일한 기능을 사용하면 반복 호출이 안전하며 부정적인 영향을 미치지 않습니다. 기울임을 구현하지 않을 경우 동일한 메시지를 반복적으로 호출하면 결과가 다를 수 있으므로 데이터 무결성 문제가 발생할 수 있습니다(예: 중복 레코드 생성, 트랜잭션 중복 처리 등).

오류 또는 시간 초과가 발생할 경우 원격 시스템에서 다중(중복) 호출을 관리하여 중복 삽입 및 중복 업데이트를 방지해야 합니다(특히 다운스트림 트리거 및 워크플로 규칙이 실행되는 경우). Salesforce 내에서 이러한 상황 중 일부를 관리할 수 있지만(특히 사용자 정의 SOAP 및 REST 서비스의 경우) 원격 시스템(또는 미들웨어)이 오류 처리를 관리하고 동일한 설계를 수행하는 것이 좋습니다.

보안 고려 사항

선택한 패턴 솔루션에 따라 다양한 보안 고려 사항이 적용됩니다. 모든 경우 플랫폼에서 로그인한 사용자의 액세스 권한(예: 프로필 설정, 공유 규칙, 권한 집합 등)을 사용합니다. 또한 프로필 IP 제한을 사용하여 특정 IP 주소 범위의 API에 대한 액세스를 제한할 수 있습니다.

보안 고려 사항을 참조하십시오.

사이드바

없음.

적시성

SOAP API 및 Apex 웹 서비스 API는 동기식입니다. 다음 시간 제한이 적용됩니다.

• 세션 시간 초과 - Salesforce 조직의 세션 시간 초과 설정을 기반으로 하는 활동이 없는 경우 세션 시간이 초과됩니다.
• 쿼리 시간 초과 - 각 SOQL 쿼리의 개별 시간 초과 제한은 120초입니다.

데이터 볼륨

데이터 용량 고려 사항은 선택한 솔루션 및 통신 유형에 따라 다릅니다.

엔드포인트 기능 및 표준 지원

끝점에 대한 기능 및 표준 지원은 선택한 솔루션에 따라 다릅니다.

국가관리

시스템을 통합할 때 키는 진행 중인 상태 추적에 중요합니다(예: 레코드가 원격 시스템에서 생성될 경우 해당 레코드에 대한 진행 중인 업데이트를 지원). 두 가지 옵션이 있습니다.

• Salesforce는 원격 레코드에 대한 원격 시스템의 기본 또는 고유 대리 키를 저장합니다.
• 원격 시스템에 Salesforce 고유 레코드 ID 또는 기타 고유한 대리 키가 저장됩니다. 이 동기 패턴에서 통합 키를 처리하는 데 특정 고려 사항이 있습니다.

복잡한 통합 시나리오

이 패턴의 각 솔루션은 변환 및 프로세스 오케스트레이션과 같은 복잡한 통합 시나리오를 처리할 때 서로 다른 고려 사항을 가집니다.

총리 제한

Salesforce Platform의 멀티테넌트 특성으로 인해 API 사용 시 제한이 있습니다.

신뢰할 수 있는 메시징

신뢰할 수 있는 Messaging은 개별 구성 요소 자체가 신뢰할 수 없는 원격 시스템에 메시지 전달을 보장하는 문제를 해결하려고 시도합니다. Salesforce SOAP API 및 REST API는 동기식이며 신뢰할 수 있는 메시징 프로토콜 자체(예: WS-ReliableMessaging)에 대한 명시적 지원을 제공하지 않습니다.

오류 및 시간 초과 시나리오가 성공적으로 관리되도록 원격 시스템에서 신뢰할 수 있는 Messaging 시스템을 구현하는 것이 좋습니다. 외부 시스템에서 플랫폼 이벤트를 게시하는 것은 Salesforce API에 의존하므로 SOAP API 및 REST API에 대해 동일한 고려 사항이 적용됩니다.

Middleware 기능

다음 표에서 이 패턴에 참여하는 미들웨어 시스템의 원하는 속성을 강조 표시합니다.

예제

인쇄 소모품 및 서비스 회사는 Salesforce를 프런트 엔드로 사용하여 프린터 소모품 및 주문을 만들고 관리합니다. 클라이언트 사이트에서 정기적으로 프린터를 모니터링하는 온 프레미스 프린터 관리 시스템(PMS)의 인쇄 사용 통계(잉크 상태, 용지 수준)로 프린터를 나타내는 Salesforce 자산 레코드가 정기적으로 업데이트됩니다. 설정된 임계값(예: 낮은 잉크 상태 또는 낮은/비어 있는 용지 수준이 30% 미만)에 도달하면 이벤트에 관심이 있는 여러 앱/프로세스(변수)에 알림이 전송되고 이메일 또는 Chatter 경고가 전송되고 주문 레코드가 생성됩니다. PMS는 Salesforce ID(Salesforce는 자산 레코드 마스터)를 저장합니다.

다음 제약이 적용됩니다.

• PMS는 Salesforce가 계약을 제공하고 PMS가 Salesforce 서비스(엔터프라이즈 또는 파트너 WSDL을 통해 정의됨)의 클라이언트(소비자) 역할을 하는 계약 우선 통합에 참여할 수 있습니다.
• Salesforce에는 사용자 정의 개발이 없어야 합니다.

이 예는 Salesforce SOAP API 또는 REST API를 사용하여 이벤트를 게시하고 Salesforce에서 선언적 자동화(플로)를 구현하는 것이 가장 좋습니다. 플랫폼 이벤트를 사용하는 주된 이유는 변수 및 무제한 구독자 수입니다. 그러나 주문과 같은 레코드의 유한 목록에 대한 간단한 업데이트의 경우 SOAP 또는 REST API를 사용하여 레코드를 업데이트합니다.

Salesforce의 경우:

• Salesforce에서 플랫폼 이벤트를 정의하여 PMS에서 가져오는 알림 데이터를 포함합니다.
• 프린터 이벤트 알림에 의해 트리거되는 플로를 만듭니다. 프로세스에서 프린터 자산을 업데이트하고 자동 실행 플로를 사용하여 주문을 만듭니다.
• Enterprise 또는 Partner WSDL을 다운로드하고 원격 시스템에 제공합니다.

원격 시스템의 경우:

• Enterprise 또는 Partner WSDL에서 클라이언트 스풀을 만듭니다.
• 통합 사용자의 자격 증명을 사용하여 Salesforce(OAuth 웹 서버 또는 전달자 토큰 플로를 통해)에 인증합니다.
• 프린터 상태 이벤트 시 PMS가 API를 호출하여 프린터 상태 플랫폼 이벤트(프린터 사용 통계 포함)를 만듭니다. Salesforce 이벤트 버스는 플로 구독자 및 기타 모든 구독자에게 알립니다.

플랫폼 이벤트를 사용할 경우 이벤트 버스에서 대용량 플랫폼 이벤트에 대해 72시간 동안 이벤트를 재생할 수 있습니다. 미들웨어 솔루션을 사용하여 해당 이벤트를 게시하면 게시 측에서 오류 처리를 통합하는 데 도움이 됩니다. 그러나 신뢰도가 높은 경우 구독자측에서 오류 처리를 구현할 수 있습니다.

이 예는 다음을 보여줍니다.

• Salesforce 동기식 API 클라이언트 구현(소비자).
• Salesforce에 대한 콜백으로 플랫폼 이벤트를 게시합니다(이전에 적용된 요청/응답 플랫폼 이벤트 패턴과 일치).

컨텍스트

Salesforce를 사용하여 고객 사례를 관리합니다. 고객 서비스 담당자가 사례에 대해 작업하는 고객과 전화를 겁니다. 고객이 결제하고 고객 서비스 담당자는 결제 처리 응용 프로그램에서 Salesforce 응용 프로그램 내 실시간 업데이트를 확인해야만 고객이 주문의 미결제 금액을 성공적으로 결제했음을 나타냅니다.

문제

Salesforce에서 이벤트가 발생하면 화면을 새로 고치지 않고 작업을 잃지 않고 Salesforce 사용자 인터페이스에서 사용자에게 어떻게 알릴 수 있습니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 고려해야 할 다양한 요소가 있습니다.

• 작업 중인 데이터를 Salesforce에 저장해야 합니까?
• 이 데이터를 볼 수 있도록 사용자 정의 사용자 인터페이스 레이어를 구축할 수 있습니까?
• 사용자에게 사용자 정의 사용자 인터페이스를 호출할 수 있는 액세스 권한이 있습니까?

솔루션

이 통합 문제에 대한 권장 솔루션은 Salesforce에서 거의 실시간 이벤트를 보장하는 플랫폼 이벤트를 사용하는 것입니다. 플랫폼 이벤트는 Salesforce 개체와 독립적인 구조화된 유연한 페이로드를 제공합니다. 또한 재생 기간이 72시간인 내구성 있는 주제를 제공합니다. 이렇게 하면 오프라인 소비자가 나중에 사용할 수 있게 되더라도 이벤트를 사용할 수 있습니다. 이 솔루션은 다음 구성 요소로 구성됩니다.

• 주제에 대한 플랫폼 이벤트를 게시하는 논리와 함께 Apex 트리거 또는 플로
• Apex 트리거 또는 플로에서 이벤트를 게시할 수 있는 주제
• 사용자 인터페이스에서 사용할 수 있는 Bayeux 프로토콜(현재 CometD)의 JavaScript 기반 구현
• Lightning 구성 요소
• 정적 자원으로 포함된 JavaScript 라이브러리

스케치

다음 다이어그램은 스트리밍 API를 구현하여 Salesforce 사용자 인터페이스에 알림을 스트리밍하는 방법을 설명합니다. 해당 알림은 Salesforce의 레코드 변경 사항에 의해 트리거됩니다.

데이터 변경으로 인해 Salesforce의 UI 업데이트 트리거

결과

혜택

이 패턴과 관련된 솔루션을 적용하면 다음과 같은 이점이 있습니다.

• 사용자 정의 폴링 메커니즘 작성 필요 없음
• 사용자가 시작하는 사용자 의견 루프 필요 없음

지원되지 않는 요구 사항

솔루션에는 다음과 같은 제한 사항이 있습니다.

• 알림 전달은 보장되지 않습니다.
• 알림 순서는 보장되지 않습니다.
• 대량 API에서 변경한 레코드에서는 알림이 생성되지 않습니다.

보안 고려 사항

표준 Salesforce 조직 수준 보안이 준수됩니다. HTTPS 프로토콜을 사용하여 스트리밍 API에 연결하는 것이 좋습니다. 보안 고려 사항 참조

사이드바

최적의 솔루션은 Salesforce에서 사용자 정의 사용자 인터페이스를 만드는 것입니다. 사용자 정의 사용자 인터페이스를 렌더링하는 데 사용할 수 있는 적절한 사용자 인터페이스 컨테이너를 고려해야 합니다. 지원되는 브라우저는 스트리밍 API 개발자 가이드에 나와 있습니다.

예제

통신 회사에서 Salesforce를 사용하여 고객 사례를 관리합니다. 고객 서비스 관리자는 고객 서비스 담당자 중 한 명이 사례를 마감할 경우 알림을 받으려고 합니다.

이 패턴에 따라 규정된 솔루션을 구현하는 경우 고객은 다음을 수행해야 합니다.

• Apex 트리거 PushTopic을 생성하여 사례가 “마감됨” 상태와 “성공함” 상태로 저장되면 플랫폼 이벤트를 보냅니다.
• 고객 서비스 관리자가 사용할 수 있는 사용자 정의 사용자 인터페이스를 만듭니다. 이 사용자 인터페이스는 이벤트 버스를 구독하여 플랫폼 이벤트를 사용합니다.
• 관리자의 고객 서비스 담당자가 생성한 경고를 표시하는 사용자 정의 사용자 인터페이스에 논리를 구현합니다.

컨텍스트

Salesforce를 사용하여 리드를 추적하고, 파이프라인을 관리하고, 기회를 만들고, 리드를 고객으로 전환하는 주문 세부 사항을 수집합니다. 그러나 Salesforce는 주문을 포함하거나 처리하는 시스템이 아닙니다. 주문은 외부(원격) 시스템에서 관리됩니다. 그러나 세일즈 담당자는 외부 시스템을 학습하거나 사용하지 않아도 Salesforce에서 실시간 주문 정보를 보고 업데이트하려고 합니다.

문제

Salesforce에서 외부 시스템에서 Salesforce로 데이터를 이동하지 않고 Salesforce 외부에 저장된 데이터를 보고 검색하고 수정하는 방법은 무엇입니까?

Forces

이 패턴을 기반으로 솔루션을 적용할 때 고려해야 할 다양한 요소가 있습니다.

• Salesforce에서 선언적/포인트 앤 클릭 아웃바운드 통합 또는 UI 매시업을 구축하려고 합니까?
• Salesforce 조직에 복사하지 않으려는 대용량 데이터가 있습니까?
• 언제든지 소량의 원격 시스템 데이터에 액세스해야 합니까?
• 최신 데이터에 실시간으로 액세스해야 합니까?
• 클라우드 또는 백오피스 시스템에 데이터를 저장하지만 Salesforce 조직에 해당 데이터를 표시하거나 처리하려고 합니까?
• Salesforce에 특정 유형의 데이터를 저장할 때 데이터 보존에 대한 우려 사항이 있습니까?

솔루션

다음 표에는 이 통합 문제에 대한 다양한 솔루션이 포함되어 있습니다.

스케치

다음 다이어그램은 Salesforce Connect 사용하여 Odata 어댑터를 사용하여 외부 시스템에서 데이터를 가져오는 방법을 설명합니다.

이 시나리오의 경우:

1. 브라우저가 AJAX 호출을 수행하여 해당 외부 개체 어댑터에서 작업을 수행합니다.
2. 어댑터는 작업을 OData 요청으로 변환하고 통합 및 서비스 계층을 통해 원격 시스템에 HTTP GET 요청을 수행합니다.
3. 원격 시스템은 통합 및 서비스 계층을 통해 Salesforce에 JSON 응답을 반환합니다.
4. 응답이 Odata 외부 개체로 번역되고 브라우저에 다시 표시됩니다.

결과

이 패턴과 관련된 솔루션을 적용하면 최종 사용자에게 트랜잭션 결과를 표시할 수 있는 사용자 인터페이스 시작 호출이 가능합니다.

통화 기법

호출 메커니즘은 이 패턴을 구현하기 위해 선택한 솔루션에 따라 다릅니다.

오류 처리

전체 솔루션의 일부로 오류 처리를 포함하는 것이 중요합니다. 오류가 발생하면(예외 또는 오류 코드가 발신자에게 반환됨) 발신자가 오류 처리를 관리합니다. Salesforce Connect Validator는 몇 가지 일반적인 쿼리 및 알림 오류 유형 및 실패 원인을 실행할 수 있는 무료 도구입니다.

혜택

Salesforce Connect 솔루션 사용의 몇 가지 이점은 다음과 같습니다.

• 이 솔루션은 Salesforce의 데이터 저장소를 사용하지 않습니다.
• 사용자는 외부 시스템과 Salesforce 간에 데이터를 정기적으로 동기화할 필요가 없습니다.
• OData 또는 cross-org 어댑터를 사용하거나 사용자 지정 Apex 어댑터를 사용하여 최소한의 코드를 사용하여 빠르게 수행할 수 있는 선언적 설정입니다.
• 사용자는 외부 개체 형태의 사용자 정의 개체와 동일한 기능을 사용하여 외부 데이터에 액세스할 수 있습니다.
• 전역 검색을 사용하여 연결된 외부 시스템에서 연합 검색을 수행할 수 있는 기능
• 클라우드 및 온 프레미스 소스에서 외부 데이터에 액세스하는 보고서를 실행할 수 있는 기능 아래의 보고 고려 사항을 참조하십시오.

Salesforce Connect 고려 사항

Salesforce Connect 솔루션은 다음 사항을 고려합니다.

• 외부 개체는 사용자 정의 개체처럼 동작하지만 일부 기능은 외부 개체에 사용할 수 없습니다. 자세한 내용은 Salesforce Connect의 Salesforce 호환성 고려 사항을 참조하십시오.
• 외부 개체가 보고서 성능에 영향을 미칠 수 있습니다. 자세한 내용은 Salesforce Connect의 보고서 고려 사항을 참조하십시오.
• Salesforce Connect 어댑터 사용에 대한 추가 고려 사항은 Salesforce Connect - 모든 어댑터 고려 사항을 참조하십시오.
• cross-org 어댑터를 사용할 계획인 경우 Salesforce Connect—Cross-Org 어댑터의 고려 사항을 참조하십시오.
• OData 어댑터를 사용하려는 경우 Salesforce Connect - OData 2.0 및 4.0 어댑터의 고려 사항을 참조하십시오.
• 사용자 정의 Apex 어댑터를 사용하려는 경우 Salesforce Connect - 사용자 정의 어댑터의 고려 사항을 참조하십시오.

보안 고려 사항

이 패턴에 대한 솔루션은 표준 Salesforce 조직 수준 보안을 준수해야 합니다. HTTPS 프로토콜을 사용하여 원격 시스템에 연결하는 것이 좋습니다. 자세한 내용은 보안 고려 사항을 참조하십시오.

OData 커넥터를 사용하는 경우 OData 외부 데이터 소스의 크로스 사이트 요청 위조(CSRF)에 대한 특수 동작, 제한 사항 및 권장 사항을 이해해야 합니다. 자세한 내용은 Salesforce Connect의 CSRF 고려 사항 - OData 2.0 및 4.0 어댑터를 참조하십시오.

사이드바

없음.

적시성

이 패턴에서 시기는 매우 중요합니다. 다음 사항에 유의하십시오.

• 일반적으로 요청은 사용자 인터페이스에서 호출되므로 프로세스에서 사용자가 대기하지 않아야 합니다.
• 외부 시스템의 가용성 및 연결에 따라 외부 데이터를 검색하는 데 시간이 오래 걸릴 수 있습니다. Salesforce에는 구성 가능한 외부 시스템의 응답을 대기할 수 있는 최대 120초 시간 초과 값이 있습니다.
• 원격 프로세스 완료는 적시에 실행되고 Salesforce 시간 초과 제한 내 및 사용자 기대 내에서 완료되어야 합니다.

데이터 볼륨

이 패턴은 Apex 호출 솔루션의 시간 초과 값이 작고 요청 또는 응답의 최대 크기 때문에 소량의 실시간 활동에 주로 사용됩니다. 메시지에 데이터 페이로드가 포함된 배치 처리 활동에서는 이 패턴을 사용하지 마십시오.

엔드포인트 기능 및 표준 지원

선택한 솔루션에 따라 끝점에 대한 기능 및 표준 지원이 결정됩니다.

국가관리

시스템을 통합할 때 키는 진행 중인 상태 추적에 중요합니다. 예를 들어, 레코드가 원격 시스템에서 생성될 경우 일반적으로 레코드에 진행 중인 업데이트를 지원하기 위한 식별 키가 필요합니다. 키를 저장할 수 있는 두 가지 옵션이 있습니다.

• Salesforce는 원격 레코드에 대한 기본 또는 고유 대리 키를 저장합니다.
• 원격 시스템에 Salesforce 고유 레코드 ID 또는 기타 고유한 대리 키가 저장됩니다. 이 동기 패턴에서 통합 키를 처리하는 데 특정 고려 사항이 있습니다.

복잡한 통합

특정 사례에서 이 패턴에 따라 규정된 솔루션은 복잡한 통합 시나리오를 구현해야 할 수 있습니다. 이러한 시나리오는 대개 미들웨어를 사용하여 해결됩니다.

• 다중 시스템 통화 전반의 통화 및 통화 결과 집계
• 인바운드 및 아웃바운드 메시지 모두 변환
• 다중 시스템에 대한 통화 전반의 트랜잭션 무결성 유지
• Salesforce와 외부 시스템 간의 기타 프로세스 오케스트레이션 활동

규제 한도

어댑터마다 제한이 다릅니다. 자세한 내용은 Salesforce Connect의 일반 제한을 참조하십시오.

Middleware 기능

다음 표는 이 패턴에 참여하는 미들웨어 시스템의 원하는 속성을 강조 표시합니다.

외부 객체 관계

외부 개체는 18자 Salesforce 레코드 ID를 사용하여 관련 레코드를 연결하는 표준 조회 관계를 지원합니다. 그러나 Salesforce 조직 외부에 저장된 데이터에는 이러한 레코드 ID가 포함되지 않는 경우가 많습니다. 따라서 외부 개체에 대해 두 가지 특별한 유형의 조회 관계(외부 조회 및 간접 조회)를 사용할 수 있습니다.

이 표에는 외부 개체에 사용할 수 있는 관계 유형이 요약되어 있습니다.

Salesforce Connect의 고데이터 볼륨 고려 사항 - OData 2.0 및 4.0 어댑터

외부 개체에 액세스할 때 조직이 속도 제한에 도달할 경우 관련 외부 데이터 소스에서 고데이터 용량 옵션을 선택하는 것이 좋습니다. 이를 수행하면 대부분의 속도 제한을 무시하지만 일부 특수 동작 및 제한 사항이 적용됩니다. 자세한 내용은 Salesforce Connect의 고데이터 용량 고려 사항을 참조하십시오.

Salesforce Connect용 클라이언트 구동 및 서버 구동 페이징 - OData 2.0 및 4.0 어댑터

외부 데이터에 대한 Salesforce Connect 쿼리에 대규모 결과 집합이 있으며, 이는 더 작은 배치 또는 페이지로 분할됩니다. 외부 시스템(서버 구동) 또는 Salesforce Connect Odata 2.0 또는 4.0 어댑터(클라이언트 구동)에서 페이징 동작을 제어할지 여부를 결정합니다. 외부 데이터 소스의 서버 구동 페이지 매김 필드는 클라이언트 구동 또는 서버 구동 페이징을 사용할지 여부를 지정합니다. 외부 데이터 소스에서 서버 구동 페이징을 활성화하는 경우 Salesforce는 기본 queryMore() 배치 크기인 행 500개를 포함하여 요청된 페이지 크기를 무시합니다. 외부 시스템에서 반환하는 페이지에 따라 배치가 결정되지만 각 페이지는 2,000개의 행을 초과할 수 없습니다. 그러나 Salesforce Connect Odata 어댑터에 대한 제한은 계속해서 적용됩니다.

예제

제조 회사에서 Salesforce를 사용하여 고객 사례를 관리합니다. 고객 서비스 에이전트는 ERP에서 보고서를 학습하고 수동으로 실행할 필요 없이 백오피스 ERP 시스템에서 실시간 주문 정보에 액세스하여 고객을 포괄적으로 파악하려고 합니다.

이 패턴에 따라 규정된 솔루션을 구현하는 경우 다음을 수행해야 합니다.

• OData 끝점을 사용하여 외부 데이터 소스를 구성합니다. 원격 응용 프로그램에 Odata 대한 기본 지원이 포함될 수 있습니다. 기타 응용 프로그램의 경우 Dell Boomi, Informatica, Jitterbit, MuleSoft, Progress Software와 같은 주요 통합 공급업체가 Salesforce Connect 협력하여 어댑터를 구축했습니다.
• 직접 또는 미들웨어 솔루션을 통해 Odata 끝점에서 Salesforce Connect 가리킵니다.
• 외부 데이터베이스 테이블을 Salesforce의 외부 개체와 동기화합니다. 사용자가 해당 외부 개체의 데이터가 포함된 페이지에 액세스하면 Salesforce Connect 백엔드 응용 프로그램에 대한 실시간 콜아웃을 만듭니다.

개발자 문서

• Salesforce 도움말: 통합 사용자에게 API 전용 액세스 권한 부여

• SOAP API 개발자 가이드

• REST API 개발자 가이드

• 스트리밍 API 개발자 가이드

• Bulk API 2.0 및 Bulk API 개발자 가이드

• Apex 개발자 가이드

• SOQL 및 SOSL 참조

• Salesforce 개발자 제한 및 할당 빠른 참조

• 플랫폼 이벤트 개발자 가이드

• Apex 개발자 가이드: Salesforce Connect

Trailhead

• 대용량 데이터

• 플랫폼 이벤트 기본 사항

• 변경 데이터 수집 기본 사항

• 빠른 시작: Salesforce Connect

엔터프라이즈 포트폴리오의 효과적인 구성원이 되려면 모든 응용 프로그램을 만들고 관련 보안 메커니즘과 통합해야 합니다. 현대적인 IT 전략은 온 프레미스 및 클라우드 기반 서비스를 조합하여 사용합니다.

Cloud-to-Cloud 서비스 통합은 일반적으로 웹 서비스 및 관련 권한 부여에 중점을 두지만, 온 프레미스 및 클라우드 서비스를 연결하면 복잡성이 증가하는 경우가 있습니다. 이 섹션에서는 보안 도구, 기술, Salesforce별 고려 사항을 설명합니다.

뒤로 프록시 서버

역방향 프록시는 웹 서버 앞에 자리잡고 해당 웹 서버에 클라이언트(예: 웹 브라우저) 요청을 전달하는 서버입니다. 역방향 프록시는 보안, 성능 및 신뢰도를 향상하기 위해 일반적으로 구현됩니다.

이는 하나 이상의 서버에서 클라이언트를 대신하여 자원을 검색하는 프록시 서버 유형입니다. 그러면 자원이 프록시 서버 자체에서 생성된 것처럼 클라이언트에 반환됩니다. 연결된 클라이언트가 모든 서버에 연락하는 중개인 프록시와 달리 역방향 프록시는 클라이언트가 연결된 서버에 연락할 수 있는 중개인입니다.

Salesforce 구현에서 일반적으로 해당 서비스는 외부 게이트웨이 제품을 통해 제공됩니다. 예를 들어, Apache HTTP, lighttpd, nginix와 같은 오픈 소스 옵션을 사용할 수 있습니다. 상업 제품에는 IBM WebSeal 및 Computer Associates SiteMinder가 포함되어 있습니다. 이러한 제품은 내부 요청자를 대신하여 모든 아웃바운드 Salesforce 요청을 프록시하고 관리하도록 쉽게 구성할 수 있습니다.

암호화

일부 엔터프라이즈에서는 선택한 트랜잭션 또는 데이터 필드를 온 프레미스 및 클라우드 기반 응용 프로그램 조합 간에 암호화해야 합니다. 조직이 추가 규정 준수 요구 사항을 준수해야 하는 경우 다음을 포함한 대안을 구현할 수 있습니다.

• Salesforce 자체, CipherCloud, IBM DataPower, Computer Associates를 비롯한 온 프레미스 상용 암호화 게이트웨이 서비스를 제공합니다. 각 솔루션의 경우 암호화된 페이로드를 보내고 받거나 HTTP(S) 요청이 실행되기 전에 특정 데이터 필드를 암호화 또는 해독할 때 트랜잭션 경계에서 암호화 엔진 또는 게이트웨이가 호출됩니다.

• Salesforce Shield Platform Encryption과 같은 클라우드 기반 옵션 Shield Platform Encryption 중요한 플랫폼 기능을 유지하면서 데이터에 완전히 새로운 보안 계층을 제공합니다. 선택한 데이터는 고급 키 파생 시스템을 사용하여 암호화 상태로 유지됩니다. 그 어느 때보다 안전하게 데이터를 보호할 수 있습니다. 자세한 내용은 Salesforce 온라인 도움말을 참조하십시오.

특수 WS-* 프로토콜 지원

보안 프로토콜(예: WS-*)의 요구 사항을 해결하려면 다음 대안을 사용하는 것이 좋습니다.

• 보안/XML 게이트웨이 - 트랜잭션 스트림 자체에 WS-Security 자격 증명(IBM WebSeal 또는 Datapower, Layer7, TIBCO 등)을 삽입합니다. 이 접근 방식을 사용하려면 Salesforce의 응용 프로그램 수준 웹 서비스 또는 웹 서비스 호출을 변경하지 않아도 됩니다. Salesforce 설치 전반에서 이 접근 방식을 재사용할 수도 있습니다. 그러나 기존 보안 게이트웨이 접근 방식에 적절한 WS 보안 입력을 관리하려면 추가 설계, 구성, 테스트, 유지 관리가 필요합니다.

• 전송 수준 암호화 - 양방향 SSL 및 IP 제한을 사용하여 통신 채널을 암호화합니다. 이 접근 방식은 자체적으로 WS-* 프로토콜을 직접 구현하지 않지만 사용자 이름과 암호를 전달하지 않고도 온 프레미스 응용 프로그램과 Salesforce 간의 통신 채널을 보호합니다. 또한 Salesforce 생성 클래스를 변경하지 않아도 됩니다. 그러나 일부 온 프레미스 웹 서비스 수정이 필요할 수 있습니다(응용 프로그램 자체 또는 미들웨어/ESB 레이어).

• Salesforce 사용자 정의 개발 - WSDL2Apex 유틸리티를 통해 아웃바운드 SOAP 요청에 WS-Security 머리글을 추가합니다. 이렇게 하면 내부 서비스를 호출하는 데 사용되는 WSDL 파일에서 Java와 유사한 Apex 클래스가 생성됩니다. 이 접근 방식은 백엔드 웹 서비스 또는 DMZ의 추가 구성 요소를 변경하지 않아도 되지만 다음을 수행해야 합니다.

  • 구축 및 테스트 작업 증가
  • WS-Security 속성을 수동으로 코딩하는 상대적으로 복잡하고 수동적인 프로세스(Apex 코드 내의 XML 직렬화 포함)
  • 더 높은 장기 서비스 점검 노력

노트: 복잡성과 Salesforce의 정기적인 업데이트를 기반으로 통합을 정기적으로 검토해야 하는 위험으로 인해 마지막 옵션은 권장되지 않습니다.

기타 보안 고려 사항

• 명명된 자격 증명: 외부 시스템에 대한 인증된 API 콜아웃을 보호하고 간소화하기 위해 고안된 명명된 자격 증명은 콜아웃 끝점의 URL 및 필수 인증 매개 변수를 하나의 정의로 지정합니다. Apex 코드를 간소화하고 인증된 콜아웃의 설정을 간소화하려면 명명된 자격 증명을 콜아웃 끝점으로 지정합니다. 자세한 내용은 여기를 참조하십시오.

• OAUTH 2.0: OAuth 2.0은 사용자가 암호 등 자격 증명을 공유하지 않고 타사 응용 프로그램에 보호된 자원에 대한 제한된 액세스 권한을 부여할 수 있는 산업 표준 인가 프레임워크입니다. 직접 암호 교환 대신 사용자가 액세스 토큰 요청을 승인하면 응용 프로그램이 자원 서버에서 사용자의 데이터에 액세스하는 데 사용합니다. 이 프로세스는 클라이언트 응용 프로그램을 사용자의 ID 및 암호와 구분하여 임시 범위별 "키"를 제공하여 보안을 강화합니다. 자세한 내용은 여기를 참조하십시오.

• 비공개 연결: 타사 클라우드 서비스에서 호스팅되는 응용 프로그램과 Salesforce 조직을 통합할 경우 HTTP 트래픽을 안전하게 전송하고 받을 수 있어야 합니다. 비공개 연결을 사용하면 Salesforce 조직과 AWS 가상 사설 클라우드(VPC) 간에 완전히 관리되는 네트워크 연결을 설정하여 Amazon Web Services(AWS) 통합의 보안을 강화할 수 있습니다. 그런 다음, 공용 인터넷 대신 연결을 통해 클라우드 간 트래픽을 라우팅하여 외부 보안 위협에 대한 노출을 줄입니다. 비공개 연결은 AWS PrivateLink라는 기능을 통해 AWS와 파트너십으로 사용할 수 있습니다. 비공개 연결은 양방향이며 인바운드 및 아웃바운드 트래픽을 모두 시작할 수 있습니다. 인바운드 연결을 사용하면 표준 API를 사용하여 Salesforce로 트래픽을 보낼 수 있습니다. 아웃바운드 연결을 사용하면 Apex 콜아웃, 외부 서비스 및 외부 개체와 같은 기능을 통해 Salesforce에서 트래픽을 전송할 수 있습니다. VPC에 대한 자세한 내용은 여기 를 참조하십시오.

플랫폼 이벤트, 변경 데이터 수집(CDC), Pub /Sub API를 사용하는 Salesforce 이벤트 버스는 엔터프라이즈에서 이벤트 기반 스타일 아키텍처(EDA)를 만들 수 있도록 지원합니다.

EDA는 이벤트 메시지 소비자(구독자)를 이벤트 메시지 제작자(게시자)와 분리하여 확장성과 유연성을 높일 수 있습니다. 특정 패턴은 관련 대안 또는 옵션을 비교하고 대비하는 기존 패턴 구조의 일부로 이 문서에 다룹니다. 그러나 이벤트 중심 아키텍처와 패턴이 상호 작용하는 방식을 포괄적으로 이해하면 필요에 맞는 패턴을 선택하는 데 도움이 됩니다.

Khalid Mohammed는 Salesforce의 전문 서비스 내에서 유명한 설계자 리더입니다. 2015년 Salesforce에 합류한 이후에는 Salesforce 직원이 되기 전에 수많은 고객 변환을 거쳐 엔터프라이즈 응용 프로그램 및 아키텍처에 대한 광범위한 전문 지식을 활용했습니다. Khalid는 배달 아키텍처 위원회를 이끌고 있으며 인증된 기술 아키텍트 리더로 인정됩니다.

Gulal Kumar는 데이터 및 통합 아키텍처에 중점을 둔 Salesforce의 소프트웨어 엔지니어링 아키텍처입니다. 통합 및 API, 현대화 프로그램, 보안, AIML 이니셔티브 분야에서 20년 이상의 경험을 보유한 그는 풍부한 전문 지식을 제공합니다. Gulal은 비즈니스 전환 이니셔티브를 발전시키고, 보안 및 복원 능력을 향상하고, 아키텍처 우수성을 촉진하고, 다양한 도메인 전반에 걸쳐 AIML 이니셔티브를 선도하기 위해 노력하고 있습니다.

Sushant는 Salesforce에서 솔루션 아키텍처 및 Salesforce Platform의 종단간 배달 전문 기술 아키텍처입니다. 플랫폼 거버넌스, 응용 프로그램 개발, 통합, DevOps에 대한 깊은 전문 지식을 보유한 그는 산업 전반의 수많은 고객 전환 프로그램을 이끌었습니다. Sushant는 탁월한 배달 및 확장 가능한 아키텍처 결과를 촉진하기 위해 노력합니다.