Happy Programmer

저번주에 진행한 회의에서 해야 하는 업무 중 하나인 플로우 에러부터 처리하려고 확인했는데

난감하게도 검색 결과도 제대로 나오지 않았다.

메일 결과와 검색 내용을 종합해서 추측해보면 해당필드에 대한 권한이 없어서 발생할 가능성이 높았다.

하지만 10번 중 6~7번이상이 제대로 발송되고 나머지 3~4번이 에러가 발생하는건

권한 문제가 아니라 플로우 자체의 성능 문제로 터진걸 의심했다.

플로우를 따라가며 에러 지점을 찾았는데

에러가 터진 원인은 생각보다 복잡해서 정확하게는 알 수 없었지만

해결은 간단했는데 필요한 필드만 쿼리하면 되는 것이었다.

극 초반에 했기 때문에 이해도가 조금 부족한 상태로 만들어서

모든 User의 필드를 다 가져오게 했는데 User의 필드들이 너무 많고 개인정보?로 인한 보안권한들도 섞여서 계산이 끝나기 전 요청시도시 거절을당하는게 아닌가 싶었다.

해당부분을 ID, Name만 가져오게 수정하니 해당 기능 전체 속도도 빨라졌는데

백여명의 User 정보라도 필드가 많을 경우 속도저하를 유발할 수 있다는 사실을 알게되었다.

--------------------아래의 에러 메세지가 메일로 전송되었다--------------------

오류 발생: 이 오류는 플로에서 레코드를 조회하려고 시도할 때 발생했습니다: SBQQ__ResetProductLookup__c, UserType, UserPreferencesUseSalesforceMailerForLexEmail ^ ERROR at Row:1:Column:1730 No such column 'UserPreferencesUseSalesforceMailerForLexEmail' on entity 'User'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.. SOAP API 개발자 안내서에서 ExceptionCode 값을 조회할 수 있습니다.

종료 후 해당 레코드페이지로 이동은 직접 라이트닝 페이지를 만들고

해당 부분을 연동해야 한다는 느낌으로 설명이 많았고

유튜브를 봐도 코드를 직접 작성해서 진행하는 모습을 볼 수 있었지만

flow의 NavigateTo를 사용해서 편하게 문제를 해결할 수 있었는데

누가 생성한 action인건지 아니면 기본 제공인지는 모르기 때문에

추가적으로 과제를 수행할 때 사용했던 연습용 페이지에서 확인하려고 했으나

메일로 업무가 갑자기 마구 추가되서 보류하게 되었다.

메일로 필드 추가 요청이 왔지만

해당 필드가 데이터베이스상 NULL값 또는 공백이 많은데 이걸 굳이 채워야 하는지 의문이고

다른 필드는 sfdc측에서 보유하지 않는 데이터 같아서 추가 확인이 필요한데

권한이 있으신 분들이 일정상 자리에 계시지 않아 연기하게 되었는데

그럼에도 해당 부분에 대해 질문하기 전 조사를 하다보니 2시간이 넘게 소모되었다.

같이 작업하시는분이 레이아웃을 전체 덮어씌우기로 날리셔서 확인했는데

외근(?)이라 자리에 안계신데 굳이 물어보기 그래서 이번 기회에 이 부분도 알아둘 겸 조사해본 결과

레이아웃이 아닌 레코드 페이지를 건드려서 전체 덮어씌우기가 되어버린 것을 확인할 수 있었다.

아직 해당 부분의 의도는 정확하게 아는 것이 아니기 때문에

내가 당장 사용해야 하는 버튼만 하나 추가해서 임시로 사용했다.

(버튼 삭제는 바로 가능하니까)

해당 버튼을 통해 저번 회의에서 나타나지 않던 기능을 확인했는데

다행히 내 잘못은 아니었고 해상도 때문에 보이지 않던 문제였고

해상도 떄문에 적용을 하지 못하는건 문제였기 때문에 issue를 작성했다.

contentDocumentLink로 trigger를 진행하는데

두번씩 진행되는 문제를 발견했다.

14:55:33:118 USER_DEBUG [51]|DEBUG|(
ContentDocumentLink:{
Id=06A6D000003bGR4UAM, 
LinkedEntityId=0056D000006msTvQAI, 
ContentDocumentId=0696D000002S9npQAC, 
IsDeleted=false, 
SystemModstamp=2023-07-31 05:55:33, 
ShareType=I, 
Visibility=AllUsers}, 
ContentDocumentLink:{
Id=06A6D000003bGR5UAM, 
LinkedEntityId=a2m6D000000BXlRQAW, 
ContentDocumentId=0696D000002S9npQAC, 
IsDeleted=false, 
SystemModstamp=2023-07-31 05:55:33, 
ShareType=V, 
Visibility=InternalUsers})

자세히 보면 ShareType가 다른 것을 알 수 있는데

해당 부분이 문제인건가 싶은 생각을 가지고 V, I를 각자 기준으로 진행해봤다.

그 뒤 추가적으로 pdf파일을 생성하는 경우 이번에는 I로 들어가는 것을 볼 수 있었고

해당 파일은 한번만 트리거가 작동하는 것을 볼 수 있었는데

각 기능의 ShareType과 LinkedEntityId의 SObjectType에서 힌트를 얻을 수 있었다.

기본적으로 파일을 업로드할 경우 올린 사람이 누구인지를 할당하는 contentDocumentLink와

올라간 파일의 위치를 저장하는 contentDocumentLink 두가지가 작동하는 것이었다.

일반적으로 유저에 속하게 되는 파일들은 I로 저장되고

업로드된 파일은 V로 저장되는 것을 볼 수 있었으며

PDF같은 즉시 생성 파일은 유저에게 할당되지 않고 해당 ID에 속하며 I로 저장되는 것을 알 수 있었다.

결국 cvl.LinkedEntityId.getSObjectType() == ‘해당 object명'.SObjectType가 해당하는 I를 사용하거나

V인 경우에도 추가로 비교했는데

막상 코드를 작성하고 보니 추가 업로드의 경우에는 하나만 해당 레코드의 아이디로 올라가 상관없고

두개의 경우에는 getSObjectType()을 할 경우 하나는 User, 하나는 해당 레코드 기준으로 생성되기 떄문에 결론적으로 getSObjectType() 체크만 진행해도 한번만 작동한다는 결론을 내릴 수 있었다.

진행 전 디버그를 찍어가며 확인한게 시간은 더 잡아먹게 만들었지만

그래도 내부적인 구조를 조금 더 자세히 알 수 있는 기회였다.

트리거는 결국 ContentDocumentLink에서 시작한 다음

해당 값에서 ContentVersion을 쿼리로 가져오고

가져온 값을 통해 다시 ContentDistribution을 생성하고

ContentDistribution List를 순회하며 해당 링크를 추가한 첨부파일레코드를 생성했다.

이제 내부 조건들이 모두 만족될 경우 알림을 보내는 트리거를 만들어야 하는데

rollup을 사용하기로 했고 대상이 될 DeliveryRequest로 만들기로 했다.

결론적으로 하다 문제를 발견했는데

출고증의 배송여부는 아무 상관이 없었고

해당 배송은 알아서 알려주기 때문에 무시해도 괜찮았다.

출고증이 배송처리가 되는 순간 OrderItem의 IsDelivery같은 필드를 true로 바꾸고

Order의 자식인 OrderItem을 롤업으로 가져온 다음 IsDelivery의 true값의 count가

Order의 롤업으로 가져온 전체 카운트와 같으며 1보다 클 경우에 배송처리를 진행하고

전체 카운트가 0인 경우는 아직 등록이 되지 않은 상태이므로 무시한다.

(1).백준 26741번 Farma는 소와 닭의 마릿수를 구해야 하는 문제였다.

소의 다리는 4개 닭의 다리는 2개이므로...

닭의 다리만큼 빼고 남은 수치 /2가 소의 마릿수가 되고

총 머릿수에서 소의 마릿수를 제외하면 닭의 숫자가 된다.

const [head, leg] = `4 10`.split(' ').map(Number)
const cow = (leg - head * 2)/2
console.log(head - cow, cow)