클레임, Azure 및 SharePoint 통합 도구 키트 5부

  • Article

클레임, Azure 및 SharePoint 통합 도구 키트 5부

이 게시물은 CASI(클레임, Azure 및 SharePoint 통합) 키트에 대한 내용을 다루는 총 5부의 시리즈 중 5부입니다. 1부에서는 전체 프레임워크와 솔루션에 대해 간략히 살펴보고 시리즈에서 다룰 내용에 대해 설명했습니다. 2부에서는 WCF 응용 프로그램을 만들고 이러한 응용 프로그램에서 클레임을 인식하도록 설정한 다음 이를 Windows Azure로 옮기기 위한 지침을 다뤘습니다. 3부에서는 새로운 사용자 지정 컨트롤을 _layouts 디렉터리의 페이지에 추가하여 SharePoint 사이트를 Azure 데이터와 연동하는 데 사용할 기본 클래스를 차례로 소개했습니다. 4부에서는 CASI 키트와 함께 제공되는 웹 파트에 대해 설명하고 이러한 웹 파트의 사용 방법과 다양한 속성 등을 다뤘습니다. 이제 마지막 게시물에서는 CASI 키트와 관련한 두 가지 주요 시나리오를 살펴볼 계획인데 하나는 3부에서 제작한 사용자 지정 컨트롤로 Azure 데이터를 가져와 ASP.NET 캐시에 저장한 다음 다른 컨트롤과 함께 사용하는 것이고 다른 하나는 이를 SharePoint 작업(이 경우 사용자 지정 SharePoint 타이머 작업)에 사용하는 것입니다.

다른 웹 파트에 컨트롤 사용

지원해야 할 주요 시나리오 중 하나는 CASI 키트 프레임워크를 사용하여 다른 SharePoint 웹 파트에 사용할 데이터를 가져오는 것이었습니다. 하지만 잠재되어 있을 수 있는 원격 WCF 끝점에 대한 일상적인 서버쪽 호출을 발생시키지 않으려 한 다른 디자인 목표도 무시할 수 없습니다. 이러한 서로 다른 두 요구 사항을 해결하기 위해 데이터를 가져와 ASP.NET 캐시에 직접 저장하는 동작을 기본 클래스 구현을 통해 지원하기로 합니다. 그러면 다른 사용자 지정 웹 파트를 개발하고 매우 단순한 패턴을 따를 수 있습니다.

1. 데이터가 ASP.NET 캐시에 있는지 확인합니다.

a. 데이터가 캐시에 있으면 캐시에서 가져옵니다.

b. 캐시에 없으면 다음과 같이 합니다.

                                                              i. 사용자 지정 컨트롤의 인스턴스를 만듭니다.

                                                            ii. OutputType을 ServerCache로 설정하고 ServerCacheName 및 ServerCacheTime에 적당한 값을 설정합니다.

                                                          iii. ExecuteRequest 메서드를 호출하고 데이터를 가져옵니다.

먼저 새 Visual Studio 프로젝트를 시작합니다. 여기서는 새 SharePoint 2010 프로젝트를 만들 수 있도록 Visual Studio 2010을 사용하기로 합니다. 새 웹 파트를 만들도록 프로젝트를 구성한 다음 두 가지 참조를 추가해야 합니다. 하나는 CASI 키트 기본 클래스에 대한 참조이고 다른 하나는 3부에서 작성한 사용자 지정 컨트롤에 대한 참조입니다. CASI 키트 기본 클래스에 참조를 추가하지 않을 경우 컨트롤의 속성을 설정하려 할 때 Visual Studio에서 속성에 구불구불한 빨간 밑줄이 그어지고 해당 속성을 찾을 수 없다는 메시지가 나타납니다. 이러한 종류의 오류 메시지가 나타나면 CASI 키트 기본 클래스에 참조를 추가하지 않았기 때문입니다.

참조를 설정하면 웹 파트에 필요한 코드는 무엇이든지 작성할 수 있습니다. Azure에서 데이터(예: 콘텐츠 또는 구성 정보 등)를 가져오는 부분에 대해서는 위에서 설명한 패턴을 구현하는 방법의 한 가지 예를 소개합니다.

string CACHE_NAME = "AzureConfigConsumerCacheSample";

int CACHE_TIME = 10;

//create a var of the type of configuration data we want to retrieve

AzureWcfPage.CustomersWCF.Customer[] Customers = null;

//look for our item in cache

if (HttpContext.Current.Cache[CACHE_NAME] != null)

{

//if we find, it cast it to our type and pull it out of cache

       Customers =

(AzureWcfPage.CustomersWCF.Customer[])

HttpContext.Current.Cache[CACHE_NAME];

}

else

{

//if it's not in cache, then retrieve it and put it into cache

       //create an instance of the control

       AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();

       //set the properties to retrieve data

       cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";

       cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.ServerCache;

       cfgCtrl.ServerCacheName = CACHE_NAME;

       cfgCtrl.ServerCacheTime = CACHE_TIME;

       cfgCtrl.MethodName = "GetAllCustomers";

       //execute the method

       bool success = cfgCtrl.ExecuteRequest();

       if (success)

       {

//get the strongly typed version of our data

//the data type needs to come from the control we are creating

Customers =

(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;

              //if you wanted the Xml representation of the object you can get

              //it from QueryResultsString

  string stringCustomers = cfgCtrl.QueryResultsString;

}

       else

       {

              //there was some problem; plug in your error handling here

       }

}

이제 코드의 일부를 좀 더 자세히 살펴보기로 하겠습니다. 먼저, 새 웹 파트에서는 WCF 끝점에 대한 서비스 참조를 추가할 필요가 없다는 점을 기억해야 합니다. 모든 것은 사용자 지정 컨트롤에 캡슐화되어 있기 때문에 사용자 지정 컨트롤을 통해 표시되는 WCF 응용 프로그램의 반환 형식을 사용하기만 하면 됩니다. 다음 코드가 이를 잘 보여 줍니다.

//create a var of the type of configuration data we want to retrieve

AzureWcfPage.CustomersWCF.Customer[] Customers = null;

이 예에서 AzureWcfPage는 제가 만든 사용자 지정 컨트롤 어셈블리입니다. CustomersWCF는 제 WCF 서비스 참조에 지정한 이름이고 Customer는 WCF 메서드에서 반환한 클래스 형식입니다. 사용자 지정 컨트롤 어셈블리에 대한 참조를 추가했기 때문에 이 모든 것이 새 웹 파트로 흘러들어갑니다.

먼저 데이터가 캐시에 있는지 확인해야 합니다. 캐시에 있으면 앞에서 저장한 Customer 인스턴스의 배열에 데이터를 캐스팅하기만 하면 됩니다. 데이터가 캐시에 없으면 사용자 지정 컨트롤의 인스턴스를 만들고 데이터를 가져오는 일곱 줄의 코드를 작성합니다. 이를 위해 다음을 수행해야 합니다.

a. 컨트롤의 새 인스턴스 만들기

b. WcfUrl, MethodName, OutputType, ServerCacheName 및 ServerCacheTime 속성 설정

c. ExecuteRequest 메서드 호출

이상입니다. 메서드 실행이 완료되면 WCF 응용 프로그램의 반환 값이 ASP.NET 캐시에 저장되므로 다음 번에 이 코드가 실행될 때는 캐시에서 값을 얻을 수 있습니다. 한편, 사용자 지정 컨트롤의 QueryResultsObject 속성에 로컬 변수 Customers를 캐스팅할 수 있으므로 제 웹 파트에서 데이터에 대해 필요한 작업은 모두 할 수 있습니다. 전반적으로 대부분의 웹 파트 개발자에게는 비교적 쉽고 간단한 작업입니다.

작업에 컨트롤 사용

이번에는 3부에서 개발한 사용자 지정 컨트롤을 사용하여 작업에 사용할 콘텐츠 및/또는 구성 데이터를 Azure에서 가져오는 방법을 살펴보겠습니다. 이 예에서는 이미 작성한 사용자 지정 SharePoint 타이머 작업 내에서 Azure의 일부 데이터를 가져오겠습니다. 패턴은 위에서 설명한 웹 파트와 매우 비슷하지만 이 경우에는 대부분의 작업에서와 마찬가지로 HttpContext가 없으므로 ASP.NET 캐시를 사용할 수 없습니다. 이때 OutputType은 페이지에서 렌더링할 필요가 없고 캐시에 저장할 필요도 없기 때문에 None이 됩니다. 대신 QueryResultsObject 및/또는 QueryResultsString에서 값 디렉터리를 가져옵니다. 다음은 이 내용을 코드로 구현한 예입니다. 이 코드는 제가 만든 사용자 지정 타이머 작업 클래스에 있는 Execute 메서드를 재정의한 것입니다.

SPWebApplication wa = (SPWebApplication)this.Parent;

//create an instance of the control

AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();

//set the properties to retrieve data

cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";

cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;

cfgCtrl.MethodName = "GetAllCustomers";

//since there's no Http context in a task like a timer job, you also need to

//provide the Url to a claims-enabled SharePoint site. That address will be used

//to connect to the STS endpoint for the SharePoint farm

cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;

//execute the method

bool success = cfgCtrl.ExecuteRequest();

//check for success

if (success)

{

//now retrieve the data and do whatever with it

       AzureWcfPage.CustomersWCF.Customer[] Customers =

(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;

       string AzureResults = cfgCtrl.QueryResultsString;

//this is where you would then do your tasks based on the data you got from Azure

foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)

       {

Debug.WriteLine(c.Email);

       }

       Debug.WriteLine(AzureResults);

}

else

{

//do something to log the fact that data wasn't retrieved

}

코드를 잠깐 살펴보기로 하겠습니다. 타이머 작업은 웹 응용 프로그램 범주의 작업이기 때문에 제일 먼저 Parent 속성을 참조하여 이 작업이 실행되는 SPWebApplication에 대한 참조를 가져옵니다. 그런 다음 3부에서 만든 사용자 지정 컨트롤을 생성하고 Azure에서 데이터를 가져오는 데 필요한 최소한의 속성을 설정합니다. 다음 코드 줄에서 SharePointClaimsSiteUrl 속성을 설정해야 합니다. 3부에서 설명한 대로 CASI 키트 기본 클래스가 ExecuteRequest 메서드를 실행할 때 HttpContext의 사용 가능 여부를 확인합니다. 사용 가능한 경우 HttpContext를 사용하여 현재 SharePoint 사이트 URL을 확인하고 해당 사이트를 통해 SharePoint STS와 연결합니다. 하지만 위에서 설명한 것처럼 작업의 코드를 실행하면 대개 HttpContext를 사용할 수 없습니다. 이 경우 기본 클래스가 SharePoint STS 연결에 사용할 URL이 무엇인지 알 수 없기 때문에 클레임 사용 웹 응용 프로그램에 사이트 URL을 명시해야 합니다. 이 구현에서 타이머 작업 코드는 클레임 사용 웹 응용 프로그램에서만 실행되는 것으로 가정하고 있으므로 현재 웹 응용 프로그램에 대한 참조를 가져온 다음 첫 번째 사이트 모음의 URL을 전달해야 합니다. 클레임 사용 응용 프로그램에 있기만 하면 어떤 사이트 모음을 사용하는지는 크게 중요하지 않습니다.

앞에서 보여 준 것처럼 SharePointClaimsSiteUrl 속성을 설정하면 ExecuteRequest 메서드를 호출할 수 있습니다. 메서드가 문제없이 실행되면 QueryResultsObject 및/또는 QueryResultsString 속성을 통해 컨트롤에서 직접 데이터를 가져올 수 있습니다.

웹 파트 및 타이머 작업 프로젝트는 모두 이 게시물에 첨부된 zip 파일에 포함되어 있습니다.

정리

이 게시물은 시리즈의 마지막 게시물입니다. 이제 CASI 키트에 대해서는 물론 키트를 사용하여 사용자의 ID 토큰이 응용 프로그램 간에는 물론 데이터 센터 경계 사이를 이동할 수 있도록 하면서 사이트 또는 클라우드의 WCF 응용 프로그램에서 호스팅되는 데이터에 쉽게 연결하는 방법을 충분히 이해했기를 바랍니다. 한마디로 패턴은 비교적 구현하기 쉽습니다.

1. 콘텐츠 및/또는 구성 데이터에 대한 WCF 프런트 엔드를 만듭니다. 클레임을 사용하도록 설정하고 클라우드로 옮깁니다(선택 사항). 사용자의 ID 및 클레임 호출을 기반으로 세분화된 사용 권한 결정 기능을 구현합니다(선택 사항).

2. CASI 키트 기본 클래스에서 상속되는 사용자 지정 컨트롤을 작성합니다. 한 메서드를 재정의하고 모두 다섯 줄의 코드를 작성한 다음 컨트롤을 단순한 레이아웃 페이지에 추가하고 배포합니다.

3. 웹 파트를 페이지에 추가하고 속성을 하나 이상 설정한 다음 WCF 데이터 렌더링을 시작합니다. 사용자 지정 웹 파트 또는 사용자 지정 타이머 작업 등의 작업에서 컨트롤을 사용하여 콘텐츠 또는 구성 데이터를 가져옵니다(선택 사항).

이제 다 끝났습니다. CASI 키트를 통해 전 세계 곳곳에 저장된 데이터에 SharePoint 팜을 연결하는 어려운 작업의 부담에서 벗어날 수 있기를 바랍니다. CASI 키트는 구성 또는 개인 설정 데이터를 가져오는 기능도 뛰어날 뿐 아니라 SharePoint 사이트에 표시할 콘텐츠 자체를 가져오기도 쉽습니다. 또한 이제 조직에서 응용 프로그램 및 데이터 센터 경계에 구현한 보안 기능을 사용할 수 있는 유연성도 얻게 되었습니다. 이를 기획하고, 디자인하고, 개발하면서 많은 즐거움을 느꼈으며 여러분도 유용하게 사용할 수 있기를 바랍니다. 늘 얘기했듯이 이 키트는 현재 v1 릴리스이며 작업 효율을 개선할 수 있는 부분이 아직 많을 것이므로 언제든지 시리즈 게시물에 의견을 주시길 바랍니다. 주기적으로 여러분의 의견을 확인하여 다음 릴리스 구상에 참조하겠습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 The Claims, Azure and SharePoint Integration Toolkit Part 5를 참조하시기 바랍니다.