나는 우리가 "공유 이야기 라는 함수 주위 메트릭을 수집할 필요가 프로젝트에." 아이디어는 매우 간단 — 인트라넷에 재미 있는 기사를 찾고 있어 사람과 공유 하고자 하는 경우, "이 이야기를 공유 라는 레이블이 있는 링크를 클릭" 귀하의 친구에 게 이메일.

우리가이 목적을 위해 사용자 지정 양식을가지고 놀, 하지만 결국, 상식 하루 원과 우리 그냥 익숙한 사용 <a href = mailto:…> 기술. (<href mailto:…> HTML의 놀라울 정도로 강력한 약간; 상 여로, 링크를 다시 내 오래 된 유닉스 맨 페이지 일으로 나를 돋보이게합니다; 그들은 일 이었다!).

이후 그들은 그들의 친숙 한 MS Outlook 클라이언트를 사용 하 여 얻을이 기술은 최종 사용자를 위한 훌륭한 인터페이스를 제공 (어떤 이메일 클라이언트가 설치 되어 있는지 또는).

그것은 어렵게 것 들 우리 불 쌍 한 개발자 유형 이후 클라이언트 * 또한 * 미래에 얼마나 자주 보여 주는 보고서를 실행 하려는 사용자가 이야기를 공유 하 고 어떤 이야기에도 자주 공유 됩니다.

우리 whiteboarded 몇 가지 잠재적인 솔루션. 내가 제일 좋아하는 탄소 복사 하는 것입니다. (CC) SharePoint 목록. 그런 식으로, 최종 사용자는 여전히 outlook 클라이언트를 가져옵니다 동안 우리가 우리 스스로 이메일의 복사본을 받을 거 야 때문에 이벤트를 캡처. 몇 가지 명백한 단점이 있다. 주요 문제는 사용자가 단순히 밖으로 빈 또는 짓 CC 주소 수 있습니다.. 그리고, 우리는 이메일의 해당 이벤트 라이브러리 관리 필요. 우리는 화이트 보드 그 정리에 대 한 책임에 예약된 된 작업.

당신은이 문제를 해결 하는 일부 영리한 접근 하는 경우, 가르쳐 주세요.

</끝>

내 블로그를 구독.

에 지 저 귐에 나를 따르라합니다 http://www.twitter.com/pagalvin

로 요청 하 고 약속, "좋은 얻을 하는 방법에 내 프레 젠 테이 션을 업로드 했습니다." 최종 사용자가 SharePoint 프로젝트 및 구현에 대 한 요구 사항. 그것은 여기: http://cid-1cc1edb3daa9b8aa.skydrive.live.com/self.aspx/SharePoint/Paul Galvin Great Requirements.zip

난 2 월에서 이것을 SharePoint 모범 사례 회의에서 발표 2009 (www.sharepointbestpractices.com). 당신이 회의 참석 하는 경우, 당신은 또한 회의 DVD에 이것을 얻을 거 야.

프레 젠 테이 션 포함 대부분 슬라이드 노트의 많은. 그것은 그냥 총알 포인트.

(다른 프레젠테이션이 거 버 넌 스 사례 연구에 대 한 여기를 참조 하십시오.: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</끝>

내 블로그를 구독.

에 지 저 귐에 나를 따르라합니다 http://www.twitter.com/pagalvin

많은 SharePoint 컨설턴트 형식 처럼, 난 많은 SharePoint 기능에 노출 되었다고. 몇 번, 꽤 깊은 다이빙. 다른 번 난 그냥 그것을 통지로 메뉴 옵션의 다른 설정에 의해 날고 있어. 그 중 하나는 "셀프 서비스 사이트 만들기.입니다." 난 이번 주에 때까지 그것을 위해 필요를 했다합니다.

이번 주, 기업과 풀고 SharePoint 더 직접 최종 사용자 제어를 포용으로 보편화 될 것입니다 생각 하는 비즈니스 문제를 해결 하기 위해 필요. 이 경우에, 특정 최종 사용자 커뮤니티를 지 원하는 사이트 서식 파일을 설계 했습니다.. 이 커뮤니티에서 여러분 것입니다 충 동 그들을 습격 할 때마다이 서식 파일을 사용 하 여 자신의 사이트를 만들 수 있어야.

"셀프 서비스 사이트 만들기를 보고 리콜" 전에 난 했습니다 항상 그 멀리 자리 잡고 생각 하는 "셀프 서비스 사이트 만들기는 내 머리 뒤와" SharePoint 용어 의미, 분명히 충분히, 뭔가 처럼 "나를 켜 경우 최종 사용자가 싶을 때 사이트를 만들 수 있습니다."

그래서, 그것을 켜십시오, 그리고 나를 위해 그것을 시도합니다, 사이트를 만들지는. 그것은 만드는 사이트 컬렉션. 꽤 큰 차이. 아니라 내가 원하는 것은, 전혀 아니에요.

최종 사용자가 사용자 지정 권한 수준을 통해 새 하위 사이트를 만들 수. 이것은 정확히 어디 내가 갔을 것 이다 첫 번째 장소에서 제외 하 고 레이블 "셀프 서비스 사이트 만들기" 라벨 속 나. 트위터를 통해, I learn that it’s deceived others as well 🙂

난 아직도 순전히 상자에서 머 무시는 동안 약간 좀 더 간소화 된 프로세스를 제공 하는 방법에 밖으로 노력, 하지만 거기에 따라 명확한 경로. 그냥 그 라벨에 의해 정신 받을 하지합니다.

</끝>

내 블로그를 구독.

에 지 저 귐에 나를 따르라합니다 http://www.twitter.com/pagalvin

내가 중 하나 였다 20 또는 30 (아니면 100?) 패널에서 마지막 밤은 뉴욕 SharePoint 사용자 그룹 회의. 일반적인 프레 젠 테이 션 형식 대신, 이 질문에 대 한 모든 했다&관객과 패널 회원 사이 A. 초기에, 마이클 Lotter 소개 나 새로운 아이디어를 공유 하 고 싶 었.

한 관객 회원 설명 어떻게 그의 회사는 그의 회사에 대 한 응용 프로그램을 작성 하는 컨설턴트를 지불 했다. 컨설턴트는 SharePoint 개체 모델을 사용 하 여 콘솔 응용 프로그램으로 그것을 쓴. 결과적으로, 이 프로그램은 팜의 서버에서 실행 되도록 했다는 의미. 이 응용 프로그램을 사용 하 고 싶 었 누구 든 지 서버에 로그온 했을 의미, 작업을 수행 하 고 로그 오프. 처음에, 이 wasn'ta 문제가, 하지만 곧, 점점 더 많은 (비 기술적인) 사용자가 유틸리티를 사용 하는 데 필요한. 그의 질문은 (지나친의 역):

"무슨 내 옵션은? 내가 직접 서버에 사용자가 로그를 보내는 유지 하 고 싶지 않아, 하지만 그들은 그 기능을 필요 합니다."

마이클 Lotter 제안 그가 새 가상 컴퓨터 구성, WFE로 팜에 가입 하 고 거기에서 응용 프로그램을 실행 하는 사용자가.

이것은 나를 위해 꽤 멋진 아이디어. 기본적으로 임시의 개념을 마음에 입으 면이 솔루션을 일반화, 거의 일회용 WFE의. 그것은 매우 청 초 한 개념 생각. 이 임시 WFE SharePoint 개체 모델을 사용 하는 콘솔 응용 프로그램을 실행할 수 있습니다.. 또한 stsadm 명령을 실행 하려면 그것을 사용할 수 있습니다.. 그것은 일반 지역 균형의 일부가 될 필요가 없습니다.. 다운 되거나 난파 되 면, 당신은 단지 새로운 한 회전 수 있습니다.. 나 자신을 반복합니다, 하지만 난 그냥 정말 깔끔한 아이디어 생각.

</끝>

내 블로그를 구독.

에 지 저 귐에 나를 따르라합니다 http://www.twitter.com/pagalvin

이것은 지난 주, 사람이 꽤 많은 양의 새로운 문서 처리 SharePoint 환경 만들기에 대 한 질문 (10,000 +/- 이 경우에). 나는 이것에 대해 많이 몰라, 하지만 이 백서에 덕분에, 기분이 훨씬 더 나은 정보.

나를 위해, 이 백서는 거의 그냥 순간에도 서 마크, 하지만 난 그것을 통해 읽기 시작 했 고 내 메인 테이크아웃을 강조 것 이라고 생각. SharePoint는 처리를 확장할 수 있습니다., 최소한, 이 부하:

• 50하루 k 새 문서.
• 10 만 문서 총.

때문에 기억 하기 쉬운 50 k/10 MM 수치를 작성. 그들은 최소한 알고, 당신은 곤경에 얻을 하지 않습니다.. 최대값은 적어도 10 % 이상 보다와 익 스 트림 튜닝, 가능성이 훨씬 더 높은.

감사, 마이크 월 시, 다시 한번 대 한 그의 주간 WSS FAQ 업데이트 및 수정 게시. 당신이 그것에 가입 하지 않은 경우, 당신은 심각 하 게 그것을 생각 한다.

</끝>

내 블로그를 구독.

지난 일주일 동안, 내 동료 내가 뉴욕에서 클라이언트에 대 한 몇 가지 일을 하 고 했다. 우리는 모스 구현 그들의 "표준을 사용 하 여 다양 한 측면을 테스트 했다" 워크스테이션 빌드 (우리의 휴대용 퍼스널 컴퓨터와 반대로). 그렇게 하는 동안, 우리가 이러한 단계에 따라 몇 가지 오류에 부딪쳤다:

• Windows 탐색기를 통해 MS word 문서를 엽니다 (WebDAV를 사용 하).
• 변경.
• 그것을 저장합니다.

우리는 몇 번을 깨 달 았지 (일반적으로 처음으로) 우리는 문서 저장, 저장 하지 않은 "막대기." 저장 저장 하지 않았다. 백업 문서를 당겨 것 이라고 우리와 우리의 변경 간단 하 게 되지 않은 거기.

우리가 시점에서 루트 문제를 이해 하지 못했지만, 하지만 우리는 우리가 있는 최신 MS 오피스 서비스 팩 그 워크 스테이션에 설치 되어 있는지 확인 해야 합니다 생각. IT 사람들이 서 하 고 그 랬 어. 우리는 테스트를 통해 다시가 서 그리고 우리는 새로운 문제를 발견. 우리가 그것을 저장 하는 때, 우리는 지금이 오류가 있어:

이번에, 모든 변경 되었습니다 것 같, 사실, 저장, 여부 우리가 응답 예 또는 아니요 스크립트 질문에.

우리가 마지막으로 살펴 실제 버전의 Office 및 워크스테이션 MS 오피스를 실행 했다 밖으로 변합니다. 2000 서비스 팩 3 도움말-보여줍니다> 에 대해 "Office 2002"로.

이야기의 교훈: 나는 항상 사무실 사용 2003 내 최소 기준 오피스 버전 WebDAV와 이끼를 사용 하는 경우로.

</끝>

내 블로그를 구독.

(검색 엔진으로, 이것은 오류 텍스트):

라인: 11807

Char: 2

오류: 개체가이 속성 또는 메서드를 지원 하지 않습니다.

코드; 0

URL: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

이 페이지에서 스크립트 실행 계속 하 시겠습니까?

하나 또는 내 최초의 블로그 게시물, SPS에서 고객을 마이그레이션하는 데 다음에 우리는 전체 프로세스를 설명 2003 이끼를. 독자 코멘트를 자세히 요구 왼쪽 그리고 여기.

마이그레이션 프로젝트에 대 한, SPS의 많은 이동 하는 좋은 방법을 찾을 수 있었습니다. 2003 이끼를 통해 문서. 초기 로드 충분히 쉬 웠 다. MOSS에서 새 대상 문서 라이브러리를 만들고 windows 탐색기를 사용 하 여 문서를 이동.

이것은 새 문서 라이브러리:

탐험가 두 개의 창을 열어합니다. SPS에서 첫 번째 포인트 2003 MOSS에서 새 문서 라이브러리에 두 번째. 다음 스크린 샷에서 표시이. 상위 브라우저 내 c에서 실제로 가리키는 유의:\임시 드라이브, 하지만 SPS를 가리키는 그것을 상상할 수 있습니다 2003 문서 라이브러리:

그 후 끌어서 놓기 작업, 내 대상 다음과 같이 보:

지금 그것은 메타 데이터 처리 시간. 우리 라는 "위치가이 문서에 대 한 메타 데이터의 한 열 가정입니다." 우리는 위의 "모든 문서에서 볼 수 있습니다." 위치는 빈 볼. 그것은 데이터 시트 보기를 사용 하 여 위치를 입력 하, 또는 각 문서 속성 하나를 위치를 추가로 이동. 가정해 실용적인 수 없습니다 위치 열 값을 자동으로 할당 되는 최종 사용자가 해야 할이 손으로. 또한, 문서의 수백이 있다 가정 하자 (어쩌면 수천) 그리고 그것이 걸릴 것입니다 많은 메타 데이터를 업데이트 하려면 많은 일. 우리 모두가 알다시피, 아무도 앉아 4 5 일 연속 문서에 대 한 메타 데이터 업데이트에 대 한 작업을 거 야. 대신, 그들은 몇 주 또는 더 긴 기간 동안 그를 탈출 것입니다.. 이 과정을 촉진 하기, 우리는 "태그가 지정 되지 않은 데이터를 만들 수 있습니다." 보기와 같이:

지금, 누군가가 내려 앉아 보내고 그들의 할당 된 일일 시간 또는 마이그레이션된 문서 태그 2, 그들은 "태그가 지정 되지 않은 문서를 사용할 수 있습니다." 그들의 노력을 집중 하는 것 보기:

사용자 태그 문서, 그들은이 목록에서 삭제.

태그 데이터 보기의이 개념 또한 데이터 유효성 검사 문제 사람들에 대 한 포럼에 문의의 클래스와 함께 도울 수 있다. 상자, 이끼에 문서를 업로드 한 사용자를 방지 하기 위해 다음 메타 데이터를 입력 하지 방법이 없습니다.. 특정 사이트 열은 필수 이며 사용자는 저장을 허용 되지 않습니다 지정할 수 있습니다 버튼. 그러나, 사용자 업로드 하는 경우 다음 브라우저를 닫습니다 (또는 문서를 업로드를 사용 하 여 windows 탐색기), 우리 메타 데이터 입력 사용자 강제로 수 없습니다. (다시, 상자 밖으로).

이 방법은 그 상황에 도움이 사용할 수 있습니다.. 우리는 "저조한 태그 데이터를 사용할 수 있습니다." 쉽게 이러한 문서를 식별 하 고 수정할 보기. KPI 커플이 있고 이러한 예외적인 상황을 관리 하기 위해 드릴 다운을 사용 하 여 데이터를 좋은 가시성.

</끝>

내 블로그를 구독.

이번 주, 난 간단한 2 서버 팜에 설치 하는 이끼를 내 팀과 조금 싸 워 왔어. 그것을 통해 간 데, MSDN 포럼에 그리고 다른 곳에서 문제가 사람들이 보고서의 종류에 대 한 큰 감사를가지고.

최종 팜 구성:

• 방화벽 내에 SQL/인덱스/인트라넷 WFE.
• WFE DMZ에.
• DMZ와 내부 서버 간의 방화벽의 일종.

우리는 프로젝트를 시작 하기 전에, 우리는 클라이언트 포트를 열어야 하는 데 필요한 게. 주고받는 동안, 그 동안 이리저리, 우리는 결코 명시적으로 중요 한 두 가지를 말했다:

1. SSL은 인증서가 필요한 것을 의미 한다.
2. DMZ 서버는 도메인의 일부 여야 합니다..

하루에 한, 우리 MOSS를 설치 하 고 데이터베이스와 이끼에 대 한 도메인 계정을 하지 않았다면 만들어진 배웠습니다.. 것 들을 따라 이동 하, 우리는 서 서 하 고 인트라넷 서버에 로컬 계정이 있는 모든 것을 설치.

이 시점에서, 우리는 SSL 인증서에 혼란을 발견 하 고, 슬프게도, 우리의 인프라 사람이 다시와 서 나중에 그 주 계속 DMZ 서버를 설치 하기로. 평균시에서, 우리 솔루션 건축가 비즈니스 물건 앞으로 이동.

주말가 및 클라이언트 인증서를 가져옵니다..

우리의 인프라가 나타나고 DMZ 서버를 도메인에 가입 되지 않은 발견 (제한 된 신뢰 경계 도메인 또는 인트라넷 도메인). 우리 거의 낭비를 1/2 그 날. 만약 우리가 우리를 수렁 누락 된 SSL 인증서 하지 않았다면, 우리는 발견이 이전. 오 오 잘….

또 다른 하루 패스 및 다양 한 보안 위원회, 관심을 당사자와 (그리) 무고 한 구경꾼 모든 동의 그것 DMZ 서버는 인트라넷 도메인 가입 확인 (이것은 한 POC, 어쨌든, 아니 생산 솔루션).

인프라 남자에 관해서 것 들을 마무리. 우리가 성공적으로 통과 하는이 시간에 다 정하게 "SharePoint 구성 마법사로 알려진 현대 결투." 우리는 중앙 관리에 있는 엿 고 … 유 호! … DMZ 서버 농장에 나열 됩니다.. 우리 조금 가까이 그리고 우리 파산 오픈 샴페인 마이트 조금 일찍 실현. WSS 서비스에 붙어 있는 "시작" 상태.

길고도 짧은 이야기, 그것은 우리가 원래 로컬 계정에서 새 도메인 계정을 중앙 관리를 통해 서비스 계정의 id를 변경 하려면 깜 빡 밝혀. 우리는 그랬다, 구성 마법사 re-ran 봐라! 우리는 사업에 있었다.

</끝>

내 블로그를 구독.

비록 그것이 문자 그대로 사실이, 실질적인 문제로 서, DMZ에는 인터넷 웹 프런트 엔드는 도메인에 있어야 합니다. (즉. 일부 독립 실행형 서버는 자체 작은 작업 그룹에서). 그것은 내부 WFE와 동일한 도메인에 있어야 필요가 없습니다.(s) 그리고 다른 서버 (아마 안와), 도메인 해야 하지만.

내 동료와 나 SharePoint 필수 구성 요소를 포함 하는 제안에 시간의 과도 한 금액을 지출. 이 농장 등에 가입 하도록 DMZ 서버 있도록 방화벽 구성의 포괄적인 목록을 포함. 슬프게도, 우리는 어딘가에 말했다 문장 추가 실패, 효과를, "이이 구성의 전체 피 묻은 포인트 DMZ WFE 서버를 허용 하는, 도메인에서, 내부 팜에 가입."

이벤트의 완벽 한 폭풍, 어디 우리가 기본적으로 보였다 왼쪽 오른쪽 모습이 수 있습니다 우리가 하는 때, 공모 과정에서 상당히 늦게 때까지 미국에서이 문제를 숨기기, 따라서 호출에서 날을 방지 내 "나쁜 뉴스를 일찍 말해" 규칙.

한숨.

내 블로그를 구독.

포럼의 사용자가 자주로 이 같은 질문:

> 안녕하세요,
>
> 가르쳐 주세요 어떤 가능성과 사용자 지정 목록을 작성 하는 경우
> 마스터 및 세부 형식 (송장 처럼) Infopath를 사용 하지 않고.
>

SharePoint에서는 그런 종류의 비즈니스 요구 사항 지 원하는 상자 기능 중 일부를 제공합니다.

일반적으로, 하나 두 목록의 조회 열을 사용 하 여 함께 링크. 구매서 헤더 정보를 포함 하는 목록 A 및 송장 세부 정보를 포함 하는 목록 B.

추가 목록을 사용 하 여 고객 번호를 유지, 제품 번호, 등.

콘텐츠 쿼리 웹 파트를 사용 하 여 (모스만) 데이터 보기 웹 파트는 목록의 병합 된 뷰를 만드는 또는. SQL Server Reporting Services (SRS) 그것을 보고 측면에 대 한도 가능.

그러나, 도 적당히 복잡 한 것에 대 한 순수한 아웃-의-더-박스 기능을 사용 하기 어려울 것 이다 몇 가지 중요 한 제한이 있다. 이들은 포함 한다:

• 관련된 조회의 크기 vs 나열. "멋" 조회 열 형식. 조회 열 형식 그 자체를 제공 여부에 따라 다르게 UI에 설정한 다중 선택 여부. 두 경우 모두에서, 아웃-오브-더-박스 컨트롤 표시 소스 목록에서 모든 사용 가능한 항목. 소스 목록에 경우 1,000 항목, 그는 문제가 될 것 이다. 조회 컨트롤 항목 페이징 하지 않습니다.. 대신, 그들의 모든 컨트롤에 끌어. 데이터 입력 및 성능 면에서 매우 어 색 사용자 인터페이스에 대 한 게.
• 조회 "당겨 다시" 정보 중 한 열. 당신은 정보의 소스 목록에서 하나 이상의 열을 뒤로 당겨 결코 수 있다. 예를 들어, 고객 "12345를 선택할 수 없습니다." 동시에 수로는 고객의 이름 및 주소를 표시 하 고. 조회 표시 고객 번호와 다른 건. 이것은 어 색 하 고 어려운 사용자 인터페이스에 대 한.
• 아니 내부 형태의 통신. 이 여기에 대해 작성 했습니다.. 계단식 드롭다운을 구현할 수 없습니다., 조건에 따라 활성화/비활성화 필드, 등.
• 계단식 삭제 또는 기본 제공 참조 무결성. SharePoint 독립 엔터티 사용자 지정 목록을 처리 하 고 전통적인 ERD 의미에서 그들을 서로 게 연결을 허용 하지 않습니다.. 예를 들어, Sharepoint를 사용 하면 두 사용자 지정 목록을 만들 수 있습니다., "고객" 그리고 "구매서 헤더". 고객 목록에서 송장 헤더를 고객에 게 다시 연결 하 만들 수 있습니다.. 다음, 목록에서 고객을 삭제할 수 있습니다.. 상자, 이 방지 하기 위해 방법이 없습니다.. 이런이 종류의 문제를 해결 하기 위해, 일반적으로 이벤트 처리기를 사용.

그것은 황량한 보일 수도, 하지만 여전히 시작 지점으로 이런이 종류의 기능을 구축 하기 위한는 SharePoint를 사용할 것. 솔루션에 필요한 사이 비록, Sharepoint와 같은 도구를 사용 하 여 그 격차를 채울 수 있습니다.:

• 이벤트 처리기. 그들을 사용 하 여 참조 무결성을 적용 하.
• 사용자 지정 열: 사용자 지정 열 형식을 만들고 기본 조회 열 대신 그들을 사용 하 여. 페이징 추가, 버퍼링 하 고 응답을 AJAX 기능.
• BDC. 이 모스 전용 기능 일반적인 조회 열에 뛰어난 사용자 인터페이스와 다른 SharePoint 목록 쿼리를 수 있습니다.. BDC는 백 엔드 서버 응용 프로그램에 밖으로 또한 도달할 수 있습니다.. BDC를 사용 하 여 복제를 피하기 위해. 백 엔드 ERP 시스템에서에서 고객 정보를 복제 하는 대신, BDC를 사용 하 여 대신. BDC 기능 속한다 고 복제 솔루션 유지 관리의 번거로움을 피할 수 있는 ERP 시스템에서 직접 정보를 좋은 사용자 인터페이스를 제공.

  BDC는 모스 기능 (WSS에서 사용할 수 없습니다) 구성에 도전.

• ASP.NET web form: SharePoint 개체 모델 또는 웹 서비스를 사용 하 여 SharePoint 목록 매우 응답성이 뛰어난 사용자 인터페이스를 제공 하면서 활용 하는 모든 기능을 갖춘 AJAX 사용 폼 만들기.

처음부터 시작 하 고 마지막 옵션 느낄 수 있습니다., 하지만 사실 그 SharePoint 플랫폼 시작 하면 다음과 같은 주요 기능을 고려합니다:

• 유지 보수와 보안 모델.
• 메뉴 시스템 유지 보수.
• "마스터 테이블" (즉. 사용자 지정 목록) 보안, 기본 유지 보수 및 감사.
• 검색.
• 백 엔드 통합 도구 (BDC).

Visual studio에서 새 빈 프로젝트와 함께 시작 하는 경우, 인프라 및 Sharepoint에서 제공 하는 것에 가까이 도착 하기 전에 구축 하는 배관의 여지가.

Microsoft SharePoint 응용 프로그램 개발의이 방향에서 확장 하고자 믿어요. 그것은 자연적인 확장 기존 SharePoint 기본을 것 같아. 마이크로소프트의 CRM 응용 프로그램 헤더/세부 사항 응용 프로그램 개발을 지 원하는 데 필요한 형식의 확장성의 큰 거래를 제공 합니다.. 그 기능 CRM에 있지만, 기술은 분명 SharePoint 개발 팀에 제공 되며 그 말까지 SharePoint 제품으로 그것의 방법을 만들 것입니다 그것을 기대합니다 2008. 지식이 나이에 대 한 통찰력 있는 사람이 있다면, 코멘트를 남겨 주세요.

</끝>