Microsoft Dynamics CRM 2015를 사용한 개발에 대한 유용한 정보
게시 날짜: 2016년 11월
적용 대상: Dynamics CRM 2015
이 항목에서는 Microsoft Dynamics CRM 2015 및 Microsoft Dynamics CRM Online 2015 업데이트를 사용자 지정하는 방법에 대한 유용한 정보를 설명합니다.
이 항목의 내용
성능에 유용한 정보
사용자 지정의 유용한 정보
효율적인 보안 방법
ISV 확장성의 최선의 방법
성능에 유용한 정보
다음과 같은 유용한 정보를 사용하면 보다 효율적인 코드를 작성할 수 있습니다.
다중 스레드 사용
응용 프로그램에 스레딩 지원을 추가하여 여러 CPU로 작업을 분산시킵니다. 이 권장 사항은 다중 프로세서 시스템에서 코드를 실행하는 것을 가정합니다.추가 정보:관리형 스레딩에 대한 NET Framework 고급 개발 가이드 문서입니다.
시스템에서 GUID를 만드는 것을 허용
시스템이 사용자가 수동으로 만드는 대신 GUID(ID)를 자동으로 할당할 수 있습니다. 이 제안 사항은 Microsoft Dynamics 365에서 효과적인 SQL 성능을 제공하는 순차 GUID를 이용할 수 있습니다. 다음 예제 코드는 Create 메서드를 호출하여 시스템에서 할당한 GUID를 가져오는 방법을 보여줍니다.
// Instantiate an account object.Account account = new Account { Name = "Fourth Coffee" };
// Create an account record named Fourth Coffee and retrieve the GUID.accountId = serviceProxy.Create(account);
초기 바인딩 유형 사용
코드를 작성할 시점에 알지 못했던 엔터티와 특성에서 코드를 작업해야 할 때 Entity 클래스를 사용합니다. 또한 사용자 지정 코드가 수 많은 엔터티 레코드를 사용하여 작업하는 경우 Entity 클래스를 사용하면 초기 바인딩 엔터티 유형보다 성능이 약간 향상됩니다. 그러나 컴파일 타임에 엔터티와 특성 이름을 확인할 수 없기 때문에 이 유연성에는 단점이 있습니다. 엔터티가 코딩 시간에 이미 정의되었고 약간의 성능 저하가 문제되지 않는 경우 CrmSvcUtil 도구를 사용하여 생성할 수 있는 초기 바인딩 유형을 사용해야 합니다.추가 정보:코드에 초기 바인딩 엔터티 클래스 사용
플러그 인 사용 안 함
가능하면 응용 프로그램을 실행하기 전에 등록된 플러그 인을 비활성화합니다.
더 빠르게 실행되는 플러그 인 작성
항상 원하는 작업을 수행하는 데 최소의 시간이 걸리는 플러그 인을 작성합니다. 예를 들어, Execute 메서드는 Microsoft Dynamics 365에서 주로 처리됩니다. 해당 메시지에 플러그 인을 등록하는 경우 자주 발생하는 Execute 메서드를 처리할 때마다 실행되므로 시스템에 상당한 영향을 미칠 수 있습니다.
동기 실행을 위해 플러그 인을 등록하려는 경우 작업이 10초 이내에 완료되도록 설계하는 것이 좋습니다. 플러그 인을 실행하는 동일한 조직 서비스에 연결된 클라이언트 응용 프로그램의 대화형 기능을 유지하기 위해 플러그 인의 처리 시간을 최소화하는 것이 좋습니다.
검색하는 데이터를 제한합니다.
서버에서 데이터를 검색하는 메서드를 사용할 때 응용 프로그램이 요구하는 데이터의 최소량을 검색합니다. 검색할 엔터티 특성의 집합인 열 집합을 지정하여 이렇게 할 수 있습니다. 예를 들어, EntityFilters 속성에 대한 EntityFilters.All 엔터티 필터를 지정하는 RetrieveAllEntitiesRequest 메시지를 사용하여 모든 메타데이터를 검색하는 것이 좋습니다. 대신 엔터티 필터를 제한하거나 RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest 또는 RetrieveRelationshipRequest 등의 메시지 중 하나를 사용하는 경우 더 나은 성능을 얻을 수 있습니다.
관련 엔터티 종속 작업 제한
Update 메서드 또는 UpdateRequest 메시지를 사용할 때는 담당자가 실제로 변경되지 않는 한 레코드에 OwnerId 특성을 설정하지 않습니다. 이 특성을 설정하면 변경 내용이 관련 엔터티에 연속 변경되어 업데이트 작업에 필요한 시간이 증가합니다.추가 정보:연속 변경 동작
클라이언트에서 프록시 설정 조정(온-프레미스만 해당)
프록시 서버는 웹 브라우저 같은 클라이언트 응용 프로그램과 실제 대상 서버 사이에 있습니다. 컴퓨터가 LAN에 있으면 프록시 서버를 사용하여 인터넷에 연결할 수 있습니다. 이 경우 프록시 서버는 게이트웨이 서버 및 방화벽 서버에 결합되거나, 그 중 일부입니다. 프록시는 웹 요청을 캐시하고 캐싱된 데이터를 사용하여 여러 클라이언트 요청을 처리할 수 있습니다. 요청된 데이터가 프록시 서버의 캐시에 없는 경우 전용 IP 주소를 사용하여 실제 서버로 요청을 전달합니다. 여기에서 프록시 서버는 클라이언트 컴퓨터를 대신하여 작동합니다.
프록시 서버가 캐시 서버로 작동할 수 있고 웹 페이지를 더 빠르게 로드해 줄 수 있지만 때때로 잘못 사용할 경우 성능이 저하될 수 있습니다. 종종 사람들은 수동 프록시 구성을 하지 않고 자동 프록시 구성을 사용합니다. 이 바로 가기를 사용하면 프록시 서버의 부하 분산에 도움이 되지만 구성 스크립트의 복잡성에 따라 자동 프록시 구성을 사용하면 상당한 지연이 발생할 수 있습니다.
Microsoft Dynamics 365 서버가 설치되면 프록시 서버를 우회하여 더 나은 처리 성능을 얻을 수 있습니다. 서버는 프록시에 연결할 필요가 없는 로컬 웹 주소를 제공합니다.로컬 주소에 프록시 서버 사용 안 함을 선택하고 예외 목록에 있는 Microsoft Dynamics 365 서버의 정규화된 도메인 이름을 제공합니다. 이렇게 하면 Microsoft Dynamics CRM SDK를 사용하여 레코드를 만들 때 처리 성능이 향상됩니다.
서비스 채널 할당 성능 향상
Microsoft Dynamics 365 웹 서비스에 연결을 설정하고 OrganizationServiceProxy 및 DiscoveryServiceProxy 서비스 프록시 클래스를 사용하여 사용자를 인증할 수 있습니다. 그러나 이러한 프록시 클래스를 부적절하게 사용하면 때때로 응용 프로그램 성능이 줄어들 수 있습니다. 따라서 SDK에서 제공하는 여러 클라이언트 클래스의 사용 시기와 방법을 이해하고 있으면 종종 더 나은 응용 프로그램 성능을 얻을 수 있습니다.
조직 웹 서비스를 사용하는 등 서비스 끝점을 사용하여 WCF(Windows Communication Foundation) 서비스 채널을 설정하면 응용 프로그램은 끝점에서 메타데이터 다운로드와 사용자 인증의 두 가지 시간이 소모되는 작업을 수행해야 합니다. 응용 프로그램이 각 응용 프로그램 세션에 대해 이러한 작업을 최소한 수행하는 경우 성능을 향상시킬 수 있습니다. 여기에 표시된 OrganizationServiceProxy 생성자는 서비스 프록시 개체가 만들어질 때마다 이러한 두 작업을 모두 수행합니다.
OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)
일반적으로 응용 프로그램 세션 동안 이 생성자를 한 번 사용하여 서비스 프록시의 인스턴스를 만들고 응용 프로그램 내의 다른 코드 경로에서 사용하기 위해 반환된 참조를 캐시하기 위해 이 응용 프로그램이 이 생성자를 사용는 경우 성능이 향상될 수 있습니다. 반환된 서비스 참조는 스레드로부터 안전하지 않으므로 다중 스레딩 응용 프로그램은 스레드당 한 인스턴스를 할당해야 합니다. 또한 응용 프로그램은 리소스에 할당된 서비스 채널을 해제하기 위해 종료하기 전에 서비스 프록시 개체에서 Dispose를 호출해야 합니다.
서비스 프록시 클래스는 다음 클래스 메서드를 사용하여 메타데이터 다운로드 및 사용자 인증을 수행합니다.
IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)
CreateManagement<TService> 메서드는 Authenticate 메서드가 사용자를 인증하는 동안 메터데이터 다운로드를 수행합니다. 이러한 메서드에서 반환되는 개체는 스레드로부터 안전하며 응용 프로그램에서 정적으로 캐시할 수 있습니다. 다른 사용할 수 있는 생성자 중 하나를 사용하는 서비스 프록시 개체를 생성하기 위해 이러한 개체를 사용할 수 있습니다.
OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)
서비스 관리와 인증된 자격 증명 개체를 캐시함으로써 응용 프로그램은 응용 프로그램 세션당 한 번 이상 서비스 프록시 개체를 보다 효율적으로 생성할 수 있습니다. 초기 바인딩 형식을 OrganizationServiceProxy에서 EnableProxyTypes 메서드 중 하나를 통해 활성화하는 경우 캐싱된 IServiceManagement<TService> 개체에서 만든 모든 서비스 프록시에서 같은 작업을 수행해야 합니다. 응용 프로그램이 메타데이터를 사용하는 경우 RetrieveTimestampRequest 메시지를 검색하고 정기적으로 호출하는 메타데이터를 캐시하여 캐시를 새로 고쳐야 하는지 여부를 확인하는 것이 좋습니다.
또한 WCF 보안 토큰(Token)을 모니터링하고 만료되기 전에 새로 고치면 토큰을 잃지 않고 인증을 다시 시작하지 않아도 됩니다. 토큰을 확인하려면 OrganizationServiceProxy 또는 DiscoveryServiceProxy 클래스에서 상속하고 토큰을 확인하는 비즈니스 논리를 구현하는 사용자 지정 클래스를 만듭니다. 또는 프록시 클래스를 새 클래스에 배치합니다. 또 다른 방법은 각 웹 서비스를 호출하기 전에 토큰을 명시적으로 확인하는 것입니다. 이러한 기술을 보여주는 코드 예제는 도우미 코드: ServerConnection 클래스 항목의 ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy 및 AutoRefreshSecurityToken에서 볼 수 있습니다.
사용자 지정의 유용한 정보
다음 유용한 정보는 Microsoft Dynamics 365를 사용자 지정하고 확장하는 데 도움이 될 수 있습니다.
Microsoft Dynamics CRM Online에 대한 유용한 정보
Microsoft Dynamics CRM Online 패턴 및 솔루션 빌더를 위한 원칙 백서 다운로드는 Microsoft Dynamics CRM Online을 사용한 솔루션 구착에 대해 구체적으로 가이드를 제공합니다.
사용자 지정 엔터티 및 특성 사용
이러한 기술을 사용하여 서버 공간을 절약합니다.
새 엔터티를 만드는 대신 기존 엔터티에 대한 사용자 지정 특성을 만듭니다.
기존 엔터티의 이름을 보다 의미 있는 이름으로 변경합니다.
엔터티를 사용자 지정해야 하는 시기
영업 기회 엔터티 같은 시스템 엔터티는 새로운 사용자 지정 엔터티로 대체하는 대신 사용자 지정하면 기존 엔터티에서 많은 기본 제공 기능을 사용할 수 있습니다. 예를 들어, 영업 기회 및 케이스 엔터티에는 고객을 연결하는 조회 필드가 있습니다. 고객은 거래처 또는 연락처가 될 수 있습니다. 조회의 동일한 형식을 가진 사용자 지정 엔터티는 만들 수 없습니다. 비즈니스에 더 의미가 있도록 시스템 엔터티의 표시 이름을 변경할 수 있습니다.
플러그 인 및 워크플로의 사용 시기
Microsoft Dynamics 365를 확장하거나 사용자 지정하는 데 관심이 있는 개발자는 여러 가지 메서드 중에서 선택하여 작업을 수행할 수 있습니다. 클라이언트 쪽 JavaScript 코드를 양식에 추가하거나 사용자 지정 ASP.NET 페이지를 추가하는 것 외에 플러그 인을 작성하거나 사용자 지정 워크플로 활동을 호출하는 웹 인터페이스를 사용하여 사용자 지정 워크플로를 만들 수 있습니다. 플러그 인을 사용하는 시기와 워크플로를 사용하는 시기를 결정하는 방법 사용하는 기술에 따라 수행해야 하는 작업과 사용자 지정을 누가 작성할지가 결정됩니다.
예를 들어, 핵심 플랫폼 작업을 시작하기 바로 전이나 후, 작업 결과가 플랫폼에서 반환되기 전에 사용자 지정 코드를 실행하려는 경우 플러그 인 실시간 워크플로를 동기화해야 합니다. 핵심 작업의 실행이 완료된 후 실행하도록 큐에 대기하고 있기 때문이 이 상황에서는 비동기 워크플로나 비동기 플러그 인을 사용할 수 없습니다. 따라서 언제 실행될지 예측할 수 없습니다. 사용자 지정 기능을 Microsoft Dynamics CRM Online에 추가하려는 경우 워크플로와 플러그 인은 지원되지만 사용자 지정 워크플로 활동은 지원되지 않습니다.
이러한 기술을 평가하고 플러그 인이나 워크플로 솔루션의 배포, 성능 및 유지 관리 문제를 고려한 후 비즈니스 목표에 가장 적합한 기술을 선택합니다.
다음 표에서는 플러그 인 및 워크플로의 특성을 요약합니다.
조건 |
플러그 인 |
워크플로 |
---|---|---|
핵심 플랫폼 작업(만들기, 업데이트, 삭제 등) 전과 후에 실행 |
핵심 작업 직전이나 직후에 실행(동기). 또한 핵심 작업 후에 실행하도록 큐에 대기할 수도 있습니다(비동기). |
비동기 워크플로는 핵심 작업 후에 실행하도록 큐에 대기합니다. 실시간 워크플로우는 플러그 인과 유사한 특징을 갖습니다. |
서버의 성능에 미치는 영향 |
동기적 플러그 인은 메인 플랫폼 처리의 일부인 플랫폼 응답 시간을 증가시킬 수 있습니다. 비동기 플러그 인은 코드가 다른 프로세스에서 실행되기 때문에 서버 응답 시간에 영향을 덜 미칩니다. |
비동기 워크플로는 코드가 다른 프로세스에서 실행되기 때문에 서버 응답 시간에 영향을 덜 미칩니다. 실시간 워크플로우는 샌드박스 플러그 인과 유사한 성능 특징을 갖습니다. |
보안 제한 |
플러그인을 플랫폼에 등록하려면 시스템 관리자나 시스템 사용자 지정자 보안 역할 및 배포 관리자 그룹의 구성원 자격이 필요합니다. |
사용자는 웹 응용 프로그램에서 대화형으로 워크플로 만들 수 있습니다. 그러나 사용자 지정 워크플로 활동을 등록하려면 배포 사용자에게 플러그 인 등록에 필요한 것과 동일한 보안 역할이 있어야 합니다. |
Microsoft Dynamics 365 버전(SKU) 지원 |
샌드박스에 등록할 때 Microsoft Dynamics CRM Online를 지원합니다. 파트너의 판단에 따라 파트너 호스팅 설치가 지원될 수 있습니다. |
워크플로우는 모든 Dynamics 365 배포에 지원됩니다. 사용자 지정 워크플로 활동은 Microsoft Dynamics CRM Online의 샌드박스 및 온-프레미스/IFD 배포용 샌드박스 내부나 외부에서 지원됩니다. |
처리 시간 |
동기 또는 비동기 실행을 위한 플러그 인 등록은 2분 내에 실행을 완료하도록 제한됩니다. |
짧거나 긴 프로세스에 적합합니다. 그러나 워크플로의 각 활동은 완료하는 데 2분 이상 걸릴 수 없습니다. |
Outlook용 Dynamics CRM 클라이언트가 오프라인일 때 작동합니다. |
온라인 및 오프 라인 모두 지원됩니다. |
오프라인일 때는 워크플가 실행되지 않습니다. |
프로세스 및 데이터 지속성 |
플러그 인은 완료될 때까지 실행됩니다. 플러그 인은 데이터가 메모리에 유지되지 않는 한 상태 비저장으로 작성되어야 합니다. |
비동기 워크플로는 SDK 호출을 통해 또는 웹 응용 프로그램 사용자를 통해 일시 중지, 연기, 취소 및 다시 시작할 수 있습니다. 워크플로의 상태는 일시 중지 또는 연기하기 전에 자동 저장됩니다. 실시간 워크플로우는 대기 상태가 될 수 없습니다. 플러그 인처럼 완료될 때까지 실행해야 합니다. |
가장 |
플러그 인은 다른 시스템 사용자를 대신하여 데이터 작업을 수행할 수 있습니다. |
비동기 워크플로는 가장을 사용할 수 없지만 실시간 워크플로에서는 사용할 수 있습니다. 실시간 워크플로는 워크플로 소유자 또는 호출하는 사용자로 실행할 수 있습니다. |
작성 |
소프트웨어 엔지니어 또는 프로그래머는 플러그 인을 작성할 수 있습니다. |
최종 사용자, 비즈니스 분석가, 관리자 등 누구나 적절한 권한이 있으면 워크플로를 작성할 수 있습니다. |
비동기 플러그 인 및 워크플로 간에 서버에 미치는 중요한 성능 영향은 없습니다.
더 적합한 워크플로 유형
성능의 관점에서 하나의 긴 워크플로를 만드는 것이 더 좋을까요, 여러 개의 하위 워크플로를 만들고 하나의 상위 워크플로에서 이를 호출하는 것이 더 나을까요? 하위 워크플로 방식은 처리 성능은 떨어지지만 워크플로 정의를 자주 변경하는 경우 보다 관리가 용이합니다. 컴파일 오버헤드는 게시하는 동안에 워크플로가 컴파일되므로 주요한 문제가 아닙니다. 그러나 각 워크플로 인스턴스가 시작되면 Microsoft Dynamics 365에 오버헤드가 증가합니다. 오버헤드는 워크플로에 사용되는 모든 엔터티가 검색되고 '워크플로 확장 작업' 및 실제 워크플로 인스턴스를 포함하는 2단계 프로세스에서 하위 워크플로가 시작되면 발생합니다. 따라서 최대 처리량을 위해 하나의 긴 워크플로 사용합니다.
사용자 지정 워크플로 활동을 완료로 표시하는 방법
Execute 메서드의 반환 값은 활동을 “완료됨”으로 표시하기 위해 워크플로 런타임에 사용됩니다. 활동이 기본 클래스 기능을 우회하지 않는 한 return base.Execute(executionContext)를 사용해야 합니다.ActivityExecutionStatus.Closed를 반환하지 않도록 방지합니다.추가 정보:ActivityExecutionStatus 열거형
사용자 지정 워크플로 활동에서 예외를 보고하는 방법
코드에서 InvalidPlugInExecutionException을 throw해야 합니다. 이 오류는 워크플로 인스턴스 양식으로 표시됩니다.
사업부에 관련된 사용자 지정 엔터티를 정의 가능
사용자 지정 엔터티에는 각 사업부가 아니라 각 보안 역할에 대한 권한이 있습니다. 지정된 사업부에게만 표시되는 사용자 지정 엔터티를 정의하려면 각 사업부에 다른 보안 역할을 만들고 적절한 역할의 사용자 지정 엔터티에 권한을 부여해야 합니다.
효율적인 보안 방법
다음 지침에 따라 비즈니스 데이터를 보호합니다.
일반
Microsoft Dynamics 365 구현을 보호하는 가장 좋은 방법은 다음과 같습니다.
조직의 Microsoft Dynamics 365 구현을 위한 승인된 보안 데이터 계획을 설정합니다.
응용 프로그램 풀을 설정할 때 필요한 최소 권한을 할당합니다.
모든 사용자가 계정에 대해 강력한 암호를 사용하도록 요구합니다. 자세한 내용은 Windows 도움말에서 "강력한 암호"를 검색하십시오.
추가 정보:TechNet: Microsoft Dynamics CRM 보안 고려 사항
역할, 권한 및 액세스 권한
Microsoft Dynamics 365 보안 모델을 사용하는 가장 좋은 방법은 다음과 같습니다.
시스템 관리자 역할에 할당된 사용자 수를 엄격하게 제한합니다. 이 역할은 절대 제거하지 마십시오.
작업에 필요한 비즈니스 최소량의 데이터에 액세스를 제공하면서 최소의 권한을 갖는 최선의 보안 방법에 따라 역할을 만듭니다. 사용자에게 작업에 적절한 역할을 할당합니다.
특정 권한을 가진 새로운 역할을 만들고 사용자가 추가 액세스 수준이나 권한이 필요한 경우 새로운 역할에 사용자를 추가합니다. 사용자의 권한은 자신에게 할당된 모든 역할의 합집합입니다. 하나 이상의 구성원이 필요한 원래 역할 권한을 부여하지 마십시오.
해당 유형의 모든 개체에 대한 광범위한 권한 대신 개별 개체에 대해 특성 사용자 권한을 부여하고 적절할 때 공유하여 사용합니다.
팀을 이용하여 기능간 그룹을 만들어 특정 개체를 팀과 공유할 수 있도록 합니다.
공유 액세스 권한을 가진 사용자를 교육하여 필요한 최소한의 정보를 공유합니다.
권한의 올리기를 방지합니다.
권한 올리기 공격은 사용자가 담당자 또는 관리자 같은 신뢰할 수 있는 계정의 권한을 가정할 수 있을 때 발생합니다. 항상 최소 권한의 사용자 계정에서 실행하고 필요한 권한만 할당합니다. 코드 실행에 관리자 또는 담당자 계정 사용을 방지합니다. 이는 공격이 성공하더라도 발생할 수 있는 손상이 제한됩니다. 추가 권한이 필요한 작업을 수행할 때는 작업 기간 동안에만 절차 서명 또는 가장을 사용합니다.
서버 쪽 개발
Microsoft Dynamics 365의 서버 쪽 코드 개발을 위한 최선의 방법은 다음과 같습니다.
Microsoft Dynamics 365 보안 모델을 우회할 수 있으므로 SDK 사용 이외의 방법으로 Microsoft Dynamics 365 데이터베이스를 수정하지 마십시오.
플러그 인은 관리자의 컨텍스트로 실행되며 이 코드는 로그온한 사용자가 액세스하지 못하는 정보에 액세스할 수 있음을 알아야 합니다.
워크플로 어셈블리 및 플러그 인의 경우 실행에 오랜 시간이 걸리는 코드를 작성하지 마십시오. 동기적으로 실행되도록 등록된 플러그인이 가능한 빨리 반환하도록 하는 것이 중요합니다.
자신의 데이터 저장소에서 Microsoft Dynamics 365 데이터를 복제하는 경우 데이터 보안을 직접 책임입니다. 데이터를 전송하는 데 플러그 인을 사용하는 경우 핵심 플랫폼 작업 후에 실행할 플러그 인을 등록해야 합니다. 로그온한 사용자에 대한 보안 권한 확인은 핵심 플랫폼 작업 중에 발생합니다.
Microsoft Dynamics 365에서 발생하는 데이터는 렌더링에 안전하지 않을 수 있습니다. 데이터는 안전하지 않은 HTML 태그를 사용하여 삽입되었을 수 있습니다.
SQL Server 엔터프라이즈 관리자를 통해 Microsoft Dynamics 365 데이터베이스에 직접 액세스하지 않는 요구 사항을 준수합니다. SDK를 우회하면 최대 SQL 주입 위협에 노출될 수 있습니다.
인터넷 배포의 경우 솔루션이 가장 취약한 링크만큼만 안전하다는 점을 기억하십시오. 응용 프로그램이 인터넷에 노출되면 보안 위협에 노출됩니다.
버퍼 오버런, 예외 등으로부터 최상의 보안을 유지하기 위해 관리형 코드를 생성하는 언어만 사용합니다.
보안에 대한 자세한 내용은 다음 항목을 참조하십시오.
클라이언트 쪽 개발
Dynamics 365 웹 응용 프로그램 및 Outlook용 Microsoft Dynamics CRM용 사용자 지정을 개발하는 최선의 방법은 다음과 같습니다.
가능하면 서버 쪽 처리를 요구하는 페이지 대신 웹 리소스를 사용합니다. 서버 쪽 처리를 사용하여야 요구 사항을 달성할 수 있는 경우 Microsoft Dynamics 365와 별도의 웹 사이트에 사용자 지정 웹 페이지를 설치하는 요구 사항을 준수합니다. 코드 보안에서 신뢰 수준에 따라 사이트에 대한 신뢰 수준을 적절히 설정합니다. 이렇게 하면 사이트간 스크립팅 위협 및 기타 위협이 줄어듭니다.
향상된 보안을 위해 별도의 웹 사이트는 Microsoft Dynamics 365와 다른 계정에서 실행되는지 확인합니다. 이 계정은 가능한 최소한의 액세스 권한을 가져야 하며 Microsoft 데이터베이스에 직접 액세스하지 않도록 해야 합니다. 사용자 응용 프로그램에서만 로그인하고 이 계정에 아무도 로그인하지 않으므로 만료되지 않는 복잡한 암호를 사용할 수 있습니다.
알려진 보안 문제로 인해 ActiveX 컨트롤은 사용하지 않도록 합니다.
클라이언트 스크립트의 한계를 알고 있어야 합니다.추가 정보:Microsoft Dynamics CRM 2015 양식용 코드 작성
플러그 인을 사용하여 데이터 변경 방법에 관계 없이 비즈니스 논리를 적용합니다.
항상 레코드를 삭제하거나 보안 역할에 새 사용자 추가 같은 민감한 변경을 할 때는 확인 대화 상자를 사용합니다. 이를 위해 Xrm.Utility.confirmDialog를 사용할 수 있습니다. 이렇게 하면 악의적인 개발자가 무해한 페이지처럼 보이는 페이지를 포함시켜 사용자가 보안을 손상시킬 수 있는 동작을 수행하도록 유도하거나 데이터에 대한 원하지 않는 작업을 수행하도록 할 수 있는 클릭 재킹 또는 UI click-jacking or UI 수정 같은 기술이 방지됩니다.
웹 사이트의 보안에 가장 좋은 방법은 다음과 같습니다.
익명 액세스를 사용하지 마십시오.
SSL(Secure Sockets Layer)에서 통합 Windows 인증, NTLM 또는 기본 인증을 사용합니다.
웹 사이트가 Microsoft Dynamics 365 이외의 다른 컴퓨터에 있는 경우 SSL을 사용하여 네트워크를 통해 암호화되지 않은 데이터를 보내는 것을 방지합니다.
자세한 내용은 다음을 참조하십시오.
ISV 확장성의 최선의 방법
ISV 확장성의 핵심 원리 중 하나는 ISV 솔루션이 단 하나만 설치되어 있다고 가정하지 않는 것입니다. 다음은 따라야 하는 모범 사례 목록입니다.
Microsoft Dynamics CRM 웹 서비스 사용에 대한 유용한 정보
코드가 URL과 변경으로부터 고립되므로 Microsoft Dynamics 365 웹 서비스 URL을 구성 파일, 예를 들어 app.config 파일에 저장해서는 안 됩니다. 예를 들어, 전세계 세 개의 Microsoft Dynamics CRM Online 데이터 센터에 다른 URL이 있습니다.
플러그 인과 사용자 지정 워크플로 활동을 저장하는 장소
디스크 상의 플러그 인이나 사용자 지정 워크플로 활동의 경우 <installdir>\Server\bin\assembly 폴더에 어셈블리를 배치합니다.
사용자 지정 웹 응용 프로그램 또는 웹 페이지를 저장하는 장소
ASPX 웹 페이지 또는 IFRAME에서 Single Sign-On 구현 항목을 참조하십시오.
웹 응용 프로그램의 표 보기가 업데이트될 때 플러그 인을 실행하는 방법
RetrieveMultipleRequest 메시지 요청에 플러그 인을 등록하고 등록하는 동안 엔터티 유형을 지정하지 않습니다.
새 웹 사이트를 만들어야 하는 시기
다음 중 하나를 적용할 때 코드에 대한 새 웹 사이트를 만듭니다.
응용 프로그램을 Microsoft Dynamics 365 응용 프로그램과 다른 응용 프로그램 도메인, 프로토콜 또는 포트에 바인딩하거나 다른 응용 프로그램 풀에서 실행해야 합니다.
응용 프로그램은 자체적으로 존재할 수 있으며 자체적으로 액세스할 수 있습니다. 예를 들어, Microsoft Dynamics 365와 서버로 상호 작용하는 포털은(웹 서비스를 사용하여) 새로운 웹 사이트에서 호스팅해야 합니다.
응용 프로그램은 항상 Active Directory 또는 통합 Windows 인증(IFD가 아님)을 사용하며 도메인간 스크립팅이 문제가 되지 않습니다. 예를 들어 응용 프로그램이 웹 서비스를 사용하여 백엔드와 상호 작용하고 Microsoft Dynamics 365 양식과 상호 작용합니다.Microsoft Dynamics 365 양식과 상호 작용하지 않는 Microsoft Dynamics 365 응용 프로그램에 포함된 IFRAME에서 호스팅되는 페이지가 이 범주에 속합니다.
참고 항목
응용 프로그램 및 서버 확장 작성
비트 플래그 설정
Microsoft Dynamics CRM 2015 양식용 코드 작성
플러그 인을 작성하여 비즈니스 프로세스 확장
사용자 지정 워크플로 활동(워크플로 어셈블리)
© 2017 Microsoft. All rights reserved. 저작권 정보