• 아티클

Sharepoint

사용자 지정 콘텐츠 형식을 이용한 데이터 관리의 표준화

Pav Cherny

 

한 눈에 보기:

  • SharePoint를 이용한 콘텐츠 수명 주기 관리
  • 문서 정보 창 만들기
  • InfoPath를 통한 Office 및 SharePoint 문서 편집

이 기사의 코드 다운로드: ContentTypes2008_02.exe (779KB)

엔터프라이즈 환경에는 대개 문서와 다른 콘텐츠 항목이 엄청나게 많기 때문에 문서와 그 메타데이터 그리고 그 동작을 중앙 집중적이고 재활용 가능한 방식으로 관리하는 데 많은 기술적, 업무적 어려움이 따릅니다.

Microsoft® Office SharePoint® Server 2007은 한 조직 내의 다양한 팀이 웹 사이트와 문서 라이브러리, 목록 등에서 작업 영역을 공유할 수 있게 함으로써 전사적 공동 작업을 촉진합니다.

SharePoint 2007에서는 콘텐츠 형식을 통해 콘텐츠 및 수명 주기 특징의 여러 측면을 표준화할 수 있습니다. 사이트 콘텐츠 형식이란 특정 사이트 모음, 사이트, 목록 또는 문서 라이브러리에 독립적으로 설정할 수 있는 메타데이터 정의를 말합니다. 이를 통해 전사적인 속성, 워크플로, 정보 관리 정책 및 기타 요소를 일관되게 설정할 수 있으며, 개별 부서나 사이트 담당자는 특정 목적에 맞게 콘텐츠 형식을 사용자 지정할 수 있습니다.

이 문서에서는 Windows® SharePoint Services(WSS) 3.0과 Microsoft Office SharePoint Server(MOSS) 2007에서 도입된 새로운 SharePoint 콘텐츠 모델을 활용하여 일반적인 특성을 기반으로 엔터프라이즈 콘텐츠를 위한 계층 구조를 만드는 방법을 설명하겠습니다. 이러한 콘텐츠 계층 구조를 활용하면 메타데이터와 워크플로, 정보 관리 정책 등을 전역적 수준에서 일관되게 적용하면서, 그와 동시에 사이트 모음과 사이트, 문서 라이브러리, 목록 등의 수준에서 고유한 콘텐츠 관리 요구 사항을 수용할 수 있는 융통성을 확보할 수 있습니다.

SharePoint 콘텐츠 형식의 심층 구조를 일부 살펴볼 수 있도록, 필자는 첨부 자료에 몇 가지 사용자 지정 도구를 포함했으며 구체적인 요구 사항에 맞게 이 도구를 확장할 수 있도록 소스 코드도 포함했습니다. 다만, 이 도구는 철저히 테스트되지 않았으므로 프로덕션 시스템에 사용해서는 안 된다는 점을 기억하시기 바랍니다. 이 코드는 TechNet Magazine 웹 사이트(technetmagazine.com/code08.aspx)에서 다운로드할 수 있습니다.

콘텐츠 수명 주기와 콘텐츠 형식 정의

SharePoint 리소스

조직 내에서 문서 및 기타 콘텐츠를 관리할 때는 여러 가지 세부적인 사항을 고려해야 합니다. 무엇보다도 콘텐츠가 생성되어 게시되고 보관 및 폐기되는 과정에서 어떤 사람이 또는 어느 프로세스에서 무슨 작업을 수행해야 하는가를 정의해야 합니다. 또한 콘텐츠 생성을 위한 구체적 서식 파일을 개발하고 역할을 정의하여 사용자에게 책임과 액세스 권한을 할당하고, 버전 제어 기능을 제공하고 규정 준수 상태를 모니터링하고 콘텐츠를 저장 및 보관하고 메타데이터를 정의하는 등의 작업도 필요합니다.

수명 주기가 매우 복잡한 콘텐츠도 있지만, SharePoint 콘텐츠 모델은 개별 콘텐츠 항목의 처리 방법을 결정하는 일반적인 특성과 전형적인 단계가 있음을 인지합니다. 예를 들어 서식 파일과 입력 양식을 통해서는 콘텐츠 생성을 구조화하고 메타데이터를 통해서는 콘텐츠 표시와 검색 기능을 구조화할 수 있습니다. 또한 편집, 승인 또는 기타 워크플로 요구 사항, 보관 요구 사항, 만료 기간, 적용 가능한 정보 관리 정책 등을 이용하여 개별 콘텐츠를 구분할 수 있습니다. 일부 콘텐츠는 특별한 서식 파일이 필요 없거나 보관되지 않을 수도 있지만 그러한 특징조차 수명 주기 차원의 특성으로 다른 항목과 구분하는 데 사용됩니다.

SharePoint 콘텐츠 모델을 이용하면 개별 콘텐츠 형식을 정의하고 계층적 관계를 설정할 수 있습니다. 계층적 관계에서는 자식이 부모 콘텐츠 형식으로부터 일반적 특성을 상속받으며, 필요에 따라 특정한 특성이 추가됩니다.

이 점을 살펴보는 가장 좋은 방법은 SharePoint의 기본 제공 콘텐츠 형식을 검토하는 것입니다. WSS 3.0과 MOSS 2007에는 문서, 작업 등 문서 라이브러리 또는 목록에 저장할 수 있는 전형적인 항목을 위해 미리 정의된 콘텐츠 형식이 다수 포함되어 있습니다. SharePoint 서버의 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 폴더에는 이러한 표준 콘텐츠 형식에 대한 정의가 들어 있습니다. 여기에는 feature.xml이라는 매니페스트 파일이 있습니다. 이 파일을 보면 SharePoint는 표준 콘텐츠 형식 정의를 숨겨진 기능(Hidden="TRUE")으로 사이트 모음 범위(Scope="Site")와 함께 구현하고 있으며 실제 콘텐츠 형식 요소가 들어 있는 Element 매니페스트 파일은 ctypeswss.xml(<ElementManifest Location="ctypeswss.xml" />)임을 알 수 있습니다.

SharePoint 기능에 관심이 있다면 MSDN® Magazine에 실린 Ted Pattison의 Office Space 칼럼 "SharePoint용 기능"(msdnmagazine.com/issues/07/05/OfficeSpace)을 추천합니다.

그러면 메모장에서 ctypeswss.xml 파일을 열고 SharePoint 사용자 인터페이스에서의 가시성에 관계 없이 표준 콘텐츠 형식을 검토해 보겠습니다. ctypeswss.xml을 수정해서는 안 됩니다. SharePoint 사용자가 새로운 콘텐츠 형식을 파생할 때 활용할 수 있도록 ctypeswss.xml 파일을 편집하여 표준 콘텐츠 형식에 새로운 필드를 추가하거나 숨겨진 콘텐츠 형식을 볼 수 있게 하려는 생각을 갖고 있다면, 그것이 불필요한 작업임을 기억하시기 바랍니다. 또한 이렇게 수정한 경우 해당 구성은 지원되지 않으므로 나중에 서비스 팩을 설치하면 사용자 지정 내용을 덮어써서 콘텐츠 관리 솔루션에 문제가 생길 수 있습니다.

그보다는 필요한 내용을 새로운 요소 매니페스트 파일에 복사해서 필요한 사용자 지정 설정을 추가한 다음 사이트 모음 내부의 모든 사이트에서 이용할 수 있도록 사이트 모음 범위와 함께 새로운 기능으로 사용자 지정 콘텐츠 형식을 배포하는 것이 훨씬 좋은 방법입니다.

ctypeswss.xml에 명시된 System 콘텐츠 형식의 CAML(Collaborative Application Markup Language) 기반 정의는 다음과 같습니다.

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Group 및 Sealed 특성은 System 콘텐츠 형식이 숨겨지고 봉인되어 있으므로 SharePoint 사용자 인터페이스에서는 변경할 수 없다는 것을 보여 줍니다. System 콘텐츠 형식은 ContentType이라는 기본 제공 사이트 열을 참조하는 단 하나의 FieldRef 요소만 갖고 있습니다. 이것은 가장 높은 수준의 추상화입니다. 다른 모든 SharePoint 콘텐츠 형식은 System 콘텐츠 형식으로부터 이 속성을 상속 받습니다. 이러한 방식으로 SharePoint는 모든 문서 라이브러리 또는 목록에 저장된 모든 콘텐츠 항목이 공통적으로 이 속성을 갖도록 합니다.

그림 1에서는 이 문서의 첨부 자료에 포함되어 있으며 계층 구조를 더 직관적으로 보여 주는 ContentTypeHierarchy 웹 파트를 볼 수 있습니다. System 콘텐츠 형식은 다른 모든 콘텐츠 형식의 루트에 있으며 그 아래 Item이 있고, 그 아래 다른 형식이 계속 이어집니다. 예를 들어 Item 콘텐츠 형식은 다음 수준의 세부 사항을 규정합니다. ctypeswss.xml을 살펴보면 Item 형식은 Title이라는 사이트 열을 참조하는 단 하나의 메타데이터 필드를 정의하고 있음을 알 수 있습니다. 이러한 방식으로 그 아래 수준의 모든 기본 제공 콘텐츠 형식은 Title 속성을 갖게 되는 것입니다.

그림 1 WSS 3.0 기본 제공 콘텐츠 형식 계층 구조

그림 1** WSS 3.0 기본 제공 콘텐츠 형식 계층 구조 **(더 크게 보려면 이미지를 클릭하십시오.)

ctypeswss.xml의 Document 콘텐츠 형식 정의에서 볼 수 있듯이 상속된 필드를 제거하는 것도 가능합니다. Document 콘텐츠 형식에는 몇 가지 대응되는 RemoveFieldRef 요소가 포함되어 있지만, Title 필드는 사용자 지정 콘텐츠 형식 안에 유지하는 것이 좋을 것입니다. Title 열은 SharePoint 문서 라이브러리 및 목록 보기의 ECB(편집 컨트롤 상자) 드롭다운 메뉴에 대한 액세스를 지원하기 때문입니다.

상속된 필드의 이름을 바꾸는 방법을 잘 보여 주는 좋은 예는 ctypeswss.xml의 Far East Contact 콘텐츠 형식입니다. 대응되는 콘텐츠 형식 ID인 0x0116을 찾은 다음, Name="Title"이라는 특성을 가진 FieldRef 요소를 확인해 보면 DisplayName 특성을 이용하여 사용자 인터페이스의 필드 이름을 변경하는 방법을 알 수 있습니다. 이 예에서 DisplayName 특성은 사용자 인터페이스에 있는 Title 필드의 이름을 "$Resources:core,Last_Name;"에서 참조하는 지역화된 데이터 값으로 변경합니다.

그림 1을 자세히 살펴보면 해당 콘텐츠 형식을 고유하게 나타내는 ContentType 요소의 ID 특성을 통해 계층적 관계가 설정된다는 것을 알 수 있습니다. 부모 콘텐츠 형식의 ID로 시작하는 모든 ID에는 16진수 값이 추가됩니다. 표준 콘텐츠 형식에는 일반적으로 두 개의 16진수 값이 추가되어 자식 콘텐츠 형식의 새로운 고유 ID를 생성합니다. 또 다른 방법은 '00'과 16진수 GUID를 추가하는 것입니다. 예를 들어 Office 데이터 연결 파일 및 유니버설 데이터 연결 파일 콘텐츠 형식은 그와 같은 방법으로 Document 콘텐츠 형식으로부터 파생된 것입니다.

여기서 잊지 말아야 할 중요한 사항은 ContentType 요소의 ID 특성은 1,024자를 넘을 수 없다는 점입니다. 그런데 대규모 계층 관계에서 모든 콘텐츠 형식이 16진수 GUID 주소 지정 기법을 사용할 경우에는 문제가 발생할 수 있습니다. 그러나 처음부터 자릿수 제한이 짧은 방법을 사용하는 것은 ID의 고유성이 손상될 수 있으므로 좋은 생각이 아닙니다.

고유성을 확보하려면 GUID 기법을 이용하여 엔터프라이즈 콘텐츠 형식에 대한 전역 네임스페이스를 설정하고 그 네임스페이스 안에서 자릿수 제한이 짧은 방법으로 전환하는 것이 좋습니다. ID 특성과 콘텐츠 형식 정의의 여러 요소에 대한 자세한 정보는 WSS 3.0 SDK의 '콘텐츠 형식 정의 스키마' 항목을 참조하십시오.

콘텐츠 형식 종속성

그러면 SharePoint 콘텐츠 형식을 이용하여 콘텐츠 항목의 관리 구조를 설정하는 방법에 대해 논의해 보겠습니다. 문서 라이브러리와 목록, 콘텐츠 형식, 사이트 열, 필드 형식 간의 상호 종속성과 같은 몇 가지 종속성을 고려해야 합니다. 종속성을 자세히 살펴보면, 라이브러리와 목록은 콘텐츠 형식을 참조하고, 콘텐츠 형식은 사이트 열을 참조하고, 다시 사이트 열은 필드 형식(예: 텍스트, 메모, 선택, 숫자, 통화 등의 표준 WSS 필드 형식)을 참조하고, 필드 형식은 WSS 핵심 어셈블리인 Microsoft.SharePoint.dll과 같은 Microsoft .NET Framwork 어셈블리 안에 있습니다.

앞서 System 콘텐츠 형식 매니페스트 파일 항목의 CAML 정의에서 살펴본 System 콘텐츠 형식으로 돌아가 보겠습니다. 살펴보면 알 수 있듯이 이 콘텐츠 형식에는 ContentType이라는 사이트 열을 참조하는 FieldRef 요소가 있습니다. 이 콘텐츠 형식 정의는 실제 ContentType 사이트 열을 정의하지 않는다는 점에 유의하십시오. ContentType은 텍스트 필드로서 Elements 매니페스트 파일 fieldswss.xml(%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 폴더)에 정의되어 있습니다. 그리고 텍스트 필드 형식은 fldtypes.xml에 정의되어 있으며 이 파일은 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML 폴더에 있습니다. 이 종속성 트리에서 반드시 기억해야 할 중요한 사항은 SharePoint 서버에서 모든 리소스를 이용할 수 있도록 해야 한다는 점입니다.

사용하고자 하는 콘텐츠 형식은 문서 라이브러리 및 목록의 사이트 수준 또는 그 이상의 사이트 계층 구조에서 생성되어야 합니다. 마찬가지로, 콘텐츠 형식의 메타데이터 필드는 반드시 기존 사이트 열을 참조해야 합니다. 표준 또는 사용자 지정 필드 형식을 기반으로 표준 또는 사용자 지정 사이트 열을 콘텐츠 형식에 추가할 수 있지만, 반드시 그 사이트 열이 로컬 사이트에 있어야 합니다. 더욱이 사용자 지정 필드 형식을 사용하려면 기반 .NET 어셈블리가 SharePoint 서버에 배포되어 있어야 합니다.

문서 서식 파일, 사용자 지정 이벤트 수신기, 워크플로 및 기타 구성 요소를 참조하는 콘텐츠 형식에 이와 유사한 종속성이 존재합니다. 예를 들어 이 콘텐츠 형식 정의에는 해당 콘텐츠 형식과 연결된 문서 서식 파일을 가리키는 DocumentTemplate 요소가 포함될 수 있습니다. 또한 XmlDocuments 요소 하나와 함께, 네임스페이스 정의, 문서 정보 창 정의 또는 사용자 지정 정보 등 콘텐츠 형식의 추가적 특성을 정의하는 하나 이상의 XmlDocument 자식 요소를 포함할 수도 있습니다.

전역 콘텐츠 형식 설정

제작 권한을 가진 사용자는 SharePoint 사용자 인터페이스에서 직접 새로운 콘텐츠 형식과 사이트 열을 만들 수 있지만, 만들어진 콘텐츠 형식은 사이트 계층 구조에서 해당 로컬 사이트와 그 아래 위치에서만 이용할 수 있습니다. 사용자 지정 사이트 열은 로컬 사이트에서만 이용할 수 있습니다. 따라서 전역 콘텐츠 형식을 설정하려면 이것으로는 충분치 않습니다. 전역 콘텐츠 형식은 시스템 환경의 모든 사이트 모음에서 이용할 수 있어야 합니다. 바로 이런 경우에 SharePoint 기능을 이용하면 매우 편리합니다. 여러 사이트 모음에 SharePoint 기능을 설치하고 활성화하면 모든 위치에 일관되게 해당 사이트 열과 콘텐츠 형식 정의를 적용할 수 있으므로 매우 간단합니다.

이 문서의 첨부 자료에는 전역 콘텐츠 형식을 설정하는 방법을 보여 주는 AdventureWorks라는 샘플 기능이 들어 있습니다. 이 기능은 제안서와 판매 자료 등 모든 유형의 고객용 자료를 생성하는 데 활용할 수 있는 Customer Documentation이라는 일반적인 콘텐츠 형식을 정의합니다. 이러한 유형의 문서는 모두 회사 이름, 연락처 세부 정보, 주소 등의 고객 정보와 연결되어야 한다고 가정하는 것이 일반적입니다. 필자는 특별히 콘텐츠 형식으로 Customer Name이라는 사용자 지정 필드를 만들고 Department와 Primary Phone과 같은 기본 제공 필드를 몇 개 추가했습니다. 콘텐츠 형식과 필드를 변경하려면 ContentTypes.xml 파일을 편집하고 필드 참조를 변경하려면 첨부 샘플의 SiteColumns.xml 파일을 편집해야 합니다.

readme.htm 파일의 설명대로 이 기능을 배포하면 여러 사이트 모음에서 일관되게 활성화할 수 있습니다. 그러면 Customer Documentation 콘텐츠 형식을 전역에서 사용할 수 있습니다. 이를 이용하면 개별 부서에서는 대상으로 지정된 문서 서식 파일과 연결되어 있는 파생된 콘텐츠 형식을 통해 특정 고객 문서 자료를 생성할 수 있습니다. 첨부 자료에는 영업 및 컨설팅에 활용할 수 있는 샘플 문서 서식 파일이 들어 있습니다. 그림 2에서는 그에 따라 생성되는 콘텐츠 형식을 볼 수 있습니다.

그림 2 Customer Documentation을 위한 부모 및 자식 콘텐츠 형식

그림 2** Customer Documentation을 위한 부모 및 자식 콘텐츠 형식 **(더 크게 보려면 이미지를 클릭하십시오.)

WSS 3.0과 MOSS 2007에서는 몇 가지 옵션을 선택하여 사용자 지정 사이트 열과 콘텐츠 형식을 위한 기능을 생성할 수 있습니다. WSS 3.0 SDK를 학습하면 XML 파일을 처음부터 새로 작성할 수 있습니다. 또한 SharePoint Designer를 사용하여 개인 웹 패키지로 목록을 내보내고, 그에 따라 생성되는 .fwp 파일의 이름을 .cab 파일로 변경하고, 이 cab 파일에서 manifest.xml 파일을 추출하여 추출된 파일에서 ContentType 정의를 검색할 수도 있습니다. 그러나 유감스럽게도 두 방법 모두 불편하고 오류 발생 가능성이 높습니다.

이와 대조적으로, SharePoint 사용자 인터페이스에서는 훨씬 쉽게 사용자 지정 사이트 열과 콘텐츠 형식을 생성할 수 있습니다. 그러나 이 인터페이스에서는 기능에 대한 XML 파일을 편집할 수 있는 옵션이 제공되지 않습니다. 기능은 SharePoint 리소스를 효율적으로 프로비전할 수 있는 방법이지만 일단 프로비전된 리소스는 콘텐츠 데이터베이스 안에만 존재합니다. 향후 출시되는 WSS 버전은 웹 파트를 내보내는 기능과 유사하게, SharePoint 사용자 인터페이스를 통해 XML 파일로 사이트 열과 콘텐츠 형식을 내보낼 수 있는 기능을 포함하게 될 것입니다. 그러나 지금은 현재 가지고 있는 기능을 활용해야 합니다.

첨부 자료에 포함된 ContentTypeSchema라는 웹 파트를 출발점으로 활용할 수 있을 것입니다. 이 웹 파트는 SharePoint 개체 모델을 이용하여 선택된 콘텐츠 형식으로부터 SchemaXML 속성을 추출합니다. XSLT(eXtensible Stylesheet Language Transformation) 기반 변환을 통해 이 웹 파트는 표시 단추를 클릭하기 전에 사용자 인터페이스에서 선택한 옵션에 따라 Field 정의 또는 ContentType 정의를 파생합니다.

그림 3에서는 이 웹 파트가 실제로 적용된 모습을 보여 줍니다. 여기에는 Customer Documentation 콘텐츠 형식을 기반으로 구성된 Active Directory® Documentation 콘텐츠 형식이 표시됩니다. Active Directory Documentation 콘텐츠 형식은 사용자 지정 Microsoft Word 서식 파일(Active Directory Template.dot)과 연결됩니다. 이 콘텐츠 형식에는 추가 필드가 없다는 점에 유의하십시오. 이 형식에서는 모든 필드가 부모 콘텐츠 형식으로부터 상속됩니다.

시스템 환경에서 이 ContentTypeSchema 웹 파트를 사용할 계획이라면, 이 웹 파트가 철저히 테스트되지 않았음을 유념하시기 바랍니다. 필자의 웹 파트는 비교적 복잡한 XSL 변환을 이용하여 현재 선택된 콘텐츠 형식의 SchemaXML 속성과 그 부모 콘텐츠 형식 사이에 델타 관계를 형성하고 있습니다. 그러나 XSLT 1.0은 아직 고급 XML 문서 변환에 맞게 제대로 설계되지 않았습니다. XML 노드를 비교할 수 있는 기본 제공 기능이 없으며 또한 CDATA 섹션과 XML 네임스페이스 역시 XSLT 1.0에서 효율적으로 처리할 수 없는 어려움을 드러냅니다.

SharePoint는 SharePoint 사용자 인터페이스 또는 SharePoint 개체 모델을 사용하여 만든 사이트 열 및 사이트 콘텐츠 형식의 정의를 콘텐츠 데이터베이스의 ContentTypes라는 테이블에 저장합니다. 그림 3에서는 필자가 만든 사용자 지정 콘텐츠 형식의 ID를 볼 수 있습니다. 다음 T-SQL 문은 그에 따라 정확한 결과를 산출합니다. SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>

그림 3 ContentTypeSchema의 사용자 지정 콘텐츠 형식 정의 웹 파트

그림 3** ContentTypeSchema의 사용자 지정 콘텐츠 형식 정의 웹 파트 **(더 크게 보려면 이미지를 클릭하십시오.)

어떤 방식을 선택하든 일단 사이트 열 및 콘텐츠 형식 정의를 확보한 후에는 전사적 콘텐츠 형식을 위한 기능을 만드는 것은 매우 간단합니다. 부서 또는 회사의 모든 전역 사이트 열과 콘텐츠 형식에 한 가지 기능을 사용하는 것이 좋습니다. 그렇게 하면 어디에 새로운 사이트 열과 콘텐츠 형식 정의를 추가할 것인지 분명해집니다.

사용자 지정 메타데이터에 대한 전사적 검색

콘텐츠 형식 계층 구조가 제공하는 직접적인 이점의 하나는 모든 자식 콘텐츠 형식이 부모 콘텐츠 형식의 메타데이터 필드를 상속한다는 점입니다. 모든 콘텐츠 형식이 공통적으로 메타데이터 필드를 갖기 때문에 문서 라이브러리에서 사용자 지정 보기와 필터를 만들기가 매우 쉽습니다.

AdventureWorks 샘플 기능은 이 점을 매우 직관적으로 보여 줍니다. 컨설턴트 또는 영업 담당자가 어떤 콘텐츠를 만들든, 만들어진 Word 2007 문서를 문서 라이브러리에 저장하려면 고객 이름(Customer Name)을 반드시 지정해야 합니다. Customer Documentation 부모 콘텐츠 형식에서 이 메타데이터 필드를 필수 필드로 정의하기 때문입니다. 그림 4에서와 같이, 컨설턴트와 영업 팀 구성원은 문서 라이브러리 보기의 항목을 Customer Name에 따라 분류하거나 필터링함으로써 고객에 대한 모든 기존 문서를 신속하고 편리하게 찾을 수 있습니다.

그림 4 공통 메타데이터에 근거한 문서 라이브러리의 다양한 문서 분류

그림 4** 공통 메타데이터에 근거한 문서 라이브러리의 다양한 문서 분류 **(더 크게 보려면 이미지를 클릭하십시오.)

또한 공통 메타데이터를 이용하면 WSS 3.0 및 MOSS 2007을 사용하여 여러 문서 라이브러리와 사이트의 콘텐츠를 찾는 작업도 간편해집니다. WSS는 단일 사이트 모음 안에서 라이브러리와 목록, 사이트 전체를 검색하는 기능을 지원합니다. MOSS 2007은 이러한 기본적인 기능에 그치지 않고, 전사적 '검색 센터'를 구현하고 SharePoint 3.0 중앙 관리 사용자 인터페이스에서 사용자 지정 메타데이터를 관리할 수 있도록 하고 있습니다. 이러한 이유로 이제부터는 MOSS 2007을 집중적으로 설명하겠습니다.

MOSS 2007에서 SSP(공유 서비스 공급자)를 구성하여 SharePoint 사이트를 크롤링하면 MOSS 2007은 콘텐츠 소스에서 사용되는 사용자 지정 메타데이터 필드를 자동으로 검색할 수 있습니다. 따라서 크롤링된 속성 목록에서 사용자 지정 메타데이터 필드를 찾을 수 있습니다.

SharePoint 기능에서 정의된 메타데이터 필드는 일반적으로 SharePoint 범주로 분류됩니다. SharePoint 중앙 관리에서 그 위치를 찾으려면 공유 서비스 관리 아래의 빠른 실행 메뉴에서 SSP로 연결되는 링크를 클릭하고 검색 설정, 메타데이터 속성 매핑을 클릭한 다음, 빠른 실행 메뉴에서 크롤링된 속성을 클릭하고 계속 진행하여 SharePoint 범주를 엽니다.

이에 대한 실제 사례를 설명하도록 하겠습니다. Customer Name이라는 메타데이터 필드는 ows_Customer_x0020_Name이라는 크롤링된 속성이 됩니다. SharePoint에서는 크롤링된 속성 앞에 "ows_"라는 접두사를 붙이며, "_x0020_"은 공백 하나를 코드 형태로 나타낸 것입니다. 이 크롤링된 속성의 세부 정보를 표시하면 사용자가 콘텐츠 검색을 수행할 때 이 크롤링된 속성의 값을 채택할 수 있도록 검색 인덱스에 기본적으로 포함되어 있음을 확인할 수 있습니다. 그러나 검색 정확도를 높이기 위해, 사용자들이 명시적으로 고객 이름으로 콘텐츠를 검색할 수 있도록 크롤링된 속성을 관리 속성에 매핑하는 것은 바라지 않을 것입니다.

크롤링된 속성을 관리 속성에 매핑할 때는 두 가지 옵션을 사용할 수 있습니다. 크롤링된 각 속성에 대해 새로운 관리 속성을 자동으로 생성하거나 크롤링된 속성을 관리 속성에 수작업으로 매핑할 수 있습니다. 첫 번째 옵션은 원하는 크롤링된 속성 범주의 설정을 표시할 때 사용할 수 있습니다. SharePoint 범주과 같은 특정 범주에서 크롤링된 속성을 표시할 때, 빠른 실행 링크의 범주 편집 옵션을 클릭합니다. 대량 크롤링 속성 설정에서 "이 범주에서 검색한 각 크롤링 속성에 대해 새 관리 속성을 자동으로 생성"이라는 확인란을 선택해야 합니다. 그러나 SharePoint는 자동으로 생성된 관리 속성에 "ows"라는 접두사를 붙이고 공백은 "x0020"으로 이스케이프합니다. 크롤링된 속성 ows_Customer_x0020_Name에 대한 관리 속성은 owsCustomerx0020Name이 됩니다. 그러나 이것은 사용자에게 친숙한 속성 이름이 아닙니다.

아마도 전사적 콘텐츠 형식을 배포한 후 크롤링된 속성을 관리 속성에 수작업으로 매핑하는 것이 더 나은 방법일 것입니다. 크롤링된 속성 하나를 하나 이상의 관리 속성에 매핑할 수 있습니다. 새로운 관리 속성을 만들려면 SharePoint 중앙 관리의 공유 서비스 관리 아래 빠른 실행 메뉴에서 SSP로 연결되는 링크를 클릭하고 검색 설정을 클릭한 다음, 메타데이터 속성 매핑이 진행되면 새 관리 속성을 클릭하여 필요한 정보를 지정하고 새로운 관리 속성을 원하는 크롤링된 속성과 연결합니다.

그러면 사용자는 '속성:' 구문의 관리 속성을 이용하거나 고급 검색을 활용하여 관련 콘텐츠 항목을 찾을 수 있습니다. 예를 들어 크롤링된 속성 ows_Customer_x0020_Name을 Customer라는 이름의 관리 속성에 매핑한 경우 사용자는 Customer: Contoso와 같이 Customer: <Customer Name> 형식의 이름을 표준 검색 상자에 지정하여 고객의 모든 문서를 검색할 수 있습니다.

콘텐츠 형식의 가장 중요한 메타데이터 필드에 대한 관리 속성을 고급 검색 페이지의 속성 목록에 포함하는 것도 좋은 생각입니다. 이 작업을 수행하려면 고급 검색 페이지를 표시한 다음 온사이트 작업을 클릭하고 페이지 편집 명령을 선택합니다. 이제 고급 검색 상자에서 편집을 클릭하면 공유 웹 파트 수정 옵션을 선택할 수 있습니다. 속성 범주를 펼치고 해당되는 텍스트 필드에 커서를 올려 놓으면, 속성 XML 문서 편집 단추를 클릭할 수 있습니다. <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>과 같은 <PropertyDefs> 요소에 속성 정의를 추가해야 하며, <PropertyRef Name="Customer" />와 같은 ResultType 요소 아래에 이 속성 정의에 대한 참조도 추가해야 합니다(예: <ResultType DisplayName="All Results" Name="default"> 요소). 그림 5a는 그에 따른 고급 검색 사용자 인터페이스를 보여 줍니다. 그림 5b는 검색 결과 페이지입니다.

그림 5a 고객 이름을 사용한 IT 인프라 문서 자료 검색

그림 5a** 고객 이름을 사용한 IT 인프라 문서 자료 검색 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 5b 고객 이름 검색 결과

그림 5b** 고객 이름 검색 결과 **(더 크게 보려면 이미지를 클릭하십시오.)

정보의 일관성 보장

지금까지 MOSS 2007을 기반으로 가장 중요한 메타데이터 필드와 콘텐츠 형식을 표준화하고 검색 기능을 엔터프라이즈의 사이트 모음 전체로 확장해 보았습니다. 이제는 사용자가 메타데이터 필드에 정확한 정보를 입력하도록 하는 것이 중요합니다.

그 방법에는 두 가지가 있습니다. 첫째, 목록 상자와 같이 사용자에게 미리 정의된 입력 옵션 선택 기능을 제공하는 사용자 지정된 InfoPath® 양식으로 문서 서식 파일의 표준 문서 정보 창을 대체할 수 있습니다. 둘째, 이벤트 수신기를 콘텐츠 형식에 바인딩한 다음, 사용자가 해당 콘텐츠 항목을 생성, 수정 또는 삭제할 때마다 메타데이터 및 기타 정보의 정확성을 확인할 수 있습니다.

두 방식은 서로를 보완합니다. InfoPath 양식은 주로 SharePoint 콘텐츠 형식의 속성을 보다 쉽게 편집할 수 있도록 하며, 이벤트 수신기는 사용자가 InfoPath 양식 밖에서 콘텐츠 형식 속성을 편집하는 경우에도 메타데이터의 유효성을 확보할 수 있게 해 줍니다. 이벤트 처리기를 특정 콘텐츠 형식에 바인딩할 수 있으며, 이렇게 하면 문서 라이브러리에 관계없이 모든 사이트 모음의 개별 콘텐츠 형식에 연결된 모든 문서에 대한 이벤트와 그에 대한 응답을 지정할 수 있습니다. 이벤트 처리기의 개발 및 배포 방법에 관한 자세한 설명은 msdn2.microsoft.com/ms453149를 참조하십시오.

콘텐츠 형식을 사용자 지정 문서 정보 창에 연결하는 가장 쉬운 방법은 콘텐츠 형식의 문서 정보 창 설정을 InfoPath 2007이 설치된 컴퓨터의 SharePoint 사용자 인터페이스에 표시하는 방법일 것입니다. 그러면 문서 정보 창 서식 파일의 새 사용자 지정 서식 파일 만들기 링크를 클릭하여 InfoPath 2007을 디자인 모드에서 시작할 수 있습니다. 그러나 명시적인 SourceID 특성이 없는 사이트 열이 사이트 콘텐츠 형식에 포함되어 있다면 InfoPath에서 문서 정보 창 양식에 맞는 유효한 XSD 스키마를 만들지 못할 수 있습니다. 예를 들어 이전에 도입된 Customer Documentation 콘텐츠 형식에는 그림 6에서 볼 수 있는 것처럼 Department, Office 및 전자 메일 등 이러한 문제를 야기할 수 있는 몇 가지 연락처 열이 포함되어 있습니다.

그림 6 InfoPath 2007의 XSD 스키마 비호환성

그림 6** InfoPath 2007의 XSD 스키마 비호환성 **(더 크게 보려면 이미지를 클릭하십시오.)

이러한 문제가 발생할 경우에 사용할 수 있는 두 가지 옵션이 있습니다. 즉, 명시적인 SourceID 특성이 없는 사이트 열에 대한 참조를 콘텐츠 형식 정의에서 제거하거나, 문제를 야기하는 기본 제공 사이트 열을 InfoPath 2007과 호환되는 사용자 지정 사이트 열로 대체할 수 있습니다. 단, 콘텐츠 데이터베이스에 프로비전된 후에는, 특히 자식 콘텐츠 형식을 이미 생성한 후에는 CAML 기반 콘텐츠 형식의 필드 참조를 변경할 수 없다는 점을 기억해야 합니다. Windows SharePoint Services에서는 부모 콘텐츠 형식 정의에 대한 변경을 추적하지 않기 때문에 더 이상은 간단히 CAML 기반 콘텐츠 형식 정의를 업데이트할 수 없으며 변경 사항이 자식 콘텐츠 형식에 자동으로 상속되지도 않습니다.

변경 사항이 자동으로 적용되게 하려면 SharePoint 사용자 인터페이스 또는 개체 모델을 통해 부모 콘텐츠 형식을 변경하거나 기존 콘텐츠 형식으로부터 파생된 새로운 콘텐츠 형식을 정의해야 합니다. 새로 콘텐츠 형식을 정의하는 방법을 사용하면 중요 필드를 제거하고 새로운 열을 추가할 수 있습니다. 그러면 새로운 콘텐츠 형식에서 다른 콘텐츠 형식이 파생될 수 있습니다. 사용자가 잘못된 콘텐츠 형식을 선택하는 것을 방지하려면 기존 콘텐츠 형식을 _Hidden 콘텐츠 형식 그룹에 추가하십시오.

앞서 언급했듯이, 배포 및 활성화를 수행한 후에는 CAML 기반 콘텐츠 형식을 업데이트할 수 없습니다. 따라서 배포 전에 전역 콘텐츠 형식을 테스트하는 것이 매우 중요합니다. 자세한 내용은 MSDN 문서 "콘텐츠 형식 업데이트"(msdn2.microsoft.com/aa543504)를 참조하십시오.

적절한 필드 참조를 사용하여 콘텐츠 형식을 만들었으면 InfoPath 2007에서 사용자 지정 문서 정보 창을 만들 수 있습니다. 가장 좋은 방법은 사이트 소유자가 자신의 자식 콘텐츠 형식에 맞는 사용자 지정 문서 정보 창을 만들도록 하는 것입니다. InfoPath 2007에서 제공하는 사용자 지정 문서 정보 창을 선택된 콘텐츠 형식에 직접 게시할 수 있도록 하는 옵션을 사용하면 배포가 간편해집니다. 그러나 InfoPath 양식을 문서 라이브러리와 같은 중앙 위치에 게시하고 콘텐츠 형식에 문서 정보 창에 대한 참조를 포함하는 것도 가능합니다. CAML 콘텐츠 형식과 함께 사용자 지정 문서 정보 창을 제공할 계획이라면 이것이 가장 좋은 방법입니다. 그림 7에서는 구현 아키텍처를 보여 줍니다.

그림 7 MOSS 2007의 중앙 위치에 XSN 파일 구현

그림 7** MOSS 2007의 중앙 위치에 XSN 파일 구현 **(더 크게 보려면 이미지를 클릭하십시오.)

이 문서와 함께 제공되는 다운로드 자료에는 InfoPath 2007과 호환되는 사이트 열을 추가함으로써 기존 AdventureWorks 기능을 확장하는 AdventureWorks_Update라는 기능이 포함되어 있습니다. AdventureWorks_Update 기능은 원래의 Customer Documentation 콘텐츠 형식을 숨김으로 표시하고 Customer Docs라는 새로운 콘텐츠 형식을 파생합니다. 이 콘텐츠 형식에서는 상속된 기본 제공 필드가 새로운 사이트 열로 교체되며 새로운 콘텐츠 형식은 사용자 지정 문서 정보 창과 연결됩니다.

새로운 Customer Docs 콘텐츠 형식 정의에는 문서 정보 창에 대한 정보를 제공하는 XmlDocument 요소가 있습니다. 구체적으로, xsnLocation 요소는 문서 정보 창을 구현하는 InfoPath 양식 http://companyresources/DIPs/customerDIP.xsn을 가리킵니다. AdventureWorks_Update 기능을 적용하는 방법에 대한 자세한 설명은 AdventureWorks_Update 폴더의 readme.htm 파일을 참조하십시오.

요약

SharePoint 콘텐츠 형식을 활용하면 메타데이터 정책을 만들어 엔터프라이즈 전역에서 콘텐츠 관리에 일관되게 활용할 수 있습니다. 콘텐츠 형식의 계층 구조는 전체 엔터프라이즈 환경에 관련된 특성을 표준화하고 상속을 통해 모든 사이트에 일률적으로 적용할 수 있게 해 줍니다.

다른 무엇보다도, 사용자가 특정 콘텐츠를 신속하고 편리하게 찾을 수 있도록 MOSS 2007의 기본 제공 검색 기능을 확장하는 것이 가능합니다. 또한 메타데이터와 관련하여 정보의 일관성을 강제하고 중앙 집중적인 정보 관리 정책을 설정할 수 있습니다. 가장 좋은 방법은 향후 변경의 필요성을 최소화할 수 있도록 가장 추상적인 메타데이터 특성을 기반으로 전역 콘텐츠 형식을 표준화하는 것입니다. SharePoint 콘텐츠 형식은 면밀히 설계된 콘텐츠 모델을 기반으로, 엔터프라이즈 전체의 콘텐츠 수명 주기 관리를 표준화하는 새로운 기능을 제공할 수 있습니다.

Pav Cherny는 Biblioso Corporation의 대표로, 공동 작업 및 통합된 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다. 출간 저서의 주된 주제는 IT 운영 및 시스템 관리입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..