비어 있던 정책 값

외부에 보내는 요청에 정책 코드가 필요한데 어떤 건은 그 값이 비어 있었고 상대가 거절 응답을 돌려줬다. 빈 값을 그대로 실어 보내고 있었으므로 실패는 상대 쪽에서 판정되고 있었다.

Open Table of contents

보내기 전에 막는 것과 보내고 실패하는 것

값이 비면 요청을 만들지 않고 그 자리에서 예외를 던지게 바꿨다. 보내고 실패하는 것과 안 보내는 것은 결과가 같아 보여도 원인이 드러나는 위치가 다르다.

안 보내면 상대에게 부담을 주지 않고 우리 쪽 로그에 원인이 남는다. 상대의 응답 코드를 해석해 원인을 되짚는 일이 없어지므로 조사 시간도 줄어든다.

몇 곳이 비었는지 세니 마흔 곳 남짓이었는데 최근 거래가 있는 곳만 추리니 여덟 곳으로 줄었다. 나머지는 거래가 없어 지금 당장 문제가 되지 않는 곳이었다.

수를 세는 것과 문제가 되는 수를 가르는 것은 다른 작업이다. 전체 수만 보고 급하다고 판단하면 우선순위가 왜곡된다.

원인을 나눠 보니 등록할 때 아예 받지 않은 경우가 대부분이었고 저장 과정에서 누락된 경우와 나중에 지워진 경우가 뒤를 이었다. 등록 화면에서 그 값이 필수가 아니었던 것이 근본이었다.

검증을 필수로 바꾸니 앞으로는 생기지 않게 됐고 이미 빈 여덟 곳은 직접 받아서 채웠다. 거래가 없는 곳은 거래가 시작될 때 필수 검증에 걸리므로 따로 챙기지 않아도 됐다.

요청을 보낼 때 막는 것보다 주문을 만들 때 막는 편이 앞이라 그쪽으로 옮겼다. 협력사 설정이 완료되지 않았다는 예외로 주문 생성 자체를 세운다.

앞에서 막을수록 되돌릴 것이 적다. 주문이 만들어진 뒤에 막히면 그 주문을 어떻게 처리할지가 새 문제로 남는다.

정책 코드는 원래 선택 항목이었다가 상대 공지로 필수가 된 값이었는데 우리 검증은 그대로였다. 공지를 받고도 반영하지 않은 기간 동안 빈 값이 계속 나가고 있었다.

그래서 상대 규격의 필수 여부와 우리 검증의 필수 여부를 나란히 적은 표를 만들었다. 우리 검증이 상대 요구보다 느슨하면 보내고 나서 실패하므로 규격이 바뀔 때마다 이 표를 대조했다.