세일즈포스(Salesforce) REST API 가이드

Salesforce Lightning Platform API 알아보기

 

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• 개발에 대한 API 우선 접근 방식의 이점을 설명합니다.
• REST API, SOAP API, Bulk API 및 Streaming API에 대한 상태 사용 사례.
• 두 가지 유형의 API 제한에 이름을 지정하고 계산 방법을 설명합니다.

Salesforce의 API 우선

어이, 친구! 구축 중인 통합을 위한 완벽한 Salesforce API를 찾기 위해 공해를 항해할 준비가 되셨습니까? 캡틴, 안대를 잡고 앵무새를 찾으세요. Lightning Platform의 바다를 탐색하고 API에 대한 모든 것을 배우려고 합니다.

 

Salesforce API 환경은 바다처럼 광대합니다. 

Salesforce는 Salesforce 플랫폼에서 기능을 구축하기 위해 API 우선 접근 방식을 취하기 때문입니다. 

API는 먼저 UI 디자인에 집중하기 전에 기능에 대한 강력한 API를 빌드하는 것을 의미합니다. 

이 접근 방식은 Salesforce 개발자에게 원하는 대로 데이터를 조작할 수 있는 유연성을 제공합니다.

 

Salesforce는 고객과 파트너가 Salesforce 기능을 확장하는 새로운 방법과 AppExchange용으로 구축할 흥미로운 앱을 항상 생각하고 있다는 것을 알고 있습니다. 플랫폼에서 개발하기 위한 포괄적인 도구 상자를 제공하는 것이 최우선 과제입니다. 이 접근 방식을 사용하면 Salesforce에서 API 위에 UI를 빌드하여 두 API 간에 동작이 동일하도록 할 수도 있습니다.

 

이 모듈을 API의 첫 번째 동료로 생각하십시오. 함께 몇 가지 일반적인 API 정보를 살펴보고 Salesforce의 API 제품군에 대한 설문조사를 수행하고 몇 가지 일반적인 API 사용에 대해 알아보겠습니다. 이 모든 정보를 통해 프로젝트에 적합한 API를 선택하는 데 필요한 지식을 얻을 수 있습니다.

Salesforce 데이터 API

Salesforce API의 바다에는 이 모듈에서 중점적으로 다루는 일반적으로 사용되는 API의 주요 군도가 있습니다. 

REST API, SOAP API, 대량 API 및 스트리밍 API입니다. 이들은 함께 Salesforce 데이터 API를 구성합니다. 

 

그 목적은 Salesforce 데이터를 조작할 수 있도록 하는 반면 다른 API를 사용하면 페이지 레이아웃을 사용자 정의하거나 사용자 정의 개발 도구를 빌드하는 것과 같은 작업을 수행할 수 있습니다. 

 

다른 Salesforce API를 사용하여 Salesforce 데이터의 하위 집합도 조작할 수 있습니다. 

 

예를 들어 Analytics REST API는 Analytics에 중점을 둡니다. 그러나 이 네 가지 API는 핵심 Salesforce 데이터의 스펙트럼에 광범위하게 적용됩니다.

REST API

REST API는 RESTful 원칙을 기반으로 하는 간단하고 강력한 웹 서비스입니다. REST 리소스 및 HTTP 메서드를 통해 모든 종류의 Salesforce 기능을 노출합니다. 예를 들어, CRUD(기록 생성, 읽기, 업데이트 및 삭제), 데이터 검색 또는 쿼리, 개체 메타데이터 검색, 조직의 제한 정보에 액세스할 수 있습니다. REST API는 XML과 JSON을 모두 지원합니다.

REST API는 요청 및 응답 프레임워크가 가볍고 사용하기 쉽기 때문에 모바일 및 웹 앱을 작성하는 데 적합합니다.

SOAP API

SOAP API는 같은 이름의 산업 표준 프로토콜을 기반으로 하는 강력하고 강력한 웹 서비스입니다. WSDL(Web Services Description Language) 파일을 사용하여 API를 통해 데이터에 액세스하기 위한 매개변수를 엄격하게 정의합니다. SOAP API는 XML만 지원합니다. 대부분의 SOAP API 기능은 REST API를 통해서도 사용할 수 있습니다. 어떤 표준이 귀하의 요구 사항을 더 잘 충족하는지에 달려 있습니다.

SOAP API는 WSDL 파일을 API와 소비자 간의 공식 계약으로 사용하기 때문에 서버 간 통합을 작성하는 데 유용합니다.

대량 API

대량 API는 한 번에 많은 데이터를 로드하고 쿼리하기 위한 특수 RESTful API입니다. 제비는 50,000개 이상의 레코드를 의미합니다. 대량 API는 비동기식이므로 요청을 제출하고 나중에 결과를 확인할 수 있습니다. 이 방법은 많은 양의 데이터를 처리할 때 선호되는 방법입니다. 벌크 API에는 두 가지 버전(1.0 및 2.0)이 있습니다. 두 버전 모두 많은 양의 데이터를 처리하지만 이 모듈에서는 사용하기가 조금 더 쉽기 때문에 Bulk API 2.0을 사용합니다.

대량 API는 처음으로 조직에 데이터를 로드하는 것과 같이 많은 레코드를 포함하는 작업을 수행하는 데 적합합니다.

스트리밍 API

스트리밍 API는 데이터가 변경될 때 트리거되는 알림을 설정하기 위한 특수 API입니다. 사용자가 특정 유형의 데이터 변경 사항을 브로드캐스트하는 채널을 구독할 수 있는 게시-구독 또는 게시/구독 모델을 사용합니다.

pub/sub 모델은 폴링의 필요성을 제거하여 API 요청 수를 줄입니다. 스트리밍 API는 변경 사항을 자주 폴링해야 하는 앱을 작성하는 데 유용합니다.

API 액세스 및 인증

Salesforce API에 액세스하기 위해 보물 지도가 필요하지 않습니다. Trailhead Playground 또는 Enterprise Edition, Unlimited Edition, Developer Edition, Performance Edition 또는 Professional Edition(추가 기능 포함) 에디션 중 하나의 조직만 있으면 됩니다. "API 사용" 권한이 있고 통합을 시작할 준비가 되었는지 확인하십시오.

SOAP API login() 호출을 제외한 모든 API 호출에는 인증이 필요합니다. 지원되는 OAuth 흐름 중 하나를 사용하거나 SOAP API login() 호출에서 검색된 세션 ID로 인증할 수 있습니다. 시작하려면 선택한 API에 대한 개발자 가이드를 확인하세요.

API 제한

가치가 있는 선장은 선박의 이익을 위해 선원을 제한해야 할 때를 알고 있습니다. 선장이 선원들에게 하루 종일 그로그를 마시게 하면 아무 일도 일어나지 않습니다. 마찬가지로 Salesforce는 인스턴스의 상태를 보장하기 위해 조직당 API 호출 수를 제한합니다. 이러한 제한은 악성 스크립트가 서버를 유목으로 부수는 것을 방지하기 위해 존재합니다. 일상 업무에 방해가 되지 않습니다. 그럼에도 불구하고 그들과 친해지는 것은 좋은 생각입니다.

API 제한에는 두 가지 유형이 있습니다. 동시 제한은 한 번에 실행되는 장기 실행 호출(20초 이상)의 수를 제한합니다. 총 한도는 24시간 동안 이루어진 통화 수를 제한합니다.

동시 제한은 조직 유형에 따라 다릅니다. Trailhead Playground의 경우 한 번에 5개의 장기 실행 호출로 제한됩니다. 샌드박스 조직의 경우 25개의 장기 실행 호출입니다.

총 한도는 구매하는 조직 버전, 라이선스 유형 및 확장 팩에 따라 다릅니다. 예를 들어 Enterprise Edition 조직은 Salesforce 라이선스당 1,000회의 호출을 받고 Partner Community 라이선스당 200회의 호출을 받습니다. " 추가 API 호출" 팩을 사용하면 동일한 Enterprise Edition 조직에서 추가로 4,000회의 호출을 받습니다. 총 제한도 조직 버전에 따라 최소값과 최대값이 적용되지만 여기서는 다루지 않습니다. 자세한 내용을 보려면 리소스 섹션에서 Salesforce 개발자 제한 및 할당 빠른 참조 링크를 확인하십시오.

남아 있는 API 호출을 확인하는 방법에는 여러 가지가 있습니다.

• 시스템 개요 페이지의 API 사용 상자. (설정에서 빠른 찾기 상자에 시스템 개요 를 입력한 다음 시스템 개요 를 선택 합니다 .)
• REST API에 대한 Sforce-Limit-Info 응답 헤더에 반환된 정보입니다.
• SOAP API에 대한 응답 본문(<type>API REQUESTS</type>)에 반환된 정보입니다.
• Lightning Platform REST API 의 /limits 호출.
• 30일 동안 집계된 조직의 API 호출을 보여주는 월별 API 요청 제한 사용량 기반 권한 .

조직이 지정한 API 호출 수를 초과할 때 알림을 설정할 수도 있습니다. 이렇게 하려면 설정에서 빠른 찾기 상자에 API 사용 알림을 입력한 다음 API 사용 알림 을 선택 합니다 .

어떤 API를 사용합니까?

통합 요구 사항에 적합한 API를 선택하는 것은 중요한 결정입니다. 다음은 지원되는 프로토콜, 데이터 형식, 통신 패러다임 및 사용 사례를 포함하여 가장 일반적으로 사용되는 API에 대한 정보입니다. 사용할 API를 고려할 때 이 섹션을 참조할 수 있는 참조로 취급하십시오.

이미 이야기한 네 가지 데이터 API에 유의하십시오. 다음에는 각각에 대해 자세히 알아보겠습니다.

API 이름규약데이터 형식의사 소통

 

 

API Name	Protocol	Data Format	Communication
REST API	REST	JSON, XML	Synchronous
SOAP API	SOAP (WSDL)	XML	Synchronous
Chatter REST API	REST	JSON, XML	Synchronous (photos are processed asynchronously)
User Interface API	REST	JSON	Synchronous
Analytics REST API	REST	JSON, XML	Synchronous
Bulk API	REST	CSV, JSON, XML	Asynchronous
Metadata API	SOAP (WSDL)	XML	Asynchronous
Streaming API	Bayeux	JSON	Asynchronous (stream of data)
Apex REST API	REST	JSON, XML, Custom	Synchronous
Apex SOAP API	SOAP (WSDL)	XML	Synchronous
Tooling API	REST or SOAP (WSDL)	JSON, XML, Custom	Synchronous

REST API를 사용하는 경우

REST API는 Salesforce와의 상호 작용을 위한 강력하고 편리하며 간단한 REST 기반 웹 서비스 인터페이스를 제공합니다. 통합 및 개발이 용이하다는 장점이 있으며 모바일 애플리케이션 및 웹 프로젝트와 함께 사용하기 위한 탁월한 기술 선택입니다. 특정 프로젝트의 경우 다른 Salesforce REST API와 함께 REST API를 사용할 수 있습니다. 목록 보기, 작업 및 종속 선택 목록에 대한 UI 빌드를 포함하여 레코드 생성, 읽기, 업데이트 및 삭제를 위한 UI를 빌드하려면 사용자 인터페이스 API를 사용하십시오. Chatter, 커뮤니티 또는 권장 사항에 대한 UI를 빌드하려면 Chatter REST API를 사용하십시오.처리할 레코드가 많은 경우 REST 원칙을 기반으로 하고 대규모 데이터 집합에 최적화된 벌크 API를 사용하는 것이 좋습니다.

SOAP API를 사용하는 경우

SOAP API는 Salesforce와 상호 작용하기 위한 강력하고 편리하며 간단한 SOAP 기반 웹 서비스 인터페이스를 제공합니다. SOAP API를 사용하여 레코드를 생성, 검색, 업데이트 또는 삭제할 수 있습니다. SOAP API를 사용하여 검색 등을 수행할 수도 있습니다. 웹 서비스를 지원하는 모든 언어로 SOAP API를 사용합니다.

예를 들어 SOAP API를 사용하여 Salesforce를 조직의 ERP 및 재무 시스템과 통합할 수 있습니다. 또한 실시간 판매 및 지원 정보를 회사 포털에 제공하고 중요한 비즈니스 시스템을 고객 정보로 채울 수 있습니다.

Chatter REST API를 사용하는 경우

Chatter REST API를 사용하여 특히 모바일 애플리케이션에서 Chatter 피드, 사용자, 그룹 및 팔로워를 표시합니다. Chatter REST API는 파일, 권장 사항, 주제, 알림, Data.com 구매 등에 대한 프로그래밍 방식의 액세스도 제공합니다. Chatter REST API는 Facebook 및 Twitter와 같은 피드가 있는 다른 회사에서 제공하는 API와 유사하지만 Chatter 이외의 Salesforce 기능도 노출합니다.

사용자 인터페이스 API를 사용하는 경우

Salesforce가 Android, iOS 및 모바일 웹용 Lightning Experience 및 Salesforce 구축에 사용하는 것과 동일한 API를 사용하여 기본 모바일 앱 및 사용자 정의 웹 앱용 Salesforce UI를 구축합니다. 사용자가 레코드, 목록 보기, 작업, 즐겨찾기 등으로 작업할 수 있는 사용자 인터페이스를 구축합니다. 단일 응답으로 데이터와 메타데이터를 얻을 수 있을 뿐만 아니라 응답이 Salesforce 관리자가 조직에 수행한 메타데이터 변경 사항과 일치합니다. 레이아웃, 선택 목록, 필드 수준 보안 또는 공유에 대해 걱정할 필요가 없습니다. 사용자가 좋아하는 앱을 빌드하기만 하면 됩니다.

Analytics REST API를 사용하는 경우

Analytics REST API를 사용하여 프로그래밍 방식으로 데이터 세트, 렌즈 및 대시보드와 같은 Analytics 자산에 액세스할 수 있습니다. Analytics Platform에 직접 쿼리를 보냅니다. Analytics Platform으로 가져온 데이터 세트에 액세스합니다. 렌즈를 만들고 검색합니다. XMD 정보에 액세스합니다. 데이터세트 버전 목록을 검색합니다. Analytics 애플리케이션을 만들고 검색합니다. Analytics 대시보드를 생성, 업데이트 및 검색합니다. 애플리케이션에 대한 종속성 목록을 검색합니다. 사용자가 사용할 수 있는 기능을 결정합니다. 스냅샷으로 작업합니다. 복제된 데이터 세트를 조작합니다.

대량 API를 사용하는 경우

Bulk API는 REST 원칙을 기반으로 하며 대량의 데이터를 로드하거나 삭제하는 데 최적화되어 있습니다. 일괄 처리를 제출하여 많은 레코드를 비동기적으로 쿼리, queryAll, 삽입, 업데이트, 업데이트 또는 삭제할 수 있습니다. Salesforce는 백그라운드에서 일괄 처리를 처리합니다.

반면 SOAP API는 한 번에 몇 개의 레코드를 업데이트하는 실시간 클라이언트 응용 프로그램에 최적화되어 있습니다. SOAP API를 사용하여 많은 레코드를 처리할 수 있지만 데이터 세트에 수십만 개의 레코드가 포함된 경우 SOAP API는 덜 실용적입니다. Bulk API는 수천에서 수백만 레코드에 이르는 데이터를 간단하게 처리할 수 있도록 설계되었습니다.

Bulk API를 사용하는 가장 쉬운 방법은 CSV 파일을 사용하여 Data Loader에서 레코드를 처리하도록 활성화하는 것입니다. Data Loader를 사용하면 고유한 클라이언트 응용 프로그램을 작성할 필요가 없습니다.

메타데이터 API를 사용하는 경우

Metadata API를 사용하여 조직에 대한 사용자 지정을 검색, 배포, 생성, 업데이트 또는 삭제합니다. 가장 일반적인 용도는 샌드박스 또는 테스트 조직에서 프로덕션 환경으로 변경 사항을 마이그레이션하는 것입니다. 메타데이터 API는 사용자 지정을 관리하고 데이터 자체가 아니라 메타데이터 모델을 관리할 수 있는 도구를 구축하기 위한 것입니다.

Metadata API의 기능에 액세스하는 가장 쉬운 방법은 Visual Studio Code용 Salesforce Extensions 또는 Ant 마이그레이션 도구를 사용하는 것입니다. 두 도구 모두 Metadata API를 기반으로 구축되었으며 표준 도구를 사용하여 Metadata API 작업을 단순화합니다. 

• Visual Studio Code용 Salesforce Extensions에는 가볍고 확장 가능한 VS Code 편집기의 Salesforce 플랫폼에서 개발하기 위한 도구가 포함되어 있습니다. 이러한 도구는 개발 조직(스크래치 조직, 샌드박스 및 DE 조직), Apex, Aura 구성 요소 및 Visualforce 작업을 위한 기능을 제공합니다.
• Ant 마이그레이션 도구는 로컬 디렉토리와 Salesforce 조직 간에 메타데이터를 이동하기 위해 스크립트 또는 명령줄을 사용하는 경우에 이상적입니다.

스트리밍 API를 사용하는 경우

Streaming API를 사용하여 Salesforce 레코드 또는 사용자 정의 페이로드의 변경 사항을 기반으로 하는 실시간 데이터 스트림을 수신합니다. Salesforce 레코드 변경 사항의 경우 Salesforce는 변경 사항이 발생할 때 알림을 게시합니다. 사용자 지정 알림의 경우 이벤트 메시지를 게시할 수 있습니다. 구독자는 푸시 기술을 시뮬레이션하는 Bayeux 프로토콜 구현인 CometD를 사용하여 알림을 받을 수 있습니다. 클라이언트는 Apex 트리거를 사용하거나 Process Builder 및 Flow Builder를 사용하여 선언적으로 일부 유형의 이벤트를 구독할 수도 있습니다.

Apex REST API를 사용하는 경우

외부 애플리케이션이 REST 아키텍처를 통해 코드에 액세스할 수 있도록 Apex 클래스 및 메서드를 노출하려는 경우 Apex REST API를 사용합니다. Apex REST API는 인증을 위해 OAuth 2.0과 세션 ID를 모두 지원합니다.

Apex SOAP API를 사용하는 경우

외부 응용 프로그램이 SOAP를 통해 코드에 액세스할 수 있도록 Apex 메서드를 SOAP 웹 서비스 API로 노출하려는 경우 Apex SOAP API를 사용합니다.

Apex SOAP API는 인증을 위해 OAuth 2.0과 세션 ID를 모두 지원합니다.

도구 API를 사용하는 경우

도구 API를 사용하여 Lightning Platform 애플리케이션용 사용자 정의 개발 도구 또는 앱을 빌드합니다. 예를 들어 도구 API를 사용하여 기존 Lightning Platform 도구에 기능을 추가하고 엔터프라이즈 통합 도구에 동적 모듈을 빌드할 수 있습니다. Tooling API를 사용하여 특정 애플리케이션 또는 서비스를 위한 특수 개발 도구를 구축할 수도 있습니다.

많은 메타데이터 유형에 대한 Tooling API의 SOQL 기능을 사용하면 더 작은 메타데이터 조각을 검색할 수 있습니다. 검색이 작을수록 성능이 향상되므로 Tooling API는 대화형 응용 프로그램 개발에 적합합니다. Tooling API는 SOAP 및 REST 인터페이스를 제공합니다.

 

1 The API-first approach to development at Salesforce lets customers:

A.Extend functionality across Salesforce features

B.Choose the API that's best suited to their needs

C.Build apps for the AppExchange

D.All of the above

 

2 REST API is best suited for which of these use cases?

A.Loading lots of data into your org for the first time

B.Writing a mobile or web app

C.Deleting 100,000 records at once

D.Pushing notifications whenever data is changed X

 

3 SOAP API is best suited for which of these use cases?

A.Building a server-to-server integration

B.Writing an app that requires using JSON X

C.Updating thousands of records at once X

D.Building a slick UI for a mobile app

 

4 Bulk API is best suited for which of these use cases?

A.Deleting several records, one record at a time

B.Writing a mobile chat app

C.Building a new Salesforce UI

D.Deleting 100,000 records at once

 

5 Streaming API is best suited for which of these use cases?

A.Notifying users whenever a record is deleted

B.Creating hundreds of account records at once

C.Writing an app where the use of XML is required

D.Using a WSDL file to specify the operations allowed on standard and custom objects

 

6 What are all the factors that contribute to the total API limit calculation?

A.Org edition and API usage over the previous month X

B.Org edition, license type, and expansion packs

C.License type and expansion packs X

D.Number of Salesforce employees forced to walk the plank

 

REST API 사용

 

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• Workbench에 로그인하고 REST Explorer로 이동합니다.
• 설명 자원을 사용하십시오.
• REST API를 사용하여 계정을 만듭니다.
• REST API를 사용하여 쿼리를 실행합니다.

REST 리소스 및 메서드

랜드 호! 선장, 선수 앞에서 REST 섬을 발견했습니다. API를 도킹하고 사용하기 전에 REST 리소스와 메서드에 대해 알아보겠습니다.

 

REST 리소스는 단일 데이터 레코드, 레코드 모음 또는 쿼리와 같은 정보 또는 작업의 추상화입니다. 

REST API의 각 리소스는 명명된 URI(Uniform Resource Identifier)로 식별되며 표준 HTTP 메서드(HEAD, GET, POST, PATCH, DELETE)를 사용하여 액세스됩니다. 

REST API는 리소스, 해당 URI 및 리소스 간의 링크 사용을 기반으로 합니다.

 

리소스를 사용하여 Salesforce 조직과 상호 작용합니다. 예를 들어 다음을 수행할 수 있습니다.

• 사용 가능한 API 버전에 대한 요약 정보를 검색합니다.
• 계정, 사용자 또는 사용자 정의 개체와 같은 Salesforce 개체에 대한 자세한 정보를 얻습니다.
• 쿼리 또는 검색을 수행합니다.
• 레코드를 업데이트하거나 삭제합니다.

REST 요청은 리소스 URI, HTTP 메서드, 요청 헤더 및 요청 본문의 네 가지 구성 요소로 구성됩니다. 요청 헤더는 요청에 대한 메타데이터를 지정합니다. 요청 본문은 필요한 경우 요청에 대한 데이터를 지정합니다. 지정할 데이터가 없으면 요청에서 본문을 생략합니다.

Account Object 설명

발이 젖을 시간입니다. 

Workbench를 사용하여 일부 API 호출을 수행할 것입니다. 

Workbench는 API를 통해 Salesforce 조직과 상호 작용하기 위한 도구 모음입니다. 

모든 HTTP 발신자로부터 REST 요청을 할 수 있기 때문에 사용할 수 있는 다른 도구가 많이 있습니다

(예: cURL 또는 Postman 확인). 그러나 Workbench는 특히 Salesforce API를 위한 친숙한 프레임워크를 제공하므로 완전한 통합을 작성할 준비가 되기 전에 자세히 알아볼 수 있는 완벽한 방법입니다.

 

첫 번째 단계는 Workbench에 로그인하는 것입니다.

1. Trailhead Playground에 로그인하고 Workbench로 이동합니다 .
2. 환경에 대해 프로덕션 을 선택 합니다.
3. API 버전에서 사용 가능한 가장 높은 번호를 선택합니다.
4. 서비스 약관에 동의합니다를 선택했는지 확인합니다 .
5. Salesforce로 로그인을 클릭합니다 .

Workbench 홈 페이지에 도착했습니다. 이 모듈에서는 Workbench의 많은 도구 중 하나인 REST Explorer만 사용합니다.

상단 메뉴에서 유틸리티 | REST 탐색기 .

다른 HTTP 인터페이스에서와 마찬가지로 REST 탐색기에서 REST API를 호출할 수 있습니다. 

텍스트 상자의 텍스트는 리소스 URI를 나타냅니다. 편의상 표시되는 URI에서 최상위 도메인은 생략됩니다. 

예를 들어 URI 텍스트 상자에 미리 채워진 리소스의 전체 URI는 https://foo.my.salesforce.com/services/data/v36.0 입니다.

 

URI 위의 라디오 버튼은 표준 HTTP 메서드를 나타냅니다. API를 호출하려면 리소스 URI를 입력하고 적절한 메서드를 선택하고 필요에 따라 헤더를 추가하고 실행을 클릭 합니다 .

 

SObject 설명 리소스를 사용해 보겠습니다. 이 리소스는 GET 메서드와 결합될 때 개체 및 해당 필드에 대한 메타데이터를 반환합니다.

 

Account 개체를 설명하려고 합니다. URI 텍스트 상자의 기존 텍스트를 /services/data/vXX.0/sobjects/account/describe 로 바꿉니다. 여기서 XX는 사용 중인 API 버전에 매핑됩니다.

잠시 시간을 내어 이 리소스의 URI를 분석해 보겠습니다.

• /services/data - REST API 요청을 하고 있음을 지정합니다.
• /v36.0 - API 버전 번호
• /sobjects - sObject 그룹화에서 리소스에 액세스하고 있음을 지정합니다.
• /account - sObject가 작동 중입니다. 이 경우 계정
• /설명 - 작업; 이 경우 설명 요청

이제 GET 메서드가 선택되었는지 확인하고 Execute 를 클릭 합니다 .

잘했어요, 캡틴. 계정 메타데이터가 화면에 나타납니다. Workbench는 응답 형식을 멋지게 지정했습니다. 원시 JSON 응답을 보려면 원시 응답 표시 를 클릭하십시오 .

계정 메타데이터는 일부 HTTP 응답 헤더 아래에 JSON으로 표시됩니다. REST API는 JSON과 XML을 모두 지원하므로 요청 헤더를 변경하여 XML 응답을 지정해 보겠습니다. HTTP 메소드 옆에 있는 헤더 를 클릭하십시오 . Accept 헤더 값의 경우 application/json을 application/xml로 바꿉니다. 요청 헤더는 다음과 같습니다.

실행 을 클릭 합니다 . 원시 XML 응답이 반환됩니다. 만세!

계정 만들기(Create an Account)

이제 SObject 리소스와 POST 메서드를 사용하여 계정을 생성해 보겠습니다. URI 텍스트 상자에서 기존 텍스트를 /services/data/vXX.0/sobjects/account 로 바꿉니다 .

 

여기서 XX는 사용 중인 API 버전에 매핑됩니다. 

 

POST 를 선택 합니다 . 

 

새 계정에 대한 필드 값을 지정하는 요청 본문 텍스트 영역이 나타납니다. 하지만 먼저 Accept 헤더를 JSON으로 다시 변경해 보겠습니다.

 

머리글 을 클릭 합니다. 

 

Accept: application/xml을 다시 Accept: application/json으로 변경합니다. 귀하의 요청은 다음과 같습니다.

요청 본문에 다음 텍스트를 입력합니다.

{ "Name" : "NewAccount1", "ShippingCity" : "San Francisco" }

복사

실행 을 클릭 합니다 . 다음과 같은 응답이 표시됩니다.

성공: true인 경우 반환된 ID로 계정이 생성되었습니다. 오류 폴더를 확장하여 오류를 확인합니다.

간단하게 계정 이름을 지정하지 않고 두 번째 계정을 만들어 보겠습니다. 요청 본문의 텍스트를 다음 텍스트로 바꿉니다.

{ "ShippingCity" : "San Francisco" }

복사

실행 을 클릭 합니다 .

어 오. REQUIRED_FIELD_MISSING 응답을 받으셨습니까? 확장 REQUIRED_FIELD_MISSING의 폴더를 한 다음 확장 필드 폴더에 있습니다. 확장된 응답은 다음과 같습니다.

이름 은 계정 생성을 위한 필수 필드 이므로 서버에서 요청을 처리하지 않았고 오류가 발생했습니다. 고맙게도 요청을 수정하는 데 필요한 모든 정보는 오류 응답에 있습니다. NewAccount2라는 이름을 지정하고 요청 본문에서 배송 도시를 변경해 보겠습니다. 요청 본문의 텍스트를 다음 텍스트로 바꿉니다.

{ "Name" : "NewAccount2", "ShippingCity" : "New York" }

복사

실행 을 클릭 합니다 . 성공!

쿼리 실행(Execute a Query)

이제 귀하 또는 다른 사용자가 수백 개의 계정을 만들었다고 가정해 보겠습니다. 배송 도시가 샌프란시스코인 모든 계정의 이름을 찾고 싶습니다. 쿼리 리소스를 사용하여 SOQL 쿼리를 실행하고 사용자 지정된 보물 지도처럼 원하는 정확한 레코드를 확인할 수 있습니다.

URI 텍스트 상자의 텍스트를 /services/data/vXX.0/query/?q=SELECT+Name+From+Account+WHERE+ShippingCity='San+Francisco' 텍스트로 바꿉니다. 여기서 XX는 사용 중인 API 버전입니다.

URI를 적절하게 인코딩하기 위해 쿼리 문자열에서 공백을 + 문자로 대체했습니다. 리소스 섹션의 링크에서 HTML URL 인코딩에 대해 읽을 수 있습니다. GET 메서드가 선택되었는지 확인하고 Execute 를 클릭 합니다 .

레코드 폴더를 확장 합니다. 우리가 만든 첫 번째 계정인 NewAccount1의 이름이 있는 폴더가 보입니까? 엄청난. 클릭하세요. 이제 속성 폴더를 클릭 합니다. url 옆에는 반환된 계정의 리소스 URI가 있습니다. 귀하의 응답은 다음과 같습니다.

통합을 작성할 때 응답에서 이 URI를 가져와 해당 계정에 대한 자세한 정보에 액세스할 수 있습니다.

Node.js 및 Ruby 샘플

이제 REST API로 가능한 일을 맛보실 수 있습니다. 물론 Workbench에서 코드 작성으로 이동할 때 선택한 프로그래밍 언어를 사용하여 REST API와 상호 작용하게 됩니다. 운 좋게도 전문 Salesforce 개발자가 REST API 사용 프로세스를 단순화하는 여러 언어용 래퍼를 작성했습니다. 다음은 래퍼 JSforce 및 Restforce를 사용하는 Node.js 및 Ruby로 작성된 두 가지 샘플 쿼리입니다.

JSforce를 사용하는 Node.js 샘플

const jsforce = require("jsforce");const conn = new jsforce.Connection({   // you can change loginUrl to connect to sandbox or prerelease env.   // loginUrl : "https://test.salesforce.com" }); // Log in with basic SOAP login (see documentation for other auth options) conn.login(   process.env.USERNAME,   process.env.PASSWORD + process.env.SECURITY_TOKEN,   (err, res) => {     if (err) {       return console.error("Failed to log in to Salesforce: ", err);     }     console.log("Successfully logged in!");     // Run a SOQL query     conn.query("SELECT Id, Name FROM Account LIMIT 5", (err, result) => {       if (err) {         return console.error("Failed to run SOQL query: ", err);       }       // Display query results       const { records } = result;       console.log(`Fetched ${records.length} records:`);       records.forEach(record => {         console.log(`- ${record.Name} (${record.Id})`);       });     });   } );

 

Restforce를 사용한 Ruby 샘플

require 'restforce' # create the connection with the Salesforce connected app client = Restforce.new :username => ENV['USERNAME'],   :password       => ENV['PASSWORD'],   :security_token => ENV['SECURITY_TOKEN'],   :client_id      => ENV['CLIENT_ID'],   :client_secret  => ENV['CLIENT_SECRET'] # execute the query accounts = client.query("select id, name from account limit 5") # output the account names accounts.each do |account|   p account.Name end

Create an Account Using REST API and Workbench

Create an account using REST API and Workbench.

• • Name: Blackbeards Grog Emporium
  • Description: The finest grog in the seven seas.

 

https://workbench.developerforce.com/login.php 접속

 

 I agree to the terms of service 체크박스 체크하시고 Login with Salesforce 버튼을 클릭합니다.

Allow 버튼을 클릭하세요.

 

REST Explorer를 선택하고 Select 버튼을 클릭하세요.

아래화면이 나타나면

/sobjects/account 를 입력창에 추가해 주세요.

라디오 항목 중 POST를 선택하면 아래와 같이 변경됩니다.

아래 구문을 입력합니다.

{   "Name" : "Blackbeards Grog Emporium",   "Description" : "The finest grog in the seven seas." }

Execute 버튼을 클릭합니다.

Account 목록에 가보면 아래와 같이 해당 Account가 생성된 것을 확인 할 수 있습니다.

해당 항목을 클릭해서 상세 페이지 보시면 Description도 정상적으로 저장되었는지 확인하세요.

SOAP API 사용

 

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• 조직에 대한 WSDL 파일을 생성합니다.
• SoapUI를 사용하여 WSDL 파일에서 SOAP 프로젝트를 만듭니다.
• SOAP API를 사용하여 Trailhead Playground에 로그인합니다.
• SOAP API를 사용하여 계정을 만듭니다.

엔터프라이즈 및 파트너 WSDL

다른 SOAP 기반 API의 한계를 넘었다면 WSDL(Web Services Description Language) 파일이 기본적으로 API 사용 방법을 이해하기 위한 지도라는 것을 알고 있을 것입니다. 여기에는 API 호출을 수행하기 위한 바인딩, 프로토콜 및 개체가 포함됩니다.

 

Salesforce는 두 가지 사용 사례에 대해 두 가지 SOAP API WSDL을 제공합니다. 엔터프라이즈 WSDL은 단일 Salesforce 조직에 최적화되어 있습니다. 강력한 형식이 지정되어 있으며 조직의 특정 구성을 반영합니다. 즉, 두 개의 다른 조직에서 생성된 두 개의 엔터프라이즈 WSDL 파일에 서로 다른 정보가 포함되어 있습니다.

 

파트너 WSDL은 많은 Salesforce 조직에서 사용하도록 최적화되어 있습니다. 형식이 느슨하며 조직의 특정 구성에 따라 변경되지 않습니다.

일반적으로 단일 Salesforce 조직에 대한 통합을 작성하는 경우 엔터프라이즈 WSDL을 사용합니다. 여러 조직의 경우 파트너 WSDL을 사용합니다.

이 단원에서는 엔터프라이즈 WSDL을 사용하여 SOAP API를 탐색합니다. 첫 번째 단계는 조직에 대한 WSDL 파일을 생성하는 것입니다. Trailhead Playground의 설정에서 빠른 찾기 상자에 API를 입력 한 다음 API 를 선택 합니다 . API WSDL 페이지에서 엔터프라이즈 WSDL 생성을 클릭 하십시오 .

엔터프라이즈 WSDL 생성 페이지에서 생성 을 클릭 하십시오 . WSDL이 생성되면 페이지를 마우스 오른쪽 버튼으로 클릭하고 컴퓨터의 어딘가에 WSDL 파일을 저장합니다. 곧 사용하겠습니다.

다음은 엔터프라이즈 WSDL 작업에 대한 팁입니다. 엔터프라이즈 WSDL은 조직의 특정 구성을 반영하므로 조직에 메타데이터를 변경할 때마다 WSDL 파일을 다시 생성합니다. 이렇게 하면 WSDL 파일이 조직의 구성과 동기화되지 않습니다.

SoapUI로 SOAP 프로젝트 만들기

이제 WSDL 파일이 있으므로 SOAP API 요청을 만들기 위해 정보를 추출하는 방법이 필요합니다. 웹 용어로 이 프로세스를 WSDL 사용이라고 합니다. 크라켄이 불운한 선원으로 가득 찬 배를 소비하는 것처럼 WSC(웹 서비스 커넥터)와 같은 도구는 WSDL 파일을 소비합니다. 그런 다음 도구는 일반 프로그래밍 언어를 사용하여 SOAP API로 요청할 수 있는 클래스를 만듭니다.

 

이 단원에서는 SoapUI라는 타사 도구를 사용하여 엔터프라이즈 WSDL 파일을 사용합니다. SoapUI는 웹 서비스 테스트를 위한 무료 오픈 소스 앱입니다. 시작하려면 SoapUI 웹사이트 에서 SoapUI OpenSource를 다운로드하여 설치하십시오 . SoapUI 구성요소만 설치하십시오.

SoapUI가 번들 및 사용하는 Java 버전이 조직의 보안 정책과 호환되는지 확인하십시오. SoapUI가 사용하는 Java 버전에 대한 정보는 Help | SoapUI 내에서 시스템 설정 .

SoapUI를 설치하고 시작한 후 파일 메뉴에서 새 SOAP 프로젝트를 선택 합니다 . 프로젝트 이름으로 Salesforce SOAP API 탐색을 입력합니다. 초기 WSDL의 경우 엔터프라이즈 WSDL 파일을 저장한 위치를 찾아 선택합니다. 다른 옵션을 변경하지 마십시오. SoapUI 창은 다음과 같습니다.

클릭 OK . 몇 초의 처리 후 탐색 Salesforce SOAP API 폴더가 화면 왼쪽의 네비게이터 창에 나타납니다. 그 아래에는 여러 작업이 포함된 SoapBinding이라는 항목이 있습니다.

그래서 우리는 여기서 무엇을 보고 있습니까? 각 작업은 우리가 할 수 있는 SOAP API 요청에 해당합니다. 각 작업의 속성은 WSDL 파일의 정보에서 가져옵니다. 각 작업에는 작업의 HTTPS 끝점과 미리 채워진 SOAP 메시지가 포함된 샘플 XML 요청도 포함되어 있습니다.

한 가지 더—Salesforce에서 TLS 1.2 이상을 사용하려면 모든 연결이 필요합니다. Java 7에서 SoapUI를 사용하는 경우 TLS 1.2는 기본적으로 활성화되어 있지 않습니다. 이전 버전의 TLS를 사용하여 Salesforce에 연결하려고 하면 오류 메시지가 표시됩니다. 좋은 소식은 이것이 매우 간단한 수정이라는 것입니다. 자세한 내용은 이 편리한 블로그 게시물 을 확인하세요.

이제 우리는 모두 SOAP API 요청을 할 준비가 되었습니다. 전진하세요, 캡앤!

Trailhead 놀이터에 로그인

SoapUI에서 로그인 작업까지 아래로 스크롤합니다. 확장한 다음 요청 1 을 두 번 클릭 합니다. 샘플 SOAP 로그인 요청이 나타납니다.

다음은 끝점 URI(1)에 대한 간략한 분석입니다.

• https:// - 보안 HTTP를 지정합니다.
• login.salesforce.com - 로그인 요청에 대한 최상위 도메인입니다.
• /services/Soap - SOAP API 요청을 하고 있음을 지정합니다.
• /c - 엔터프라이즈 WSDL을 사용하고 있음을 지정합니다. 파트너 WSDL에 /u를 사용합니다.
• /36.0 - API 버전 번호입니다. v 접두사가 일부 API에는 버전 번호 앞에 포함되고 일부는 포함되지 않기 때문에 누락되었습니다. 이 동작은 Salesforce API의 특징일 뿐입니다.
• /0DF36000000LHZw - 패키지 버전 번호입니다.

이 예에서는 관리되는 패키지를 사용하지 않으므로 URI 끝에서 패키지 버전 번호를 제거할 수 있습니다. 지금 하세요.

SOAP 메시지(2)에는 우리가 SOAP 메시지에서 찾을 것으로 예상되는 모든 것, 즉 봉투, 헤더 및 본문이 포함되어 있습니다.

LoginScopeHeader 요소 내부의 속성은 셀프 서비스 및 고객 포털 사용자의 인증과 관련됩니다. 목적상 이러한 값에 대해 걱정할 필요가 없으므로 전체 <urn:LoginScopeHeader> 요소(<urn: LoginScopeHeader>에서 </urn:LoginScopeHeader>까지의 모든 항목)를 삭제합니다. 창에서 텍스트를 강조 표시하고 Delete 키를 누릅니다.

다음으로, 메시지 본문의 <urn:login> 요소를 살펴보십시오. 이 요소는 로그인 요청의 대부분입니다. 여기에서 사용자 자격 증명을 제공합니다. ?s를 Trailhead Playground의 사용자 이름과 비밀번호로 바꾸십시오.

이렇게 하려면 Trailhead Playground 자격 증명이 필요합니다. 앱 런처에서 Playground Starter를 찾아 열고 아래 단계를 따르세요. Playground Starter 앱이 표시되지 않으면 Trailhead 도움말에서 Trailhead Playground의 사용자 이름 및 암호 찾기를  확인하십시오 .

1. 로그인 자격 증명  가져오기 탭을 클릭하고 사용자 이름을 기록해 둡니다.
2. 내 비밀번호 재설정 을 클릭합니다 . 그러면 사용자 이름과 연결된 주소로 이메일이 전송됩니다.
3. 이메일에 있는 링크를 클릭합니다.

Salesforce에 알려지지 않은 IP 주소에서 API 요청을 하고 있으므로 비밀번호 끝에 보안 토큰을 추가해야 합니다. 예를 들어 비밀번호가 mypassword이고 보안 토큰이 XXXXXXXXXX인 경우 <urn:password> 요소 안에 mypasswordXXXXXXXXXX를 입력합니다.

보안 토큰을 얻으려면 개인 설정으로 이동한 다음 내 개인 정보 아래의 내 보안 토큰 재설정 페이지 로 이동 하십시오 . 보안 토큰 재설정을 클릭 하여 토큰과 함께 Trailhead Playground와 연결된 이메일 주소로 이메일을 보냅니다.

SOAP 메시지는 다음과 같습니다.

요청 창 왼쪽 상단의 재생 버튼(녹색 삼각형)을 클릭합니다. 이 버튼은 요청을 전송하여 SOAP 메시지를 바다로 보냅니다. 응답을 확장하면 다음과 같습니다.

축하합니다, 캡틴. 성공적으로 로그인했습니다. 응답에는 조직 및 사용자에 대한 많은 정보가 포함되어 있습니다. 가장 중요한 것은 여기에 강조 표시된 조직의 내 도메인 이름(또는 내 도메인을 사용하지 않는 경우 인스턴스)과 향후 요청에 사용할 세션 ID가 포함되어 있다는 것입니다.

인스턴스 및 세션 ID를 텍스트 파일에 복사합니다. 우리는 1분 안에 그것들을 사용합니다.

조직의 인스턴스가 변경될 수 있으므로 통합 구축을 시작할 때 인스턴스에 대한 참조를 하드 코딩하지 마십시오! 대신 조직의 내 도메인 로그인 URL을 사용하십시오. 내 도메인을 사용하여 Salesforce 조직에 대한 고객별 도메인을 구성합니다. A My Domain은 인스턴스 이름을 변경하는 번거로움을 없애줄 뿐만 아니라; 또한 이를 사용하여 브랜드를 강조하고, 조직을 보다 안전하게 만들고, 로그인 페이지를 개인화할 수 있습니다. 조직이 Winter '21 릴리스 이전에 생성된 경우 이 기능을 활성화해야 할 수 있습니다. 내 도메인을 설정하는 방법에 대한 지침 은 사용자 인증 을 참조하십시오 .

내 도메인은 이미 Trailhead 놀이터에 있습니다.

기본적으로 내 도메인은 모든 Trailhead Playground에서 이미 켜져 있습니다. Trailhead Playground에서 내 도메인을 켜거나 설정을 변경하려고 하지 마십시오. 내 도메인 설정을 변경하면 플레이그라운드 조직이 잠길 수 있습니다.

프로덕션 조직에서 내 도메인을 사용하여 조직에 고유한 하위 도메인을 만들 수 있습니다. 조직의 로그인 URL에 https://na17.salesforce.com과 같은 Salesforce 인스턴스가 포함된 경우 내 도메인을 배포하면 https://mydomainname.my.salesforce.com과 같은 회사별 로그인 URL로 바뀝니다.

내 도메인은 사용자 정의 Lightning 구성 요소를 만들고 조직에서 SSO(Single Sign-On)를 설정하는 데 필요합니다. Winter '21 조직에서 생성된 모든 프로덕션, Developer Edition 및 평가판 조직은 기본적으로 내 도메인을 가져오는 것이 매우 중요합니다. 프로덕션 조직에서 내 도메인을 활성화하는 방법을 알아보려면 Salesforce 도움말의 내 도메인 으로 이동하십시오. My Domain 및 Trailhead Playground에 대해 자세히 알아보려면 이 지식 문서를 확인 하십시오 .

계정 만들기

REST API에서 했던 것처럼 SOAP API로 계정을 생성해 봅시다. 화면 왼쪽의 탐색 창에서 만들기 작업을 찾습니다. 확장하고 요청 1 을 두 번 클릭 합니다.

레코드 생성은 로그인보다 복잡하기 때문에 create() SOAP 메시지에는 더 많은 요소가 포함됩니다. 대부분의 요소는 요청 헤더에 포함되며 대부분은 선택 사항입니다. 일을 단순화하기 위해 대부분의 헤더 정보를 삭제하지만 이러한 헤더에서 제공하는 옵션은 레코드를 생성할 때 사용할 수 있다는 점을 기억하십시오. 각 헤더가 하는 일에 대한 정보는 SOAP API 개발자 안내서의 SOAP 헤더 항목을 확인하십시오.

그러나 삭제하고 싶지 않은 헤더는 SessionHeader입니다. 여기에는 login() 응답에서 얻은 세션 ID가 포함됩니다. 계속해서 <urn:EmailHeader>에서 </urn:AssignmentRuleHeader>까지의 다른 헤더를 삭제하십시오. 귀하의 메시지는 다음과 같습니다.

텍스트 파일에 복사한 세션 ID를 가져와 <urn:sessionId> 태그 안에 붙여넣고 ?를 대체합니다.

메시지 본문을 몇 가지 더 조정해야 합니다. 먼저 계정을 생성한다고 지정합니다.  태그의 텍스트를 다음과 같이 변경합니다. . 이 조정은 XML 인스턴스 스키마 선언을 사용하여 올바른 레코드 유형을 지정합니다.

또한 계정 이름을 지정하고 싶습니다. sObjects 요소 내에 <Name>샘플 SOAP 계정</Name>을 추가합니다. fieldsToNull 및 Id 요소도 삭제합니다. 이제 귀하의 메시지는 다음과 같습니다.

요청하기 전에 마지막으로 해야 할 일. 로그인이 아닌 조직의 인스턴스를 지정하도록 끝점을 변경하고 URI 끝에서 패키지 버전을 제거합니다. 끝점 URI는 다음과 같습니다. https:// MyDomainName .my.salesforce.com/services/Soap/c/36.0.

요청을 보낼 준비가 되었습니다. 녹색 삼각형을 다시 클릭합니다. 그것은 효과가 있었다! 반응을 살펴보자.

LimitInfoHeader에 주목하십시오. 이 헤더는 API 사용에 대한 정보를 반환합니다. 위의 예에서 우리는 오늘 100,000개의 허용된 호출 중 9개를 만들었습니다.

응답 본문에서 <result> 요소를 확인하십시오. <success>true</success>는 레코드가 성공적으로 생성되었음을 나타냅니다. <id>에는 향후 요청에서 사용할 수 있는 레코드의 ID가 포함됩니다.

SOAP API로 요청하는 기본 사항을 다루었습니다. 물론 각 작업에는 자체 매개 변수와 특성이 있습니다. SOAP API와의 통합 작성을 시작할 때 SOAP API 개발자 안내서를 지도로 사용하는지 확인하십시오.

 

Create an Account Using SOAP API and SoapUI

Create an account using SOAP API and SoapUI.

• • Name: Bluebeards Grog House
  • Description: It is better than Blackbeards.

 

 

아래 화면이 나오면 Ctrl + S 를 눌러 저장합니다.

https://www.youtube.com/watch?v=EMOVBgmcuQE