Process Builder에 대한 모범 사례
안녕하세요 저는 에이펙스 코딩을 배우기 위해 책을 읽고 있는데 PB와 관련된이 단락을 찾았습니다.
가장 좋은 방법은 단일 개체에 대해이 하나의 프로세스를 통해 관리되는 모든 제어로 정의 된 단일 Process Builder 프로세스가 있는지 확인하는 것입니다. 실제로 이것은 항상 유지 관리 할 수있는 것은 아니며 프로세스를 Apex 트리거로 마이그레이션해야 할 수도 있습니다. 개체 당 둘 이상의 프로세스가 필요한 상황에 처한 경우 이러한 프로세스를 Apex로 마이그레이션하는 것을 고려해야합니다.
바티 슨, 폴. Apex를 사용한 Salesforce 개발 학습 : 손쉽게 Apex 코드 작성, 실행 및 배포 (영어 버전) (p. 26). BPB 간행물. 킨들 에디션.
내가 이해하는 것은 프로세스 빌더의 개체에 대한 모든 업데이트가 단 하나의 프로세스에서 실행되어야한다는 것입니다!
각 개체에 대해 10 개 이상의 프로세스가 있다는 점을 감안할 때 약간 걱정됩니다.
답변
개체에 대해 단일 프로세스 빌더를 사용하는 것이 올바른 접근 방식이지만이 규칙의 예외는 생성 이벤트에 대한 프로세스 빌더와 업데이트 이벤트에 대한 프로세스 빌더가있는 경우입니다.
개체의 PB 한도는 salesforce.stackexchange.com 에서이 질문 을 확인하십시오.
프로세스 빌더에 대한 모범 사례를 보려면 다음 링크로 이동하십시오.
PB를위한 10 가지 모범 사례
Salesforce Process Builder 모범 사례
이 질문으로 질문하려는 다른 질문이 있으면 질문을 업데이트하십시오.
건배
예, 흐름 통합은 모범 사례로 간주됩니다. Process Builder 흐름을 통합해야하는 조직에서 일했기 때문에 긍정적 인 측면과 부정적인 측면 모두에 대해 이야기 할 수 있습니다. 우리가이 방향으로 밀린 이유는 여러 개체에 대한 저장 작업에 대한 관리자 제한에 도달했기 때문입니다. 이러한 흐름을 통합하면 흐름이이 문제에 기여하는 정도까지이 문제가 해결됩니다. 매우 복잡한 조직이 있고 관리자 제한 예외를 관찰하는 경우 흐름 통합을이를 해결하기위한 초기 단계로 고려해야합니다.
단점에 관해서는 몇 가지가 있습니다. 한 가지 이유는 버전 관리가 좀 더 복잡해집니다. 그리고 흐름의 잘못된 오류 처리는 기본적으로 "Process Builder에서 문제가 발생했습니다"만 알 수 있으며 어떤 노드가 문제를 일으켰는지 알 수 없기 때문에 더욱 악화됩니다. 개시 문제는 더 자세한 정보를 제공하는 오류 이메일을 보내지 만 단위 테스트의 문제는 당신을 매우 건조하게 만듭니다. 테스트를 실행하고 올바른 로그 파일과 그 섹션을 추적 할 수 있기를 바라는 것 외에는 말 그대로 조사 할 방법이 없습니다. 특히이 전략을 고려해야하는 조직은 유효성을 검사하는 데 오랜 시간이 걸리는 경향이 있으므로 배포 유효성 검사 중에 만 발생하는 오류가있는 경우 매우 까다로울 수 있습니다.
통합하는 경우 단위 테스트 목적으로 흐름을 우회 할 수있는 필드를 개체에 추가하는 것이 좋습니다. 그렇지 않으면 전체 시스템이 관리하기에 너무 취약 해집니다.
이 권장 사항도 읽었지만 프로세스의 유지 관리 / 가독성이 매우 중요합니다. 계정에는 정확히 10 개의 프로세스가 있으며, 그중 일부는 생성 이벤트 용이고 일부는 업데이트 이벤트 용입니다.
일부 프로세스는 필드를 복사하고, 다른 프로세스는 개체를 만들고, 일부는 메일 경고를 호출합니다. 물론 이들 모두는 다른 조건을 가지고 있습니다. 일부는 미래에 액션을 생성하기도합니다. 이것을 단지 두 개의 프로세스 (하나는 생성 용, 하나는 업데이트 용)에 넣으면 매우 큰 프로세스가 될 것입니다.
유지 관리 측면에 대해 자세히 설명하려면 개체 당 하나의 프로세스 만 있고 샌드 박스에서 새 기능을 작업한다고 가정합니다. 프로덕션에서 빠른 수정을 수행해야한다고 가정 해 보겠습니다. 이 수정 사항은 새로운 기능과 관련이 없지만 동일한 개체에 적용됩니다. 모두 하나의 큰 프로세스이기 때문에 샌드 박스에도 적용해야합니다. 그리고 그것은 프로세스의 우아한 업데이트가 아닙니다. 변경 세트는 단순히 새 버전을 추가하고 아무것도 병합하지 않습니다.
또한 한 가지 기능을 일시적으로 비활성화하려면 별도의 프로세스가있는 경우 해당 프로세스를 비활성화하면됩니다. 하나의 큰 프로세스가있는 경우 어딘가에서 어떤 조건을 편집해야하고 어디에서 무엇을했는지 기억해야합니다. 좋은 결과 내길 바랄 게.
객체의 모든 기능을 하나의 큰 프로세스에 넣는 것은 유지 관리에 대해 배운 모든 교훈에 위배됩니다.
그래서 지금은 그것들을 별도의 프로세스에 보관하고 있습니다. Apex 클래스로 마이그레이션하기위한 권장 사항은 말도 안됩니다. 프로세스 / 플로 / 워크 플로를 통해 요구 사항을 충족 할 수없는 경우에만 Apex 프로그래밍을 고려해야합니다. Apex 코드는 오류가 발생하기 쉽고 조직을 훨씬 유연하게 만듭니다.