Microsoft Azure 솔루션에 대한 수신기 작성
게시 날짜: 2016년 11월
적용 대상: Dynamics CRM 2015
이 항목에서는 Microsoft Azure 서비스 버스에 게시되는 Microsoft Dynamics CRM 2015 메시지를 읽고 처리할 수 있는 수신기를 작성하는 방법에 대해 설명합니다. 전제 조건으로 Microsoft Dynamics 365 수신기의 세부 사항을 배우기 전에 Microsoft Azure 서비스 버스 수신기를 작성하는 방법에 익숙해 져야 합니다. 자세한 내용은 Azure 서비스 버스 설명서 및 샘플 코드를 참조하십시오.
이 항목의 내용
큐 수신기 작성
단방향, 양방향 또는 REST 수신기 작성
메시지 필터링
큐 수신기 작성
메시지 큐는 서비스 버스 끝점에서 받은 메시지의 리포지토리입니다.큐 수신기는 이러한 큐에 대기 중인 메시지를 읽고 처리하는 응용 프로그램입니다. 서비스 버스 메시지는 큐에 저장되므로 수신기는 큐에서 받는 메시지를 위해 지속적으로 수신할 필요가 없습니다. 큐 수신기는 메시지가 큐에 도착한 후에 시작할 수 있으며 해당 메시지를 여전히 처리합니다. 다음 섹션에서 설명하는 다른 유형의 수신기는 지속적으로 수신해야 합니다. 그렇지 않으면 메시지를 읽을 수 있는 기회를 놓칩니다. 이러한 메시지는 Microsoft Dynamics 365 또는 다른 원본에서 만들어질 수 있습니다. 큐 수신기를 작성할 때 각 메시지 헤더 동작을 확인하여 메시지가 Microsoft Dynamics 365에서 만들어진 것인지 결정해야 합니다.
ReceiveAndDelete 모드에서 Receive를 사용하여 소거식 메시지 읽기를 수행할 수 있습니다. 여기서 메시지를 읽고 큐에서 제거합니다. 또는 PeekLock 모드를 사용하여 비소거식 읽기를 수행하면 메시지를 읽지만 큐에서 계속 사용할 수 있습니다. 이 SDK에서 제공되는 영구 큐 수신기 샘플 코드는 소거식 읽기를 수행합니다. 큐에서 메시지 읽는 방법에 대한 자세한 내용은 큐에서 메시지를 받는 방법을 참조하십시오.
항목은 큐와 유사하지만 게시/구독 모델을 구현합니다. 하나 이상의 수신기는 항목을 구독하고 해당 큐에서 메시지를 받을 수 있습니다.추가 정보:큐, 항목 및 구독
중요
영구 큐와 항목은 지원되지만 메시지 버퍼 큐는 지원되지 않습니다. 이러한 계약을 사용하려면 Azure SDK 버전 1.7 또는 1.8을 사용하여 수신기 응용 프로그램을 작성해야 합니다.
다중 시스템 소프트웨어 디자인에서 큐 및 항목을 사용하면 시스템이 분리될 수 있습니다. 수신기 응용 프로그램을 사용할 수 없게 되면 다시 온라인 상태가 되었을 때 Microsoft Dynamics 365에서 메시지 배달은 계속 수행되고 수신기 응용 프로그램은 큐 메시지를 계속 처리할 수 있습니다.추가 정보:큐, 항목 및 구독.
메시지 버퍼 수신기를 업데이트하여 영구 큐 사용
다음 절차는 메시지 버퍼에서 영구 큐에서 메시지를 받는 수신기 응용 프로그램을 영구 큐에서 메시지를 받는 수신기 응용 프로그램으로 업데이트할 때 수행해야 하는 일반적인 단계를 나열합니다.
Microsoft Azure 포털 및 동일한 솔루션에서 메시지 버퍼에 사용된 경로와 동일한 경로에서 큐를 만듭니다.
개발 컴퓨터에 Microsoft Azure SDK 버전 1.7 또는 1.8을 설치합니다.
클래스 및 메서드 관련 메시지 버퍼를 제거하여 수신기 코드를 업데이트한 후 QueueClient 및 Receive로 바꿉니다. 필요한 읽기 모드RetrieveAndDelete 또는 PeekLock를 사용해야 합니다. 큐에서 메시지 읽는 방법에 대한 자세한 내용은 큐, 항목 및 구독을 참조하십시오.
수신기 응용 프로그램을 빌드합니다.
큐 끝점에서 메시지 버퍼에서 사용한 것과 동일한 솔루션 경로를 사용하는 한 Microsoft Dynamics 365 구성을 변경할 필요가 없습니다.
단방향, 양방향 또는 REST 수신기 작성
앞에서 설명한 큐 수신기 외에도 Microsoft Dynamics 365에서 지원되는 세 가지 다른 서비스 버스 계약인 단방향, 양방향 및 REST에 대한 수신기를 작성할 수 있습니다. 단방향 수신기는 서비스 버스에 게시된 메시지를 읽고 처리할 수 있습니다. 양방향 수신기는 동일한 작업을 수행할 수 있지만 일부 정보의 문자열이 다시Dynamics 365으로 반환될 수 있습니다.REST 수신기는 REST 끝점을 사용하는 점을 제외하면 양방향 수신기와 동일합니다. 이러한 수신기는 서비스 버스를 통해 전송된 메시지를 읽으려면 서비스 끝점에서 지속적으로 수신해야 합니다.Microsoft Dynamics 365에서 메시지를 서비스 버스에 게시하려고 할 때 수신기가 수신하지 않으면 메시지를 보내지 않습니다.
수신기 작성은 ABC(주소, 바인딩 및 계약)으 구조화되어 있습니다. 다음 정보는 단방향 수신기의 ABC를 식별합니다.
주소: 서비스 URI
수신기가 끝점으로 등록되면 Microsoft Dynamics 365에서 메시지가 서비스 버스에 게시될 때마다 수신기의 Execute 메서드가 호출됩니다.Execute 메서드는 메서드 호출에서 데이터를 반환하지 않습니다. 자세한 내용은 단방향 수신기 샘플 샘플: 단방향 수신기를 참조하십시오.
양방향 수신기는 단방향 수신기와 유사한 방식으로 코딩됩니다. 양방향 수신기의 ABC는 다음과 같습니다.
주소: 서비스 URI
이 양방향 계약의 경우, 실행 메서드는 메서드 호출에서 문자열을 반환합니다. 자세한 내용은 양방향 수신기 샘플 샘플: 양방향 수신기를 참조하십시오.
REST 수신기는 양방향 수신기와 유사한 방식으로 코딩됩니다.REST 수신기의 ABC는 다음과 같습니다.
주소: 서비스 URI
바인딩: WebHttpRelayBinding
REST 계약에서 Execute 메서드는 메서드 호출에서 문자열을 반환합니다. 자세한 내용은 REST 수신기 샘플 샘플: REST 수신기를 참조하십시오.REST 수신기 샘플에서는 양방향 샘플에서처럼 ServiceHost가 아니라 WebServiceHost가 인스턴스화됩니다.
참고
양방향 또는 REST 수신기에서 기본 제공(ServiceBusPlugin) 플러그 인을 사용할 경우 플러그 인은 수신기에서 반환된 문자열 데이터를 사용하지 않습니다. 하지만 사용자 지정 Azure 인식 플러그 인은 이 정보를 사용할 수 있습니다.
수신기 샘플을 실행할 때 사용자에게 묻는 발급자 암호는 Microsoft Azure 서비스 버스 관리 키입니다. WS2007 Federation HTTP 바인딩은 “토큰” 모드 및 WS-Trust 1.3 프로토콜을 사용합니다.
메시지 필터링
Microsoft Dynamics CRM 2015 및 CRM Online에서 보낸 각 중개 메시지 속성 속성에 추가된 추가 정보의 속성 모음이 있습니다. 영구 큐 및 항목 계약 끝점에 사용할 수 있는 속성 모음에는 다음 정보가 들어 있습니다.
조직 Url
발신자 ID
시작 사용자 ID
엔터티 논리 이름
요청 이름
서비스 버스 메시지가 게시되는 Microsoft Dynamics 365에서 처리되는 이 정보는 조직, 사용자, 엔터티 및 메시지 요청을 식별합니다. 수신기 코드는 이 정보에 따라 수신하는 메시지를 처리하도록 선택할 수 있습니다.추가 정보:샘플: 여러 요청 실행
참고 항목
Microsoft Dynamics CRM 2015에 대한 Azure 확장
사용자 지정 Azure 인식 플러그 인 작성
샘플: 영구 큐 수신기
샘플: 단방향 수신기
샘플: 양방향 수신기
샘플: REST 수신기
Azure 서비스 버스를 통해 Microsoft Dynamics CRM 2015 데이터 보내기
© 2017 Microsoft. All rights reserved. 저작권 정보