전자결재 시스템 로직 구현하기
그동안 배운 내용을 바탕으로 프로젝트로 그룹웨어를 만들어보기로 했다. 보통은 ERP시스템과 같이 사용하는 경우가
많지만 한정된 시간에 만들어야 했기 떄문에 사용자의 편의성이나 유틸리티를 최소한으로 결재의 순서와 흐름을 이해하는 방향으로 구현했다.
전자결재를 구현하면서 한가지 깨달은게 있는데 코딩만 잘해서는 시스템을 만들기에 어려움이 있다.
해당 기능과 사용 목적에 대해 서도 알고 있어야 개발이 수월하다는 것.
예를들어 컴퓨터를 파는 사람이 컴퓨터의 가격, 전원을 넣는 방법, 모니터 연결 방법만 알고 있다면 그 가게는 잘 될 수가 없다. 컴퓨터를 만들진 못하더라도 안에 들어가는 부품의 종류, 호환가능한 메인보드, 렘 용량, 멈춤 시 재부팅 정도는 알고 있어야 한다는 것이다. 개발자도 내가 잘 모르는 분야에 있어서 개발을 맡았을 때에는 먼저 해당 분야에 대해
전문가적인 지식까지는 아니더라도 어느정도의 이해가 있어야 개발할 수 있다는 것을 이번 프로젝트를 하면서 깨달았다.
나는 그룹웨어를 실제로 써본적이 없어서 전자결재 시스템이 정확히 어떤 일을 하는지 몰랐기 때문에 결재 시스템의 정의부터 알아봐야했다. 전자결재는 하급자가 상급자에게 기안서를 작성하여(ex)휴가,물품 발주,프로젝트 건의 등등 회사마다 다르다) 승인을 받는 것을 전산화한 시스템을 말한다. 여기서 하급자가 올린 기안서를 검토해서 승인하는 행위를 '결재'라고 하는데 '결제'와는 다른 의미인 것을 알 수 있을 것이다.
내가 참고한 결재 시스템은 기안서에 관련된 사람을 4가지 분류로 하고 있는데
로 구분하고 있다. 여기서 상신이란 내가 작성한 기안서를 상급자에게 보고받기 위해 올리는 행위를 '상신'이라고 한다.
해당 모델을 기준으로 결재에 직접적인 권한을 가지는 사람은 결재자와 합의자이다. 참조자와 시행자는 상신된 기안서에결재 권한을 가지진 않았지만 해당 기안서와 관련이 있는 사람들을 말한다. 즉 결재 순서를 정한다면 참조자와 시행자는 배제하고 봐도 무방하다. 결재를 하는 사람이 아니기 때문에.
내가 설계한 전자결재 모델은 단순히 직급에 따라 결재순서를 고려하는 방식으로 했다. 결재순서를 정하는 방식에는
직책이나 부서 등 여러가지 고려 요소가 있겠지만 어디까지나 로직의 전체적인 흐름을 구현하려고 했기 때문에 디테일한 부분은 덜어내고 온전하게 기능이 동작되도록 하는데에 집중했다.
기본 use case diagram은 해당 사진과 같다.
결재자를 선택하려면 부서별 사원을 선택하도록 설계했는데 결재 합의 참조 시행자에 대해 해당하는 사원을 선택하고 버튼을 누르면
자동으로 input란에 들어오도록 설계했고 기안을 누르면 전자결재에 해당하는 DB로 저장되도록 했다.
여기서 실제 결재 권한을 가진 결재,합의자와 참조,시행자의 DB 테이블을 분리 했는데 이렇게하면
결재 순서를 정할때 좀더 간단하게 접근할 수 있기 때문에 나눠서 저장하도록 설계했다.
다음은 내가 작성한 기안서를 가지고 결재순서를 정하는 로직에 대해 설명하려 한다. 그전에 결재 용어에 대해 알 필요가 있는데 결재자와 합의자는 해당용어로 결재순서를 구분한다.
결재에 참여하는 결재자와 합의자만 기안서의 내용에 결재할 수 있는 권한이 있으며 결재 흐름에 따라 적합한 결재버튼이 기안서에 나타난다. 합의자는 결재자보다 결재순위에 우선순위에 있다. 합의자는 상신된 기안서에 부서간 협조 가능 여부를 승인하는 사람인데 협조가 되지 않으면 결재자가 승인을 하더라도 해당 기안을 실행할 수 없다고 생각했기 때문이다. 단 합의자간의 결재순서는 따로 구분짓지는 않아서 합의와 거부버튼만 나타나게 했다.
결재순서를 조회하는 sql문은 결재자와 합의자를 따로 나눠서 직급별로 순서를 매겨서 union으로 병합했고
top n 쿼리를 사용해서 결재 순서 넘버를 부여하는 방식으로 구현했다. 여기서 내 순서를 알아보려면
where 문을 이용해서 내 사원번호를 조회하면 rownum으로 내 순서를 알 수 있다.
결재 버튼이 나오는 트리거는 반복문과 조건을 이용해서 구현했다. 예결 기결 후결중에서 조건을 중복 만족했을때 가장먼저 나오는 버튼은 후결이다 내차례가 됐든 앞의 결재자가 예결을 했든 내 뒤의 결재자가 결재를 이미 했으면 내차례는
후결이 된다. 다음 우선순위는 기결로 했는데 구현하고나서 보니 기결과 예결은 로직을 어떻게 짜느냐에 따라 반대가 될 수도 있을 거 같다. 여기선 예결을 가장 나중 우선순위로 했다.
이런 과정을 바탕으로
내 순서에 맞는 기안 버튼이 나오게 된다.
기안버튼에 따라 결재 분류와 상태가 바뀌는 것을 볼 수가 있다.
합의자는 합의 거부버튼만 나오고 만약 모든 결재자가 결재승인을 했을경우 상태는 종결이 된다.
시행자와 참조자는 직접적인 결재권한이 없는 사람들이지만 기안서 진행사항과 디테일을 확인 할 수 있기때문에 결재버튼은 없다
전체적인 흐름은 이정도고 프로젝트를 진행하면서 느꼈던 점은
1.단순히 코딩하는 방법 뿐만 아니라 해당 기능과 사용 목적에 대해 서도 알고 있어야 개발이 수월하다는 것을 알게 됐다.
2.ERD와 USE CASE같은 사전작업을 진행할 때 신경 써서 가이드라인을 만들면 실제 코드로 구현하는 시간이 크게 단축된다.
3.자바에서 자바스크립트로는 값의 적용이 가능하지만 그 반대는 되지 않는다.
4.Git을 이용한 협업에는 가급적 같은 페이지를 같이 개발하지 않는 것이 좋다(충돌이 자주 난다)
다만 프로젝트 기간 내에 아웃풋을 내야했기 때문에 디테일적인 면이 떨어져서 아쉬운 점이 있었던것 같다. 결재우선순위 로직을 짜는데 생각 보다 시간이 오래 걸렸고 더 좋은 코드가 있었을텐데 하는 아쉬움도 있었다. 그룹웨어가 생각보다 참고할 만한 자료가 없어서 맨땅에 헤딩하는 느낌도 있었다 그래도 모르는 부분을 찾아가면서 배우는 점도 많았고 여러모로 도움이 많이 되는 프로젝트 였던것 같다. 혹시라도 그룹웨어를 구현하고자 하는 나같은 초보개발자 분들에게 조금이나마 도움이 됐으면 하는 바램이다.
사실 게시판이나 그룹웨어 로그인, 사원별 권한 적용도 있지만 그동안 프로젝트로 블로그 포스팅에 조금 소홀해져 가장 핵심기능인 전자결재를 먼저 포스팅 했고 시간이 남을때 따로 작성해보려한다.