[개발일지] - 632

남은 인터페이스들을 운영에 배포할 준비를 하는데

어제와 비슷한 에러가 다시 발생해서 확인해줘야 했는데

다른 부분에서 발생했지만 조금 더 원인에 가까워 질 수 있었다.

 

결론적으로 전혀 관련없는 프로세스에서

제품 등을 사용한 독자적인 price를 사용하려고 하는데

standard PriceBookEntry가 존재하지 않으면 custom이 생성되지 않아서

key가 입력되지 않은 형태의 standard PriceBookEntry를 생성해버렸고

추후 그 제품을 사용한 PriceBookEntry를 생성하려고 시도할 때

External Key를 사용해서 접근하려고 하기 때문에

기존에 있던 것과 별개를 만들려고 헀지만 이미 제품, PriceBook2는 사용되고 있기 때문에

생성할 수 없어서 에러가 발생했던 문제였다.

 

PriceBookEntry를 삭제할 수도 없고 막 삭제하기도 애매하기 때문에

결국 맞는 키값들을 넣어주는 방식으로 매칭해줬고

추후 들어가는 값들은 생성 시점에 처리하기로 했다.

 

안타깝게도 PriceBookEntry는 Trigger 등록이 되지 않았기 때문에

내부적으로 생성되는 로직의 경우 수동 관리를 해야 한다고 하는데

그쪽 로직은 여태 있는 데이터가 10개가 안되고 거의 등록되지 않는다고 하기 때문에

수동으로 처리를 하셔도 큰 문제는 없다는 것 같다.

 

차라리 스케쥴을 돌려서 하루에 한번쯤 Standard인 경우 Key를 넣어주는게 안정적일 것 같은데

스케쥴을 돌리지 않는 이유는 모르곘지만 넘어가기로 했다.

 

이전 다우오피스 연동 부분의 진행사항에 대한 문의가 들어왔는데

고객사와 회의를 하는데 이전에 같이 처리헀던 담당자분은 육아휴직이시고

인수인계가 제대로 되지 않고 휴가를 가셔서 전반적으로 업무 파악이 안된다는 것 같았다.

 

자세히 확인해보니 작년 6월에 이미 거의 마무리가 된 상태였는데

다른 업무 요청으로 계속 마무리 근처에서 미뤄지다가

8월에 일정 확인을 마지막으로 바로 앞 순번 작업을 12월까지 처리하다가

담당자분이 12월에 사라지셔서 그 뒤로 진행되지 않았는데

너무 오랜만에 확인해서 파악이 잠깐 어려웠지만

정상적인 사용 방식을 확인하고 진행하니 개발서버에서 실제 다우오피스에 등록 및 상태값 업데이트 등

전반적인 기능이 잘 작동하는 부분까지 확인하고 영업쪽에 전달드렸다.

 

어제 테스트클래스를 다 작성했기 때문에

인터페이스들을 운영에 배포해야 했는데

다른 개발쪽은 아직 진행되고 있고 필드, 개체 등이 아직 배포되지 않았기 때문에

인터페이스 배포에 필요한 개체, 필드만 먼저 운영에 반영했다.

 

인터페이스 배포 에러를 통해서 필드를 파악했는데

처음엔 인터페이스에 있는 개체, 필드들을 먼저 올렸지만

추후에는 그 개체에 필요한 fm필드가 참조하는 필드들도 올려야 했고

배포할 때마다 발생하는 에러 관련 필드들을 올리다가

다시 운영에 배포하는 방식으로 배포 시도를 5~6번 하고 나서야 정상적으로 처리할 수 있었다.

 

품질쪽, 클레임, 캠페인 등

처리해야 할 인터페이스들이 많았는데

필드, 개체 배포 또한 개발에서 운영으로 넘기면서 진행하기 때문에

생각보다 이 부분에서 시간이 많이 지연되어버렸다.

 

테스트클래스는 다 작성되어있기 때문에

그냥 개발에서 운영으로 배포만 하면 되는줄 알았는데

전반적인 개체, 필드가 없으니 반영이 생각보다 많이 힘들었다.

 

인터페이스 배포를 거의 마무리하고 있는 상태에서

갑작스럽게 호출이 있어서 확인해보니 매주 수요일 주간회의였는데

나를 뺴고도 대부분이 각자 업무에 바빠서 회의를 모르고 있었고

처음에 회의실에 들어간 분만 양치기 소년처럼 회의가 있다고 하지만

막상 회의실에 들어가 있는 사람도 없고 불도 꺼져있어서

다시 가다가 돌아오고 다시 가다 돌아오고 사람들이 회의실 근처에서 웅성거리며 모여있었다.

 

인터페이스 배포를 마치고 파일 업로드도 미리 해둬야 했는데

개발서버에서 비동기 배치로 처리하는 로직을 운영에 배포한 다음 테스트할겸 파일업로드를 시작했는데

생각보다 너무 빠르게 잘 올라가서 당황스러울 정도였다.

 

확실히 6개로 쪼개서 발송하니 금방 다 올라가고 있었는데

파일 업로드는 이제 다 해결된 것 같아서 기분이 좋았지만

파일 용량이 올라가니 결국 속도는 거의 제자리로 돌아왔다.

 

포인트는 SFDC쪽에서 ContentVersion을 등록할 때 시간지연인 것 같은데

배치가 여러개 돌아가면 다른 작업이 느려지는 것처럼

동일한 페이지에서 배치로 돌린다고 해도 실제 속도가 더 좋아지는지는 확신하기 어려웠는데

일단 6배 빨라진건 전혀 아닌 것 같고 저용량 파일의 경우 몇배 이상 빨리진 체감이 확 되긴 했는데

ContentVersion 처리 이전 부분은 배치로 처리하면 지연될게 없기 때문에

ContentVersion 부분 처리만 연달아 진행되는 것 처럼 되서 체감되는 것일 수도 있을 것 같고

일단 마이그레이션 진행이 우선이기 때문에 테스트는 어려울 것 같은데

추후 이전 로직을 복구해서 다시 배포한 다음

서로 다른 페이지에서 동시에 같은 파일 테이블을 업로드할 경우

각각 완료시간이 언제인지 비교해보는 것도 재미있을 것 같다.

 

파일 업로드를 한참 지켜보다가 9시 40분쯤 중단점, 에러를 따로 정리한 다음

나머지 업로드는 내일 하기로 하고 퇴근했다.

 

 

(1).백준 16212번 정열적인 정렬은 주어진 값들을 정렬해서 출력하면 되는 문제로

간단하게 sort를 통해서 정렬을 해결해서 join으로 요청 포맷을 만들어줬고

정렬 시 sort로 하면 문자열은 정상적으로 되지만

숫자의 경우에도 1, 11, 2, 21, 3과 같이 앞글자 기준으로 처리되기 때문에

(a,b) ⇒ a-b 와 같이 숫자 정렬이 가능하도록 처리해줬다.

const input = `6
14 5 8 7 1 10`.split('\n').map(el => el.split(' ').map(Number))[1].sort((a,b) => a - b)

console.log(input.join(' '))