서비스 팩 2 이후부터 변경 시 워크플로가 자동으로 시작되지 않음

서비스 팩 2 이후부터 변경 시 워크플로가 자동으로 시작되지 않음

안녕하세요. 저는 SharePoint Designer 팀에서 관련된 글을 올리고 있는 Stephen입니다. 이 문서에서는 Office SharePoint Server 2007 및 Windows SharePoint Services 3.0용 서비스 팩 2(영문일 수 있음)에 포함된 픽스에 대해 설명하고자 합니다. 이 픽스는 SharePoint Designer 2007에서 디자인된 워크플로에 영향을 줍니다. 따라서 의도적으로 하나가 아닌 두 개의 워크플로를 사용하여 워크플로 루프를 만드는 방법을 보여 드리겠습니다.

서비스 팩 2 이전까지는 우연히 자동으로 트리거되는 워크플로를 디자인하여 무한 루프를 만드는 것이 굉장히 쉬웠습니다. 예를 들어 다음과 같은 시나리오를 가정해 보십시오.

1) 항목이 변경되면 워크플로가 시작됩니다.

2) 워크플로가 현재 항목을 업데이트하거나 변경합니다(예: 현재 항목의 필드 설정 작업 사용).

3) 워크플로가 항목을 변경했으므로 워크플로가 자동으로 트리거됩니다.

따라서 전자 메일을 보낸 다음 현재 항목을 업데이트하는 변경 시 워크플로를 사용한다면 받은 편지함에 금새 수백 통의 전자 메일이 도착하게 될 것입니다.

하지만 서버에 서비스 팩 2(SP2)를 설치한 이후부터는 항목 변경 시 시작되는 워크플로가 더 이상 현재 항목을 변경/업데이트하여 자동으로 트리거되지 않습니다. 이 무한 루프 시나리오가 가능하지 않게 되는 것입니다.

그러나 많은 사람들이 지금까지 무한 루프를 사용하는 워크플로를 디자인했습니다. 예를 들어 한 작업 항목에서 무한정 루프되어 작업이 완료로 표시될 때까지 매일 미리 알림을 보내는 변경 시 워크플로를 디자인할 수 있었습니다. 이 워크플로는 자동 트리거를 위해 목록에 추가된 카운터 열을 업데이트하여 자동으로 트리거됩니다. 또한 이 워크플로에는 특정 조건을 만족하면 워크플로를 중지하거나 중단하는 규칙이 있습니다. 이 경우 작업 상태가 완료됨이면 워크플로가 현재 항목을 변경하지 않고 중지됩니다. SP2 이후부터는 이 워크플로가 자동으로 트리거될 수 없으므로 사실상 중단됩니다.

유용하게 사용할 수 있는 무한 루프를 SP2가 차단하는 것은 아닙니다. 그러나 예전처럼 작동하는 워크플로를 다시 만들려면 서로를 트리거하는 변경 시 워크플로를 두 개 이상 디자인해야 합니다. 현재 항목을 업데이트/변경하여 서로를 트리거하는 두 개의 변경 시 워크플로는 "상호 재귀" 시나리오에 해당합니다.

그뿐만 아니라 서로를 트리거하는 짧은 워크플로를 여러 개 사용하여 상태 기반 워크플로를 구현하는 것은 매우 흔한 일입니다. 예를 들어 상태 필드가 포함된 목록이 있고 이 목록에 변경 시 워크플로가 여러 개 연결되어 있을 수 있습니다. 이들 워크플로는 모두 상태 필드를 업데이트하는 단계를 마지막에 포함합니다. 따라서 한 워크플로가 상태를 업데이트하여 다른 여러 워크플로를 트리거하고 그러면 트리거된 워크플로는 상태 필드의 값을 검토하여 실행을 계속할지, 아니면 중지할지 여부를 결정합니다. 이러한 상태 기반 워크플로도 "상호 재귀" 시나리오에 해당하는데 하나의 워크플로가 현재 항목을 변경/업데이트하여 여러 다른 변경 시 워크플로를 시작하기 때문입니다. SP2는 상호 재귀에 기반을 둔 이러한 상태 기반 워크플로를 차단하지 않습니다.

요약

· SP2 이전에는 변경 시 워크플로 하나가 현재 항목을 업데이트하여 자신을 트리거하는 방식으로 무한 루프에 들어갈 수 있었습니다.

· SP2 이후부터는 변경 시 워크플로 하나가 현재 항목을 업데이트하여 다른 변경 시 워크플로를 트리거할 수 있지만 자신을 트리거할 수는 없습니다. 따라서 상호 재귀 시나리오가 얼마든지 가능하며, 간단한 변경 시 워크플로를 여러 개 사용하여 상태 기반 워크플로를 구현하는 시나리오가 여기에 포함됩니다.

· 다시 말씀 드리지만 생성 시 워크플로가 현재 목록에 항목을 만들도록 하여 무한 루프를 만드는 방법은 한 번도 가능했던 적이 없습니다. 모든 워크플로에는 "내가 시작할 수 없는 워크플로"라는 속성이 있으며 이 속성은 항목이 만들어질 때 시작되는 워크플로가 루프되지 않도록 하는 데 사용됩니다.

· 또 한 가지 주의할 점은 이전의 시나리오는 모두 단일 목록이나 라이브러리에 연결된 워크플로만 포함한다는 사실입니다. 목록 간 시나리오에서의 무한 루프는 변경 시 워크플로나 생성 시 워크플로에 대해 모두 가능합니다.

서비스 팩 2 이전의 루프 만들기

이 섹션에서는 SP2 이전에 변경 시 워크플로 하나로 무한 루프를 사용하는 방법을 예로 보여 줍니다. SP2 이후부터는 이 워크플로가 자신을 트리거하지 않으므로 다음 섹션에서는 별개의 두 워크플로를 사용하여 무한 루프를 만드는 방법을 예로 보여 줍니다.

팀 작업이라는 작업 목록이 있고 작업이 완료로 표시될 때까지 매일 미리 알림을 보내는 워크플로를 디자인하려 한다고 가정해 보십시오.

먼저 기본값이 0인 카운터(Counter)라는 열을 목록에 추가합니다.

워크플로만 이 카운터 열에 액세스하고 업데이트할 수 있도록 카운터 열을 목록 양식에서 숨겨야 합니다(새 항목, 항목 편집). 먼저 목록 설정 페이지에서 고급 설정을 클릭한 다음 콘텐츠 형식 관리를 허용하도록 설정합니다.

목록 설정 페이지에서 각 콘텐츠 형식을 클릭하고 다음 페이지에서 카운터 열을 클릭합니다. 그런 다음 카운터 열을 숨기도록 설정합니다. 목록의 모든 콘텐츠 형식에 대해 이 작업을 수행합니다.

카운터 열을 만들고 열이 양식에 나타나지 않도록 숨겼으면 이제 워크플로를 디자인할 차례입니다.

매일 미리 알림 워크플로는 항목이 만들어지거나 변경될 때마다 시작되어야 합니다.

첫 번째 단계에서는 두 가지 사항을 확인합니다. (1) 작업이 이미 완료로 표시되어 있으면 워크플로가 중지됩니다. 이 규칙은 작업이 마지막으로 완료로 표시될 때마다 루프를 중단합니다. (2) 작업이 완료되지 않았으면 워크플로는 작업 기한이 미래의 날짜인지(오늘 이후 날짜) 확인합니다. 여기서는 기한이 될 때까지 미리 알림을 보내지 않으려고 하므로 작업 기한이 미래의 날짜이면 기한이 될 때까지 워크플로가 일시 중지됩니다.

두 번째 단계에서는 작업이 완료되었는지 다시 확인합니다(이전 단계에서 기한이 될 때까지 워크플로가 일시 중지되었는데 그 사이에 작업이 완료되었는지 확인). 작업이 아직 완료되지 않았으면 워크플로가 하루 동안 일시 중지됩니다.

세 번째 단계에서는 워크플로가 일시 중지되어 있는 동안 작업이 완료되었는지 다시 확인합니다. 작업이 완료되었으면 워크플로가 중지됩니다.

작업이 완료되지 않았으면 워크플로는 (1) 전자 메일 미리 알림을 보냅니다. (2) 현재 항목/카운터 필드를 조회하여 CurrentCount 변수를 설정합니다. (3) CurrentCount에 1을 추가하고 이 값을 NewCount 변수에 저장합니다. (4) 카운터 열을 NewCount 변수에 저장된 값으로 설정합니다.

기본적으로 이 단계에서는 워크플로가 실행될 때마다 카운터 열의 값을 1씩 증가시키므로 카운터 열을 보면 미리 알림을 보낸 횟수를 알 수 있습니다. 그리고 가장 중요한 사실은 이 단계의 끝에 수행되는 "현재 항목의 필드 설정" 작업이 현재 항목을 변경하는 작업이므로 워크플로가 자신을 트리거하고 루프를 만든다는 점입니다.

서비스 팩 2 이후의 루프 만들기

SP2 이후에도 이러한 루프를 이용할 수 있지만 자신을 트리거하는 단일 워크플로 대신 서로를 트리거하는(상호 재귀) 두 개의 워크플로를 디자인해야 한다는 점이 다릅니다.

이때는 (1) 개수를 증가시키는 카운터 워크플로와 (2) 실제로 미리 알림 메일을 보내는 작업자 워크플로를 사용합니다.

첫 번째 워크플로 - 카운터 워크플로

앞에서와 같이 기본값이 0인 카운터 열을 목록에 만들고 콘텐츠 형식 관리를 허용하도록 설정하고 목록의 모든 콘텐츠 형식에 대해 이 필드를 숨김으로 설정해야 합니다.

두 개의 워크플로를 사용하는 이 디자인에는 SendMail이라는 두 번째 열이 필요합니다. 이 열은 작업자 워크플로에 대한 플래그 역할을 합니다. 기본값은 No여야 합니다. 그렇지 않을 경우 작업 항목이 변경되면 전자 메일 미리 알림이 전송됩니다.

카운터 워크플로는 항목이 만들어지거나 변경되면 시작됩니다.

첫 번째 단계에서는 작업 상태를 확인합니다. 작업이 완료되었으면 카운터 워크플로가 중지됩니다.

여기서는 기한이 될 때까지 미리 알림을 보내지 않으려고 하므로 작업 기한이 미래의 날짜(오늘 이후의 날짜)이면 기한이 될 때까지 두 번째 단계가 일시 중지됩니다.

세 번째 단계에서는 작업이 완료되었는지 다시 확인합니다. 즉, 이전 단계에서 워크플로가 일시 중지되어 있는 동안 작업이 완료되었는지 확인합니다. 작업이 아직 완료되지 않았으면 워크플로가 하루 동안 일시 중지됩니다.

마지막 단계에서는 상태를 다시 확인하여 하루 동안의 일시 중지 기간 동안 작업이 완료되었는지 확인합니다. 작업이 완료되지 않았으면 워크플로가 (1) 카운터 열의 값을 1씩 증가시키고 (2) SendMail을 Yes로 설정하여(기본값은 No임) 현재 항목을 업데이트합니다.

두 번째 워크플로 - 작업자 워크플로

앞의 카운터 워크플로는 현재 항목을 업데이트(변경)하는 것으로 종료됩니다. 이러한 업데이트는 항목이 변경되면 시작되도록 설정된 작업자 워크플로를 트리거합니다.

작업자 워크플로는 단순히 SendMail 플래그가 Yes로 설정되어 있는지만 확인합니다. Yes로 설정되어 있으면 워크플로는 미리 알림 메시지를 보내고 플래그를 다시 No로 설정합니다.

SendMail 플래그를 No로 설정하면 앞의 카운터 워크플로를 트리거하도록 변경됩니다. 카운터 워크플로와 작업자 워크플로는 서로를 트리거하여 작업이 완료료 표시될 때까지 매일 미리 알림을 보냅니다.

무한 루프 대신 카운터 열이 특정 값, 예를 들어 5개의 미리 알림에 도달하면 작업자 워크플로가 작업 알림을 에스컬레이션하도록 설정할 수도 있습니다. 다음 단계에서는 미리 알림 개수에 따라 서로 다른 분기를 실행합니다. 개수가 5에 도달하면 워크플로는 관리자에게 메시지를 보냅니다. 관리자의 전자 메일 주소는 전자 메일 보내기 작업에 하드코딩하거나 워크플로 조회를 사용하여 목록에서 검색할 수 있습니다.

특정 개수의 미리 알림이 전송된 후에는 다른 개인이나 그룹에 작업을 다시 배정하도록 작업자 워크플로를 설정할 수도 있습니다. 이 단계에서 워크플로는 에스컬레이션된 작업에 대한 추가 작업을 수행할 책임이 있는 팀 구성원으로 이루어진 SharePoint 그룹에 작업을 다시 배정합니다.

개수가 특정 숫자에 도달하면 루프를 종료하려는 경우 작업자 워크플로가 아니라 카운터 워크플로의 첫 번째 단계에 분기를 추가해야 합니다. 이 분기는 카운터 열의 값이 6에 도달하면 루프를 중지합니다.

이 정보가 도움이 되길 바랍니다.

- Stephen

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Service Pack 2 prevents an on-change workflow from starting itself을 참조하십시오.

!-->