SharePoint 사이트의 변경 사항에 대한 매일 요약 경보를 만드는 방법

StackOverflow https://stackoverflow.com/questions/921509

문제

나는 최근에 SharePoint 사이트 내의 변경에 대해 사람이 매일 요약 경보를 받도록 요구하는 요구 사항을 얻었습니다. 각 사이트에는 사이트의 콘텐츠를 담당하는 소유자가 있습니다.

현재 작동하는 방법은 사이트 내의 모든 목록/라이브러리에 대한 경고를 자동으로 설정하는 것입니다.

// Get the Lists on this Site
SPListCollection siteLists = currentSite.Lists;
foreach (SPList list in siteLists)
{
    if (!list.ToString().Equals("Master Page Gallery"))
    {
        if (list.ReadSecurity == 1) // user has read access to all items
        {
            // Create an Alert for this List
            Guid alertID = currentUser.Alerts.Add(list, SPEventType.All, SPAlertFrequency.Daily);

            // Set any additional properties
            SPAlert newAlert = currentUser.Alerts[alertID];
        }
    }
}

이것은 두 가지 문제를 만듭니다.

  1. 사용자는 생성 된 다양한 경고가 있습니다. 이상 : 매일 요약이 포함 된 이메일 하나만 있습니다.
  2. 사이트의 새 목록이나 라이브러리를 확인하려면 일부 모니터를 설정하고 사용자에 대한 경고를 자동으로 설정해야합니다.

Q : 사이트의 모든 변경 사항에 대한 매일 요약 경고를 어떻게 만들 수 있습니까?

도움이 되었습니까?

해결책

당신이 찾고있는 솔루션은 감사 프레임 워크를 통해 사용할 수 있다고 생각합니다. 감사는 SP에서 매우 강력합니다. 불행히도 출력에 압도하기 쉽습니다.

감사는 SPSITE, SPWEB, SPLIST 및 SPITEM 속성에서 이용할 수있는 속성입니다.

이 속성을 사용하여 특정 감사 플래그 (.audit.auditflags 속성 사용)를 조정하여 요구 사항을 사용하여 "변경"을 정의하는 방법에 따라 다르지만 생각할 수있는 거의 모든 것이 사용 가능합니다).

에 대한 세부 사항 스파이 핏 대상 MSDN에서 사용할 수 있습니다.

무엇을 감사하고 싶은지 정의하면 해당 정보를 사용자에게 다시 가져와야합니다.

기본적으로 SP는 사이트 수집 수준 ([사이트 수집의 URL]/_ 레이아웃/reporting.aspx? category = 감사)에서 사용할 수있는 멋진 보고서를 설정합니다. 이것들은 당신의 필요를 충족시킬 수 있습니다.

초기 솔루션은 사용자를위한 이메일을 통해 경고를 언급했습니다. 대부분의 사용자는 이메일로 정보를 중앙 집중화하고 싶어한다는 점을 감안할 때 (MySite는 보고서에 링크를 넣을 수있는 좋은 장소이지만) 조금 더 많은 일을 할 수 있습니다.

SpauditQuery 및 SpauditentRycollection 객체를 사용하여 객체 모델을 통해 필요한 감사 정보를 가져올 수 있습니다. 다시, MSDN에는 몇 가지 정보가 있습니다 이 객체를 사용하는 방법에.

하루가 끝날 때 실행되는 사용자 정의 SPJOBDEFINITION을 설정하여 사용자에게 해당 사이트의 감사 보고서를 이메일로 보내는 것이 좋습니다. 앤드류 코넬은 큰 설명을 가지고 있습니다 맞춤형 작업을 설정하는 방법 그의 블로그에서.

요약:

  • 문제의 SPWEB에 대한 감사를 활성화하십시오
  • 각 spweb에 대해 SpauditQuery 및 SpauditentRycollection을 사용하여 보고서 작성
  • 각 SPWEB 소유자에게 보고서를 이메일로 보내기 위해 매일 밤 실행되는 SPJOBDEFINITION을 만듭니다.

다른 팁

사이트에서 감사 정책을 활성화하기 전에 고려해야 할 사항은 추가 된 성능 오버 헤드입니다.

여기서 발자국을 최대한 적게 유지하는 것이 좋습니다!

즉,이 정보를 원하는 특정 콘텐츠 유형 또는 특정 목록이라면이 CT 또는 목록에 대한 정보 정책 만 활성화해야합니다!

또한 로깅을 최소로 유지하십시오. 예 : 삭제 또는 복원이 아닌보기에만 관심이있는 경우이 이벤트 만 기록하십시오!

대형 사이트에서 나는 감사하는 것이 실제로 쓰레기 성능을 보았습니다!

또한 일부 경고에주의하십시오. 문서 라이브러리가 아닌 것처럼 목록에서 감사를 활성화 할 수 있지만 많은 이벤트 (예 : 이벤트보기)가 목록 항목에 대해 특별히 기록되지 않습니다! 이것은 어디에도 설명되지 않았지만 (실제로 Ted Pattison이 MSDN 기사에서 항목 수준 감사를 언급 한 것을 보았습니다) CSS 및 제품 팀에서 직접 품목 수준 감사가 SP2007에서 구현되지 않는다는 것을 직접 가지고 있습니다. 대신 로그에서 목록이 이벤트를 얻는다.

문서는 상당히 정상적으로 추적되지만 게시 페이지 (API의 문서가 목록 항목이 아닌 문서로 간주되는)의 감사보기에 대한 문제가 발생했습니다 (예 : 감사 정책이 상속 된 상태에서 구현 된 경우 감사 정책이 구현 된 경우 CT) 그래서 그게 알아야 할 것입니다.

편집 : 어제와 더 나쁜 테스트를 거쳤습니다. 게시 페이지 ~이다 뿐 사이트 수준 감사 정책을 설정하면 추적했습니다! 목록 또는 컨텐츠 유형에 정책을 설정하는 경우 (또는 정책으로 콘텐츠 유형에서 상속되는 콘텐츠 유형) 아니요 spaudititemtype. 문서 수준 이벤트. 사이트에 설정하면 너무 많은 감사를받을 수 있습니다! 예를 들어. 보기는 X2 뷰 이벤트를 트리거하고 업데이트와 동일하므로 너무 많이 기록됩니다. 정책이 목록과 CT에 올릴 때 아무것도 감사하지 않는 버그처럼 보입니다 ...

여기의 주요 메시지는 다음과 같습니다. 로그인 한 내용은 신중합니다. 로그에 예상되는 것이 실제로 기록 된 사이트 성능 테스트에 영향을 미치기 때문입니다!

HTH Anders Rask

글쎄, 품목 레벨 감사가 없다는 것은 아닙니다. 품목 레벨 감사가 구현되었지만 특정 항목에 대해 켜야합니다. 목록 항목이 있으면 인스턴스를 가져 와서 목록에 이와 동일하게 감사를 켭니다. 문제는 ListItem이 생성 될 때이를 켜는 방법입니다. 워크 플로우가 도움이 될 수 있습니까?

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top