Sharepoint

엔터프라이즈 환경에서의 효과적 데이터 수집 방법

Keith Deshaies

한 눈에 보기:

• 데이터 수집 및 처리
• 정보 관리 논리와 표시 논리 분리
• Microsoft Office 2007 기술을 활용한 데이터 수집 솔루션 구축

이 기사의 코드 다운로드: DataGathering2008_02.exe (567KB)

기업에서는 다양한 방법으로 엄청난 양의 정보를 수집합니다. 데이터는 전자 메일, 설문 조사, 웹 양식 등의 데이터 수집 방법을 통해 들어옵니다. 일반적으로 데이터는 유용하다고

할 수 있습니다. 그러나 수많은 데이터 수집 도구와 각양 각색의 정보를 제대로 관리하기는 쉽지 않습니다. 데이터의 안정적인 통합과 안전한 공유는 IT 조직에게 피할 수 없는 과제가 됩니다. 관련 표준과 서비스 지향의 아키텍처가 발전을 거듭하면서 IT 전문가가 더욱 간편하고 안전하게 데이터에 액세스할 수 있게 되었지만 효율적인 엔터프라이즈 아키텍처를 구축하는 데 필요한 도구와 기술을 가지고 있더라도 각종 전용 인터페이스 때문에 어쩔 도리가 없는 경우가 너무 많습니다. 문제는 이로 인해 호환되지 않는 솔루션을 구축하게 된다는 점입니다.

Microsoft® Office system이 제공하는 기술을 예로 들어보겠습니다. Windows® SharePoint® Services 3.0을 사용하면 부서별 설문 조사를 간단히 만들 수 있지만 조직의 표준에 부합하지 않을 수 있습니다. 회사에서 웹 기반 공동 작업 및 데이터 통합을 위한 플랫폼으로 ASP.NET과 SharePoint를 사용한다면 이러한 설문 조사 방식이 표준 솔루션이 될 수 있습니다. 반면 필자의 직장과 같은 환경에서 SharePoint는 여러 가지 플랫폼 중 하나일 뿐입니다.

하지만 SharePoint가 IBM, HP, Siebel 등에서 제공하는 다양한 시스템과의 통합 옵션을 많이 제공하는 것은 사실입니다. 그리고 다양한 백 엔드 시스템으로 결과 데이터가 전달되도록 유지하면서 임시 솔루션을 만들려는 고급 사용자라면 이러한 옵션이 유용할 것입니다. 그러나 전문적인 솔루션 설계자에게는 InfoPath® 2007이 더 적합합니다.

2007 Office system에 포함된 InfoPath 2007을 사용하면 솔루션의 표시 논리를 서버에서 호스트되는 정보 관리 논리에서 분리할 수 있습니다. XML 기반 InfoPath 기술을 활용하여 기업용 데이터 수집 솔루션을 구축할 수도 있습니다. 뿐만 아니라 InfoPath 양식을 디자인할 때는 XML, 웹 서비스, 솔루션 아키텍처, ASP.NET 또는 SharePoint 개체 모델에 대한 세부 지식이 거의 필요하지 않습니다.

이 기사에서는 InfoPath 2007, Office SharePoint Server 2007 및 Forms Services로 유연한 데이터 수집 솔루션을 구축하는 방법에 대해 알아보겠습니다. 또한 XML로 다중 계층 엔터프라이즈 아키텍처에서 어떻게 표시 논리를 비즈니스 논리와 분리할 수 있는지 예를 통해 설명하겠습니다.

이 기사에서 "데이터 수집"은 사람들로부터 정보를 수집하는 프로세스를 말합니다. 물론 데이터 원본을 크롤링하는 등 데이터를 수집할 수 있는 다른 방법도 많지만, 이렇게 자동화된 방법은 이 기사에서 다루지 않습니다.

데이터 획득과 처리

데이터 획득과 관련한 요구 사항은 복잡할 수 있지만 그 프로세스에는 몇 가지 공통점이 있습니다. 이러한 공통 작업을 중앙 집중식 모듈에서 해결하고 고유한 요구 사항을 분산된 구성 요소에서 처리하면 중복 작업, 유지 관리 부담 및 총 소유 비용을 낮출 수 있습니다.

일례로, 공개 기업은 법률 규정의 제한을 받기 때문에 회사 차원의 정보 관리 정책으로 구현되는 비즈니스 요구 사항이 필요합니다. 이러한 정책은 부서 경계를 넘나드는 데이터 수집 솔루션에 영향을 미치고 개별 부서의 업무 중복을 야기하는 경우가 많습니다. 예를 들어 HR 부서(직원 정보 처리)와 고객 서비스 부서(고객 정보 처리)에서 개인 식별 정보를 수집할 때 적용되는 규칙이 있습니다. 개별 부서 간에서 서로 유사하지만 관련되어 있지는 않은 비즈니스 프로세스에도 정보 관리 솔루션을 통합할 기회는 있습니다.

그림 1에는 일반적인 비즈니스 프로세스의 예가 나와 있습니다. 자신에게 배정된 업무를 동료와 서로 바꾸려는 직원은 먼저 동료의 동의를 구하고 업무 일정을 관리하는 관리자나 조정자의 승인을 받은 후 감독자의 승인을 얻어야 합니다. 직원 간에 교대 근무 시간을 바꾸는 경우를 예로 들 수 있습니다. 이러한 업무 배정의 교환이 부서 간에 여러 가지 양식을 사용해 이루어지더라도 워크플로와 정보 관리 논리는 다양한 부서 솔루션에서 공유될 수 있습니다.

그림 1** 부서 간에 공유할 수 있는 샘플 데이터 수집 프로세스 **(더 크게 보려면 이미지를 클릭하십시오.)

물론 중복되는 구성 요소를 통합하려면 상당한 양의 작업이 필요합니다. 회사 전체에 조직 변경 사항을 적용하기는 쉽지 않지만 Office system 기술을 활용한다면 이러한 변경을 간편하게 수행할 수 있는 견고한 기반을 구축할 수 있습니다. InfoPath 2007을 사용하면 개별 부서에서 중앙의 표준화된 정보 관리 시스템과 통합되는 양식 응용 프로그램을 만들 수 있습니다. 그리고 SharePoint 2007을 사용하면 IT 부서에서 사이트 모음, 사이트 및 문서 라이브러리에 대한 관리 권한을 개별 부서와 팀에 위임할 수 있습니다. 결과적으로 팀에서는 IT 부서의 지원을 최소한으로 받으면서 직접 솔루션을 구축해 배포할 수 있으며, IT 부서에서는 워크플로, 정보 관리 정책, 백업 절차와 같은 모든 공유 서비스 및 구성 요소를 계속 제어할 수 있습니다.

데이터 수집 작업의 중앙 집중화

기업에서는 개별적인 정보 관리 요구 사항을 해결할 수 있도록 팀에 전용 응용 프로그램 서버를 제공하는 경우가 많습니다. 이 경우 IT 부서는 하드웨어와 운영 체제가 제대로 실행되도록 유지하는 역할만 하고 솔루션의 전반적인 관리는 개별 부서에서 담당합니다. 이러한 환경에서는 부서 간에 조정되는 부분이 적고 정보 공유가 어렵습니다.

데이터 수집 작업을 중앙 집중화하는 데 있어서 기술적인 문제는 주로 공유 환경에서 호스트되는 사용자 지정 구성 요소의 보안, 성능, 유지 관리 및 지원과 관련이 있습니다. 예를 들어 부서별 응용 프로그램 서버에서 개별 솔루션을 호스트하는 경우 오작동하는 구성 요소에 따른 영향이 제한적이지만 공유 환경에서는 훨씬 광범위하게 비즈니스 프로세스에 영향을 미칠 수 있습니다. 결과적으로 IT 부서에서는 중앙 집중화된 시스템에서 사용자 지정 구성 요소를 배포 및 유지 관리하는 것과 관련하여 엄격한 정책을 설정할 수밖에 없습니다.

부서별 SharePoint 솔루션을 중앙 서버 팜에서 호스트하려면 부서별 솔루션의 모든 사용자 지정 구성 요소를 중앙 응용 프로그램 서버에 배포하고 유지 관리해야 합니다. 이 문제는 백 엔드 웹 서비스에서 채워지는 드롭다운 목록으로 솔루션의 UI를 확장하는 사용자 지정 필드 형식을 사용하여 해결할 수 있습니다. 사용자 지정 워크플로를 사용하는 방법도 있지만 동일한 용도로 웹 파트를 사용하는 방법도 있습니다. 이들은 모두 관리 코드로 작성되고 Microsoft .NET Framework 어셈블리로 배포됩니다.

비교적 적은 수의 SharePoint 솔루션만 중앙 응용 프로그램 서버 팜으로 옮기더라도 까다로운 구성 및 지원 문제가 발생할 수 있습니다. 어셈블리를 GAC(전역 어셈블리 캐시)에 배포해야 하는 경우 어셈블리를 완전 신뢰 상태로 실행해야 하므로 보안 문제가 발생합니다. 구성 요소를 잘못 프로그래밍하면 시스템이 SQL 삽입, 사이트 간 스크립트 또는 서비스 거부 공격에 노출될 수 있습니다. 구성 요소가 통상적인 작업 부하뿐만 아니라 최대 부하와 장기 실행 작업까지 감당할 수 있어야 합니다. 또한 구성 요소가 이벤트를 동기적으로 처리하면서 다른 프로세스를 차단하지 않아야 하고 입력 유효성 검사를 안정적으로 수행하여 사용자가 데이터베이스나 원격 웹 시스템을 업데이트하는 데 사용되는 열에 SQL 문 또는 스크립트를 삽입할 수 없도록 해야 합니다.

간단히 말해, 여기서 우리의 목표는 표준 제품 기능을 기반으로 안전하고 확장 가능한 서버 구성을 구현하는 것입니다. 다시 사용 가능하고 철저한 테스트를 거친 솔루션을 활용한다면 막대한 양의 사용자 지정 구성 요소를 작성해야 하는 어려움을 피할 수 있습니다. 이때 프런트 엔드는 분산하고 백 엔드는 중앙 집중화하는 것이 좋습니다. 구성 요소를 느슨하게 연결하는 방식으로 통합함으로써 기존 솔루션을 최대한 다시 사용하도록 하는 것이 핵심입니다.

비즈니스 논리 분리

자, 그렇다면 서버에 구성할 수 있는 유연한 데이터 수집 솔루션은 어떻게 구축해야 할까요? 그림 2와 같이 솔루션 아키텍처를 데이터 저장소, 비즈니스 논리 그리고 표시 논리 또는 UI의 개별 계층으로 분리하는 방법이 가장 좋습니다. 최근에 UI는 일반적으로 브라우저를 기반으로 하고 비즈니스 논리는 웹 응용 프로그램 서버에 위치합니다. 그리고 UI와 비즈니스 논리는 데이터베이스와 비관계형 데이터 리포지토리에 액세스합니다.

그림 2** 3계층 아키텍처 기반의 일반적인 엔터프라이즈 솔루션 **(더 크게 보려면 이미지를 클릭하십시오.)

비즈니스 논리는 트랜잭션이 데이터베이스 관리 시스템 전반에 원자성으로 적용되도록 하는 트랜잭션 논리를 포함하는 경우가 많습니다. 또한 HTTP를 통한 여러 중간 계층 서비스, 메시지 큐, RPC 등이 비즈니스 논리에 통합될 수도 있습니다. 그러나 전반적인 솔루션 아키텍처는 본질적으로 3계층 모델입니다.

그림 2에는 엔터프라이즈 환경에 구현되는 비즈니스 논리의 복잡성이 나와 있지 않습니다. 그림에서는 응용 프로그램 서버가 브라우저 기반 양식을 표시하고 전송된 데이터를 처리하는 데만 주력하는 것처럼 보이지만, 이 그림에는 워크플로, 규정 준수 또는 정보 관리 요구 사항이 반영되지 않았습니다. 이러한 요구 사항을 해결하려면 비즈니스 논리를 표시 논리와 정보 관리 논리로 나누어야 합니다. 이렇게 비즈니스 논리를 나누면 각 솔루션마다 구성 요소를 새로 작성하지 않고도 중간 계층 구성 요소를 필요에 따라 다양하게 조합할 수 있습니다.

그림 3은 이러한 아키텍처를 보여 줍니다. 중심에는 콘텐츠 또는 데이터가 있고 그 주위에 수명 주기 전반에 걸쳐 콘텐츠를 관리하는 정보 관리 논리가 위치합니다. 표시 논리는 사용자 인터페이스를 통한 데이터 액세스 기능을 제공하기 위해 정보 관리 논리와 상호 작용합니다.

그림 3** 정보 관리 논리와 표시 논리 분리 **

XML 수집 및 처리

SOA(서비스 지향 응용 프로그램) 환경에서는 데이터 구조와 데이터를 정의하고 구성 요소 간에 이를 공유하는 데 주로 XML이 표준으로 사용됩니다. 따라서 표시 구성 요소와 정보 관리 구성 요소 간의 인터페이스에도 XML을 사용하는 것이 좋습니다.

통신은 양방향으로 이루어져야 합니다. 즉, XML을 브라우저가 읽을 수 있는 문서로 변환해야 하며 양식에서 생성된 XML 문서도 변환해야 합니다. 최근까지 XML 기반 양식 응용 프로그램을 작성하기 위해서는 고도의 프로그래밍 기술이 필요했습니다. 결과로 만들어지는 XML 데이터가 조직 간의 정보 교환이 가능하도록 업계 스키마에 부합해야 하는 경우에는 특히 더 그랬습니다.

InfoPath 2007을 활용하면 XML 기반 양식 개발이 훨씬 쉬워집니다. XML에 대해 충분한 지식이 있다면 분명 도움이 되지만 양식 디자이너나 고급 사용자는 XML 전문가가 아니더라도 쉽게 XML 기반 양식 응용 프로그램을 작성할 수 있습니다. 양식 디자이너는 XML 문서나 XML 스키마를 InfoPath로 가져온 다음, 해당 데이터 원본에서 양식의 필드로 개별 특성과 요소 노드를 매핑하기만 하면 됩니다. 또한 웹 서비스 또는 SQL Server® 데이터베이스를 기반으로 양식 디자인을 시작하거나, 백그라운드에서 자동으로 기본 스키마와 데이터 바인딩을 생성하는 InfoPath의 기능을 활용해 빈 서식 파일에서 새로 양식을 작성할 수 있습니다.

InfoPath와 XML 스키마를 사용하여 양식을 표준화하면 몇 가지 이점을 얻을 수 있습니다. 잘 정의된 XML 스키마가 이미 있다면 워크플로 및 정보 관리 구성 요소의 개발자와 양식 디자이너가 동일한 데이터 구조를 대상으로 솔루션을 만들 수 있습니다. 양식 디자이너가 양식을 새로 만드는 경우 개발자는 양식이 완성될 때까지 기다려서 기본 데이터 구조에 어떤 영향을 미치는지 확인해야 합니다. 데이터 구조가 정의된 후에는 새 양식 서식 파일 등 이후에 새로 만드는 솔루션에 기반 데이터 구조가 동일한 기존 워크플로와 정보 관리 구성 요소를 다시 사용할 수 있습니다. 또한 이후에 새로 추가하는 워크플로와 정보 관리 구성 요소가 기존 양식 및 데이터와 함께 작동할 수 있습니다. 업계에서 확립된 스키마를 기반으로 데이터 수집 솔루션을 구축하면 더욱 유연한 솔루션을 얻을 수 있습니다. 이러한 솔루션은 다른 회사에서 동일한 스키마를 사용하여 만든 솔루션과 호환되기 때문입니다.

필자는 직원과 관리자를 연결하는 DirectReports라는 간단한 스키마를 만들었습니다. 관리자는 이 스키마로 만들어지는 양식을 통해 직속 부하 직원을 평가할 수 있습니다. 이 기사와 함께 제공되는 다운로드(technetmagazine.com/code08.aspx)의 Direct Reports 폴더에는 스키마와 양식, 그리고 양식을 다시 만드는 방법을 설명하는 readme.htm 파일이 들어 있습니다. 기본적인 수준의 양식이지만 일반적인 개념을 이해하는 데에는 충분하리라 생각합니다.

여기서 짚고 넘어가야 할 중요한 것이 있습니다. 필자는 InfoPath에 유효성 검사 논리를 만들지 않았지만 그래도 InfoPath는 사용자 ID와 전자 메일 주소를 정해진 형식(domain\account 및 recipient@domain.tld)으로 입력할 것을 요구합니다. 그렇지 않으면 만들어지는 XML 문서가 유효하지 않게 됩니다. 이는 XML 스키마가 이러한 형식을 정의하기 때문입니다. 그림 4에서 볼 수 있듯이 잘못된 데이터가 있는 양식을 저장할 수는 있지만 전송할 수는 없습니다. 실제로 다른 위치로 데이터를 전송하지 않고도 이를 테스트할 수 있도록 양식에 임시 전송 규칙을 추가했습니다. 이런 유형의 오류 없이 완벽하게 양식에 입력했는지는 InfoPath 2007 유효성 검사를 통해 자동으로 확인됩니다.

그림 4a** 사용자가 양식을 전송하지 못하도록 하는 유효성 검사 오류 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 4b** 생성되는 오류 메시지 **(더 크게 보려면 이미지를 클릭하십시오.)

XML 스키마는 표시 논리와 정보 관리 논리 사이의 바인딩 계약 역할을 합니다. InfoPath는 양식 디자이너가 의도적으로 데이터 구조를 변경하지 못하도록 스키마를 잠급니다. 설정된 XML 스키마를 변경하면 새로운 양식 서식 파일과 함께 사용할 워크플로 모듈과 같은 기존 엔터프라이즈 솔루션이 손상될 수 있기 때문에 이 보호 기능은 매우 중요합니다.

InfoPath는 양식 응용 프로그램에 고급 표시 논리를 적용할 수 있는 다양한 기능을 제공합니다. XML 파일, 웹 서비스, SharePoint 라이브러리와 목록, 데이터베이스 등에 있는 데이터로부터 의미 있는 기본값을 얻을 수 있습니다. 규칙을 통해 사용자 선택을 기준으로 필드 값을 변경하고, 유효성 검사 논리를 추가하고, 높은 수준의 사용자 지정 요구 사항을 해결하기 위한 관리 코드를 추가하고, Forms Service를 사용하여 웹을 통해 액세스할 수 있는 양식 서식 파일을 만들 수 있습니다. 어떤 경우든 양식을 통해 수집되는 데이터는 결국 스키마 정의에 부합하는 XML 문서 형태로 정보 관리 논리에 전달됩니다.

XML 또는 메타데이터를 이용한 작업

이쯤에서 정보 관리 논리를 전송된 XML 문서에 직접 적용해야 하는지, 아니면 필요한 정보를 메타데이터로 추출하는 파서를 사용해야 하는지 궁금할 것입니다. SharePoint는 두 가지 방식을 모두 지원합니다. 개발자들은 XML 문서에서 직접 작업하는 방식에 익숙해져 있지만 메타데이터를 사용하면 보다 유연하게 작업을 수행할 수 있습니다.

메타데이터의 유연성을 설명하기 위해 그림 4의 Direct Reports 양식에서 전달된 XML 문서를 구문 분석하는 간단한 웹 서비스를 만들었습니다. 이 웹 서비스의 소스 코드, 설치 파일 및 단계별 지침이 포함된 readme.htm은 이 기사와 함께 제공되는 다운로드 파일의 XMLParsingWebService 폴더에 있습니다. 이 웹 서비스는 XML 문서에서 관리자의 사용자 ID를 읽고, 사용자 ID를 도메인 부분과 사용자 이름 부분으로 나누고, 나뉜 부분을 기준으로 메시지를 만든 다음, 반환할 일반 예외를 발생시키고, 처리된 정보를 InfoPath 양식에 의사 오류 메시지 형식으로 표시합니다. 이는 데이터가 전송된 후 InfoPath에 대화 상자를 표시하는 손쉬운 방법입니다. 이 웹 서비스는 훌륭하게 작동하지만 readme.htm 파일의 설명에 따라 DirectReports.xsd의 OrgPerson 요소 이름을 Manager로 바꾸고 InfoPath 양식을 새 스키마로 업데이트하는 경우와 같이 기본 데이터 원본을 변경하면 웹 서비스에서 오류가 발생합니다. XML 문서가 달라지고 user-id 요소에 액세스하기 위한 이전 XPath 식이 유효하지 않게 되므로 이는 당연한 결과입니다. OrgPerson 스키마와 Manager 스키마는 거의 동일하고 InfoPath 양식은 완전히 동일하며 원하는 처리 결과도 같지만 차이가 미미함에도 불구하고 중복된 웹 서비스를 배포하고 유지해야 합니다.

따라서 응용 프로그램 서버에서 사용자 지정 코드 사용을 최소화하려는 경우에는 이 방법이 적합하지 않습니다. 이와는 대조적으로 XML 노드를 메타데이터 필드에 매핑하고 메타데이터를 기준으로 처리 프로세스를 수행하면 XML 스키마가 달라도 유사한 데이터 구조에 동일한 워크플로와 정보 관리 논리를 사용할 수 있습니다. 하위 요소가 올바른 메타데이터 필드에 매핑되고 데이터 형식이 처리 요구 사항에 맞도록 하면 기존 코드를 다시 사용하는 데 문제가 없습니다.

XML 노드를 메타데이터 필드에 매핑하는 것은 그림 5와 같이 XML 노드를 InfoPath 양식의 UI 컨트롤에 바인딩하는 것과 비슷합니다. SharePoint에서 메타데이터 필드는 사이트 또는 목록 수준에서 정의되고 콘텐츠 형식 정의에서 참조되는 열에 해당합니다. 콘텐츠 형식은 메타데이터 필드, 워크플로, 양식과 같은 콘텐츠 항목의 특성을 정의합니다. SharePoint에서는 이러한 콘텐츠 형식의 메타데이터 필드를 연결된 XML 문서의 해당 노드와 동기화된 상태로 유지하기 위해 속성 승격과 강등을 수행하는 기본 제공 XML 파서가 사용됩니다. 속성을 승격할 때 이 XML 파서는 XML 문서의 노드 값을 문서 라이브러리의 해당 열에 추출하고, 속성을 강등할 때는 문서 라이브러리에서 열 값을 가져와서 다시 문서에 쓰는 정반대의 프로세스를 수행합니다. 여기서 가장 중요한 것은 XML 파서가 메타데이터 필드와 매핑된 XML 노드를 동기화된 상태로 유지한다는 점입니다.

그림 5** InfoPath와 SharePoint 간의 XML 스키마 매핑 **(더 크게 보려면 이미지를 클릭하십시오.)

SharePoint 개체 모델을 사용하는 경우 웹 파트, 워크플로 및 정보 관리 논리가 기본 XML 문서뿐만 아니라 메타데이터 필드와도 작동합니다. 즉, 매핑된 메타데이터 필드의 값을 변경하면 XML 문서의 노드 값이 변경되고 그 반대도 마찬가지입니다. 게다가 XML 문서에서 직접 작업하면 비즈니스 논리와 XML 스키마가 밀접하게 연관됩니다. 또한 매핑된 메타데이터 필드는 코드의 재사용성을 높입니다. 물론 환경에 적합한 방법을 선택해야 하겠지만 대개 메타데이터 필드를 사용하는 SharePoint 솔루션은 유연성이 높고 코드를 다시 사용할 기회를 더 많이 제공합니다.

SharePoint에서 XML 노드와 메타데이터 필드가 어떻게 연결되는지 살펴볼 수 있도록 이 기사와 함께 제공되는 자료에 사용자 지정 문서 라이브러리를 구축하는 SharePoint 기능을 포함했습니다. 다운로드의 OrgPersonLib 폴더에 있는 OrgPersonContentType.xml 파일을 살펴보시기 바랍니다. OrgPerson 콘텐츠 형식은 UserID, FullName, EMail, Direct_x0020_Reports라는 네 가지 필드를 참조합니다. FullName과 EMail은 기본 제공 필드이고 UserID와 Direct_x0020_Reports는 OrgPersonSiteColumns.xml에 정의된 사용자 지정 필드입니다.

필드 정의는 매우 간단합니다. 필드 정의에서 직접 XML 노드에 필드를 바인딩할 수도 있고 콘텐츠 형식에서 이 정보를 덮어쓸 수도 있습니다. 필자는 XML 문서와 관련없는 콘텐츠 형식뿐만 아니라 다른 XML 구조를 사용하는 콘텐츠 형식에 사용자 지정 필드를 사용할 수 있는 후자의 기법을 사용하기로 했습니다. OrgPerson 콘텐츠 형식은 앞서 설명한 OrgPerson 스키마의 해당 배열과 일치하는 XML 노드에 메타데이터 필드를 바인딩합니다. 동일한 메타데이터 필드를 다른 XML 노드에 바인딩하는 추가 콘텐츠 형식을 정의하는 AdditionalContentTypes.xml 파일도 있습니다. Node 특성의 XPath 식을 살펴보면 그 차이를 알 수 있습니다.

해당 라이브러리 열을 통해 노드 값이 노출되는 OrgPersonLib 형식의 문서 라이브러리에 다른 형식의 XML 문서를 저장할 수 있습니다. 이 단순한 매핑 기법에서는 네 가지 콘텐츠 형식(OrgPerson, Manager, Supervisor 및 User)이 공통의 메타데이터 필드 집합을 참조하기 때문에 워크플로와 정보 관리 논리를 다시 사용할 수 있습니다.

그림 6에는 Direct_x0020_Reports의 OrgPerson 콘텐츠 형식에 포함된 FieldRef 요소가 나와 있습니다. 이 요소는 /OrgPerson/direct-report/user-id라는 XPath 식에 따라 직속 부하 직원의 user-id 노드에 필드를 매핑합니다. XML 문서에는 직속 부하 직원 항목이 여러 개 포함될 수 있으므로 Aggregation 특성을 지정하는 것이 중요합니다. 이 특성은 XML 파서가 반환된 값 모음을 처리하는 방식을 정의합니다. 이 특성을 지정하지 않으면 XML 파서가 첫 번째 노드 값만 추출합니다. 지원되는 집계 값은 sum, count, average, min, max, merge, plain text, first, last입니다.

그림 6** XPath 식에 매핑된 메타데이터 필드 **(더 크게 보려면 이미지를 클릭하십시오.)

모든 샘플 콘텐츠 형식은 표준 upload.aspx 페이지를 DocumentTemplate으로 사용하므로 SharePoint UI에서 새로 만들기 단추를 클릭하면 문서 라이브러리에 XML 파일을 업로드할 수 있습니다. 확장명이 .xml인 파일을 업로드하면 SharePoint는 기본 제공 XML 파서를 자동으로 호출합니다. 단, WordProcessingML 파일의 경우에는 SharePoint가 WordProcessingML 파서를 호출합니다. XML 파서는 업로드된 .xml 파일을 조사하여 연결된 콘텐츠 형식을 확인합니다. 이는 필드 정의에 지정된 위치에서 노드 값을 추출하고 속성 승격을 수행하기 위한 것입니다. OrgPersonLib\XMLFiles 폴더에 있는 OrgPerson.xml 파일을 업로드할 때 이 프로세스를 직접 확인할 수 있습니다. 이 XML 문서의 구조는 OrgPerson 콘텐츠 형식 정의에 지정된 XPath 식과 일치합니다. 따라서 SharePoint는 .xml 파일에서 데이터를 추출하고, 해당 라이브러리 열에 데이터를 쓰고, 읽기 전용으로 지정되지 않은 문서 속성을 확인하고 업데이트할 수 있도록 EditForm.aspx 페이지에 데이터를 표시합니다. 그림 7에는 OrgPerson.xml에서 추출된 데이터가 표시된 EditForm.aspx 양식이 나와 있습니다.

그림 7** 추출된 데이터가 포함된 EditForm.aspx 양식 **(더 크게 보려면 이미지를 클릭하십시오.)

EditForm.aspx에서 User ID(사용자 ID), Full Name(전체 이름) 또는 E-Mail(전자 메일) 값을 변경하면 SharePoint는 속성 강등을 통해 기본 XML 문서의 노드 값을 변경합니다. 그러나 이제 여러분이 직접 필요한 논리를 양식에 구현하지 않는 한 SharePoint가 XML 스키마 제한을 강제로 적용하지 않습니다.

SharePoint는 양식 응용 프로그램의 표시 논리도 실행하지 않습니다. 예를 들어 User ID(사용자 ID)를 변경할 때 SharePoint는 새 값이 NetBIOS 규칙에 맞는지 확인하거나 Full Name(전체 이름) 필드와 E-Mail(전자 메일) 필드를 새 선택 항목에 맞게 자동으로 업데이트하지 않습니다. 따라서 개별 필드를 변경했을 때 일관성 문제가 발생할 가능성이 있으면 콘텐츠 형식 정의의 해당 열을 읽기 전용으로 지정해야 합니다. 결과적으로 사용자는 InfoPath와 같은 양식 응용 프로그램을 사용하여 데이터를 업데이트할 수밖에 없습니다. 그리고 XML 파서는 XML 문서의 모든 변경 내용을 SharePoint의 해당 메타데이터 필드로 승격합니다.

OrgPersonLib 샘플에서 OrgPersonLib\XMLFiles 폴더의 어떤 .xml 파일이든 업로드할 수 있습니다. 이들 .xml 파일은 매우 상이한 데이터 구조를 사용하지만 SharePoint는 문제 없이 콘텐츠 형식을 인식하고 올바른 노드 값을 사이트 열로 승격합니다. 그 이유는 필자가 XML 문서를 해당 콘텐츠 형식과 연결하는 처리 명령을 XML 파일에 사용했기 때문입니다. OrgPerson.xml 파일에는 이러한 정보가 없지만 문제가 되지는 않습니다. 처리 명령이나 문서 서식 파일을 통해 XML 문서를 콘텐츠 형식과 연결하지 못할 경우 SharePoint는 기본 콘텐츠 형식을 사용합니다. OrgPersonLib 예에서는 OrgPerson 콘텐츠 형식이 사용되었으므로 XML 문서가 올바르게 구문 분석됩니다.

그림 8은 XML 문서를 특정 콘텐츠 형식에 명시적으로 연결하는 방법을 보여 줍니다. MicrosoftWindowsSharePointServices 처리 명령은 ContentTypeID를 0x010100668E393E4F0EFF4294DBD202D5D8321D로 정의하는데, 이것은 AdditionalContentTypes.xml에서 정의된 User 콘텐츠 형식의 ID입니다.

그림 8** User.xml 샘플 파일의 처리 명령과 XML 데이터 **(더 크게 보려면 이미지를 클릭하십시오.)

XML 파서는 MicrosoftWindowsSharePointServices 처리 명령을 처리하고 ContentTypeID 값을 ContentType 메타데이터 필드에 씁니다. 이 메타데이터 필드는 System 콘텐츠 형식의 루트 수준에서 정의되므로 모든 SharePoint 콘텐츠 형식이 이 메타데이터 필드를 공유하게 됩니다. SharePoint 서버에서 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 폴더에 있는 fieldswss.xml 파일을 열고 MicrosoftWindowsSharePointServices를 검색하면 SharePoint에서 처리 명령과 ContentType 필드가 어떻게 연결되는지 살펴볼 수 있습니다. PITarget 특성은 처리 명령인 MicrosoftWindowsSharePointServices를 가리키고 PIAttribute는 User 콘텐츠 형식의 ID가 들어 있는 ContentTypeID를 가리킵니다.

InfoPath의 콘텐츠 형식 연결

XML 구문 분석과 콘텐츠 형식 연결과 관련된 기술은 많은 양식 디자이너들이 어려워하는 전문적인 분야지만 InfoPath 2007은 그 세부 과정을 자동으로 해결해 줍니다. OrgPersonLib 샘플과 함께 제공되는 readme.htm 파일에는 SharePoint의 Direct Reports 양식 서식 파일을 게시하고 동일한 메타데이터 필드(UserID, FullName, EMail, Direct_x0020_Reports)에 바인딩할 콘텐츠 형식을 만들기 위한 설명이 포함되어 있습니다. SharePoint UI의 OrgPersonLib 문서 라이브러리에 새 콘텐츠 형식을 쉽게 추가할 수 있습니다. 하지만 새 콘텐츠 형식도 InfoPath 양식 서식 파일을 기존 XML 문서를 업데이트할 때 양식 응용 프로그램을 호출할 문서 서식 파일로 가리킵니다. 그림 9는 InfoPath 게시 마법사를 통해 XML 노드 값과 SharePoint 사이트 열 간의 속성 매핑을 손쉽게 수행하는 과정을 보여 줍니다. 그리고 다시 한 번 강조하지만 노드 값을 기존 사이트 열과 연결하면 기존 SharePoint 구성 요소를 다시 사용할 수 있습니다.

그림 9** InfoPath 2007의 속성 매핑 **(더 크게 보려면 이미지를 클릭하십시오.)

결론

추가 온라인 리소스

• InfoPath 2007 팀 블로그
• W3C XML 스키마 사양 및 개발
• XML 스키마 소개
• Office SharePoint Server 2007의 워크플로
• InfoPath 2007 Forms Services

Office에서 제공되는 기술을 활용하면 기업의 설계자들이 손쉬운 코드 다시 사용과 정보 교환이 가능한 데이터 수집 솔루션을 구축할 수 있습니다. 또한 InfoPath 2007을 사용하면 다양한 출처로부터 정보를 획득하여 SharePoint와 같은 여러 시스템에 해당 데이터를 전송하는 솔루션을 만들 수 있습니다. SharePoint는 개발자가 워크플로와 정보 관리 구성 요소를 작성할 수 있도록 웹 서비스와 인터페이스를 포괄적으로 제공합니다. 이러한 구성 요소를 중앙 집중화된 SharePoint 서버에 호스트하면 부서에서 개별 응용 프로그램을 작성하는 데 필요한 인프라가 구축됩니다.

또한 개별 부서에서는 필요한 데이터 수집 솔루션을 보다 신속하게 만들 수 있습니다. 그리고 규정 준수나 기타 회사 전체에 적용되는 비즈니스 요구 사항도 부서 간 차원에서 해결할 수 있으며 응용 프로그램 서버에 사용되는 사용자 지정 구성 요소의 수가 줄어 IT 환경의 관리 용이성과 안정성이 향상됩니다.

Keith Deshaies는 자유 기고 테크니컬 라이터이자 대규모 통신 회사의 IT 분석가로 일하고 있습니다. Microsoft Office와 SharePoint 기술을 전문으로 다루는 Keith는 Society for Technical Communications의 회원이기도 합니다.

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