S2S 통합을 수행해야하므로 몇 가지 릴리스가되었지만 예상치 못한 문제가 발생하여 다른 사용자가보다 효과적으로 해결할 수 있습니다.Salesforce에서 salesforce 로의 왕복 필드 업데이트 문제
S2S를 통해 연락처를 공유하는 두 개의 조직이 있습니다.
각 조직의 연락처는 동일한 스키마를 가지며 표준 입력란과 맞춤 입력란이 있습니다. 체크 박스 필드 A, 및 번호 (18,0) 필드 B.는
조직 1 필드 A를 발행하고, B.
조직이 구독을 필드 구독 : 난 그냥 두 개의 사용자 정의 필드가 기본 케이스를 재현 한 A 필드에 게시하고 B 필드를 게시합니다.
Org 1은 S2S를 통해 Org 2에 대한 연락처를 공유하여 모든 S2S 워크 플로를 시작합니다. 조직 2에는 자동 승인이 설정되어 있습니다.
Org 2에는 B 필드의 값을 계산하기 위해 단순히 필드 A를 사용하는 Insert Before Insert 트리거가 있습니다. 필드 A가 선택되어 있으면 필드 B에 2를 채 웁니다.이 옵션을 선택하지 않으면 0입니다. (물론이 작업은 실제로 수행해야 할 작업의 과도한 단순화이지만 기본 재현 가능 사례입니다.)
모두 작동합니다. Org 2의 벌금 - 필드 A와의 접촉이 정상적으로 이루어졌으며 필드 결과가 필드 B로 계산됩니다.
결과는 필드 B가 자동으로 다시 공유되지 않음을 나타냅니다. 다음 연락처 업데이트. Org 2에서 "Description"과 같은 동일한 연락처에서 비공유 필드를 편집하는 것만 큼 간단 할 수 있습니다. 그런 다음 필드 B의 이전에 계산 된 값이 조직 1로 다시 푸시됩니다.
나는 이것이 필드 B의 계산이 삽입 전 (Before Insert) 내에서 발생하기 때문에 S2S 연결은 현재 업데이트 트랜잭션이 오직 수행되었다고 가정하기 때문에 (이 논리가 무한한 S2S 업데이트를 방지하는 방법을 이해할 수 있음을 알 수 있습니다. 루프).
필드 B가 변경 될 때 강제로 (새, 더미) 공유 필드를 업데이트하는 워크 플로 필드 업데이트를 만들려고했지만 Salesforce와 동일한 실행 컨텍스트에 있기 때문에 업데이트가 다시 실행되지 않았습니다. 재사용을 면제한다고 간주합니다. 또한 필드가 변경 될 때 연결 대기열로 리드를 전달한 워크 플로 규칙을 시도했지만 작동하지 않았습니다.
그런 다음 AfterUpdate 트리거에서 다시 업데이트 문을 시도했습니다. 공유 필드가 업데이트 된 경우 공유 객체를 다시로드하고 다시 업데이트하십시오. 그것도 작동하지 않았다.
해결 방법은 BeforeUpdate 트리거에 의해 공유 필드가 변경된 레코드를 다시로드하고 접촉하는 AfterUpdate 트리거에서 호출하는 Future 메서드입니다. 이로 인해 필드 결과가 원래 조직에 거의 실시간으로 표시됩니다.
이 솔루션은 현재 나를 위해 작동하지만 뭔가를 놓친 것 같습니다. 이로 인해 미래 호출과 DML이 필요한 것보다 더 많이 실행됩니다.
아무에게도 더 좋은 해결책이 있습니까?
'@ future'을 고수하고 싶습니다. 이 기능을 사용하기 위해 개발자의 입장에서 본다면 아마도 Org 2에서 만든 업데이트가 게시 된 필드에서 무한 루프 생성에 대한 우려를 확인하지 않을 것입니다. 그들이 그 사건을 처리하지 않으면, 루프 가능성, 더 쉬운 개발자, 다음 기능으로 넘어갑니다. '@ future '는 부작용 (예고없이 향후 릴리스에서 사라질 수있는 나쁜 습관을 가지고 있음)을 사용하지 않고 원하는 것을 정확히 수행하기 때문에 좋아합니다. –