[개발일지] - 48

오늘은 어제 작성한 메일 미답변 관련 4개 통합 작업을 진행하고 있었는데

인터페이스 팀 업무로 RMA 인터페이스를 배정받았다.

 

미답변 관련은 직접적인 내 업무는 아니기도 하고

내일 회의에서 진행될 예정이지만

인터페이스 팀 업무는 직접적으로 할당된 업무이기 때문에

인터페이스 업무를 먼저 진행하기로 했다.

(게다가 첫 프로젝트는 마감일이 미정인 상태라 현재 RMA 관련이 더 급할 수 있다)

 

모든 기업에서 거의 동일한 절차로 진행되기 때문에 부담없이 적자면

고객의 케이스가 접수될 경우 RMA 처리를 하는 것이 내 업무였는데

해당 부분이 작성될 떄 가격을 책정하는 곳과의 인터페이스를 통해

RMA를 마무리하고 RMA가 Order로 전송되게 하는 부분이었고

작업은 다시 배치를 사용해서 진행할 것 같았다.

 

주문쪽에 작성된 인터페이스를 보며

어떻게 진행될지 분석해보고 있으라고 하셨는데

정확한 업무는 내일 오후 진행될 회의에서

고객사에서 정확하게 정해줘야 진행될 것 같았기 때문에

회의 전 준비시키는 단계라고 이해했다.

 

확실히 인터페이스에 대한 경험은 바닥이기 때문에

이번에도 새로 배울점이 많았는데

시작하자마자 아래와 같은 코드(필드 다 날린 상태)를 볼 수 있었다.

SELECT Id, (SELECT Id FROM OrderLineItems__r) FROM Order__c

 

초반에는 그냥 그런가보다 하고 넘어갔곘지만

저런 방식으로 아이템들이 나오는게 신기했는데

가져온 값을 debug찍어보니 아래와 같은 형태로 ID만 나왔지만

System.debug(orderList);

Order__c:{Id=ID1}, Order__c:{Id=ID2}, Order__c:{Id=ID3}, Order__c:{Id=ID4}

아래와 같이 for문으로 조회한 결과 아이템들이 리스트형태로 나오는 것을 볼 수 있었다.

for(Order__c order : orderList){
    System.debug(order.OrderLineItems__r);
}

(OrderLineItem__c:{Order__c=ID1, Id=ID}, OrderLineItem__c:{Order__c=ID1, Id=ID})
(OrderLineItem__c:{Order__c=ID2, Id=ID}, OrderLineItem__c:{Order__c=ID2, Id=ID}, OrderLineItem__c:{Order__c=ID2, Id=ID})
(OrderLineItem__c:{Order__c=ID3, Id=ID}, OrderLineItem__c:{Order__c=ID3, Id=ID})
(OrderLineItem__c:{Order__c=ID4, Id=ID}, OrderLineItem__c:{Order__c=ID4, Id=ID})

 

그냥 출력할 경우 Item들이 찍히지 않는 것과

막상 for문으로 각자 접근을 시도하면 찍히는 것이 신기했는데

생각해보면 초반에 사용했던 쿼리로도 관계를 타고 조회했던 것과 유사한 것 같다.

 

코드를 분석하던 중 생성자를 static으로 하지 못한 것은

내부 값을 사용해야 하기 때문이고

굳이 static으로 하나를 더 생성해서 콘스트럭터를 호출하는 이유는 

플로우에서 작동시킬 때 static만 호출이 가능했기 때문이었다.

 

where id = :dataId 형태로 들어가게 쿼리를 작성했지만

1개가 아닌 리스트로 받은 다음 [0]으로 사용한 이유는 이해하지 못했는데

limit 1을 하고 객체로 가져올 경우 어딘가에서 에러가 터진 적이 있는 것 같았다.

 

Order가 아닌 Order__c로 개체가 구성되어 있었고

하위 개체들 또한 당연히 커스텀으로 구성되어 있었는데

왜 이렇게 복잡한 일을 진행했는지 몰랐지만 

질문하기엔 바빠보이셔서 검색해보니

의외로 사람들끼리 의견 대립이 존재하는 주제였다.

 

결론적으로는 __c로 스탠다드 개체를 커스텀으로 바꿀 경우

확장성이 증가하는 장점이 있지만

스탠다드 개체의 자연스러운 연결들을 대체하기 위해

연관된 개체들까지 전부 커스텀으로 생성해야 하며

기본적으로 제공하는 연결 및 기능 또한 사용할 수 없는 단점이 있고

업그레이드 등에 따라가기 힘들다는 단점도 존재했다.

 

하지만 반대로 지원 중단 등 확장 기능을

세일즈포스에 의존하지 않고 직접 구현한다는 부분에서 장점이 있기 때문에

어떤 부서인지에 따라서 의견이 갈리고 성향에 따라서도 갈리는 문제 같았지만

결론적으로 대부분 Order__c(물론 상황에 따라서)를 손들어주는 것 같았다.

 

RecordType.DeveloperName이라는 부분이 있어서 뭔지 몰랐는데

검색해본 결과 아래와 같은 필드들이 RecordType 내부에 있는 것을 확인할 수 있었다.

Id, DeveloperName, Name, SobjectType, Description, IsActive, BusinessProcessId, NamespacePrefix

 

마지막으로 특정 Wrapper의 사용이 없음에도 불구하고 존재했었는데

알고보니 상대방측의 api가 아직 미완성이라 미리 틀만 잡아놓고 완성 후 사용할 예정이라고 하셨다.

 

오늘도 이것저것 많이 배울 수 있었던 보람찬 하루였다.

 

 

(1).백준 5597번 과제 안 내신 분..?은 1~30번이 있는 반에서 28명만 과제를 제출했을 때

과제를 제출하지 않은 사람을 찾는 문제였다.

 

처음에는 배열로 접근했지만 의외로 배열로 접근할 경우 밀려나서 해당 위치를 찾기 힘들었고

결국 객체에 값을 담은 다음 없는 사람을 찾는 방식으로 진행했다.

 

값의 숫자 자체를 기억하는 배열 처리를 위해서 map, sort까지 진행했었지만

사실 다 필요없고 문자열과 숫자를 ==비교로 처리했어도 됐을 것 같다.

const input = `3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30`.split('\n').map(Number).sort((a,b) => a-b)

const obj = {}
for(let i = 0 ; i < input.length ; i++){
    obj[input[i]] = 1
}

for(let i = 1 ; i < 31 ; i++){
    if(!obj[i]){
        console.log(i)
    }
}