매일, 수천 개의 기업과 수백만 명의 사용자은 Salesforce Platform이 구동하는 애플리케이션을 사용하여 클라우드에서 비즈니스를 운영합니다. 플랫폼이 그렇게 성공적인 이유는 무엇입니까? 왜 귀하의 비즈니스를 지원하기 위해 Trust 할 수 있습니까? 플랫폼이 귀사와 같은 비즈니스에 제공하는 고유한 혜택은 무엇입니까?

이 기술 요약은 Salesforce Platform이 클라우드 컴퓨팅용 고유한 소프트웨어 아키텍처를 사용하여 신뢰할 수 있고 확장 가능하며 쉽게 사용자 정의할 수 있는 최종 사용자 환경을 제공하는 방법에 대해 설명합니다. 이 요약을 읽은 후에는 Salesforce Platform을 비즈니스 응용 프로그램에 가장 적합한 선택으로 만드는 기본 기술을 더 잘 이해할 수 있습니다.

Salesforce Platform은 성공적인 클라우드 컴퓨팅 플랫폼과 응용 프로그램의 관련 생태계의 탁월한 예입니다. 밀레니엄 전반 이후 플랫폼은 다음을 지원하는 기반이 되었습니다.

• 판매 및 고객 서비스와 같은 일반적인 사용 사례에 대한 많은 인기있는 비즈니스 응용 프로그램
• 금융 및 의료 등과 같은 더 전문적인 용도 사례에 대한 산업별 응용 프로그램
• 고유한 사용 사례를 위한 수백만 개의 사용자 지정 애플리케이션 및 애플리케이션 확장

대부분의 경우 Salesforce Platform은 독특한 소프트웨어 아키텍처로 구축, 사용, 사용자 정의 및 확장하기 쉬운 애플리케이션을 지원하며 뛰어난 성능과 신뢰성을 갖추기 때문에 매우 성공적이고 인기가 있습니다. 플랫폼의 소프트웨어 아키텍처의 핵심은 멀티테넌트, 메타데이터 기반 디자인입니다.

Salesforce Platform의 소프트웨어 아키텍처는 다음과 같습니다.

• Multitenant — 여러 테넌트(조직, 사업부 등)의 다양한 요구 사항을 격리하고 동시에 지원합니다.
• 메타데이터 구동 - 모든 테넌트가 사용자 인터페이스(UI) 및 비즈니스 논리와 같은 요소를 설명하는 메타데이터, 데이터를 사용하여 앱과 사용자 환경을 쉽고 빠르게 사용자 정의할 수 있습니다.

Salesforce Platform을 사용하여 새 응용 프로그램 개체를 만들거나 코드를 작성하는 경우 플랫폼에서 데이터베이스에 실제 테이블을 만들거나 코드를 컴파일하지 않습니다. 대신 플랫폼은 몇 가지 메타데이터를 저장하기만 하면 런타임 시 가상 응용 프로그램 구성 요소를 동적으로 구체화할 수 있습니다. 플랫폼을 사용하면 모든 테넌트의 메타데이터가 비공개로 유지되고 잠금 또는 가동 중지 시간 없이 쉽게 업데이트할 수 있으므로 모든 테넌트가 격리적으로 앱을 구축하고 사용자 정의할 수 있습니다. Salesforce Platform은 같은 메타데이터를 사용하여 응용 프로그램을 다른 응용 프로그램 및 자동 프로세스와 통합하는 데 사용할 수 있는 사용자 정의 API, RESTful 및 웹 서비스(SOAP 기반) 인터페이스를 제공합니다.

준비된 솔루션은 플랫폼의 광범위한 앱 마켓플레이스인 AppExchange에서도 사용할 수 있습니다. 신뢰할 수 있는 파트너 및 독립 소프트웨어 공급업체(ISV)의 광범위한 에코시스템에 의해 구축된 AppExchange 패키지는 무료 또는 유료 응용 프로그램 확장 프로그램 및 특정 비즈니스 요구 사항을 충족하기 위해 사용할 수 있는 전체 응용 프로그램을 설명하는 타사 메타데이터입니다.

이 고도로 사용자 정의 가능하고 확장 가능한 아키텍처를 지원하기 위해 Salesforce Platform의 단일 인스턴스는 다음을 사용합니다.

• 테넌트별 메타데이터 및 데이터를 저장하는 단일 스키마를 사용하는 단일 공유 다중 테넌트 데이터베이스입니다.
• 메타데이터 및 데이터를 읽어 런타임 시 각 테넌트의 사용자에게 동적으로 테넌트별 응용 프로그램, 비즈니스 논리 및 API를 제공하는 다중 테넌트 커널(응용 프로그램 런타임)입니다.

Salesforce 관리 커널을 테넌트 관리 메타데이터와 명확하게 구분하면 Salesforce, 테넌트, ISV가 중단 없이 시스템의 일부를 독립적으로 개발할 수 있습니다.

이 개요를 기반으로 이 기사의 후속 섹션에서는 다음과 같은 주요 디자인 측면에서 파생된 플랫폼의 고유한 기능에 대한 자세한 정보를 제공합니다.

• 플랫폼 데이터 레이어
• 플랫폼 애플리케이션 개발
• 내부 플랫폼 처리
• 플랫폼 인프라

Salesforce Platform의 응용 프로그램 런타임 및 혁신적인 데이터 레이어는 함께 테넌트별 데이터, 스키마 사용자 정의, 비즈니스 논리를 안전하게 격리합니다. 높은 수준에서 스키마는 다양한 사용 사례를 지원합니다.

• 응용 프로그램을 만들거나 사용자 정의하면 플랫폼이 모든 테넌트에 대한 메타데이터를 유지하는 공유 데이터베이스 테이블에 관련 메타데이터를 저장합니다.
• 응용 프로그램을 사용하여 데이터를 읽거나 쓸 경우 플랫폼이 모든 테넌트에 대한 데이터를 유지하는 공유 데이터베이스 테이블에 데이터를 저장합니다.
• 또한 플랫폼은 런타임 시 요청 대기 시간을 최적화하기 위해 커널이 사용하는 여러 테이블에 내부 메타데이터를 유지합니다.

그러나 단일 공유 데이터베이스 및 스키마는 모든 테넌트의 데이터를 어떻게 비공개로 유지할 수 있습니까? 플랫폼의 모든 테넌트는 조직으로 알려져 있습니다. 즉, 조직입니다. 그리고 공유 데이터베이스 테이블의 모든 조직별 레코드에는 OrgID가 있습니다. 커널이 데이터베이스에 액세스하면 각 조직의 활동이 비공개로 유지되도록 이 고유 식별자를 사용합니다.

조직별 객체(일반적인 관계형 데이터베이스 언어에서 테이블을 생각), 필드, 저장된 절차, 데이터베이스 트리거 등은 플랫폼이 *유니버설 데이터 사전(UDD)*으로 알려진 몇 가지 데이터베이스 테이블에 저장하는 메타데이터에 의해 설명되는 가상 구조입니다.

• MT_Objects는 개체에 대한 고유 식별자(ObjID), 조직(OrgID), 개체에 대해 제공하는 이름(ObjName)을 포함하여 응용 프로그램에 대해 정의하는 개체에 대한 메타데이터를 저장하는 데이터베이스 테이블입니다.
• MT_Fields 시스템 테이블은 각 개체에 대해 선언하는 필드(열)에 대한 메타데이터를 저장합니다(필드에 대한 고유 식별자(FieldID), 조직(OrgID), 필드를 포함하는 개체(ObjID), 필드 이름(FieldName), 필드의 데이터 유형, 필드에 색인화가 필요한지 여부를 나타내는 부울 값(IsIndexed), 개체의 다른 필드(FieldNum)에 대한 필드 위치를 포함합니다.

메타데이터가 핵심 구성 요소이므로 플랫폼에서 메타데이터에 대한 액세스를 최적화해야 합니다. 그렇지 않으면 자주 메타데이터에 액세스하면 서비스가 확장되지 않습니다. 이 잠재적인 병목을 고려하여 플랫폼은 대규모하고 정교한 메타데이터 캐시를 사용하여 가장 최근에 사용된 메타데이터를 메모리에 유지하고, 성능이 저하되는 디스크 I/O 및 코드 재구성을 방지하고, 애플리케이션 응답 시간을 단축합니다.

MT_Data 시스템 테이블은 MT_Objects 및 MT_Fields의 메타데이터로 정의된 모든 조직별 테이블 및 해당 필드에 매핑되는 응용 프로그램에 액세스할 수 있는 데이터를 저장합니다. 각 행에는 전역 고유 식별자(GUID), 행을 소유한 조직(OrgID), 포괄적인 개체 식별자(ObjID)와 같은 식별 필드가 포함됩니다. MT_Data 테이블의 각 행에는 해당 레코드에 대한 "자연 이름"을 저장하는 이름 필드도 있습니다. 예를 들어, 계정 레코드에서 "계정 이름", 사례 레코드에서 "사례 번호"를 사용할 수 있습니다.

값0 ... 슬롯으로도 알려진 ValueN 플렉스 열은 각각 MT_Objects 및 MT_Fields에 선언된 테이블 및 필드에 매핑되는 응용 프로그램 데이터를 저장합니다. 모든 유연한 열은 변수 길이 문자열 데이터 유형을 사용하므로 구조화된 모든 유형의 응용 프로그램 데이터(문자열, 숫자, 날짜 등)를 저장할 수 있습니다. 다음 그림에 표시된 바와 같이 동일한 개체의 두 개의 필드는 저장하기 위해 MT_Data의 동일한 슬롯에 매핑할 수 없습니다. 그러나 각 필드가 다른 개체에서 파생되는 한 단일 슬롯은 여러 필드의 정보를 관리할 수 있습니다.

MT 필드는 텍스트, 숫자, 날짜 및 날짜/시간과 같은 여러 표준 구조화된 데이터 유형 중 하나를 사용할 수 있으며, 선택 목록(목록된 필드), 자동 번호(자동 증분, 시스템 생성 순서 번호), 수식(읽기 전용 파생 값), 마스터-세부 사항 관계(외부 키), 확인란(부울), 이메일, URL 등과 같은 특수 용도 _ 풍부한 구조화된 데이터 유형을 사용할 수 있습니다. MT_Fields는 Null이 아닌 필수 필드이며, 플랫폼에서 적용되는 사용자 정의 확인 규칙(예: 하나의 필드가 다른 필드보다 커야 함)이 있습니다.

개체를 선언하거나 수정하면 플랫폼에서 개체를 정의하는 MT_Object의 메타데이터 행을 관리합니다. 마찬가지로 각 필드에 대해 플랫폼은 해당 필드 데이터를 저장하기 위해 필드를 MT_Data의 특정 유연한 열에 매핑하는 메타데이터를 포함하여 MT_Fields의 행을 관리합니다. 플랫폼이 실제 데이터베이스 구조가 아닌 메타데이터로 개체 및 필드 정의를 관리하므로 시스템은 다른 조직과 사용자의 동시 활동을 차단하지 않고도 온라인 다중 테넌트 응용 프로그램 스키마 유지 관리 활동을 허용할 수 있습니다. 비교를 위해 기존의 관계형 데이터베이스 시스템에 대한 온라인 테이블 재정의에는 일반적으로 임시 잠금이 필요하며 종종 번거로운 복잡한 프로세스와 예약된 응용 프로그램 가동 중지 시간이 필요합니다.

이전 그림의 MT_Data 간소화된 표현에 표시된 바와 같이 유연한 열은 범용 데이터 유형(변수 길이 문자열)이며, 이를 통해 플랫폼이 다양한 구조화된 데이터 유형(문자열, 숫자, 날짜 등)을 사용하는 여러 필드 간 단일 유연한 열을 공유할 수 있습니다.

플랫폼은 모든 유연한 열 데이터를 일반 형식으로 저장하고, 응용 프로그램이 데이터를 읽고 데이터를 유연한 열에 쓸 때 필요한 경우 데이터베이스 시스템 데이터 유형 변환 함수를 사용합니다(예: TO_NUMBER, TO_DATE, TO_CHAR).

MTData에는 이전 그림에 표시되지 않은 열도 포함되어 있습니다. 예를 들어, 행을 만든 사용자 및 해당 행이 생성된 시기, 행을 마지막으로 수정한 사용자 및 행이 마지막으로 수정된 시기를 포함하여 감사 데이터를 관리하는 4개의 열이 있습니다. MT_Data에는 플랫폼이 행이 삭제된 시점을 나타내는 데 사용하는 _IsDeleted 열도 포함되어 있습니다.

플랫폼은 최대 32,000자의 긴 텍스트 필드를 저장할 수 있도록 필드를 *문자 대형 객체(CLOB)*로 선언하는 것도 지원합니다. MT Data의 각 행에 CLOB가 있는 경우 플랫폼은 _MT_Clob이라는 테이블에 CLOB를 오프라인으로 저장하며, 시스템은 필요에 따라 MT_Data의 해당 행에 연결할 수 있습니다.

참고: 플랫폼은 빠른 텍스트 검색을 위해 데이터베이스 외부의 색인화된 형식으로 CLOB도 저장합니다. 플랫폼의 텍스트 검색 엔진에 대한 자세한 내용은 검색을 참조하십시오.

플랫폼은 다양한 유형의 필드를 자동으로 색인화하여 확장 가능한 성능을 제공합니다.

기존 데이터베이스 시스템은 네이티브 데이터베이스 색인을 사용하여 특정 조건과 일치하는 필드가 있는 데이터베이스 테이블에서 특정 행을 빠르게 찾습니다. 그러나 플랫폼은 단일 유연한 열을 사용하여 다양한 구조화된 데이터 유형의 많은 필드의 데이터를 저장하기 때문에 MTData의 유연한 열에 대한 네이티브 데이터베이스 인덱스를 생성하는 것은 실용적이지 않습니다. 대신 플랫폼은 색인화하도록 표시된 필드 데이터를 _MT_Indexes 피벗 테이블의 해당 열로 동기식으로 복사하여 MT_Data의 색인을 관리합니다.

MT_Indexes에는 플랫폼에서 해당 데이터 유형의 필드 데이터를 찾는 데 사용하는 StringValue, NumValue, DateValue와 같은 강력하게 입력된 색인화된 열이 포함되어 있습니다. 예를 들어, 플랫폼이 MT_Data Flex 열의 문자열 값을 MT_Indexes의 StringValue 필드에 복사하고 DateValue 필드에 날짜 값을 복사하는 등 MT_Indexes의 기본 색인은 표준이 아닌 고유한 데이터베이스 색인입니다. 내부 시스템 쿼리에 개체의 구조화된 필드를 참조하는 검색 매개 변수가 포함된 경우 플랫폼의 사용자 정의 쿼리 최적화 프로그램은 MT_Indexes를 사용하여 관련 데이터 액세스 작업을 최적화합니다.

참고: 이 플랫폼은 사례 폴링 알고리즘을 사용하여 문자열 값을 범용, 대/소문자를 구분하지 않는 형식으로 변환하기 때문에 여러 언어 간의 검색을 처리할 수 있습니다. MT_Indexes 테이블의 StringValue 열에 이 형식으로 문자열 값이 저장됩니다. 런타임 시 쿼리 최적화 프로그램이 최적화된 SQL 문이 해당 대/소문자 폴드 StringValue를 필터링하도록 데이터 액세스 작업을 자동으로 구축하며, 이는 검색 요청에 제공된 리터럴에 해당합니다.

플랫폼을 사용하면 개체의 필드에 고유한 값(대/소문자를 구분하거나 대/소문자를 구분하지 않음)이 포함되어야 하는 시점을 표시할 수 있습니다. MT_Data의 배열 및 필드 데이터에 대한 값 열의 공유 사용을 고려할 경우 개체에 대해 고유한 데이터베이스 색인을 만드는 것은 실용적이지 않습니다. (이 상황은 비고유 색인에 대해 이전 섹션에서 논의한 상황과 유사합니다.)

사용자 정의 필드의 고유성을 지원하기 위해 플랫폼은 MT_Unique_Indexes 피벗 테이블을 사용합니다. 이 테이블은 MT_Unique_Indexes의 기본 데이터베이스 색인에 고유성이 적용되는 것을 제외하고 MT_Indexes 테이블과 매우 유사합니다. 응용 프로그램이 고유성이 필요한 필드에 중복 값을 삽입하려고 시도하거나 관리자가 중복 값이 포함된 기존 필드에 고유성을 적용하려고 시도하면 플랫폼이 응용 프로그램에 적절한 오류 메시지를 반환합니다.

드문 경우, 플랫폼의 외부 검색 엔진(검색에 설명됨)이 과부하되거나 사용하지 못할 수 있으며, 검색 요청에 적시에 응답할 수 없습니다. 최종 사용자에게 실망스러운 오류를 반환하는 대신 플랫폼이 합리적인 검색 결과를 제공하기 위해 보조 검색 메커니즘으로 돌아갑니다.

대상 레코드의 이름 필드를 참조하는 검색 조건이 있는 직접 데이터베이스 쿼리로 구현되는 대체 검색입니다. 잠재적으로 비용이 많이 드는 조인 쿼리를 실행하지 않고 전역 객체 검색(테이블에 걸친 검색)을 최적화하기 위해 플랫폼은 모든 레코드의 이름을 기록하는 MT_Fallback_Indexes 피벗 테이블을 유지합니다. MT_Fallback_Indexes에 대한 업데이트는 트랜잭션이 레코드를 수정할 때 동기식으로 수행되므로 대체 검색에서 항상 최신 데이터베이스 정보에 액세스할 수 있습니다.

MT_Name_Denorm 테이블은 MT_Data에 각 레코드의 ObjID 및 이름을 저장하는 lean 데이터 테이블입니다. 응용 프로그램에서 상위/하위 관계와 관련된 레코드 목록을 제공해야 하는 경우 플랫폼에서 MT_Name_Denorm 테이블을 사용하여 하이퍼링크의 일부 등 앱에 표시하기 위해 참조된 각 레코드의 이름을 검색하는 상대적으로 간단한 쿼리를 실행합니다.

이 플랫폼은 조직이 테이블 간 관계(참조 무결성)를 선언하는 데 사용할 수 있는 관계 데이터 유형을 제공합니다. 관계 유형으로 개체의 필드를 선언하면 플랫폼이 필드를 MT_Data의 값 필드에 매핑한 다음 이 필드를 사용하여 관련 개체의 ObjID를 저장합니다.

조인 작업을 최적화하기 위해 플랫폼은 MT_Relationships 피벗 테이블을 유지합니다. 이 시스템 테이블에는 필요한 경우 양방향으로 효율적인 개체 이동을 허용하는 두 가지 기본 데이터베이스 고유 복합 색인이 있습니다.

마우스 클릭 몇 번으로 플랫폼은 모든 필드에 대한 내역 추적을 제공합니다. 조직에서 특정 필드에 대한 감사를 활성화하면 내부 피벗 테이블을 감사 추적으로 사용하여 필드에 대한 변경 사항(기존 및 새 값, 변경 날짜 등)에 대한 정보를 비동기식으로 기록합니다.

기본 데이터베이스 색인을 포함하여 모든 플랫폼 데이터, 메타데이터 및 피벗 테이블 구조가 기본 데이터베이스 분할 메커니즘을 사용하여 OrgID로 물리적으로 분할됩니다. 데이터 분할은 데이터베이스 시스템에서 대규모 논리적 데이터 구조를 더 작고 관리 가능한 조각으로 물리적으로 나누기 위해 제공하는 입증된 기술입니다. 또한 파티션은 멀티테넌트 환경과 같은 대규모 데이터베이스 시스템의 성능, 확장성, 가용성을 향상하는 데 도움이 됩니다. 정의적으로 모든 플랫폼 쿼리는 특정 조직의 정보를 대상으로 하므로 쿼리 최적화 프로그램은 전체 테이블 또는 색인이 아닌 조직의 데이터를 포함하는 데이터 파티션에 액세스하는 것을 고려해야 합니다. 이러한 일반적인 최적화는 "파티션 자르기"라고도 불립니다.

이 섹션에서는 앱 개발자가 스키마의 기본 메타데이터를 만든 다음, 데이터를 관리하는 앱을 구축하는 방법을 설명합니다. 해당 메타데이터 및 데이터는 이전 섹션에 설명된 플랫폼 데이터 레이어에 저장됩니다.

개발자는 플랫폼의 브라우저 기반 개발 환경(일반적으로 플랫폼 설정 화면이라고 함)을 사용하여 서버측 응용 프로그램 구성 요소를 선언적으로 구축할 수 있습니다. 설정의 포인트 앤 클릭 UI는 응용 프로그램의 데이터 모델 생성(개체 및 해당 필드와 관계 포함), 보안 및 공유 모델(사용자, 프로필, 역할 계층 포함), 사용자 인터페이스(화면 레이아웃, 데이터 입력 양식, 보고서 포함), 선언적 논리(워크플로), 프로그램 논리(저장된 절차 및 트리거) 등 응용 프로그램 스키마 구축 프로세스의 모든 패싯을 지원합니다. 예를 들어 Salesforce 플로를 사용하면 광범위한 사용 사례를 쉽게 자동화할 수 있습니다. 아래에 표시된 설정의 Flow Builder UI를 사용하면 사용자와 상호 작용하는 워크플로를 그래픽 방식으로 설계 및 구현하거나 일정에 따라 또는 이벤트로 트리거되면 자동으로 실행할 수 있습니다.

설정 화면을 사용하면 코드가 없거나 매우 적은 응용 프로그램을 쉽게 개발하고 사용자 정의할 수 있습니다. 예:

• 플랫폼 네이티브 UI는 코드 없이 쉽게 구축할 수 있습니다. 기본 앱 UI는 쿼리, 삽입, 업데이트, 삭제를 포함하여 일반적인 모든 데이터 액세스 작업을 지원합니다. 네이티브 플랫폼 응용 프로그램에서 수행하는 각 데이터 조작 작업은 한 번에 하나의 개체를 수정하고 별도의 트랜잭션에서 각 변경 사항을 자동으로 커밋할 수 있습니다.
• 민감한 데이터가 포함된 개체에 대한 텍스트 필드를 정의할 때 플랫폼이 해당 데이터를 암호화하고 경우에 따라 입력 마스크를 사용하여 눈에 띄는 화면 정보를 숨길 수 있도록 필드를 쉽게 구성할 수 있습니다.
• 선언적 확인 규칙은 조직이 프로그래밍 없이 도메인 무결성 규칙을 적용하는 간단한 방법입니다. 예를 들어 LineItem 개체의 수량 필드가 항상 0보다 큰지 확인하는 확인 규칙을 선언할 수 있습니다.
• 수식 필드는 계산된 필드를 객체에 쉽게 추가할 수 있는 플랫폼의 선언적 기능입니다. 예를 들어 LineItem 개체에 필드를 추가하여 LineTotal 값을 계산할 수 있습니다.
• 롤업 요약 필드은 상위 개체에서 하위 필드 정보를 쉽게 집계할 수 있는 교차 개체 필드입니다. 예를 들어 LineItem 개체의 LineTotal 필드를 기반으로 SalesOrder 개체에 OrderTotal 요약 필드를 만들 수 있습니다.

참고: 내부적으로 플랫폼은 네이티브 데이터베이스 기능을 사용하여 수식 및 롤업 요약 필드를 구현하고 진행 중인 트랜잭션의 일부로 값을 효율적으로 동기식으로 재계산합니다.

플랫폼은 개발자가 앱을 구축하는 데 사용할 수 있는 몇 가지 개방형, 표준 기반 API를 제공합니다. RESTful 및 웹 서비스(SOAP 기반) API 모두 플랫폼의 다양한 기능에 액세스할 수 있습니다. 응용 프로그램은 다양한 API를 사용하여 다음을 수행할 수 있습니다.

• 응용 프로그램 스키마를 설명하는 메타데이터 조작
• CRUD(비즈니스 데이터 만들기, 읽기, 업데이트, 삭제)
• 대량 레코드를 대동기식으로 대량 로드 또는 쿼리
• 안전하고 확장 가능한 방식으로 거의 실시간 데이터 스트림 노출

앱은 *Salesforce Object Query Language(SOQL)*을 사용하여 간단하지만 강력한 데이터베이스 쿼리를 구성할 수 있습니다. 구조화된 쿼리 언어(SQL)의 SELECT 명령과 마찬가지로 SOQL을 사용하면 소스 개체, 검색할 필드 목록, 소스 개체에서 행을 선택하기 위한 조건을 지정할 수 있습니다. 예를 들어, 다음 SOQL 쿼리는 이름이 'Acme' 문자열과 같은 모든 계정 레코드의 ID 및 이름 필드 값을 반환합니다.

SELECT Id, Name FROM Account WHERE Name = 'Acme'

플랫폼에는 모든 텍스트 관련 필드를 자동으로 색인화하는 전체 텍스트 다국어 검색 엔진도 포함되어 있습니다. 앱은 *Salesforce 개체 검색 언어(SOSL)*를 사용하여 이 사전 통합 검색 엔진을 사용하여 텍스트 검색을 수행할 수 있습니다. 한 번에 하나의 개체만 쿼리할 수 있는 SOQL과 달리 SOSL을 사용하면 여러 개체에 대한 텍스트, 이메일, 전화 필드를 동시에 검색할 수 있습니다. 예를 들어, 다음 SOSL 문은 이름 필드에 'Joe Smith' 문자열을 포함하는 리드 및 연락처 개체의 레코드를 검색하고 검색된 각 레코드의 이름 및 전화 번호 필드를 반환합니다.

FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

여러 면에서 Java와 유사한 Apex는 개발자가 응용 프로그램 스키마에서 절차 논리를 중앙 집중화하는 데 사용할 수 있는 강력한 개발 언어입니다. Apex 코드는 프로그램 변수와 상수를 선언하고, 기존의 흐름 제어 문을 실행하고, 데이터 조작 작업을 수행합니다(삽입, 업데이트, 업서트, 삭제), 트랜잭션 제어 작업을 수행합니다(setSavepoint, 롤백).

플랫폼에 Apex 프로그램을 두 가지 다른 형태로 저장할 수 있습니다. 이름이 지정된 Apex 클래스로서 (일반적인 데이터베이스 언어에서 저장된 절차와 마찬가지로) 필요한 경우 응용 프로그램이 실행하는 방법, 또는 특정 데이터베이스 조작 이벤트가 발생하기 전에 또는 이후에 자동으로 실행되는 데이터베이스 트리거로. 두 가지 형태 모두에서 플랫폼은 Apex 코드를 컴파일하고 UDD에 메타데이터로 저장합니다. 조직이 Apex 프로그램을 처음 실행할 때 플랫폼의 런타임 해석기가 컴파일된 버전의 프로그램을 해당 조직의 MRU(최근 사용) 캐시에 로드합니다. 그런 다음, 동일한 조직의 사용자가 동일한 일정을 사용해야 하는 경우 플랫폼은 메모리를 저장하고 이미 메모리에 있는 실행 준비 프로그램을 공유하여 다시 프로그램을 재구성하는 오버헤드를 방지할 수 있습니다.

여기저기 간단한 키워드를 추가하면 개발자가 Apex 사용하여 많은 고유한 응용 프로그램 요구 사항을 지원할 수 있습니다. 예를 들어 개발자는 메서드를 사용자 정의 RESTful 또는 SOAP 기반 API 호출로 노출하거나 비동기식으로 예약 가능하게 만들거나 대규모 작업을 배치로 처리하도록 구성할 수 있습니다.

Apex "단순히 다른 절차 언어" 이상입니다. 이는 시스템에서 신뢰할 수 있는 멀티테넌스를 제공하는 데 도움이 되는 통합 플랫폼 구성 요소입니다. 예를 들어 플랫폼이 런타임 시 실패할 코드를 방지하기 위해 클래스 내의 모든 내장 SOQL 및 SOSL 문을 자동으로 확인합니다. 그러면 플랫폼에서 유효한 클래스에 대한 해당 개체 종속성 정보를 유지하고 이를 사용하여 종속 코드를 중단하는 메타데이터 변경을 방지합니다.

많은 표준 Apex 클래스 및 시스템 정적 방법은 기본 시스템 기능에 간단한 인터페이스를 제공합니다. 예를 들어, 삽입, 업데이트, 삭제와 같은 시스템 정적 DML 메서드에는 개발자가 원하는 대량 처리 옵션(모두 또는 없음 또는 부분 저장)을 나타내는 데 사용할 수 있는 간단한 부울 매개 변수가 있습니다. 이러한 메서드는 호출 정기에서 읽을 수 있는 결과 개체를 반환하여 실패한 레코드 및 이유를 판단합니다. Apex 플랫폼 기능 간의 직접적인 연결의 다른 예로는 내장된 이메일 클래스 및 XmlStream 클래스가 포함됩니다.

Salesforce는 다음 두 가지 중요한 원칙을 염두에 두고 구축했으므로 플랫폼의 성능과 확장성이 크게 향상됩니다.

• 효율적인 대규모 기본 플랫폼 기능을 제공합니다.
• 개발자가 가능한 한 효율적으로 모든 작업을 수행할 수 있도록 돕습니다.

플랫폼은 다음을 포함하여 플랫폼의 고유한 처리 아키텍처에 다음 원칙을 통합합니다.

• 쿼리
• 검색
• 대량 작업
• 스키마 수정
• 다중 테넌트 격리
• 휴지통

대부분의 최신 데이터베이스 시스템은 대상 테이블 및 색인 데이터에 대한 관련 통계를 고려하는 비용 기반 쿼리 최적화 프로그램을 사용하여 최적의 쿼리 실행 계획을 결정합니다. 그러나 일반적인 비용 기반 최적화 프로그램 통계는 단일 테넌트 응용 프로그램용으로 설계되었으며 멀티테넌트 환경에서 쿼리를 실행하는 지정된 사용자의 데이터 액세스 특성을 고려하지 못합니다. 예를 들어, 데이터 용량이 많은 개체를 대상으로 하는 지정된 쿼리는 가시성이 높은 사용자(모든 행을 볼 수 있는 관리자)와 가시성이 낮은 사용자(자신과 관련된 행만 볼 수 있는 판매 담당자)를 위해 다른 실행 계획을 사용하여 더욱 효율적으로 실행될 수 있습니다.

멀티테넌트 시스템에서 최적의 쿼리 실행 계획을 결정하기 위한 충분한 통계를 제공하기 위해 플랫폼은 모든 조직의 객체에 대해 완전한 세트의 최적화 통계(테넌트, 그룹, 사용자 수준)를 유지합니다. 통계는 특정 쿼리에서 잠재적으로 액세스할 수 있는 행 수를 반영하며, 전체 조직별 개체 통계(예: 조직 전체에서 소유한 총 행 수) 및 보다 세분화된 통계(예: 특정 권한 그룹 또는 최종 사용자가 잠재적으로 액세스할 수 있는 행 수)를 주의 깊게 고려합니다.

또한 플랫폼은 특정 쿼리에서 유용하게 입증된 다른 유형의 통계도 유지합니다. 예를 들어 플랫폼에서 모든 사용자 정의 색인에 대한 통계를 유지하여 해당 필드의 null이 아닌 고유 값의 총 수를 표시하고 각 목록 값의 카디널리티를 표시하는 선택 목록 필드의 히스토그램을 유지합니다.

기존 통계가 없거나 유용하지 않은 경우 플랫폼의 최적화 프로그램은 합리적으로 최적의 쿼리를 구축하는 데 도움이 되는 몇 가지 전략을 사용합니다. 예를 들어, 쿼리가 개체의 이름 필드를 필터링하는 경우 최적화 프로그램은 MT_Fallback_Indexes 테이블을 사용하여 요청된 행을 효율적으로 찾을 수 있습니다. 다른 시나리오에서는 최적화 프로그램이 런타임 시 누락된 통계를 동적으로 생성합니다.

최적화 프로그램 통계와 함께 사용되는 플랫폼의 최적화 프로그램은 지정된 사용자의 그룹 구성원 자격, 개체 및 행에 대한 사용자 정의 액세스 권한 등 조직 사용자의 보안 도메인에 대한 정보를 유지하는 내부 보안 관련 테이블(그룹, 구성원, GroupBlowout 및 사용자 정의 공유)에도 의존합니다. 이러한 정보는 사용자별로 쿼리 필터의 선택성을 결정하는 데 매우 중요합니다. 플랫폼의 내장형 보안 모델에 대한 자세한 내용은 Platform Developer Basics Trailhead를 참조하십시오.

다음 그림의 플로 다이어그램은 플랫폼이 MT_Data와 같은 대규모 힙 테이블 중 하나에 있는 데이터에 대한 요청을 처리할 때 발생하는 상황을 보여줍니다. 요청은 API 호출 또는 저장된 절차와 같은 여러 소스에서 시작될 수 있습니다. 먼저 플랫폼이 멀티테넌트 인식 통계를 고려하는 "사전 쿼리"를 실행합니다. 그런 다음, 서비스는 사전 쿼리에서 반환한 결과를 기반으로 특정 설정에서 실행할 수 있도록 최적의 기본 데이터베이스 쿼리를 구축합니다.

다음 표에 표시된 바와 같이 플랫폼은 쿼리를 제출하는 사용자 및 쿼리의 필터 조건 선택성에 따라 네 가지 방법으로 동일한 쿼리를 실행할 수 있습니다.

사용자는 대화형 검색 기능을 사용하여 응용 프로그램의 데이터베이스 전체 또는 선택한 범위를 스캔하고 응답 시간이 초과인 순위가 지정된 결과를 반환할 수 있습니다. 플랫폼 애플리케이션에 이 기능을 제공하기 위해 플랫폼은 트랜잭션 엔진과 별도의 검색 엔진을 사용합니다. 레코드를 업데이트하면 트랜잭션 엔진이 핵심 데이터베이스를 업데이트하고 색인화를 위해 관련 데이터를 검색 엔진으로 전달합니다. 레코드를 검색할 때 검색 엔진이 색인을 사용하여 쿼리를 빠르게 처리하고 관련 데이터베이스 레코드에 대한 링크와 함께 순위가 지정된 결과를 반환합니다.

응용 프로그램이 텍스트 필드(CLOB, 이름 등)의 데이터를 업데이트하면 색인화 서버라는 백그라운드 프로세스 풀이 검색 엔진이 핵심 트랜잭션 엔진 외부에서 유지하는 해당 색인을 비동기식으로 업데이트할 책임이 있습니다. 색인화 프로세스를 최적화하기 위해 플랫폼은 트랜잭션이 커밋될 때 내부 "인덱싱" 테이블에 수정된 텍스트 데이터 청크를 동기식으로 복사하여 색인화 서버가 디스크에서 읽어야 하는 데이터 양을 최소화하는 상대적으로 작은 데이터 소스를 제공합니다. 검색 엔진은 각 조직에 대해 별도의 색인을 자동으로 유지합니다.

현재 색인화 서버의 부하 및 사용량에 따라 텍스트 색인 업데이트가 실제 트랜잭션보다 느려질 수 있습니다. 오래된 색인에서 발생하는 예기치 않은 검색 결과를 방지하기 위해 플랫폼은 전체 텍스트 검색 결과를 구체화할 때 시스템에서 고려하는 최근 업데이트된 행의 MRU 캐시도 유지합니다. 플랫폼은 잠재적인 검색 범위를 효율적으로 지원하기 위해 사용자별 및 조직별로 MRU 캐시를 유지합니다.

플랫폼의 검색 엔진은 여러 방법을 사용하여 검색 결과 내에서 레코드의 순위를 최적화합니다. 예를 들어, 시스템에서 검색을 수행하는 사용자의 보안 도메인을 고려하고 현재 사용자가 액세스할 수 있는 행에 더 많은 가중치를 부여합니다. 또한 특정 행의 수정 내역을 고려하고 상대적으로 정적인 행보다 더 적극적으로 업데이트된 행의 순위를 지정할 수 있습니다. 사용자는 원하는 대로 검색 결과에 가중치를 부여하도록 선택할 수 있습니다(예: 최근에 수정된 행에 더 강조 표시).

트랜잭션이 많은 응용 프로그램은 반복 작업을 대량으로 결합하고 실행할 때 오버헤드를 줄이고 성능이 훨씬 향상됩니다. 예를 들어, 응용 프로그램이 많은 새 행을 로드할 수 있는 두 가지 방법을 비교합니다. 비효율적인 접근 방식은 개별 행을 삽입하는 루프와 함께 일상을 사용하여 각 행 삽입에 대해 API 호출을 한 번씩 수행하는 것입니다. 훨씬 효율적인 접근 방식은 행의 배열을 만들고 단일 API 호출로 일상적으로 모든 행을 삽입하는 것입니다.

API 호출에 구축되므로 플랫폼을 사용하는 효율적인 대량 처리는 개발자에게 간단합니다. 내부적으로 플랫폼은 명시적 대량 작업과 관련된 모든 내부 단계도 대량 처리합니다.

플랫폼의 대량 처리 엔진은 해당 단계에서 발생한 분리된 오류를 자동으로 고려합니다. 대량 작업이 부분 저장 모드에서 시작되면 엔진이 알려진 시작 상태를 식별한 다음, 프로세스의 각 단계(대량 필드 데이터 확인, 대량 사전 트리거 실행, 대량 레코드 저장 등)를 실행하려고 시도합니다. 엔진이 단계 중에 오류를 감지하는 경우 엔진이 위반 작업 및 모든 부작용을 롤백하고 오류를 유발하는 행을 제거한 다음, 계속해서 나머지 행 하위 집합을 대량으로 처리합니다. 이 프로세스는 엔진이 오류 없이 행 하위 집합을 커밋할 수 있을 때까지 각 연속 단계를 반복합니다. 응용 프로그램이 반환 개체를 검사하여 실패한 행 및 발생한 예외를 식별할 수 있습니다.

참고: 자유 재량에 따라 일체 또는 없음 모드를 대량 작업에 사용할 수 있습니다. 또한 대량 작업 동안 트리거 실행에는 작업량을 제한하는 내부 총괄자가 적용됩니다.

특정 유형의 개체 정의를 수정하려면 간단한 UDD 메타데이터 업데이트 이상이 필요합니다. 이러한 경우 플랫폼은 클라우드 데이터베이스 서비스 전체에 대한 전반적인 성능 영향을 줄이는 데 도움이 되는 효율적인 메커니즘을 사용합니다.

예를 들어 열의 데이터 유형을 선택 목록에서 텍스트로 수정할 때 백그라운드에서 발생하는 상황을 고려합니다. 플랫폼은 먼저 열의 데이터에 대한 새 슬롯을 할당하고 현재 값과 연결된 선택 목록 레이블을 대량으로 복사한 다음, 새 슬롯을 가리키도록 열의 메타데이터를 업데이트합니다. 모든 작업이 진행되지만 데이터에 대한 액세스는 정상적이며 응용 프로그램이 눈에 띄는 영향 없이 계속 작동합니다.

다른 예로 개체에 롤업 요약 필드를 추가할 때 발생하는 상황을 고려하십시오. 이 경우 플랫폼은 효율적인 대량 작업을 사용하여 백그라운드에서 초기 요약을 비동기식으로 계산합니다. 백그라운드 계산이 진행되는 동안 새 필드를 보는 사용자는 플랫폼에서 현재 필드 값을 계산하고 있음을 나타냅니다.

플랫폼에 플랫폼 코드 실행과 관련된 광범위한 총괄자 및 자원 제한 집합이 있는 플랫폼은 공유 멀티테넌트 시스템 자원의 악의적 또는 의도하지 않은 독점 방지를 위해 있습니다. 예를 들어, 플랫폼은 코드 스크립트 실행을 면밀하게 모니터링하고 사용 가능한 CPU 시간, 사용 가능한 메모리 수, 실행할 수 있는 쿼리 및 DML 문 수, 수학 계산 수, 실행할 수 있는 아웃바운드 웹 서비스 호출 수 등을 제한합니다. 플랫폼의 최적화 프로그램에서 실행하기에 너무 비싼 것으로 간주되는 개별 쿼리는 발신자에게 런타임 예외를 적용합니다. 이러한 제한은 다소 제한적인 것처럼 들리지만 모든 관련 응용 프로그램에 대한 공유 데이터베이스 시스템의 전체적인 확장성 및 성능을 보호하기 위해 필요합니다. 장기적으로 이러한 조치는 개발자들 사이에서 더 나은 코딩 기법을 홍보하고 플랫폼을 사용하는 모든 사람에게 더 나은 환경을 조성하는 데 도움이 됩니다. 예를 들어 처음에 한 번에 한 행에 천 개의 행을 비효율적으로 업데이트하는 루프를 코딩하려고 시도하는 개발자는 리소스 제한으로 인해 런타임 예외를 수신한 다음, 플랫폼의 효율적인 대량 처리 API 호출을 사용합니다.

잘못 작성된 응용 프로그램으로 인해 발생하는 잠재적인 시스템 문제를 방지하기 위해 새 프로덕션 응용 프로그램 배포는 엄격하게 관리되는 프로세스입니다. 조직이 새 응용 프로그램을 개발에서 프로덕션 상태로 전환하려면 먼저 Salesforce에서 응용 프로그램의 플랫폼 코드 순서의 기능을 확인하는 단위 테스트를 수행해야 합니다. 제출된 단위 테스트는 응용 프로그램의 소스 코드의 75%를 포함하지 않아야 합니다.

Salesforce는 플랫폼의 Sandbox 개발 환경에서 제출된 단위 테스트를 실행하여 응용 프로그램 코드가 전체 멀티테넌트 모집단의 성능 및 확장성에 부정적인 영향을 미칠지 여부를 판단합니다. 개별 단위 테스트 결과는 실행된 총 줄 수와 테스트에서 실행되지 않은 코드에 대한 특정 정보와 같은 기본 정보를 나타냅니다.

응용 프로그램의 코드가 Salesforce에서 프로덕션에 대해 인증되면 응용 프로그램의 배포 프로세스는 응용 프로그램의 모든 메타데이터를 프로덕션 플랫폼 인스턴스에 복사하고 해당 단위 테스트를 다시 실행하는 단일 트랜잭션으로 구성됩니다. 프로세스의 일부가 실패할 경우 플랫폼에서 트랜잭션을 롤백하고 문제 해결에 도움이 되는 예외를 반환합니다.

참고: Salesforce는 플랫폼의 개발 릴리스마다 모든 응용 프로그램에 대한 단위 테스트를 다시 실행하여 새 시스템 기능 및 개선 사항이 기존 응용 프로그램을 중단하는지 사전에 파악합니다.

프로덕션 응용 프로그램이 활성화되면 플랫폼의 내장 성능 프로파일러가 자동으로 분석하고 관리자에게 관련 피드백을 제공합니다. 성능 분석 보고서에는 응용 프로그램 기능을 조정하는 데 검토하고 사용할 수 있는 느린 쿼리, 데이터 조작, 하위 루틴에 대한 정보가 포함됩니다. 또한 관리자가 응용 프로그램을 디버그할 수 있도록 런타임 예외에 대한 정보를 기록하고 반환합니다.

앱이 개체에서 레코드를 삭제하면 플랫폼이 MTData에서 행의 IsDeleted 필드를 수정하여 삭제할 행을 표시합니다. 이 작업을 수행하면 행이 _휴지통으로 알려진 것으로 효과적으로 배치됩니다. 플랫폼을 사용하면 휴지통에서 최대 15일 동안 선택한 행을 복원하고 MT_Data에서 영구적으로 제거할 수 있습니다. 플랫폼은 해당 조직의 저장소 제한을 기반으로 조직에 대해 유지 관리하는 총 레코드 수를 제한합니다.

작업이 마스터-세부 사항 관계와 관련된 상위 레코드를 삭제하면 참조 무결성 규칙을 어기지 않으면 플랫폼이 모든 관련 하위 레코드를 자동으로 삭제합니다. 예를 들어 SalesOrder를 삭제하면 플랫폼에서 자동으로 삭제를 종속 LineItems로 계단식으로 만듭니다. 이후에 휴지통에서 상위 레코드를 복원할 경우 모든 하위 레코드도 자동으로 복원됩니다.

반대로 조회 관계와 관련된 참조된 상위 레코드를 삭제하면 플랫폼에서 모든 종속 키를 null로 자동으로 설정합니다. 이후에 상위 레코드를 복원하는 경우 삭제 및 복원 작업 간에 재할당된 관계를 제외하고 플랫폼에서 이전에 null된 조회 관계를 자동으로 복원합니다.

휴지통은 삭제된 필드와 해당 데이터도 조직에서 영구적으로 삭제하거나 설정된 일 수가 경과될 때까지 저장합니다. 이 기간까지 전체 필드와 모든 데이터를 복원할 수 있습니다.

진동성은 기업이 현대 세계에서 성공하기 위한 핵심입니다. Salesforce Platform의 기본 계층을 통해 비즈니스 응용 프로그램이 신속하게 새로운 문제에 적응하므로 인프라가 아닌 비즈니스에 집중할 수 있습니다.

인프라스트럭처(예: 기본 서비스 및 컴퓨팅 자원)는 Salesforce Platform의 상위 계층을 지원하는 기본 기술입니다. Hyperforce는 재생에너지의 100%를 기반으로 하는 Salesforce Platform 인프라스트럭처로 규정 준수, Trust 및 확장성 등 주요 고객 과제를 해결합니다.

여러 지리적 위치에서 운영되는 엔터프라이즈는 데이터 관리에 대한 새로운, 진화하는, 변화하는 규정을 준수해야 합니다. Salesforce는 AWS 지역 가용성을 기반으로 점점 더 많은 국가에서 Hyperforce 배포하므로 현재 플랫폼 응용 프로그램 및 사용자는 엄격한 데이터 저장소 또는 데이터 보호 표준을 충족하는 방식으로 민감한 워크로드를 실행할 수 있습니다. 예를 들어, Hyperforce에서 제공하는 Salesforce의 유럽 연합(EU) 운영 구역을 통해 EU 기업은 쉽게 데이터를 EU에 보관할 수 있습니다.

보안, 신뢰성, 가용성은 최종 사용자에게 Trust 수 있는 약속을 전달하기 위해 모든 비즈니스 응용 프로그램이 고려해야 하는 비기능 요구 사항입니다. Hyperforce 사용하면 Salesforce Platform을 사용하면 기업에서 신뢰할 수 있는 비즈니스 응용 프로그램을 쉽게 전달할 수 있습니다.

• 보안 — Hyperforce는 사용 중인 고객 데이터와 전송 중인 고객 데이터를 기본적으로 엔드 투 엔드 암호화합니다. Hyperforce 제로 Trust 아키텍처는 자원에 대한 암시적 액세스가 없도록 엄격한 ID 확인 프로세스를 적용합니다. Hyperforce는 최소 권한의 원칙을 사용하므로 작업이 적절한 시간에 적절한 액세스 권한으로 승인됩니다.
• 신뢰성 — Hyperforce의 모든 인스턴스는 여러 개의 클라우드 가용성 영역과 현대화된 접근 방식을 사용하여 발생 응답을 가속화하여 고가용성과 복원성을 갖춘 플랫폼을 제공합니다.
• 가용성 - Hyperforce의 최신 CI/CD 파이프라인과 블루/그린 애플리케이션 릴리즈를 통해 애플리케이션 유지 관리 기간을 1년간 1분으로 최소화할 수 있습니다.

Sales Cloud 및 Service Cloud와 같은 앱의 기반이 되는 Salesforce는 개별 엔터프라이즈 및 서비스 공급자가 공급 체인 관리, 청구, 회계, 상거래, 규정 준수 추적, 인사원 관리, 청구 처리를 비롯한 다양한 사용 사례를 위한 수백만 개의 비즈니스 응용 프로그램을 구축한 입증된 응용 프로그램 개발 플랫폼입니다. 플랫폼의 고유한 멀티테넌트 메타데이터 기반 아키텍처는 클라우드용으로 특별히 설계되었으며, 미션 크리티컬 인터넷 규모 애플리케이션을 신뢰할 수 있고 안전하게 지원합니다. 플랫폼 개발자는 표준 기반 API 및 네이티브 개발 도구를 사용하여 응용 프로그램의 데이터 모델(개체 및 관계 포함), 비즈니스 논리(워크플로 및 확인 포함), 다른 응용 프로그램과의 통합 등 현대 웹 또는 모바일 응용 프로그램의 모든 구성 요소를 쉽게 구축할 수 있습니다.

플랫폼이 시작된 이후 Salesforce의 엔지니어가 플랫폼 응용 프로그램을 확장하여 변화하는 비즈니스 수요를 충족할 수 있는 기능을 사용하여 멀티테넌스에 최적화했습니다. 대량 데이터 처리 API, Apex, 전체 텍스트 검색 엔진 및 고유한 쿼리 최적화 프로그램과 같은 통합 시스템 기능은 개발자가 거의 또는 전혀 노력하지 않고 종속 애플리케이션을 매우 효율적이고 확장 가능하게 만듭니다.

Salesforce의 프로덕션 응용 프로그램 배포 관리 접근 방식은 플랫폼에 의존하는 모든 응용 프로그램에 뛰어난 성능, 확장성, 신뢰성을 보장합니다. Salesforce는 플랫폼 응용 프로그램에서 운영 정보를 지속적으로 모니터링하고 수집하여 기존 및 신규 응용 프로그램에 즉시 도움이 되는 증분 개선 및 새로운 시스템 기능을 촉진합니다.

Steve Bobrowski는 성공적인 기업가이자 기술 리더로서 2008년부터 Salesforce 전체에서 다양한 역할을 비롯한 여러 주요 엔터프라이즈 소프트웨어 회사에서 근무해 왔습니다. 현재 Steve는 Salesforce의 CTO 사무실에서 회사의 기술 아키텍처 전략을 지원합니다.

Tom Leddy는 Salesforce의 설계자 복음주의자입니다. 그는 설계자가 최상의 작업을 수행할 수 있도록 지원하는 리소스, 도구 및 지침을 만들기 위해 글로벌 Salesforce 아키텍트 커뮤니티를 지원합니다. Twitter에서 톰과 연결합니다.