Happy Programmer

오자마자 그동안 밀린 업무들과 휴가 중 처리했던 일들을 확인했는데

생각보다 그렇게까지 많지는 않았지만 오전에 회의가 잡혀있었기 때문에 이번주는 상당히 바쁠 것 같았다.

일단 휴가 전날에 인터페이스 예정 요청이 왔었기 때문에

먼저 말은 헀었기 때문에 우선 처리하려고 시작했다.

해당 내용을 처리하는데 계속 유지보수 관련 리마인드가 날아오고

추가적으로 문제점이 나타나서 예상 처리시간이 회의를 제외하고 16시간 이상일 것 같았다.

빠르게 초반 요청을 처리할 수 있어서 운영에 반영까지는 할 수 있었지만

에러가 발생하는데 원인 파악 전에 회의에 들어가야 했고 회의에서 추가 인터페이스 업무를 받았다.

그래도 인터페이스 업무 자체는 4개의 인터페이스 진행에 2달의 일정이었기 때문에

진짜 빡빡하게 돌아가지는 않을 것 같았지만

이 외에도 인터페이스 프로젝트가 2개정도 예약되어있기 때문에 아무래도 당분간은 바쁘지 않을까 싶다.

개발 관련 데이터를 정리하는데

실시간이 아니지만 삭제, 추가, 업데이트된 내용을 전부 반영해야 한다는게 말이 좀 안되는 것 같은데

삭제된 데이터를 삭제하지 않고 delete = true 같은 방식으로 처리하는 것도 아닌 진짜 삭제여서

어떤게 삭제되었는지 파악하려면 결국 모든 보유한 데이터를 다 조회해야 하기 때문에

전체 데이터 비교는 필수적으로 진행해야 할 것 같았다.

SAP에서 데이터를 줄 경우 모든 데이터와

SFDC에서의 모든 데이터를 가져온 다음 key값을 각각 만들어서

중복되는 경우에는 LastModifiedDate가 Date로 기입되기 떄문에

Today로 하고 싶지만 사실 전날 저녁에 된 경우에 반영되지 않기 때문에

결론적으로는 Yesterday를 사용해서 진행해야만 할 것 같다.

그 외에 추가된 데이터는 insertList에 넣어주고

key가 존재했지만 SAP에서 받아온 값에는 없는 경우에 deleteList에 넣어준 다음

LastModifiedDate로 얻어온 값들만 updateList에 넣어서 처리하면

그나마 최저 DML 작업으로 업데이트를 진행할 수 있을 것 같은데

인터페이스를 진행할 때 에러나 시간 지연은 없이 가능할 것 같다.

이것도 조금 복잡해보이지만 사실 이게 제일 간단한 인터페이스고

나머지는 Order과 PriceBook, OrderItem 등 여러개가 엮인 인터페이스들을

주고 받는 양방향 인터페이스들이기 때문에 상당히 복잡할 것 같다.

회의 내용을 간단히 정리한 다음

아까 진행하던 운영 배포된 내용을 다시 테스트해봤는데

자세히 보니 정확한 인터페이스 값 전송을 위해 Postman으로 발송 후 가져온 값이

‘’가 아닌 “”로 감싸져 있어서 sfdc 에러가 발생한 것이었고

다시 ‘’로 수정 후 전송하니 정상 처리되는 모습을 확인하고 고객사에 전달했다.

중간에 JS관련 질문이 들어와서 같이 확인했지만 둘 다 원인을 파악하지 못했는데

나중에 문제가 해결되고 들어보니 SFDC의 경우 이벤트 작동 위치가 멋대로 Lightning이 들어가기 때문에

event.target 같은 방식으로 값을 가져오려고 시도하면 에러가 발생할 수 있고

event.currentTarget으로 값을 가져와야 정상 작동하는 경우가 있다고 한다.

추가로 진행하는 인터페이스의 프로젝트의 경우

예전에는 바로 운영으로 올렸기 때문에 개발 환경변수 등이 없었기 때문에

인터페이스용 개발서버 환경변수들을 정의서에 정리하고

SFDC의 IP 주소값들을 같이 첨부해 메일로 발송했다.

중간에 카카오톡, 이메일 알림발송 관련 작업을 했던 곳에서 시연회가 있었는데

나는 참여하지 않지만 내가 작성한 부분에 대해 확인하기 위해 문의하셔서

해당 Flow관련해서 답변드렸다.

이후 유지보수로 들어왔던 내용을 파악하는데

여러명이 다른 경로로 요청사항을 받아서 코드가 꼬여있었기 떄문에

전체 내용을 다 파악하고 논리 순서대로 따라가서 주석 등을 복구해야 했다.

5시가 좀 넘은 시점에서 문제는 해결했지만

SAP에서 값을 수정할 수 없어서 중복생성된 데이터 처치가 곤란해졌는데

퇴근시간이 넘어버렸기 때문에 결국 따로 나가서 저녁을 먹고 추가로 진행해야 했다.

SAP에서 Key값을 통해 연결된 값이 있었지만 Key값을 변경해서 두개가 생성되었고

그 자식 레코드들까지 전부 우르르 변경된 상태였는데 SAP에서 값을 원복할 수 없었기 때문에

추가로 생성된 Key의 값에 x를 추가해서 Key의 단일성을 지킬 수 있게 만든 다음

기존의 값들을 전부 새로 등록된 Key(SAP 등록된 값)에 맞게 확인하며 매칭시켜주고

새로 등록된 레코드와 자식레코드들을 전부 지우고 SAP 인터페이스 재전송을 해보니 정상처리됐다.

8시쯤 오전에 처리한 내용 중 비정상 작동하는 부분이 있었는데

해당 부분은 서버(고객사? 고객협력사?)쪽 문제였기 때문에 같이 전달했었는데

해당 부분에 대해 의도와 다르게 작동하는 부분을 찾아줘서 고맙다는 인사를 받았고

좀전에 처리한 부분에 대해서도 감사하다는 인사를 받으니 뿌듯하게 작업을 마무리할 수 있었다.

(1).백준 9443번 Arrangement of Contest는 제목을 가지고 A부터 연속되는 글자를 Z까지 만들면 점수를 얻는 대회로

보유한 제목들을 통해 얻을 수 있는 최고점을 출력해야 하는 문제였다.

A~Z까지의 제목을 순차적으로 확인해야 했는데

객체에 담아서 Map 형태로 조회하기 때문에 조회까지는 쉬웠지만

A~Z를 일일히 치기는 귀찮아서 생각해보니 아스키코드로 대문자를 불러올 수 있기 때문에

fromCharCode()를 사용해서 A~Z까지의 글자가 객체에 있는지 확인 후 count를 증가시키는 방법으로 해결했다.

const input = `12
Arrangement_of_Contest
Ballot_Analyzing_Device
Correcting_Curiosity
Dwarf_Tower
Energy_Tycoon
Flight_Boarding_Optimization
Garage
Heavy_Chain_Clusterization
Intellectual_Property
J
Kids_in_a_Friendly_Class
Lonely_Mountain`.split('\n')

const checkMap = {}
let count = 0
for(let i = 1 ; i < input.length ; i++){
    checkMap[input[i][0]] = true
}
for(let i = 65 ; i < 91 ; i++){
    if(checkMap[String.fromCharCode(i)]){
        count++
    }
    else{
        break
    }
}

console.log(count)