Experience League

Experience Cloud

Document Cloud

워크플로우 우수 사례

워크플로우를 통해 Adobe Experience Manager(AEM) 활동을 자동화할 수 있습니다.

이는 AEM 환경에서 발생하는 많은 양의 처리를 나타내므로 사용자 정의 워크플로우 단계가 모범 사례에 따라 작성되지 않거나 기본 작업 과정이 가능한 효율적으로 실행되도록 구성되지 않은 경우 결과적으로 시스템이 손상될 수 있습니다.

따라서 워크플로우 구현을 신중하게 계획하는 것이 좋습니다.

구성

워크플로우 프로세스를 구성할 때(사용자 정의 및/또는 즉시 사용) 주의해야 할 몇 가지 사항이 있습니다.

임시 워크플로

높은 섭취 로드를 최적화하려면 워크플로우를 일시적으로 정의할 수 있습니다.

워크플로우가 일시적인 경우 중간 작업 단계와 관련된 런타임 데이터는 실행 시 JCR에 지속되지 않습니다(출력 변환은 물론 지속됨).

이점은 다음과 같습니다.

워크플로우 처리 시간 단축최대 10%.
저장소 증가를 크게 줄일 수 있습니다.
삭제할 때 더 이상 CRUD 워크플로우가 필요하지 않습니다.
또한 TAR 파일 수를 줄여 파일 수를 줄입니다.

주의

감사를 위해 워크플로우 런타임 데이터를 보관/보관하는 것이 비즈니스 명령인 경우 이 기능을 활성화하지 마십시오.

DAM 워크플로 조정

DAM 작업 과정에 대한 성능 조정 지침은 AEM Assets 성능 조정 안내서를 참조하십시오.

최대 동시 워크플로 수 구성

AEM에서는 여러 워크플로 스레드를 동시에 실행할 수 있습니다. 기본적으로 스레드 수는 시스템의 프로세서 코어 수의 절반으로 구성됩니다.

실행 중인 워크플로우가 시스템 리소스를 요구하는 경우, 이는 AEM이 작성 UI 렌더링과 같은 다른 작업에 거의 사용하지 않는다는 것을 의미합니다. 따라서 벌크 이미지 업로드와 같은 활동 중에는 시스템이 느려질 수 있습니다.

이 문제를 해결하려면 최대 병렬 작업의 수를 시스템에 있는 프로세서 코어 수의 2/4에서 3/4 사이로 구성하는 것이 좋습니다. 이렇게 하면 시스템이 이러한 워크플로우를 처리할 때 응답성을 유지할 수 있을 만큼 충분한 용량을 확보할 수 있습니다.

최대 병렬 작업을 구성하려면 다음 중 하나를 수행할 수 있습니다.

AEM 웹 콘솔에서 OSGi 구성을 구성합니다.대기열의 경우:Granite Workflow Queue(Apache Sling 작업 큐 구성).
AEM 웹 콘솔의 Sling 작업 옵션에서 큐를 구성할 수 있습니다.작업 큐 구성용:http://localhost:4502/system/console/slingevent의 Granite Workflow Queue.

또한 Granite Workflow 외부 프로세스 작업 큐에 별도의 구성이 있습니다. 이 값은 InDesign Server 또는 이미지 클릭과 같은 외부 바이너리를 실행하는 워크플로 프로세스에 사용됩니다.

개별 작업 큐 구성

경우에 따라 개별 작업 기준으로 동시 스레드 또는 기타 큐 옵션을 제어하도록 개별 작업 대기열을 구성하는 것이 유용합니다. Apache Sling 작업 큐 구성 팩터리를 통해 웹 콘솔에서 개별 큐를 추가하고 구성할 수 있습니다. 나열할 적절한 항목을 찾으려면 워크플로우의 모델을 실행하고 Sling 작업 콘솔에서 찾습니다.예를 들어 http://localhost:4502/system/console/slingevent에 있습니다.

임시 워크플로우에 대해 개별 작업 대기열을 추가할 수도 있습니다.

워크플로 제거 구성

표준 설치 AEM에서는 매일 및 매주 유지 관리 활동을 예약하고 구성할 수 있는 유지 관리 콘솔을 제공합니다.예를 들면 다음과 같습니다.

http://localhost:4502/libs/granite/operations/content/maintenance.html

기본적으로 주별 유지 관리 창에는 워크플로 제거 작업이 있지만 실행되기 전에 구성해야 합니다. 워크플로우 삭제를 구성하려면 웹 콘솔에 새 Adobe Granite Workflow 제거 구성을 추가해야 합니다.

AEM의 유지 관리 작업에 대한 자세한 내용은 작업 대시보드를 참조하십시오.

사용자 지정

사용자 정의 워크플로우 프로세스를 작성할 때 고려해야 할 몇 가지 사항이 있습니다.

위치

워크플로우 모델, 방사형, 스크립트 및 알림에 대한 정의는 유형에 따라 저장소에 있습니다.즉, 특별한 사용자 정의 등

노트

AEM 6.5의 리포지토리 구조화를 참조하십시오.

위치 - 워크플로우 모델

워크플로우 모델은 유형에 따라 저장소에 저장됩니다.

즉시 사용 가능한 워크플로우 디자인은 다음 경로 아래에 있습니다.

/libs/settings/workflow/models/
주의
하지 않음:
- 이 폴더에 사용자 정의 워크플로우 모델을 배치합니다.
- /libs에서 모든 항목 편집
업그레이드 시 또는 핫픽스, 누적 수정 팩 또는 서비스 팩을 설치할 때 변경 사항을 덮어쓸 수 있으므로
사용자 정의 워크플로우 디자인은 다음 항목에 포함됩니다.
```
/conf/global/settings/workflow/models/...
```
런타임 워크플로우 디자인(기본 및 사용자 정의 모두)은 다음 경로 아래에 있습니다.

/var/workflow/models/
기존 워크플로우 디자인(디자인 시간 및 런타임 모두)은 다음 경로에서 유지됩니다.

/etc/workflow/models/

노트

이러한 디자인을 AEM UI 을(를) 사용하여편집하면 세부 사항이 새 위치로 복사됩니다.

위치 - 워크플로우 발사체

워크플로우 실행 프로그램 정의도 다음 유형에 따라 저장소에 저장됩니다.

즉시 사용 가능한 워크플로우 방사선은 다음 경로 아래에 있습니다.

/libs/settings/workflow/launcher/
주의
하지 않음:
- 이 폴더에 사용자 지정 워크플로 릴리스를 배치합니다.
- /libs에서 모든 항목 편집
업그레이드 시 또는 핫픽스, 누적 수정 팩 또는 서비스 팩을 설치할 때 변경 사항을 덮어쓸 수 있으므로
사용자 지정 워크플로우 릴리터는 다음과 같이 유지됩니다.
```
/conf/global/settings/workflow/launcher/...
```
이전 워크플로우 릴리터는 다음 경로 아래에 있습니다.

/etc/workflow/launcher/

노트

이러한 정의가 AEM UI 을(를) 사용하여편집되면 세부 정보가 새 위치로 복사됩니다.

위치 - 워크플로우 스크립트

워크플로우 스크립트는 다음 유형에 따라 저장소에 저장됩니다.

즉시 사용 가능한 워크플로우 스크립트는 다음 경로 아래에 있습니다.

/libs/workflow/scripts/
주의
하지 않음:
- 이 폴더에 사용자 정의 워크플로우 스크립트 중 하나를 배치합니다.
- /libs에서 모든 항목 편집
업그레이드 시 또는 핫픽스, 누적 수정 팩 또는 서비스 팩을 설치할 때 변경 사항을 덮어쓸 수 있으므로
사용자 정의 워크플로우 스크립트는 다음과 같이 보관됩니다.
```
/apps/workflow/scripts/...
```
이전 워크플로우 스크립트는 다음 경로 아래에 있습니다.

/etc/workflow/scripts/

위치 - 워크플로 알림

워크플로우 알림은 다음 유형에 따라 저장소에 저장됩니다.

즉시 사용 가능한 워크플로우 알림 정의는 다음 경로 아래에 있습니다.

/libs/settings/workflow/notification/
주의
하지 않음:
- 이 폴더에 사용자 정의 워크플로 알림 정의를 배치합니다.
- /libs에서 모든 항목 편집
업그레이드 시 또는 핫픽스, 누적 수정 팩 또는 서비스 팩을 설치할 때 변경 사항을 덮어쓸 수 있으므로
사용자 지정 워크플로우 알림 정의는 다음과 같이 유지됩니다.
```
/conf/global/settings/workflow/notification/...
```
노트

워크플로우 알림 텍스트를 재정의하려면 다음 아래에 겹쳐진 경로를 만듭니다.

/conf/global/settings/workflow/notification/<path-under-libs>
이전 워크플로우 알림 정의는 다음 경로 아래에 있습니다.

/etc/workflow/notification/

프로세스 세션

사용자 정의 개발에서와 마찬가지로, 가능한 경우 사용자의 세션을 사용하는 것이 좋습니다.

보안 지침 준수를 위한 최상의 방법
시스템이 세션을 열고 닫도록 관리

워크플로우 프로세스를 구현할 때

특별한 사유가 없으면 워크플로우 세션이 제공되므로 사용해야 합니다.
워크플로 엔진에서 가능한 동시 실행 문제와 함께 상태가 일치하지 않을 수 있으므로 워크플로 단계에서 새 세션을 만들지 마십시오.
워크플로우의 프로세스 단계 내에서 새 JCR 세션을 취득해서는 안됩니다.프로세스 단계 API에서 제공하는 워크플로우 세션을 jcr 세션에 적용해야 합니다. 예:

public void execute(WorkItem item, WorkflowSession workflowSession, MetaDataMap args) throws WorkflowException {
        // to obtain a jcr session:
        javax.jcr.Session jcrSession = workflowSession.adaptTo(javax.jcr.Session.class);

        // to obtain a sling resource resolver:
        org.apache.sling.api.resource.ResourceResolver slingResourceResolver = workflowSession.adaptTo(org.apache.sling.api.resource.ResourceResolver.class);

세션 저장:

워크플로우 프로세스 내에서 WorkflowSession을(를) 사용하여 저장소를 수정하는 경우 세션을 명시적으로 저장하지 마십시오. 워크플로우가 완료되면 세션이 저장됩니다.
Session.Save 워크플로우 단계 내에서 호출하면 안 됩니다.
- 워크플로 jcr 세션을 조정하는 것이 좋습니다.그런 다음 워크플로우 엔진이 워크플로우 실행을 완료하면 세션을 자동으로 저장하므로 save은(는) 필요하지 않습니다.
- 자체 jcr 세션을 만드는 프로세스 단계에서는 권장되지 않습니다.
불필요한 비용 절감을 제거하여 오버헤드를 줄이고 워크플로우를 보다 효율적으로 만들 수 있습니다.

주의

여기에 있는 권장 사항에도 불구하고 자신만의 jcr 세션을 만드는 경우 해당 세션을 저장해야 합니다.

방사선의 숫자/범위 최소화

등록된 모든 워크플로 시작에 대한 책임을 지는 리스너가 하나 있습니다.

다른 방사선의 전역 속성에 지정된 모든 경로에서 변경 사항에 대해 듣습니다.
이벤트가 전달되면 워크플로우 엔진은 각 런처를 평가하여 실행해야 하는지 확인합니다.

너무 많은 방사포를 만들면 평가 프로세스가 더 느리게 실행됩니다.

단일 실행 장치에 대한 저장소 루트에 글로벌 경로를 만들면 워크플로 엔진이 저장소의 모든 노드에 대해 이벤트를 만들고 평가하고 생성/수정할 수 있습니다. 이러한 이유로 필요한 방사포만 만들고 가능한 한 구체적인 글로벌 경로를 만드는 것이 좋습니다.

이러한 방사포가 워크플로우 행동에 미치는 영향 때문에 사용하지 않는 즉시 사용 가능한 방사선을 비활성화하는 데에도 유용합니다.

방사선에 대한 구성 개선 사항

사용자 지정 launcher 구성이(가) 다음과 같은 기능을 지원하도록 개선되었습니다.

여러 조건을 "AND"로 결합합니다.
단일 조건 내에 OR 조건이 있습니다.
기능 플래그가 활성화되었는지 또는 비활성화되었는지 여부에 따라 방사기를 비활성화/활성화합니다.
실행 조건 시 regex를 지원합니다.

다른 워크플로에서 워크플로우를 시작하지 않음

워크플로우는 메모리에서 생성된 객체와 저장소에서 추적된 노드를 모두 고려하여 상당한 양의 오버헤드를 처리할 수 있습니다. 이러한 이유로 추가 워크플로우를 시작하는 대신 워크플로우 자체 내에서 처리를 수행하는 것이 좋습니다.

이러한 예로는 컨텐츠 세트에 비즈니스 프로세스를 구현한 다음 해당 컨텐츠를 활성화하는 워크플로우가 있습니다. 게시해야 하는 각 컨텐트 노드에 대해 컨텐트 활성화 모델을 시작하는 대신 이러한 노드 각각을 활성화하는 사용자 정의 워크플로우 프로세스를 만드는 것이 좋습니다. 이 방법을 사용하려면 추가 개발 작업이 필요하지만 각 정품 인증에 대해 별도의 워크플로우 인스턴스를 시작하는 것보다 실행 시 더 효율적입니다.

다른 예로 여러 노드를 처리하고, 워크플로우 패키지를 생성한 다음 해당 패키지를 활성화하는 워크플로우가 있습니다. 패키지를 생성한 다음 패키지를 페이로드로 사용하여 별도의 워크플로우를 시작하는 대신 패키지를 생성하는 단계에서 워크플로우의 페이로드를 변경한 다음 동일한 워크플로우 모델 내에서 패키지를 활성화하는 단계를 호출할 수 있습니다.

핸들러 진행

워크플로우 모델을 디자인할 때 워크플로우 단계에서 핸들러를 미리 활성화할 수 있습니다. 또는 워크플로우 단계에 코드를 추가하여 다음에 실행할 단계를 결정한 다음 실행할 수 있습니다.

성능이 향상되므로 핸들러 이동을 사용하는 것이 좋습니다.

워크플로 단계

워크플로우 단계를 정의한 다음, 작업/단계를 특정 워크플로우 단계에 할당할 수 있습니다.

이 정보는 받은 편지함](/docs/experience-manager-65/sites-authoring/workflows-participating.html?lang=ko#opening-a-workflow-item-to-view-details-and-take-actions)에서 작업 항목의 [워크플로우 정보 탭을 클릭하면 작업 과정의 진행 상황을 표시하는 데 사용됩니다. 기존 워크플로우 모델을 편집하여 단계를 추가할 수 있습니다.