비밀구분 대외비 농협 신용 신 시스템 구축 프레임웍 설계서 (F06. 개발프레임웍) 2007.08.22

목 차 1. 개요 1.1 개발 프레임웍 범위 2. EMB 설계 2.1 EMB 구성요소 1.2 개발 프레임웍 설계 방향 목 차 1. 개요 1.1 개발 프레임웍 범위 1.2 개발 프레임웍 설계 방향 1.3 개발 프로세스 1.4 디렉토리 구조 1.5 디렉토리 관리 원칙 및 권한 1.6 프로세스 흐름도 1.7 주요 Activity 및 수행조직 1.8 형상관리 1.9 무중단 통합 개발 환경 1.10 ProFrame 과 업무 DB 유저 분리 1.11 메타정보 동기화 1.12 IO 동기화 2. EMB 설계 2.1 EMB 구성요소 2.2 설계 사례연구 2.3 EMB 디자인 가이드 2.4 SM 설계 기준 2.5 BM 설계 기준 2.6 배치 프로그램 설계기준 2.7 공통함수 (Common Function) 설계 기준 2.8 서비스모듈 vs 비지니스모듈 3. 개발표준 3.1 M/W 표준 3.2 명명규칙 표준

목 차 4. C코딩 표준 4.1 C코딩 일반원칙 4.2 주석\ 4.3 상수 4.4 매크로 4.5 타입 4.6 구조체 목 차 4. C코딩 표준 4.1 C코딩 일반원칙 4.2 주석\ 4.3 상수 4.4 매크로 4.5 타입 4.6 구조체 4.7 변수 4.8 유틸리티 4.9 연산자 4.10 함수 4.11 제어문 4.12 금지함수 4.13 헤더파일 4.14 변경히스토리 4.15 Script 표준 5. 개발 환경 5.1 UNIX 디렉토리 구조 5.2 표준 검증 체크리스트 5.3 프로그램 개발절차 5.4 컴파일 환경 5.5 리소스 권한 6 통합개발툴 ( ProFrame Studio) 6.1 개요 6.2 화면구성 6.3 주요기능 7 개발지원 관리자시스템 7.1 개요 7.2 화면구성 7.3 주요기능 7.4 테이블목록

1. 개요 1.1 개발 프레임웍 범위 New Framework을 사용하여 업무 개발 시 개발/QA 조직에게 제공하는 개발/QA 환경, 개발 표준, 개발 절차 등을 정의한다. 1.2 개발 프레임웍 설계 방향 개발 환경을 프로세스 중심으로 설계하며 이행 이후 유지보수 단계에서도 동일한 프로세스를 적용하도록 설계한다.

1.3 개발 프로세스 (1) 구현 및 단위 테스트 프로세스 프로그램 편집을 완료하고 바이너리를 생성하고 테스트 완료 후 프로그램 소스 및 바이너리들을 릴리즈하는 프로세스 (2) 품질관리 및 시스템 통합 테스트 프로세스 소스 QA 또는 실행 QA를 실시하는 프로세스 (3) 적용 및 유지보수 프로세스 QA 완료된 프로그램 바이너리를 온라인(운영) 시스템에 이행하고, 유지보수하는 프로세스 설계완료 구현 및 단위 테스트 품질관리 및 시스템 통합 테스트 적용 및 유지보수

1.4 디렉토리 구조 NBSDEV NBSQAS NBSREP NBSRUN 개발환경은 개발(NBSDEV) / QA(NBSQAS) / 보관(NBSREP) Branch로 구성 NBSQAS와 NBSREP 디렉토리는 개발시스템과 물리적으로 다른 시스템에 구성되더라도 NFS (Network File System) 을 이용하여 중복관리 하지 않는다. 즉, 개발환경에서도 운영환경이 이관된 파일의 size, date 등 속성을 read만 할 수는 있도록 환경제공을 한다. 운영환경은 NBSRUN 으로 구성 각각의 시스템의 명칭은 표준화 팀의 시스템 명명규칙을 따른다. 디렉토리 구조 (전체) NBSDEV : 업무개발 조직이 구현 및 단위 테스트를 수행하는 작업디렉토리 NBSQAS : QA 조직이 품질관리 및 시스템 통합 테스트를 수행하는 디렉토리 NBSREP : 온라인(운영) 시스템에 반영되는 소스 및 관련 파일을 최종 보관하는 디렉토리 NBSRUN : 온라인(운영) 시스템의 디렉토리로 바이너리 및 실행관련 파일(SQL, SHELL) 존재 root NBSDEV NBSQAS NBSREP NBSRUN 구현 및 단위 테스트 품질관리 및 시스템통합테스트 보관 적용 및 유지보수

1.5 디렉토리 관리 원칙 및 권한 1.5.1 디렉토리 관리 원칙 1.5.2 디렉토리 권한 각 디렉토리 관리는 프레임웍 유저가 일괄 관리한다. 개발자용 계정은 필요시 별도로 발급하고 LOG 디렉토리만 접근을 허용한다. 각 세부업무 별 디렉토리는 별도로 존재한다. 각 업무 별 디렉토리에는 구현 및 테스트에 필요한 모든 하위 디렉토리가 존재한다. 각 업무 별 디렉토리 하위의 모든 파일은 일일 백업한다. (개인 홈 디렉토리는 대상이 아님) 디렉토리에서 다른 디렉토리로 이행 후 동시에 삭제함으로써 중복 소스가 존재하는 것을 방지한다. (예 : NBSDEV -> NBSQAS 이행 후 NBSDEV 의 이행된 소스 삭제함) 1.5.2 디렉토리 권한 개발조직 QA 운영조직 설명 NBSDEV Write READ (Write) - 구현 및 단위 테스트 NBSQAS 품질관리 및 시스템 통합 테스트 NBSREP (Read) 통합 테스트 완료된 버전에 대한 보관 NBSRUN 온라인(운영) 적용 및 유지보수

1.6 프로세스 흐름도 1.6.1 개발 기간 개발 프로세스 흐름도 NBSDEV NBSQAS NBSREP 개발 및 테스트 시스템 1. 개발자가 개발 완료한 소스는 PL 승인 후 품질관리 및 통합테스트를 위한 디렉토리로 이관되고, 이관과 동시에 개발용 디렉토리에서 삭제 된다. 2. 품질관리에서 통과되지 못한 소스는 재수정 요청과 함께 개발 디렉토리로 이관되고, 품질관리 디렉토리에서 삭제된다. 3. 품질관리를 통과한 소스에 대하여 종합테스트를 수행하고, 종합테스트 후 통과한 소스에 한하여 보관 디렉토리로 이관되고 (운영시스템에 반영과 동시에), 품질관리 디렉토리에서는 삭제된다. 단 종합테스트에 통과하지 못한 소스는 개발자에게 재 수정 요청과 함께 개발 디렉토리로 이관된다. 통합테스트 이전, 단위테스트 완료된 소스는 QAS 로 이행되고, QA의 역할은 소스 레벨의 QA를 실시한다. 이후 통합테스트는 QAS Branch 에서 이루어지게 된다. QAS 의 소스는 3단계로 절차로 관리된다. (소스 QA 이전 – 종합 테스트 이전 – 보관(운영) 시스템 이관 이전) NBSDEV (개발용) NBSQAS (품질관리) NBSREP (보관) 개발 및 테스트 시스템 NBSRUN (운영/유지보수) 온라인(운영) 시스템 1. PL 승인 후 2. 재 수정 3. 보관

1.6.2 온라인 운영 및 유지보수 프로세스흐름도 개발 및 테스트 시스템 온라인(운영) 시스템 NBSDEV NBSQAS 1. 개발자가 개발 완료한 소스는 PL 승인 후 품질관리 및 통합테스트를 위한 디렉토리로 이관되고, 이관과 동시에 개발용 디렉토리에서 삭제 2. 품질관리에서 통과되지 못한 소스는 재수정 요청과 함께 개발 디렉토리로 이관되고, 품질관리 디렉토리에서 삭제 3. 품질관리 및 통합 테스트를 통과한 소스는 보관용 디렉토리로 이관되고, 이관과 동시에 품질관리 디렉토리에서 삭제 ( 품질관리는 3단계 절차로 관리된다 ) 3. 보관된 소스 중 바이너리, 라이브러리, 쉘 스크립트, SQL 등과 같이 실행과 관련된 파일만 운용시스템으로 복사 4. 품질관리 통과된 소스 중 변경요건 발생한 경우 QA가 개발 디렉토리로 복사 (삭제 안함) - 개발자는 REP에 존재하는 소스에 대한 READ 권한이 없음 - NBSREP는 개발시 필요한 헤더파일과 바이너리만 READ 권한만 존재 개발 및 테스트 시스템 온라인(운영) 시스템 NBSDEV (개발용) NBSQAS (품질관리) NBSREP (보관) NBSRUN (운영/유지보수) 1. PL 승인 후 2. 재 수정 3. 보관 3. 이행 4. 수정 요건 발생시 (COPY) COPY

1.7 주요 Activity 및 수행조직 1.7.1 업무개발자 - 프로그램 편집 조직 : 업무 개발자는 설계서를 근거로 프로그램을 개발한다. - 코딩 표준 검토 조직 : 업무 개발자가 육안 및 code inspection 툴을 이용하여 표준 준수여부를 체크한다. - 바이너리 생성: 업무 개발자가 컴파일, 디버깅 후 최종 생성된 바이너리를 dlupdate 하여 반영한다. - 테스트 수행 : 업무 개발자가 테스트케이스를 작성하고 테스트케이스별로 단위테스트를 수행한다. 설계완료 프로그램 작성 테스트 수행 및 결과반영 1. 유형별 템플릿은 자동제공 2. 사양서 내용을 제공된 템플릿에 추가 3. 프로그램 작성 표준 준수 1. 테스트 대상 등록 2. 테스트 시나리오별로 테스트 수행 3. 테스트 결과반영후 프로그램 릴리즈 1. 구현대상 프로그램 유형 확정 2. 프로그램 유형별 사양서 완료 3. I/O 설계서 및 테이블 정의서 완료

1.7.2 QA조직 품질관리 수행 : QA가 이관 요청된 프로그램을 육안 및 그 외의 방법으로 변경내역을 체크한다. 같이 이관되어야 할 프로그램 목록을 체크하여 빠진 것이 없는지 체크한다. 품질관리 결과 반영: QA 는 부정 수정된 소스프로그램을 반려하고 수정을 요청한다. 비표준 코딩영역 및 누락된 이관 대상 프로그램을 개발자에게 통보한다. 테스트완료 품질관리 수행 품질관리 결과반영 1. 소스 QA 수행 2. 실행 QA 수행 1. 통과한 바이너리만 적용 2. 위반 소스/바이너리 개발자 통보

1.7.3 QA 및 운영조직 - 적용 대상등록: QA 및 운영조직이 적용대상을 등록하여 지정된 시간에 운영시스템에 반영되도록 한다. - 운용 유지보수: QA 및 운영조직은 운용 및 유지보수한다. 이관된 프로그램이 제대로 운행되는지 확인한다. QA완료 적용대상 등록 운용 유지보수 1. 즉시/시점, 신규/ 교체/삭제 등록 여부에 따라 적용대상 등록 2. 즉시/시점/신규/ 교체/삭제 등록 방법은 프레임웍 제공 1. 운용 모니터링 2. 장애시 조처

1.8 형상관리 1.8.1 형상관리 흐름도 import export 개발 시스템 QA 시스템 소스보관 운영 시스템 export 변경요건발생 import export 개발 시스템 QA 시스템 소스보관 운영 시스템 PFM_XXX DEV_XXX PFM_XXX DEV_XXX 생성 Binary 생성 Binary 생성 Binary PFM_XXX 생성 Binary 생성 소스 생성 소스 생성 Binary export import 통합개발 서버 Framework Runtime Framework Runtime 통합개발 서버 Framework Runtime 형상관리툴 형상관리툴 Studio WebAdmin Studio DB 및 소스이관 바이너리만 이관 관리화면 (ezBuilder) 관리화면 (ezBuilder)

1.8.2 형상관리 절차 형상관리 절차는 개발기  QA, QA  운영기 2단계로 구축한다. (1) 개발기 - 통합개발환경 서버, Runtime, Test Framework, WebAdmin 모두를 포함 - 업무 개발 및 소스 Generation, 테스트 - -DDEBUG 옵션적용 컴파일 (2) QA 서버 - 개발DB데이타 및 생성된 소스 보관 - 생성된 소스의 compile 환경 , 통합개발환경을 통한 소스 생성 컴파일 - Test Framework, WebAdmin 은 관리하지 않음 - 운영기 Deploy를 위한 사전작업, 형상관리 연동을 위한 서버 - -DDEBUG 옵션 없이 컴파일 하여 디버그 정보 소스레벨 무효화 처리 (3) 운영기 - Runtime만 구성 - Runtime 환경의 제어는 농협 커스터마이즈된 화면으로 한다. (ezBuilder로 작성) - 엄격한 접근 제어. 설정 및 환경추가를 위해서 정해진 절차와 프로그램을 통해서만 가능

1.9 무중단 통합 개발 환경 통합개발서버를 하나로 통합하는 경우는 개발서버를 하나로 일원화하여 패치 및 관리의 편의가 있으나 개발서버 장애가 발생할 경우 모든 시스템의 개발이 중단되는 위험이 있다. 1.9.1 개발환경 (1) 재무회계시스템의 환경과 신용신시스템의 환경설정이 달라 서로 통합할 수 없다. (2) 이후 발생되는 프로젝트는 신용신시스템에 통합하여 개발한다. (3) 개발 서버가 물리적으로 분리되어 있을 경우는 파일공유시스템을 이용하여야 한다. 1.9.2 재무회계 별도 가는 이유 - DBIO 변수명명 규칙 상이 - DBIO 물리명 명명규칙 상이 - 배치모듈 명명규칙 상이 - 배치프로그램 생성 디렉토리 상이 - 소스가 팀코드/리소스그룹에 생성 상이 개발DB Open, save ( port 8190 ) 소스생성 통합개발서버 (JEUS) WebT Test HTTP 테스트 개발자 (신용시스템) 단위테스트 신용신시스템 AP개발서버 (Tmax) 업무DB Compile, Dlupdate ( port 9941 ) Connect 유지 Log Server DBIO Unix cmd 서비스 서비스 서비스 DBIO make_sm.sh pfmdlupdate Rebuild_dbiolib.sh ... DBIO DBIO libxxxx.so … Open, save ( port 8190 ) 개발DB 통합개발서버 (JEUS) WebT Test HTTP 개발자 (재무회계) 단위테스트 회계시스템 AP개발서버 (Tmax) 업무DB Log Server Compile, Dlupdate ( port 9941 ) DBIO Telnet 접속 Unix cmd 서비스 서비스 서비스 DBIO make_sm.sh pfmdlupdate Rebuild_dbiolib.sh ... DBIO DBIO libxxxx.so … ProFrame 관리자 (일반 개발자는 telnet 접속불가)

1.10 ProFrame 과 업무 DB 유저 분리 어플리케이션 프로그램에서는 _app 유저를 사용하며 이 유저는 select, update, delete, insert 권한을 테이블의 owner에서서 grant 받는다. 운영환경도 동일하다. ProFrame Studio JEUS 통합 개발서버 jdbc Grant 모든 테이블 Synonym 생성 NBPF_APP DEV_XXX PFM_SVC Etc. NBPF DEV_XXX PFM_XXX jdbc Web Admin jdbc dbio_gen Grant PFM_XXX Synonym 생성 영업점 업무 단말 Tmax 업무서버 dbio 업무유저_APP 업무테이블 synonym PFM_XXX synonym 업무유저 업무테이블 dbio dbio Grant 모든 테이블 Synonym 생성

1.11 메타정보 동기화 1.11.1 아키텍쳐 농협메타서버 프로프레임 개발 A ( 신용신시스템 ) 농협메타 정보와 프로프레임에서 사용하는 메타정보를 일치시키기 위하여 농협메타에 정보가 등록/변경될 때 프로프레임으로 변경사항을 전달한다. 농협메타서버에서 프로프레임 JEUS 서버로 변경정보를 한다. 농협메타서버 프로프레임 개발 A ( 신용신시스템 ) 농협 메타 화면 ? JEUS 개발서버 WAS Servlet request 등록 프로프레임 메타 metaMgr 조회 농협메타 개발자 프로프레임 개발 B ( 재무회계 ) JEUS 개발서버 등록 프로프레임 메타 농협메타시스템은 프로프레임으로부터 정상응답을 받지 못 하면 일정시간 후 재시도한다. 조회

1.11.2 코딩 방법 및 오류메시지 농협메타시스템에서 메타정보를 등록할 때 프로프레임으로 변경된 메타정보를 전달해 줄 수 있도록 api를 제공한다. <농협메타에서 프로프레임으로 메타를 전달하는 방법> 오류코드 오류 메시지 101 서버IP오류입니다 102 접속 포트가 숫자타입이 아닙니다 103 접속 포트로 허용된 값이 아닙니다 111 물리명을 입력해야 합니다 112 물리명은 영문자, 숫자, '_' 문자의 조합만 가능합니다 113 물리명은128자 이내여야 합니다 114 논리명은128자 이내여야 합니다 115 필드타입은 number, string, long만 가능합니다 116 길이값이 숫자가 아닙니다 117 길이는 5 자리(99999) 이하만 가능합니다 118 long형은 18자리 이하 소수점없는 정수형만 가능합니다 119 소수점자리수가 숫자타입이 아닙니다 120 소수점자리수는 3 자리 이하만 가능합니다 121 string형은 소수점을 지정할 수 없습니다 122 123 number형은 19자리 이상 정수 및 소수점있는 수만 가능합니다 124 MetaGroup을 입력해야 합니다 125 설명은 1000자까지만 가능합니다 MetaManager mm = new MetaManager(); mm.func(“add”); mm.setPhysicalName(“cust_no"); mm.setLogicalName(“고객번호"); mm.setFieldType(“string"); mm.setLength(“20"); mm.setPoint(“0"); mm.setDescription(“유일한 고객식별번호"); mm.setTargetIpPort(“8.1.1.3”, “8190”); mm.send();

1.11.3 전달항목 숫자형일 경우 프로프레임에서 소수점이 있거나 19자리 이상인 정수이면 프로프레임메타에 number 타입으로 변경하여 등록한다. 항목명 Java TYPE 길이　 유효값 사용예 func 기능 ● CHAR 10 add, update, delete insert PhysicalName 물리명 128 opr_brc LogicalName 논리명 조작사무소코드 FieldType 타입 16 string, number string Length 길이 5 6 Point 소수점 3 Description 설명 ○ 500 프레임팀 변경사항 1.number는 19자리 이상 정수형 또는 소수점이 있는 수는 number 18이하 소수점없는 수는 long 으로 변환하여 등록 2. 메타와 프로프레임의 길이 표현이 서로 다르므로 프로프레임에서는 정수부,소수부로 분리하여 등록 ex) number(10.2) 로 입력시 number 8, 2 로 변환하여 등록 3. 메타는 Func add/update/delete 를 세팅하고 send 하면 func 에 해당하는 메소드를 call

1.12 IO 동기화 1.12.1 개요 MCA 프로프레임 개발 A ( 신용신시스템 ) 프로프레임 개발 B ( 재무회계 ) 단말, 채널통합(MCA), 코어간의 입력/출력 구조체를 동기화함으로써 개발자는 한 군데서만 IO를 정의하면 되도록 지원한다. MCA 프로프레임 개발 A ( 신용신시스템 ) iStudio화면 ? JEUS 개발서버 등록 프로프레임 메타 조회 매핑정보 개발자 프로프레임 개발 B ( 재무회계 ) JEUS 개발서버 조회 프로프레임으로부터 정상응답을 받지 못 하면 MCA에서도 등록하지 않고 rollback 처리한다.

2. EMB 설계 2.1 EMB 구성요소 2.1.1 용어 정의 II. EMB 어플리케이션 설계 Terminology 산출물 Description SM (Service Module)  TMAX TP Service 의 entry point로서 transaction 처리 단위이며 기타 모듈의 조합으로 구현 BM (Business Module) 업무 처리 로직을 포함하고 있는 업무 기능 블록으로 모듈 pool에서 관리되는 업무 재활용 단위 FM (Flow Module) 논리적 개념으로 업무 처리 흐름을 제어하는 역할을 하며 IM 과 LM 으로 구분 IM (Inner Module) FM의 한 종류이며 노드와 노드 사이에 위치하며 물리적으로 내부 static function으로 생성 LM (Loop Module) FM의 한 종류이며 반복 처리되는 경우에 사용하고 loop 종료 조건을 반드시 기술해야 무한루프 방지 VM (Virtual Module) 직접 코딩 기술이 가능한 모듈로서 재사용되지 않는 연산등 function 로직 처리에 사용되며 VM 내에서 변수선언 금지 VF (Virtual Function) static function으로 모듈 내에서 반복 사용되는 로직 처리에 사용되며 argument 직접 정의 가능

2.1.2 EMB 모듈 호출 연관도 업무기능모듈 (SM, BM 등) 사이에는 FM을 배치하여 process flow의 가시성을 높일 수 있도록 하는 것을 권장한다. Business logic 을 담고 있는 모듈이다. 모든 모듈 호출이 가능하나 BM에서 SM으로 직접 호출은 불가능하다. Edge 역할로 사용되어 노드와 노드 사이를 연결하며 모든 모듈 호출 가능하다. Leaf node 역할로만 사용된다. 따라서 다른 모듈을 호출할 수 없다. BM SM IM LM FM VM VF DBIO Granularity finer

개발자가 코딩하는 서비스 소스 example 2.2 설계 사례연구 2.2.1 수도코드( pseudo code ) typedef struct 입금_context_s 입금Context; struct 입금 _context_s { long 실명구분; long 과목구분; 적수반영_io_t 적수반영_io; }; long 입금(void) { 입금Context _context; 입금Context *context = &_context; PFM_TRY(a000_초기화(context)); PFM_TRY(b000_입력검증(context)); PFM_TRY(c000_처리(context)); if (context->실명구분 == 1) { PFM_TRY(d000_실명처리(context)); } PFM_TRY(e000_출력(context)); return RC_NRM; PFM_CATCH: if (rc == RC_END) { return RC_NRM: return RC_ERR; static long c000_처리(입금Context *context) { switch (context->과목구분) { case 1: PFM_TRY(c100_유동성처리(context)); break; case 2: PFM_TRY(c200_정기성처리(context)); default: PFM_ERR(“과목코드오류”); return RC_ERR; } return RC_NRM; c100_유동성처리(입금Context *context) DBIO : 유동성 원장 SELECT; 유동성원장->잔액 += CB입력->금액; DBIO : 유동성 원장 UPDATE; static long c200_정기성처리(입금Context *context) { DBIO : 정기성 원장 SELECT; if (정기성원장->사고신고 == 1) { 정기성원장->사고신고 = 0 } rc = dlcall(“적수반영”, &context->적수반영_io); context->실명구분 = context->적수반영_io->out->실명구분; 정기성원장->적수 += context-> 적수반영_io->out->적수; 정기성원장->잔액 += CB입력->금액; DBIO : 정기성 원장 UPDATE; return RC_NRM; 개발자가 코딩하는 서비스 소스 example 1. 단위 함수간 static call 2. 단위 함수간 context 를 통한 자료 공유 3. 단위 함수에서 ComBuf 접근 가능 4. 계층적인 처리 및 리턴구조

2.2.2 EMB 형태로 설계된 결과

2.3 EMB 디자인 가이드 모든 프로그램에는 초기화, 입력항목검증, 메인로직, 종료처리, 예외처리 의 기본형태 및 순서를 유지하여 일관성 및 표준화를 확보해야 한다. 5단계 레벨이내에서 표현한다. 초기화,입력값검증,정상종료처리,예외처리 기본 생성한다. -로직이 없더라도 형태는 유지한다. -예외처리는 정상종료되지 않은 경우 수행되는 로직 2레벨에는 IM 을 배치(예외처리는 예외) VM을 너무 작은 단위로 나누면 흐름파악이 어려울 수 있다. VM이 연속으로 나열되는 것은 지양한다. 논리명은 한글로 입력하여 가시성 높인다. 논리명이 길 경우 스페이스로 분리하여 자동 줄바꾼다. IM 하위노드가 VM 하나인 경우는 지양한다. 향후 IM은 내부 function 으로 , VM은 block으로 소스 생성된다.

2.4 SM 설계 기준 서비스는 End-user (channel) 의 실시간 요청이 필요한 프로그램 으로서 M/W 에서 관리되고 실행되는 프로그램이다. 2.4.1 온라인 프로그램의 대상 (1) End User 란 - End-user 는 고객, 텔러, ATM 등(MCA) 나 단위 시스템 (EAI) 등을 말함 - End-user 에 운영조직(op console, Job scheduler) 는 해당되지 않음 (2) 고려사항 - 기능중심으로 대상 선정하고 단품성을 지녀야 함 - 파라미터 테이블 관리, 후행/센터컷 등은 온라인 서비스로 구성 가능 - 독립적인 거래로 인식되어야 하는 경우 (반드시 별도의 업무로그를 남겨야 하는 경우) - 트랜잭션을 분리할 필요가 있는 경우 (3) 서비스모듈 - 서비스 모듈은 온라인 거래 처리를 위한 비즈니스 단위이다. ( commit/rollback의 단위 ) - 서비스모듈, 업무선후처리 에서는 컴버프를 Read, Write 가 가능하다. - SM은 업무선후처리 모듈을 가진다. - 입출력구조체는 거래코드별 지정할 수 있으며 거래코드별 서비스는 하나로 한다. 거래코드:서비스:입력구조체:출력구조체 = 1:1:1:1 관계 - 서비스모듈은 TMAX TP Service 로서 transaction 처리 단위 - 단말 등 채널과 단위시스템에서 직접 호출되는 프로그램 - 독자적인 commit/rollback 처리 단위(N-tx, 1-tx) - 연동호출되는 대상프로그램 - 거래코드에 따라 호출되는 서비스가 정해진다.

2. 4. 2 SM 의 단품성 단품성이란 고유기능을 가진 최소단위를 말한다 2.4.2 SM 의 단품성 단품성이란 고유기능을 가진 최소단위를 말한다. SM이 단품성을 가지게 될 수록 모듈의 재사용성이 높아진다. 기본기능 이외의 복합적인 기능이 추가되어 있을 때 모듈의 사용자는 모듈의 동작기능을 정확히 이해하여야 하는 어려움이 증가되므로 재사용성과 오류발생율이 높아지게 된다. 예) 입금서비스는 입금 기능만 가져야 하고 지급서비스는 지급기능만 가져야 한다. 입금과 지급기능을 동시에 가지고 있는 모듈이라면 별도의 새로운 서비스를 작성하여야 한다. 입금서비스 잘못 사용 예 지급.입금서비스 입금 초기화 지급.입금 초기화 입력검증 입력검증 지급처리 지급 지급처리 지급 원장반영 원장반영 입금 입금서비스는 순수 입금기능만 수행해야하는데 입금서비스에서 지급서비스까지 호출 사례 순수 단위기능의 입금서비스와 지급서비스를 묶어서 새로운 “지급.입금서비스” 를 별도 작성 EMB 디자인의 목표 - 모듈의 기능을 최소단위로 분할하여(decomposition) 제공될 때 개발자는 레고블럭을 조립하듯이 프로그램을 구성 - 업무 흐름 파악 용이하여 개발 및 유지보수의 비용절감 실현

2.5 BM 설계 기준 2.5.1 개요 BM은 재사용성이 가장 중요한 설계 기준이며 dlcall 되는 단위모듈로서 고유한 기능을 가진 최소 기능단위이다. 2.5.2 작성대상 - 두개 이상의 프로그램(SM, BM) 에서 호출되는 모듈 - 타팀에서 원장접근을 위해 사용하는 원장관리모듈 2.5.3 작성방법 - 너무 작은 로직을 BM으로 도출하지 않는다. ( 프로그램내에서만 재사용되는 루틴은 BM으로 도출하지 말고 Virtual Function 으로 작성한다) - BM에서는 SM을 호출하지 않는다. BM은 컴버프를 사용할 수 없기 때문에 SM호출이 어렵다. - BM의 return value 는 RC_NRM, RC_ERR, RC_END 로 한정한다. - BM은 독립적인 in/out 항목을 정의하여 필요한 값을 넘겨 받고 넘겨준다. - BM에서는 컴버프 를 직접 사용할 수 없다. - BM 에서 글로벌변수를 사용할 경우 호출하는 프로그램에서 글로벌변수를 선언하지 않은 경우에 오류가 발생될 수 있으므로 BM의 재활용성(SM,BM,BTM어디에서든 호출가능하도록)을 높이기 위하여 BM내에서는 글로벌변수를 사용하지 않도록 한다. - BM 은 FLOW + VM + VF + DBIO + RULE + 다른(BM) 으로 이루어지게 된다. - VM이나 VF를 이용하여 직접 코딩에의하여 dbio, ComBuf등 다른 모듈을 부르면 안된다. - BM은 업무 처리 로직을 포함하고 있는 업무 기능 블록이다. - BM은 모듈 pool에서 관리되는 업무 재활용 단위이다. - BM은 독자적인 commit/rollback의 단위가 아니다. - BM은 유틸리티성 function단위의 작은 단위는 아니다. - BM은 entry function은 하나만 작성한다. 나머지 함수들은 static 선언하여 내부함수로 작성한다.

2.5.4 SM과 BM 의 상호 호출 관계 (Case 1) Wrapper SM 작성 (Case 2) Wrapper BM 작성 BM에서 SM을 호출할 경우 순환구조에 빠질 수 있기 때문에 원칙적으로 금지한다. BM에서 SM을 호출하면 다시 SM이 다른 프로그램을 호출하게 되는 경우가 발생될 수 있다. BM역시 최소기능단위로 분할된 말단노드일 때 재사용성이 높아진다. 필요에 따라 Wrapper 모듈을 작성하여 타팀에 제공해야 되는 다음의 두가지 경우가 있다. Wrapper BM에서만 SM호출을 허용한다. (Case 1) Wrapper SM 작성 재사용되는 모듈일 경우 BM 으로 작성한다. 다음과 같은 경우에는 wrapper SM을 별도 작성하여 제공한다. 1. DB instance 를 다르게 사용하는 SM 이 호출하게 될 경우 ( ex. 계좌거래내역 조회 ) (Case 2) Wrapper BM 작성 n-tx로 호출되어야 하는 경우는 SM으로 작성한다. 다음의 경우에는 wrapper BM 을 별도 작성하여 제공한다. 1. 모듈에서 이를 호출해야 하는 경우 ( ex. 채번 ) 수신 계좌 거래내역 조회 모듈이 있다고 하면 채번과 같은 경우 N-TX 거래가 되어야 하기 때문에 SM을 작성하여 제공한다고 하면 수신 SM 거래조회BM 뱅킹 외환BM 수수료BM 채번SM BM이 SM을 호출할 수 없다고 가정될 때 호출하는 비즈모듈이 순차적으로 SM으로 작성되어야 하는 불합리가 발생된다 똑같은 모듈이라할 지라도 호출하는 SM에 따라 접속 DB가 달라지므로 대행 에서는 뱅킹쪽의 거래내역BM을 통해서 거래조회가 불가능 대행 SM 거래조회BM 뱅킹 외환SM 수수료SM 채번SM 이런 경우에는 거래조회BM 담당자는 거래조회BM을 호출하는 SM 을 별도 제공 이런 경우에는 채번SM 담당자는 채번SM을 호출하는 채번BM 을 별도 제공 거래조회BM 거래조회 SM 대행 SM 뱅킹 채번BM 채번SM 외환BM 수수료BM 이런 경우에는 wrapper SM을 tpcall 한다. 이런 경우에 한하여 BM에서 SM을 호출하는 것을 허용하며 채번BM 이 채번SM을 호출할 때는 VM 에서 직접 코딩으로 DlCall 한다.

2.5.5 라이브러리 생성 원칙 .so 로 생성되는 라이브러리 일반적인 기준 - 라이브러리 변경 시 해당 라이브러리를 LINK하는 모든 서버 재 기동 필요 (DLCALL 제외) - 하나의 라이브러리는 하나의 호출함수와 하나의 입력 파라미터, 하나의 출력 파라메타를 갖는 것을 원칙으로 한다. 단, 업무와 상관 없고 변경이 발생할 확률이 적은 경우 여러 호출함수를 묶어 하나의 라이브러리로 생성하고, DLCALL 하지 않다. ex) 프레임웍의 utility 등 공통 모듈 프로그램은 변경시 여러 프로그램에게 영향을 주고, 다른 프로그램도 모두 테스트되어야 하므로 공통모듈 변경시 기존과 동일한 INPUT 에 대하여는 동일한 OUTPUT 을 주어야 하고, 변경 및 추가 기능에 대하여는 별도의 function code 로 정의하여 제공한다 - 온라인과 배치 모두 호출 될 수 있으므로 각 프로그램의 특화된 내용을 포함하지 않는다. [예 : M/W API / ComBuf 구조체 등] - ComBuf 구조체의 item 항목을 넘길 필요가 있는 경우 해당 item 항목을 직접 넘긴다. 모듈의 input/output에 포인터 변수 사용금지 이 기종 DBMS 또는 각 업무 팀간 DB user가 달라져서 호출하는 프로그램의 DB user 권한이 호출하는 팀의 DB access 권한이 없는 경우 온라인 서비스로 작성 되야 함

2.6 배치 프로그램 설계기준 2.6.1 배치 프로그램의 대상 2.6.2 배치 프로그램 작성원칙 운영조직이 업무 요건에 따라 정해진 시간 또는 필요시 수행되는 프로그램 주로 일괄처리를 필요로 하는 프로그램 Job scheduler, op console 등 Batch 실행 인터페이스를 통하여 실행되는 프로그램설정 2.6.2 배치 프로그램 작성원칙 프레임웍 자동 처리 부분 DB 접속 배치 실행 히스토리 관리 프로그램 실행은 쉘 스크립트 작성하여 실행한다. 작업 스케줄링은 자동화 도구에 등록한다. 에러처리 및 로깅처리는 프레임웍 표준 API를 사용한다. Loop 속 DML 작업시 주기적으로 commit 처리를 해 줘야 한다. ( 매 1000건 마다 commit 권장 ) 2.6.3 Data File 처리 Data file 위치: 쉘 스크립트에서 전달 받으며 절대경로로 전달 된다 Record layout : fixed format 및 delimiter 사용여부는 프로그램/업무성격에 따라 적합한 형태 결정

2.7 공통함수 (Common Function) 설계 기준 2.7.1 작성대상 공통함수는 dlcall 되는 대상이 아니기 때문에 로직이나 입출력항목의 변화가 없는 경우에 한한다. 2.7.2 작성방법 - 공통함수는 업무팀의 지정된 공통담당자만 개발한다. - dlcall 대신 일반 함수call 되는 단위 함수이다. - 공통함수는 하나의 파일에 여러 개의 함수가 포함될 수 있다. - 로직의 변경이 없는 최소한의 기능을 하나의 함수로 작성한다. - pool에서 끌어다 사용할 수 없고 VM 에서 직접 코딩으로 호출한다. - 개발자를 위한 api 사용매뉴얼이 필요하다. - 업무개발자가 직접 개발해서는 안되며 필요시 업무공통담당자를 지정하거나 프레임팀 요청한다. - 호출시 PFM_TRY 로 감싸지 않으며 return value는 다양할 수 있다.

2.8 서비스모듈 vs 비지니스모듈 서비스모듈(SM)은 서비스처리의 기본 단위이며, 비즈니스모듈(BM)은 기능 블록화된 업무 모듈로서 이를 조립하여 서비스 모듈이 구성할 수 있다. 구 분 서비스 모듈(SM) 비즈니스 모듈 (BM) 입출력데이터 전달 ComBuf를 통해 전달 (M/W buffer) 모듈 인터페이스를 통해 전달 ( C 포인터 Argument ) 작성 기준 창구단말 등 채널에서의 직접 호출됨 2개 이상의 모듈(SM,BM)에서 호출되어 사용 호출되는 위치 서비스프레임 서비스모듈 또는 비즈니스모듈 로깅 이미지로깅, 서버로깅, commit/rollback의 단위 독자적인 로그파일은 없으며 호출한 서비스의 로그에 남음 생성 Binary Library (.so)

3. 개발표준 3.1 M/W 표준 3.1.1 서버 환경설정 M/W 표준에 대한 모든 결정은 농협 시스템팀의 M/W 관리정책에 따라 결정한다. 프레임웍 팀 지원 내용 XA, Non-XA dependant 한 부분은 프레임웍에서 control 함으로써 개발자의 소스 수정 없이 변경이 가능하게 한다. 업무팀 및 시스템팀 요청시 Non-XA와 XA 서버를 구분하여 서버를 build 하는 방법 및 makefile을 제공 서버그룹 설계 방침 업무 분류, DBMS/트랜잭션 처리 단위를 고려한다. (소문자) 형식 : sv_업무구분(2자리)_000(일련번호) 예) : sv_gy_001 개발단계 서버 구성 모든 서버는 XA로 구성함을 원칙으로 함 서버와 서비스는 1:1 로 작성하여 테스트 편의를 도모하고, POD서버로 구성한다. 최종 종합테스트 단계에서 Non-XA 대상서버를 Non-XA 로 build 하여 종합테스트를 시행하고 최종 결과를 토대로 Non-XA 사용여부를 결정한다. 단, 반드시 트랜잭션을 분리해야 하는 서버는 시스템팀의 승인 후 Non-XA로 작성가능 한다. 개발단계시 서버명명규칙  TCS서버 : T+서비스명, UCS서버 : U+서비스명

3.1.2 서버그룹 설계 고려사항 업무 팀 관리측면에서 여러 업무가 하나의 서버에 구성되는 것을 지양한다. DBMS / 트랜잭션 단위 DB User 별 단위로 XA, Non_XA를 구분하여 설정한다. 대량 data 처리용 서비스 및 장시간 처리가 필요한 서비스는 별도 서버 그룹으로 분리한다. H/W 결정후 결정 할 사항 부하조절(Load Balancing) 장애대책(Backup) Tightly coupled 방식 사용 (1TX에서 DB Lock 방지) 항 목 내 용 기타 업무분류 업무분류 단위로 구분 Back-Up / Load Balancing M/W Back-Up / Load Balancing 단위 Database Database Vender / Instance / User 단위 XA Transaction Transaction 처리를 DBMS(RM)에서 담당 2PC 가능 Non-XA Transaction Transaction 처리를 User가 Define 함

3.1.3 서버 설계 고려사항 XA 와 Non-XA 구분 거래에 대한 빈도 거래량이 많은 서비스는 일정 개수(5~10)를 같은 서버로 구성하여 서버 개수로 부하를 조절한다. 빈번하지 않는 서비스는 업무 기준으로 여러 서비스를 묶어서 구성한다. 거래에 대한 소요시간 소요시간이 긴 서비스는 별도의 서버로 구성 서비스 연동 여부 ( 연동되는 서비스를 같은 서버로 구성할 경우 순환호출로 lock이 걸릴 수 있으므로 동일한 서버로 구성하지 않는다 ) DB Instance가 단일한 경우 또는 조회성 업무나 2PC(Phase Commit)등을 요구하지 않는 경우에는 기본적으로 Non-XA 형태로 프로그램 개발 고려 구 분 XA Non-XA 트랜잭션 TP-Monitor(TM) User Define 장점 2PC(Phase Commit) 가능 프로그램이 간단 이기종 DB와 연계 가능 속도가 빠르다 장애발생 가능성이 적으며 오류조치가 간단하다 System Resource를 적게 차지한다 단점 수행속도가 느리다 System Resource를 많이 차지한다 장애 발생시 오류조치가 어렵다 2PC(Phase Commit) 불가하다 Transaction을 사용자가 책임진다 대상 (예) 입 / 지급 서비스 거래내역 조회

3.1.4 서비스 설계 고려사항 기능 위주의 거래 별 서비스 설정한다. Service 의 Depth (tpcall/tpacall) 를 최대한 짧게 한다. (2~3 단계를 넘지 않게 한다) Non-XA로 작성되는 서비스의 경우 Transaction 처리는 Service 내에서 완료해야 한다 Service time-out 시간을 고려해야 한다. 개발 및 운영단계의 서비스 명은 변경하지 않고 동일하게 가져간다. 서비스 설정 예시 어플리케이션 서버 명 (운영 단계) 유형 분류 서비스 서비스명 수신 sv_sv_001 TCS SVSV2014R0 부도조회 ″ SVSV2013I0 미결제 어음내역조회 sv_sv_002 SVSV3099R0 ……… 여신 nl_gs_003 NLGS1366R0 고객금융지정어음조회 NLGS1368R0 매출어음대상조회　　 nl_gs_004 NLGS1033R0 여신원장변경

3.2 명명규칙 표준 3.2.1 업무코드 표준 업무코드는 업무코드(2자리) 와 세부업무코드(2자리) 로 구성되며 표준화팀의 업무분류약어 체계를 따른다. 업무코드와 업무세분류코드를 기준으로 프로그램, 거래코드, 구조체 등이 명명되므로 표준을 준수하는 것이 중요하다. 3.2.2 리소스그룹 리소스그룹은 업무구분(2)+세부업무구분(2) 으로 명명한다. 리소스그룹별로 서버 디렉토리에 소스가 구분되어 생성된다. 권한관리를 리소스그룹별 관리될 수 있도록 팀명과 동일하게 명명한다. 3.2.3 거래코드 거래코드는 입력되는 전문의 유형에 따라 부여되며 거래코드가 결정되면 수행되는 서비스는 반드시 하나로 결정되어져야 한다. ○ 거래코드 명명규칙 : 서비스명과 동일 - 서비스명 : 프로그램 명명규칙에 따른다. ○ 하나의 서비스에서 처리하는 거래의 성격을 다르게 정의할 필요가 있는 경우 사용한다. ○ 거래코드별로 시스템선처리, 업무선처리에서 거래제어가 적용됨을 고려하여 설계한다. ○ 거래코드, 서비스명, 입출력 구조체는 1:1:1 관계로 명명한다. ○ 등록/수정 거래와 조회거래는 별개의 거래번호와 서비스로 분리할 것을 권장한다. 예) 화면번호 : 0123 (0123 : 화면번호) 처리프로그램 : GYHC0123R0 거래코드 : GYHC0123R0 입력구조체 : GYHC0123R0_IN 출력구조체 : GYHC0123R0_OUT

서비스명 H G A P 2 5 R 3.2.4 서비스모듈 명명규칙 업무구분(2) 세부 업무분류(2) 화면식별번호(4) 식별자(2) 예) 회계관리 (HG) 예) 중앙회 회계관리(AP) 예) 화면번호(2550) 예) 조회 (R) + 번호 (0) 등록/수정(I) 삭제(D) 팝업(P) 번호 : 0 ~ Z 서비스명 대문자로 작성 H G A P 2 5 R 1 2 3 4 5 6 7 8 9 10 항목 명명규칙 예시 서비스모듈명 서비스명 HGAP2550R0 거래코드 서비스명 과 동일 입력구조체 거래코드 + ‘_IN’ HGAP2550R0_IN 출력구조체 거래코드 + ‘_OUT’ HGAP2550R0_OUT 서브구조체 거래코드 + ‘_IN/OUT’+_SUB’ + 일련번호(2) HGAP2550R0_IN_SUB01

모듈명 m h g a p s l e 3.2.5 비즈니스모듈, 배치모듈의 명명규칙 구분자(1) 업무구분(2) 세부 업무분류(2) 설명 및 확장자(10) 예) 모듈 (m) 배치(b) 쉘(s) 데몬(d) 예) 회계관리 (hg) 예) 중앙회 회계관리(ap) 예) 테이블 약어 포함 용도 기술 (최대 10자리) m h g a p s l e 모듈명 소문자로 작성 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 항목 명명규칙 예시 입력구조체 모듈명 + ‘_in’ mhgapsample_in 출력구조체 모듈명 + ‘_out’ mhgapsample_out 서브구조체 모듈명 + ‘_in/out’+_sub’ + 일련번호(2) mhgapsample_in _sub01

3. 2. 6 DBIO 맵의 명명규칙 DBIO 는 하나의 맵이 하나의 DBIO모듈로 생성된다 3.2.6 DBIO 맵의 명명규칙 DBIO 는 하나의 맵이 하나의 DBIO모듈로 생성된다. SQL 아래의 유형에 따라 4가지로 타입을 갖는다. DBIO 맵 이름은 소문자로 구성한다. 쿼리 type(1) 실행 type(1) 일련번호(3) 예) view (v) persist(p) execSQL(e) dynamicSQL (d) 예) select (s) fetch(f) insert(i) update(u) delete(d) 예) 5번째 (005) 001 ~ 999 table_ID _ v s 5 일련번호 000 은 dwio에서 기본쿼리맵으로 사용됨 DBIO 맵명 소문자로작성 1 2 3 4 5 유형 설명 Persist 단일테이블에 대한 SELECT/UPDATE/INSERT/DELETE의 기능을 수행 View Persist에서는 지원할 수 없는 여러 테이블에 대한 JOIN등의 SELECT를 수행 ExecSQL View 에서 지원할 수 없는 INSERT/UPDATE/DELETE에 대한 복잡한 질의문 DynamicSQL 실행 시에 SQL이 변경될 수 있는 Dynamic SQL로 DBA 승인 후 사용 가능

4. C코딩 표준 4.1 C코딩 일반원칙 4.1.1 개발자 직접 코딩시 일반원칙 4.1.2 명명규칙 일반원칙 code는 되도록 100 column 이내에 작성한다. Indentation 단위는 space 4byte 로 한다. 여러 줄에 걸쳐 문장을 쓰는 경우는 space를 이용하여 left align을 맞춰 준다. 개발자가 직접 코딩할 수 있는 부분은 VM, VF, Module 진입조건, 예외처리 등이다. 4.1.2 명명규칙 일반원칙 변수, 함수, 타입, 파일의 이름은 소문자로만 구성한다. 상수, macro 함수의 이름은 대문자로만 구성한다. 여러 단어로 구성되어 있고 단어를 명확히 구분해 줘야 할 때는 underscore(_)를 사용한다. Identifier(변수)의 이름은 Hungarian notation을 사용할 수 있다. 변수/함수 이름은 긴 단어 혹은 몇 개의 단어를 약어집에 등록된 약어를 이용하여 축약하여 사용할 수 있다. 함수명은 동사로 시작한다. 변수선언은 함수시작 바로 다음에서 한다. (VM 에서 변수 선언 금지) /* 여러 줄로 작성하는 경우 space를 이용하여 indentation (left align) 을 맞추어 줌 */ if ( (flag_a == 1) && (flag_b == 2) && (flag_c == 3) { /* 여기서부터 소스 작성 */ }

4. 2 주석 ○ 개발자가 작성하는 Comment는 C 형식(/. …. /)만 이용한다 4.2 주석 ○ 개발자가 작성하는 Comment는 C 형식(/* … */)만 이용한다. ○ 한줄 주석 “//”는 프로프레임에서 생성한 주석에만 사용한다. ○ 모든 함수의 body 앞에는 미리 정의된 형태의 comment 를 삽입한다. ○ function body 의 특정 부분에 대해 comment 를 달 때는 위 한 줄을 띄워 준다. ‘else {‘ 바로 밑에 적는다거나 하여 comment 바로 위가 비어 있다면 ○ 띄워 줄 필요가 없다. ○ comment의 indent도 comment 가 설명하고자 하는 부분의 indent와 일치시킨다. ○ box 형태의 주석은 첫 줄은 비우고, ‘*/’는 마지막 comment의 오른쪽이 아닌 그 다음 줄에 달도록 한다. /* 한줄 주석인 경우 */ // /* *********************************************************************** * 박스형태의 주석 * 주로 function 주석에 사용하고 function등을 구분하기 위하여 사용한다. * 위아래 구분이 될 필요가 있는 경우 사용 *************************************************************************/

4.3 상수 4.3.1 작성 방법 대상 (#define 을 이용하여 정의하는 상수) 4.3 상수 4.3.1 작성 방법 대상 (#define 을 이용하여 정의하는 상수) 여러 함수 또는 프로그램 내에서 공유가 필요한 값 runtime이 아닌 compile 시기에 반영되어야 하는 값 명명규칙 명칭은 대문자로만 구성한다. 상수의 명은 아래의 항목에 해당하는 유형을 찾아 Prefix로 이용하거나 아래 항목을 조합하여 유형을 명시하여 준다. 파일명 또는 업무명을 반영하여 동일 상수가 중복 정의 되는 것을 막는다. 항목 (유형 prefix) 리턴 값 : RC_ 로 정의 변수의 길이 : LEN_ 로 정의 최대, 최소 값 : MAX_ , MIN_ 로 정의 횟수 : CNT_ 로 정의 고유명 : 기타 고정 값 중 가독성과 유지 보수시 편의성을 높이기 위한 값 (기관번호등) 구조체 출력 : PRINT_ 로 정의 작성 방법 define문으로 여러 개의 상수를 정의할 때에는 왼쪽을 가지런히 맞춘다. 여러 개의 순차적인 상수 값을 정의하는 경우는 define문 대신 enum type을 이용하여 디버깅시의 편리를 도모한다.

4.3.2 상수 정의 각 팀 별 공통 상수 : 각 팀 별 공통상수가 필요한 경우 작성 헤더파일 명칭 : 업무코드명 + Const.h 예) svsvConst.h (예 : 수신공통팀에서 공통상수를 정의해야 하는 경우) 업무구분명을 정의하는 상수명의 prefix로 사용해야 한다. 예) SVSV_YOGUBUL 프레임웍에서 제공하는 상수는 업무구분명을 prefix로 사용하지 않는다. 예) LEN_DATE 업무팀별 상수파일은 업무팀별 공통담당자를 지정하여 작성하고 관리하도록 한다. 테이블의 필드 값 상수 : 테이블에 대한 상수 정의가 필요한 경우 헤더파일 명칭 : tablename_const.h 테이블 명을 상수명에 반영한다. 프로그램간의 공유가 필요한 상수 : 헤더파일 명칭 : 프로그램의 interface header (프로그램명.h) 프로그램명(파일명)을 상수명에 반영한다. 프로그램 내부의 함수간 공유가 필요한 상수 프로그램 내부(소스)에서 정의 프로그램 명을 반영하는 것이 원칙이나, 프로그램 명을 생략하는 것도 가능하다. 하나의 함수에서만 사용하는 상수 #define으로 정의 하지 않음 (값 직접 기술) : 주석으로 상수 내용 설명

4.3.3 상수정의 예제 /* pfmConst.h 참고 */ /* 리턴함수 관련 상수 정의 */ #define RC_NRM 0 /* 정상 */ #define RC_ERR ( RC_NRM - 1 ) /* 에러 */ #define RC_NFD ( RC_ERR - 1 ) /* 데이터 not found */ #define RC_DUP ( RC_ERR - 2 ) /* 데이터 키 중복 */ . . . /* svsyConst.h */ /* 수신공통에서 정의하는 헤더파일 */ /* 예 : 상품구분을 위하여 정의한 상수 */ #define SVYG_YOGUBUL 1 /* 수신의 요구불 상품 */ /* 예: MSDCHANDO01.h 라는 모듈 인터페이스에서 정의하는 상수 */ /* 변수의 길이나 최대값 횟수를 지정하는 #define LEN_MSDCHANDO01_NAME 10 /* NAME 변수의 길이 */ #define MAX_MSDCHANDO01_AMT 100000000 /* 최대 금액 */ #define MSDCHANDO01_FLAG_ONLY_CHECK 1 /* 필드의 변수로 사용할 Flag */

4.4 매크로 4.4.1 매크로 정의 대상 (#define 을 이용하여 정의하는 함수 또는 변수) Compile 시점에 선택적으로 정의 또는 무효화(nullification) 시키기 위한 것 __inline 정보가 필요한 것 개발 편의성 및 가독성을 높이기 위하여 제공되어야 하는 것 항목 구조체 디버그 메시지 출력 : PRINT_STRUCTNAME(*ptr) 항목 체크 : CHECK_ 로 정의 변수 값 : 변수명의 대문자 값 ComBuf 항목 변수 input / output 구조체 변수 : IN, OUT 또는 PGMNAME_IN /_OUT 으로 정의 table 구조체 변수 정의위치 해당 구조체 또는 변수가 정의 선언된 곳에서 기술한다. (소스 또는 헤더파일) 매크로만을 정의한 별도의 헤더파일을 작성하지 않는다 정의방법 매크로 명은 파일명을 추가하여 명칭이 중복되는 것을 방지한다 단, 프로그램 내에서 정의하여 사용하는 매크로의 경우 프로그램 명을 생략할 수 있다 do { } while(0) 을 이용하여 [;] 을 강제화 한다 매크로는 영문 대문자 및 ‘_’로만 선언한다. 구조체는 포인터형으로 선언한다. Ex) #define CUST (&context->TB_NB_CUST) 고려사항 : 매크로가 변경되면 해당 매크로를 사용하는 프로그램은 재 컴파일 되어야 하므로, 여러 프로그램에서 사용되며 변경이 발생될 가능성이 있다면 가능한 함수로 작성하여 사용한다.

4.4.2 매크로 정의 예시 /* 매크로의 대상 */ /* __inline 되어야 하는 정보가 필요한 경우 불가피하게 매크로 사용 필요 */ #define PFM_DBG(...) mpfm_dbg('D', __FILE__, __func__, __LINE__, __VA_ARGS__) /* 매크로 정의 방법 */ #define PRINT_STRUCT_NAME(p_buff) do {\ PFM_DBG ("===============================================================");\ PFM_DBG (" PRINT STRUCT NAME "); \ PFM_DBG ("field01 [%-.100s]", (p_buff)->field01); \ PFM_DBG ("field02 [%ld]", (p_buff)->field02); \ PFM_DBG ("field03 [%ld]", (p_buff)->field03); \ PFM_DBG ("==============================================================="); } while(0) /* 매크로 사용방법 */ PRINT_STRUCT_NAME(&struct_name); /* ; 를 사용해야 함 */

4.5 타입 type에 unsigned, signed와 같은 것을 사용하지 않는다. 가급적 long, char [], PfmNumber type만을 사용한다. 사용을 제안하는 타입 float, double, long double, pointer형 은 가급적 사용하지 않는다. 19자리를 넘는 정수형 변수는 PfmNumber를 사용한다. DBIO, ProMapper, Studio 에서 정의 시 사용하는 타입 string ( char [] ) : 문자열의 정의 PfmNumber(number) : 금액이나 비율처럼 소수점이 있는 변수 long : flag나 금액과 관련이 없는 숫자 변수 char 한자리와 double, float, pointer 는 ProMapper 와 DBIO 헤더파일에서 사용할 수 없다. unsigned int var; /* 가급적 사용하지 않는다. */ int var; /* 가급적 사용하지 않는다. */ char flag; /* 가급적 long type 으로 사용한다. */ long flag; /* flag로 숫자만 사용하는 변수 */ PfmNumer num_var; /* 금액 또는 실수 형의 숫자 */ char str[100+1]; /* 문자 */

4.6 구조체 4.6.1 구조체 일반 - enum 타입은 _e, struct 타입은 _s 로 끝낸다 - 구조체의 typedef 는 구조체 정의와 동시에 한다. - 하나의 구조체는 하나의 타입만 정의 해서 사용한다 (중복정의 사용 금지) - 구조체의 명칭은 프로그램 명을 반영하여 정의 한다. - 프로그램에서 고유하게 존재하는 context 구조체는 programContext 로 정의 하여 사용한다 - 구조체 신규 생성시 논리명은 한글로, 물리명은 영문으로 명명한다 - 모듈(SM, BM)의 입력구조체의 논리명은 ~_입력, 출력구조체는 ~_출력으로 명명한다. - 구조체 속의 구조체를 include 할 경우는 include 된 구조체의 물리명은 sub 로 한다. /* 구조체 정의 방법 */ typedef struct { char field01[LEN_FILENAME_FILED01 + 1]; /* 필드 한글명 */ long field02; /* 필드 한글명 */ } filename_in_t ; (작성예) SFFC8300R0_IN *input; /* 입력구조체 */ SFFC8300R0_OUT *output; /* 출력구조체 */ } SFFC8300R0Context;

4.6.2 모듈의 IN/OUT 구조체 모듈의 인터페이스 구조체를 설계할 때는 최대한 모듈의 재사용성과 독립성을 보장할 수 있도록 고려해야 한다. (1) 포인터형 변수 선언 금지 - 포인터 변수 : 구조체포인터를 넘기게 될 경우 모듈에서 사용되는 항목이 명확히 드러나지 않기 때문에 사용을 금지한다. - 컴버프 포인터 : 컴버프항목 중 모듈에서 사용되는 항목을 선택적으로 전달하여 모듈에서 사용하는 항목을 드러나도록 한다. (2) Available Data Type - 재사용성과 이식성을 위하여 사이즈가 지정된 char 와 PfmNumber, long 형만 사용 double, float, int, char 는 사용하지 않음 - 소수점있는 숫자는 PfmNumber 형을 사용 ex) PfmNumber inpamt; - Non Framework 시스템과의 인터페이스용 구조체의 숫자는 fixed length의 char 형을 사용 ex) char sndamt[20]; - 비록 한글자라도 string 형으로 선언 ex) char end_yn[1]; (3) 변수명 - 구조체의 항목명(변수)은 모두 meta 시스템에 등록 후 사용

4.7 변수 변수는 함수의 시작 부분에만 정의 하여 사용한다. - VM 에서 변수를 선언하여 사용하는 것은 금지한다. - 매크로 내부에서 변수 선언은 허용한다. 변수 선언과 동시에 초기화 또는 default 값을 설정한다. pointer 변수 선언 시에 ‘*’는 변수 바로 앞에 위치시킨다. 한 줄에 여러 type의 변수를 선언하지 않는다. 전역 변수는 가급적 사용하지 않는다. 필요한 경우 Context에 선언하여 사용한다. 전역 변수의 이름은 반드시 ‘g_’로 시작하여 지역 변수와의 충돌을 피하고, 전역변수가 아닌 변수는 g_로 시작하는 이름을 사용하지 않는다. 전역변수는 static 변수로 선언하고, 외부 파일에서 공유사용하지 않는다. 지역변수는 Inner Module에만 선언하여 사용한다. (Virtual Module에서 변수를 선언하지 않는다) 구조체 변수명은 가독성을 위하여 구조체 정의명과 동일하게 명명한다. looping variable 은 가급적 ix, iy, iz 등을 사용하고 한글자 변수는 사용하지 않는다. 변수명은 반드시 2 문자 이상이어야 한다. 함수의 return 값을 받는 변수는 rc라는 이름을 사용한다. rc 변수는 반드시 long type 으로 선언한다. 프로그램 context 구조체 포인터를 나타내는 변수는 context라는 이름을 사용한다. /* 예 : 변수 정의 방법 */ long rc = RC_NRM; /* return code 는 rc 로 정의하고, default 값 할 */ pgmnameContext context; /* context 변수는 context 라는 변수명을 사용한다. */

4.8 유틸리티 II. EMB 어플리케이션 설계 (1) Number type 연산 함수 (1) 18자리 이하 소수점 없는 숫자만 long type으로 선언한다. (int type 은 사용하지 않는다) (2) 그 외에 모든 numeric type은 프로프레임이 제공하는 PfmNumber type만을 사용한다. (3) PfmNumber type의 연산은 반드시 프로프레임에서 제공하는 number API를 사용해야 한다. 예) PfmNumer v, x, y; long rc; rc = pfmNumberAdd(&v, x, y); /* v = x + y */ (2) Function Prototype long function_name(destination, source, length, format) 형태를 일반으로 한다. 해당 프로그램의 헤더파일에 선언하여 호출되기 전에 prototype 이 선언되도록 한다. (3) Return Value 기본적으로 성공/실패에 따라 RC_NRM/RC_ERR 을 return value 로 한다. pfm*Is*() 형태의 함수는 TRUE/FALSE 를 return value 로 한다. (4) 유틸리티 종류 유틸리티 API는 일자 및 시간 관련 함수(DateTime utility), 숫자 관련 함수(Number utility) 및 문자열(String utility) 3종류로 제공되며 이 외에 크기 비교 및 에러/디버그 관련 매크로가 제공된다. 농협에서 기존에 사용하던 유틸리티로 프레임에서 관리하며 사용할 수 있도록 함께 가이드한다.

4.9 연산자 일반적인 연산자의 앞 뒤는 한 칸씩 반드시 띄어 준다. 축약형 연산자는 사용 가능하다. 연산자가 혼용된 경우는 괄호를 이용하여 명확하게 우선 순위를 표시하여 준다. comma‘,’ 연산자 뒤에는 반드시 한 칸을 띄운다. Type casting 연산자 이용 시에 pointer 를 사용할 경우는 ‘*’ 앞에 한 칸을 띄어 준다. if 문이나 대입문과 같이 수식이 길어져서 두 줄로 나누어야 하는 경우는 연산자를 중심으로 왼쪽과 오른쪽 subtree에 해당하는 부분으로 나누어지도록 하며 우선순위가 낮은 연산자를 중심으로 나누며 오른쪽 subtree에 해당하는 부분이 연산자를 가지고 다음 줄에 분리되며 인덴테이션의 수준은 연산자의 우선순위를 반영하도록 기술한다. /* 축약형 연산자 : 사용가능 */ a += 10; /* a = a + 10; */ a++; /* a = a + 1 */ /* pointer를 사용한 casting 시 (type *) 형태로 정의 */ target = (char *) source; /* 연산자가 혼용된 경우 : () 를 이용하여 우선순위 표시 */ if ( (flag_a == 1) && (flag_b == 2) && (flag_c == 3) ) { }

4.10 함수 라이브러리와 같이 일반 사용자가 호출할 수 있는 함수와 호출할 수 없는 함수가 공존하는 프로그램에서는 호출할 수 없는 함수를 static으로 선언한다. (1) Entry function (외부 호출되는 함수 명칭) dlcall할 때 호출되는 함수로서 프로그램명과 동일하게 명명하고 static 으로 선언하지 않는다. 모듈 내에서 entry function은 하나만 존재해야 한다. (2) 내부(static)함수명칭 a000_xxxxxxxx () 과 같이 명명해야 하며 EMB 디자인상에서 IM(Inner Module)이 내부static함수로 소스생성이 되므로 IM의 function name이 내부(static) 함수명칭이다. static 함수에 종속되는 함수는 a000_ -> a100_ -> a110 -> a115 등으로 명명한다. 같은 level 에서는 0~9, a~z 까지의 순서로 적용한다. 예 : a000 -> a100 -> a200 -> … -> aa00 -> ab00 -> … -> az00 Virtual function 과 같이 호출되는 위치가 여러 곳인 경우 x000, y000 를 이용하여 정의할 수 있다. (3) 함수 prototype ANSI Function Prototype 형태로 선언하여 사용한다. function prototype은 소스에서 호출되는 function 순서, 즉 종속되는 함수가 호출하는 함수 밑에 나오도록 작성한다. Function protoitype은 함수가 호출되기 전에 선언되어야 한다. /* function prototype */ static long a000_init_proc (pfmcbuf_t *cb, stpl1010aContext *context); static long b000_input_data_validation (stpl1010aContext *context); static long b100_xxxx_validation (stpl1010aContext *context); static long b110_xxxx_validation (stpl1010aContext *context); static long b120_xxxx_validation (stpl1010aContext *context); static long b200_xxxx_validation (stpl1010aContext *context); …

4.11 제어문 4.11.1 개요 for, while, if 문의 다음에 오는 문장은 비록 한 문장이라 할 지라도 다음 줄에 space 4byte 를 띄우고 위치시킨다. for, while, if, switch 문에서 brace({ … })로 여러 문장을 묶을 경우, left brace’{‘의 위치는 다음 줄에 for, while, if 문에 일치하게 맞추거나 space 1byte 띄우고 같은 줄에 위치시킨다. 우괄호 ’}’의 위치는 for, while, if 문의 위치에 맞추어 마지막 문장 다음 줄에 적는다. for 문에서 semi-colon(;) 뒤에는 한 칸을 띄운다. switch 문에서 case 문의 수직 위치는 switch 문과 맞추며, 각 case 문에 해당하는 코드는 반드시 그 다음 줄에서 space 4byte를 띄운 후에 시작한다. 그리고 break 문 다음에 한 줄을 띄어서 그 다음 case 문과 쉽게 구별되도록 한다. if ~ else는 else를 if 문의 위치와 맞춘다. if 문 다음에 설령 한 문장이 오더라도 else가 뒤따르면 brace를 이용하여 묶어 준다. 또한, else가 없는 if 문 다음에 한 문장이 오더라도 그 문장에 if 가 들어간다면 그것도 역시 brace를 이용하여 묶어 준다.

4.11.2 제어문 사용예 if (var == 1) blah ~~~; /* 잘못된 작성 예 */ if (var == 1) { /* brace 를 작성하고 brace 의 위치는 조건 다음에 space 이후 */ blah ~~~; } if (var == 1) /* 또는 brace의 위치는 다음 줄에 위치시킨다. */ { if (var == 1) { blah~~~;} else { /* else 문은 if 문과 같은 level 로 위치한다. */ blah~~~; switch (flag) { /* brace 위치는 if 문과 동일하게 옆 또는 다음라인 모두 가능하다 */ case 1: /* case 의 위치는 switch와 같은 level 로 작성한다. */ break; /* break 다음라인은 한 줄 띄어 쓰기 한다 */ case 2: break; default: /* default 는 가능한 기술하여 주도록 한다. */

4.12 사용을 제한(금지)하는 C 함수 리스트 사용금지함수를 온라인서버, 배치서버별로 별도 관리한다. 사용금지함수로 등록되면 컴파일 할 때 오류메시지를 보여준다. 대체함수가 있는 경우는 대체함수를 사용한다. 금지함수 중에 프로그램에서 꼭 필요한 함수는 wrapper 함수를 별도 제공한다. 상세한 금지함수 목록은 별첨을 참고한다. 4.12.1 대체함수 strcpy -> strncpy strcat -> strncat sprintf -> snprintf gets -> fget (2) 대표적인 온라인 금지함수 scanf, fscanf, sscanf, vscanf, vsscanf, vfscanf realpath, getopt, getpass, streadd, strecpy, strtrns -> getwd malloc, realloc sleep printf, fprintf exit stdin, stdout , stderr

4.13 헤더파일 Header File 대상 (include 대상) 자신의 프로그램에서만 사용하는 구조체, Macro, Data Layout 등은 Header File로 작성하지 않는다. 다른 여러 헤더파일만 include하거나 또는 유사한 기능을 묶는 헤더파일을 작성하지 않는다. 팀 별 공통으로 작성(이용)하는 헤더파일 팀 별 공통 상수 헤더파일 (업무모듈명+ Const.h, 예 : svsvConst.h) 팀 별 ComBuf 헤더 파일 (업무모듈명+ComBuf.h, 예 : baddComBuf.h) 팀 별 Macro 헤더 파일( 업무모듈명+Macro.h, 예 : svsvMacro.h ) Header File 작성원칙 기능이 유사하다고 해서 해당 헤더파일을 모두 include 하지 않는다. Header File 작성항목 Comment include files constant/macro Structure global variables function prototype : 다른 프로그램에서 호출하는 함수

4.14 변경히스토리 프로그램의 변경 히스토리는 각 노드의 특성(property)의 Comment 에 아래의 양식대로 기술한다. 특히 프로그램 노드에는 변경히스토리가 반드시 기술되어야 한다. 변경 History 영역에 작성자, 일자, 근거, 변경내역 을 기록한다. ================================================================================== 변경일자 변경자 근거 변경내용 ---------------------------------------------------------------------------------- 2007.02.05 홍길동 약관변경 만기일을 2008년으로 연장 =================================================================================== 코멘트의 생성된 예) /************************************** * KIND : Service Module Interface * NODE ID : 0 * NAME : * 결산보정계정목록 * DESCRIPTION : * ========================================================================== * 변경일자 변경자 근거 변경내용 * -------------------------------------------------------------------------- * 2007.02.05 홍길동 신시스템구축 신규작성 *************************************/

4.15 Script 표준 4.15.1 Shell Script 대상 - 배치 프로그램을 실행 시키는 경우 Shell Script 를 작성하여 실행한다. - Job 단위 별로 하나의 script 를 작성한다. - Job scheduler 선정 후 script 작성 단위 확정 4.15.2 Shell Script 작성 원칙 - SQL 실행은 DBA의 보안 정책에 따라 결정한다. - 실행 프로그램이나 사용되는 파일의 경로는 절대 경로로 기술한다 - 쉘 스크립트 내에서 프로그램 실행은 background 로 실행하지 않는다. - 단, 동시에 여러 프로세스 실행 필요 시 Job scheduler 에서 shell 을 여러 개 실행한다 참고 : 온라인/모듈의 경우 배치 프로그램을 실행 시킬 필요가 있는 경우 해당 쉘 을 background 로 실행한다. - 프로그램 실행 결과 체크를 의무화 한다 (결과가 항상 정상인 경우에도 해당) 성공 (0) / 오류 (~0) - Logging 필요 시 프레임웍에서 제공하는 API (shell script) 를 이용하여 기록한다. 고려사항 : Job scheduler 의 logging 확인 / 스크립트 작성대상 (Job 단위 경우 필요)

5. 개발 환경 5.1 UNIX 디렉토리 구조 inc env tpl mkfiles cfg bin shl pfm proframe lib $PRJROOT package site.xml logserver Features com.tmax.proframe.studio.feature_버젼.jar jeus5/webhome/app_home patch plugins PfmDevSvr.xml pfmdevsvr WEB-INF lib pfmdevsvr.jar, proframe.jar css site.jar, pfmwebadmin.jar 팀코드 (업무구분+세부업무) bin compile images batch jeus-web-dd.xml web.xml src include module js inc service release dbio lib webAdmin src lib sys inc pmap lib src xml

5.1 UNIX 디렉토리 구조 5.1.1 package 디렉토리 package 디렉토리는 프로프레임 패키지에서 제공되는 헤더, 라이브러리가 보관되는 곳으로 프로프레임 관리자 계정만 접근이 가능하도록 제한한다. 구분 디렉토리 비고 Project Root /prjroot prjroot는 프로젝트별로 정의 함 Package Root /prjroot/package ProFrame은 통합개발환경으로 JEUS를 사용하고, C버전인 경우 Tmax를 사용하고 있음. ProFrame Home /prjroot/package/proframe ProFrame Root /prjroot/package/proframe/pfm ProFrame Binary /prjroot/package/proframe/pfm/bin ProFrame Util & Binary ProFrame Config /prjroot/package/proframe/pfm/cfg ProFrame Config File ProFrame Include File /prjroot/package/proframe/pfm/inc ProFrame Library /prjroot/package/proframe/pfm/lib ProFrame Library File ProFrame Shell Util /prjroot/package/proframe/pfm/shl ProFrame Shell Utility ProFrame Template Home /prjroot/package/proframe/pfm/tpl ProFrame 환경변수 Template /prjroot/package/proframe/pfm/tpl/env ProFrame 환경변수 Template 파일. TP, OS, DB, WAS별로 분리되어 있음. ProFrame Makefile Template /prjroot/package/proframe/pfm/tpl/mkfiles ProFrame Makefile Template 파일. TP, OS, DB, WAS별로 분리되어 있음. ProFrame xml Parser /prjroot/package/proframe/pfm/tpl/xml ProFrame이 사용하는 C버전 XML Parser. ProFrame Customizing Root /prjroot/package/proframe/pfm_dev ProFrame Customizing 작업 디렉토리 JEUS Home /prjroot/package/jeus JEUS Home. 이하 디렉토리는 JEUS와 같음. Plugin 패치 Home /prjroot/package/jeus/webhome/app_home/patch Plugin 자동 패치 Home WebAdmin 용 jsp 홈 /prjroot/package/jeus/webhome/app_home/pfmdevsvr/webAdmin 테스트프레임웍 등 web Admin 용 jsp 화면 Tmax Home /prjroot/package/tmax Tmax Home. 이하 디렉토리는 Tmax와 같음.

5.1 UNIX 디렉토리 구조 5.1.2 release 및 compile 디렉토리 release 및 dbio 디렉토리는 프로프레임에 의하여 자동 생성되는 소스들이 보관된다. 개발자가 수정하는 영역이 아니기 때문에 팀별 구분없이 리소스가 보관된다. 구분 디렉토리 비고 엔진에서 생성한 소스 작업 Home /prjroot/release PomMapper, DBIO등 엔진에서 생성한 소스 생성 및 작업 Home 디렉토리 ProMapper에서 생성한 소스 작업 Home /prjroot/release/pmap PomMapper에서 생성한 소스 생성 및 작업 디렉토리 PomMapper에서 생성한 소스 /prjroot/release/pmap/src PomMapper에서 생성한 라이브러리 /prjroot/release/pmap/lib PomMapper에서 생성한 헤더 /prjroot/release/pmap/inc PomMapper에서 생성한 메타 정보 /prjroot/release/pmap/xml DBIO에서 생성한 소스 작업 Home /prjroot/release/dbio DBIO에서 생성한 소스 생성 및 작업 디렉토리 DBIO에서 생성한 헤더 /prjroot/release/dbio/inc DBIO에서 생성한 라이브러리 /prjroot/release/dbio/lib DBIO에서 생성한 소스 /prjroot/release/dbio/src 사용자 생성한 소스 작업 Home /prjroot/compile SM, BM, Module등 사용자사 생성한 소스 생성 및 작업 디렉토리 사용자 그룹별 Home /prjroot/compile/team1 team1은 리소스그룹명이다. 리소스그룹=업무구분+세무업무구분 서비스모듈 소스 /prjroot/compile/team1/src/service 서비스모듈 소스 파일 보관 비즈모듈 소스 /prjroot/compile/team1/src/module 비즈모듈,배치모듈 소스 및 make파일 보관 배치프로그램 소스 /prjroot/compile/team1/src/batch 배치서버프로그램 소스 및 make파일, 실행shell 보관 서버프로그램 소스 /prjroot/compile/team1/src/server TCS, UCS서버 소스 보관

5.2 표준 검증 체크리스트 5.2.1 체크리스트 (공통사항) 구분 항 목 여 부 1. 일반원칙 1. 프로그램 source 명은 명명규칙을 준수 하는가? 2. 프로그램 source 시작부에 미리 정의된 형태의 comment를 작성하였는가? 3. 프로그램 header 파일명은 명명규칙을 준수 하는가? 4. 프로그램 header에 미리 정의된 형태의 comment를 작성하였는가? 5. Indentation 단위는 space 4byte 를 사용하는가? 2. 주석 1. Body 부에 필요한 설명을 하고 있는가? 2. 변경시 변경 comment 를 추가하였는가? 3. 타입 / 상수 1. 모든 타입은 프로그램 헤더에서 typedef 에 정의되었는가? 2. 상수는 모두 대문자로 정의하고, 명명규칙을 준수하는가? 4. 변수 1. 변수는 해당 block(함수) 의 시작위치에서 선언되었는가? 2. 변수의 선언시 정의된 타입 또는 정의된 상수를 사용하여 선언하였는가? 3. 전역변수를 사용하지 않았는가, 사용시 g_ 로 시작하는 명명규칙을 준수하였는가? 4. 변수명은 소문자를 사용하고 정의된 약어 또는 약어의 조합을 사용하였는가? 5. Virtural Module 에서 변수를 사용하지 않고 Inner Module 에서만 변수선언하였는가? 5. 연산자 1. 연산자를 혼용 사용한 경우 괄호를 이용하여 우선순위를 명확히 표시하였는가?

5.2.1 체크리스트(공통사항) 구분 항 목 여 부 6. 함수 1. 함수명은 명명규칙을 준수하였는가? 항 목 여 부 6. 함수 1. 함수명은 명명규칙을 준수하였는가? 2. 모든 함수에 미리 정의된 형태의 comment 작성하였는가? 3. 내부에서만 사용되는 함수의 경우는 static으로 선언되었는가? 4. static 함수에 종속되는 함수의 경우 depth 를 표시하였는가? 예) a000 -> a100 -> a110 -> a111 7. 제어문 1. 제어문의 brace 의 시작 및 끝 위치를 준수하는가? 2. switch 문에서 모든 case 문은 새로운 줄에서 시작하고, indentation은 switch 문에 맞춘다. 3. 모든 switch 문에 default 문이 존재하는가? (validation 체크한 경우 제외) 8. 제한/금지 함수 1. 금지 및 제한하는 C 함수를 사용하지 않는가? 2. DB connect/disconnect 을 사용하지 않는가? 3. 트랜잭션 begin, commit/rollback 을 사용하지 않는가? (배치 및 C/C 예외) 4. pfm_tpreturn(), pfm_clireturn(), pfm_svcreturn() 의 서비스 종료함수를 사용하지 않는가? 9. 내용검토 1. while, for 문 사용시 무한 loop 에 빠지는 경우가 없는가? (UCS 프로그램 제외) 2. 종료 값 리턴시 정상시에는 RC_NRM, 비정상시에는 RC_ERR 을 반환하고 있는가? 3. 타 팀 Table 또는 파라미터 테이블을 직접 access 하지 않는가?

5.2.2 체크리스트 (프로그램 유형별) 여 부 구분 항 목 10. 프로그램 항 목 여 부 10. 프로그램 1. EMB 의 기본형태(초기화, 입력항목검증, 업무처리, 정상종료, 예외처리)를 유지하고 있는가? 2. 온라인 프로그램에서 파일을 읽고 쓰지 않는가? 3.온라인 프로그램에서 배치프로그램을 실행하지 않는가? 4. 입력 구조체 리스트의 입력여부를 체크 하였는가? 5. 모듈의 입력 파라미터로 컴버프를 사용하지 않는가? 6. 배치모듈에서 loop 내에서 commit 을 주기적으로 하고 있는가? 7. 배치모듈에서 입력 argument 의 개수 및 입력 여부를 체크하였는가? 11. 쉘 스크립트 1. 프로그램 및 사용할 파일의 경로가 절대 경로로 표시되었는가? 2. 프로그램 실행 시 background 모드로 실행하지 않는가? 3. 프로그램 실행 결과를 체크하는가?

5.3 프로그램 개발절차 5.3.1 개요 개발 프로세스 중 구현 및 단위 테스트 부분을 프로그램 작성 관점에서 상세하게 기술 유형별 (온라인, 모듈, 배치) 프로그램 구현절차를 기술하고, 각 작성 단계별로 설명 유형별로 제시되어야 할 템플릿 종류 및 요건 설명, 템플릿 제공 유형별 템플릿 및 샘플은 별도 파일로 제공 5.3.2 절차 사전 작업 개발 환경 구축 설계 산출물 확인 유형별 프로그램 개발 프로그램 등록 I/O 정의 프로그램 작성 Compile 및 실행 Binary 생성 실행 및 테스트 Release QA 및 테스트 보고서 작성 완료 프로그램 이행

5.3.3 관련 참조 매뉴얼 Framework 매뉴얼 온라인/배치 아키텍처 (연동, 온라인/배치 프레임 구조 등) 개발표준, 작성표준, 개발 프로세스 등 디버깅 절차 및 에러 처리 방법 DBIO, I/O Formatter studio 및 API 사용법 Utility 사용법 등 개발 툴 (ProBuilder) 사용 매뉴얼 M/W 개발자 가이드 (서버/서비스 등록 및 Boot/Down, Log file 등) SQL 작성방법 및 DBMS 개발자 가이드 단말 화면 Drawing Tool 사용법 MCA 전문 등록 사용법 기타 C native 함수 사용법 gdb 등 debug tool 사용법

5.3.4 온라인 프로그램 개발절차 프로그램 등록 및 I/O 정의 M/W config에 서버/서비스 등록 거래파라미터 등록 단말 화면 정의 (단말 drawing tool) 입력 및 표준 전문 (MCA) ProMapper 정의 (Interface header) DBIO 구조체 정의 (table header) 프로그램 작성 서비스모듈(SM) 작성 서버프레임 생성 (프레임웍을 이용한 자동생성) Compile make file 자동 생성 (프레임웍을 이용한 자동생성) 실행 및 테스트 test client 또는 단말을 이용한 거래 수행

5.3.5 모듈 프로그램 개발절차 프로그램 I/O 정의 인터페이스 구조체 정의 (모듈 헤더파일 템플릿 이용) DBIO 구조체 정의 프로그램 작성 모듈 프로그램 템플릿 이용하여 작성 Compile make file 자동 생성 (프레임웍을 이용한 자동생성) 실행 및 테스트

5.3.6 배치 프로그램 개발절차 프로그램 I/O 정의 DBIO 구조체 정의 인터페이스 및 공유 필요한 구조체 정의 (optional) 프로그램 작성 배치 프로그램 프레임 자동생성 배치 업무 기능 모듈 작성 Compile 실행 스크립트 작성 스크립트 템플릿 이용하여 작성 실행 및 테스트

공통 내용을 포함하는 하나의 make file 5.4 컴파일 환경 5.4.1 Make file 공통 유형별 OS server 설정 내용 M/W include module DBMS batch Framework 공통 내용을 포함하는 하나의 make file 각 유형별 make file 공통 make_common 이라는 하나의 make file 로 작성하고, 유형별 Make file 에서 Include 함 M/W, DBMS, OS library 및 Framework 필수 library 설정 소스, 헤더파일, library 경로 설정 (환경변수를 통하여 경로 포함) 각종 compile option 설정 유형별 각 유형별 로 존재하고 유형별로 반영하고 설정해야 하는 값 포함 Binary 생성 위치 및 dependency 포함

5.4.2 컴파일환경 정의 라이브러리 및 헤더파일 적용 경로 순서 OS, M/W, DBMS에 관련 Framework 관련 사용자가 지정하는 위치의 라이브러리 및 헤더파일 개발 디렉토리의 소속된 업무 분류 모듈 (QA 인 경우 QA 디렉토리) 보관 디렉토리의 소속된 업무 분류 모듈 보관 디렉토리의 공통 팀 라이브러리 적용 방법 LD_LIBRARY_PATH 와 컴파일 단계의 Library path 설정 방법 현재 LD_LIBRARY_PATH 가 우선함 컴파일 방법 컴파일 단위는 개발한 기능 프로그램과 프레임 프로그램 컴파일로 이루어 진다. 컴파일 방법은 Proframe Studio 안에서 실행한다,

5.4.3 실행파일 생성 절차 서버 cc sv_sd_01.c sv_sd_01.o ld sv_sd_01 LINK ld -b SDCD0001R1.c cc SDCD0001R1.o libSDCD0001R1.so 서비스 SDCD0002R1.c cc SDCD0002R1.o ld -b libSDCD0002R1.so LINK 모듈 msdcdcheck.c cc msdcdcheck.o ld -b libmsdccheck.so * Dlcall 사용시 library link할 필요가 없음.

5.4.4 컴파일환경 정의 LINK 방식에 따른 함수 호출 차이점 비교 object file (.o) archive library (.a) shared lib (.so or .sl) dlcall binary 생성시 라이브러리 직접기술 포함하지 않는다. 참조방법 생성된 binary 내에서 (여러 버전 존재가능) 호출 시점에서 library path 에서 검색하여 호출 (library path 관리 필요) 호출 시점에서 dlcall 대상 리스트에서 검색하여 호출 변경시 추가작업 재 컴파일 필요 library 만 교체하면 됨 (단 교체시 사용 프로그램 재 기동 필요) dlupdate 를 통해 동적으로 교체 가능 archive library 는 .o binary 묶음 library path = 환경변수의 LD_LIBRARY_PATH + compile 시 지정하는 library PATH

5. 4. 5 비즈모듈 컴파일 모듈별 make파일이 각각 생성된다. Make파일의 명은 module_모듈명 5.4.5 비즈모듈 컴파일 모듈별 make파일이 각각 생성된다. Make파일의 명은 module_모듈명.mk 이며 컴파일 방법은 make –f module_모듈명.mk 이다. [모듈의 make 템플릿] # Target # ------------------------------------------------------------------------------------------------ # BASE = 모듈명 TARGET = lib$(BASE)$(OS_SO_SUFFIX) # Objects AP_OBJS = $(BASE).o # MY DEFINE MY_C_DEFINE = MY_IPATH = MY_CFLAGS = MY_LDPATH = MY_LDLIBS = # Static Objects OBJS = $(AP_OBJS) # include common env file include $(PFMTPL)/mkfiles/make_common include $(PFMTPL)/mkfiles/make_dependency_module

5.4.6 서비스모듈 컴파일 컴파일방법 : make_sm.sh 서비스명 [서비스모듈의 make 파일 템플릿] #!/usr/bin/sh returnCheck() { if [ $? != 0 ] then echo $1 exit 1 fi } main() BASE=`echo $1|cut -d"." -f1-1`; export BASE echo 'BASENAME = ['$BASE']' echo 'make -f $PFMTPL/mkfiles/make_service_module ' $2 $3 $4 make -f $PFMTPL/mkfiles/make_service_module $2 $3 $4 returnCheck "Compile Error!!" exit 0 main $@

5.4.7 배치 모듈 컴파일 배치프로그램의 컴파일은 배치모듈 컴파일과 배치서버프로그램의 컴파일기능 따로 있다.

5.5 리소스 권한 5.5.1 리소스 권한관리 리소스에 대한 접근 권한을 사용자, 사용자그룹, 기타그룹에 대하여 각각 다르게 지정할 수 있다. (1) 사용자 권한 설정 권한을 설정할 때에는 각각의 해당하는 이진 비트 자리에 권한 설정에 따라 이진 비트를 세팅하여 16 진수로 표현한다. 미사용 Use Build Open Save List 1 : 허용 0 : 불허 1 권한값 1F 0 + 0 + 0 + 1 8 + 4 + 2 + 1 1 15  F 2) 리소스에 대한 권한은 사용자(User), 사용자그룹(Group), 기타그룹(Other) 별로 지정할 수 있다. 3) 사용자그룹은 리소스를 상호 편집, 저장 할 수 있는 것을 기준으로 정한다. Ex) 수신, 여신, 외환 … 4) 사용자그룹 아래 리소스그룹을 별도 나눌 수 있지만 리소스그룹 별로는 권한 설정을 할 수 없다. 5) 농협에서의 리소스에 대한 권한의 표준은 다음과 같다. 사용자권한 : 1F (사용자는 모든 권한부여) 사용자그룹권한 : 1F (그룹은 모든 권한 부여) 기타그룹권한 : 15 (기타그룹은Open, List 권한 부여) 권한값 Use Build Open Save List 1F 1 1E 1D … 12 11 10 Use : navigator 에서 drag & drop 하여 EMB 에 붙일 수 있는 권한 Build : EMB Design을 compile 할 수 있는 권한 Open : EMB Design을 열어서 볼 수 있는 권한 Save : 변경된 내용을 저장할 수 있는 권한 List : Navigator에서 확인해 볼 수 있는 권한

5.5.2 리소스 권한 관리 예시 사이트 권한 정책에 따라 사용자,사용자그룹,기타그룹에 대한 권한을 default 지정하여 모든 리소스에 대하여 동일한 룰이 적용되도록 한다. 권한 지정 대상 테이블 : DEV_RESOURCE, DEV_HISTORY, DEV_GROUP_RESOURCE 예제 :  사용자 및 그룹은 리소스에 모든 권한이 있고 다른 그룹은  리소스에 대한 읽기 및 리스트 권한만 지정 ALTER TABLE DEV_RESOURCE MODIFY (USER_RIGHT  VARCHAR2(2) DEFAULT '1F');  ALTER TABLE DEV_RESOURCE MODIFY (GROUP_RIGHT VARCHAR2(2) DEFAULT '1F'); ALTER TABLE DEV_RESOURCE MODIFY (OTHER_RIGHT VARCHAR2(2) DEFAULT '15'); ALTER TABLE DEV_HISTORY MODIFY (USER_RIGHT  VARCHAR2(2) DEFAULT '1F'); ALTER TABLE DEV_HISTORY MODIFY (GROUP_RIGHT VARCHAR2(2) DEFAULT '1F'); ALTER TABLE DEV_HISTORY MODIFY (OTHER_RIGHT VARCHAR2(2) DEFAULT '15'); ALTER TABLE DEV_GROUP_RESOURCE MODIFY (GROUP_RIGHT VARCHAR2(2) DEFAULT '1F'); UPDATE DEV_RESOURCE  SET USER_RIGHT = '1F',     GROUP_RIGHT = '1F',     OTHER_RIGHT = '15'; UPDATE DEV_HISTORY  SET USER_RIGHT = '1F',     GROUP_RIGHT = '1F',     OTHER_RIGHT = '15'; UPDATE DEV_GROUP_RESOURCE SET GROUP_RIGHT = '1F‘;

5.5.3 개별 리소스 권한 관리 예시 사이트 권한 정책에 따라 사용자,사용자그룹,기타그룹에 대한 권한을 개별 리소스에 대하여 동일한 룰이 적용되도록 할 수 있다. 개별리소스스 권한 지정  : PfmDevSvr.xml 예제 :  사용자 및 그룹은 리소스에 모든 권한이 있고 다른 그룹은  리소스에 대한 읽기 및 리스트 권한만 지정 <configField id="DBIO_USER_RIGHT" value="1F" type="String" xmlns=""/> <configField id="DBIO_GROUP_RIGHT" value="1F" type="String" xmlns=""/> <configField id="DBIO_OTHER_RIGHT" value="15" type="String" xmlns=""/> <configField id="SERVICE_MODULE_USER_RIGHT" value="1F" type="String" xmlns=""/> <configField id="SERVICE_MODULE_GROUP_RIGHT" value="1F" type="String" xmlns=""/> <configField id="SERVICE_MODULE_OTHER_RIGHT" value="15" type="String" xmlns=""/>

5.6 데이터 베이스 Connect 방안 5.6.1 ProFrame 4.0 Connect 방식 ○ libpfmDbioConnectDB.so, pfmDbioConnectDB() 함수를 tdlcall 하는 방식. - pfmDbioConnectDB(char *input, pfmDbioConnectDBInput *connect_info) 함수 Customizing - connect_info 구조체에 ID, Password, TNS Name을 설정하도록 되어 있음. 5.6.2 농협 재무회계 개발기 ProFrame Multi DB Connect 방법 ○ DB Connection 정보를 환경변수에서 읽어오도록 함. - Tmax 환경파일 각 서버 그룹에 ENVFILE 지정하여 DB Connection 정보를 아래와 같이 환경변수에 설정 함. * CONNECT_INFO=nbhg_app/shdguqapp@NBHGT - pfmDbioConnectDB() 함수에서 CONNECT_INFO 환경변수를 읽어 pconnect_info 파라미터에 설정. 5.6.3 농협 시스템 팀 Tmax Non-XA DB Connect 관리 방안 ○ DB Connect 함수(dbConnect())를 만들어 lib{데이터베이스명}.so로 각 업무팀에 배포. - DB ID. Password를 시스템 팀 에서만 관리하고, 환경변수, 환경 파일 등에 노출하지 않기 위해 바이너리 형태로 배포. - 개발자들은 DB연결을 위해 dbConnect() 함수를 호출하고, Link시에 시스템 팀에서 배포한 해당 DB의 Connect Library를 Link시킨다. 5.6.4 ProFrame Multi DB Connect 제안 방안 ○ ID, Password를 환경변수, 환경파일 등에 노출하지 않음. - Multi DB Connection을 위해 환경변수 CONNECT_INFO에 TNSNAME만을 export * CONNECT_INFO=NBHGT - pfmDbioConnectDB() 함수 Customizing시에 TNSNAME을 비교하여 ID, Password를 설정하도록 코딩 하여 바이너리 배포 ○ libpfmDbioConnectDB.so 생성 및 배포를 시스템 팀에서 관리. - DB ID, Password를 시스템 팀에서만 관리하기 위함. 전체 인터페이스 유형 채널과 MCA 2. 채널과 EAI - 채널에서 직접 EAI로 접속하는 경우는 절대 없음으로 위 유형은 삭제한다. 3. MCA와 CORE/단위시스템 4. EAI와 CORE/단위시스템 5. MCA와 EAI 6. 채널과 CORE/단위시스템 - 채널에서 직접 CORE로 접속하는 경우는 절대 없으며 , 단 단위시스템이 2Tier인 경우 채널에서 직접 접속하는 경우는 있음 ※ 통합단말서버(BP),대외계와 전자금융은 MCA Layer로 한다.

Service Module library 6 통합개발툴 ( ProFrame Studio) 6.1 개요 ProFrame 4.0 기반에서는 개발자가 ProFrame Studio를 통해 전문 개발, SQL 개발, 서비스 Flow 디자인, 업무 모듈의 작성 모든 개발 작업을 수행합니다. ProFrame Studio는 통합 개발 서버와 XML 기반으로 통신하며 서버 상의 메타 저장소에 있는 리소스 정보 및 목록을 조회하고 작성한 소스 및 정보를 서버 상에서 컴파일(또는 저장) 요청을 합니다. 또한 개발자 권한 관리, 소스 버전 관리 등의 리소스 관리가 통합적으로 이루어 지는 구조이다. ProFrame Studio 개발자 PC 개발서버 통합 개발 서버 DBIO Header DBIO library Biz. Module Library Service Module library 전문 개발 SQL Flow 업무 Meta Repository 전문/구조체 Header 전문-구조체 변환 library 리소스 정보, 버전 정보, 리소스 의존도, 권한 정보, IO Property 정보 등 소스 제너레이션 통합된 개발 도구 (ProFrame Studio) 통합 개발 서버를 통한 개발 리소스 통합 관리 메타 Repository 기반 표준 관리 주요 특징

V 통합개발서버 6.1.1 통합개발환경 최종리소스 history ProFrame Studio 리소스 history XML 통합개발서버에서 리소스를 통합 관리하므로 리소스간의 영향도 분석과 히스토리 관리가 용이해 지게 된다. 개발자의 권한 관리 정책 최종리소스 history 계정 관리 Tool들의 최신 버전 운영바이너리 모임 admin developer guest .... ProFrame Studio (includes DBIO Studio, ProMapper) 리소스 history XML 통합개발서버 리소스 생성/수정 이력 관리 DB 프레임워크 리소스 영향 그래프 영향도 분석 configuration Version 삭제 리소스 history 삭제 리소스 history 이력 관리하여 복구 가능 소스들간의 영향도 분석을 위한 데이터의 모음 V 환경설정 관리 버전 관리

6.2.1 프로빌더 – EMB design 프로빌더를 통하여 EMB 디자인을 하고 소스생성, 컴파일을 손쉽게 할 수 있다. 소스편집기능 이외에 컴파일, 단위테스트, 로그보기, 리소스검색 등 개발에 필요한 다양한 기능이 제공된다. EMB 디자인 창 팔레트 Outline 창 콘솔창 네비게이터 창

6.2 화면구성 6.2.2 DBIO ProFrame 4.0 DBIO Studio는 여러 유형의 SQL을 테이블과 칼럼 정보를 선택하여 생성하거나 입력하여 모듈의 메타 데이터를 생성하고 이를 이용하여 DBIO 모듈을 생성합니다.또한 SQL의 테스트 및 실행 플랜보기 등의 SQL 작성 및 테스트에 필수적인 기능들을 지원하고, Repository를 기반으로 권한 관리, 버전 관리, 영향도 분석 등의 통합 개발환경과 통합된 기능들을 지원합니다. DBIO Map 목록 테이블 컬럼 목록 매핑 정의 형식 정의 조건 정의 자동생성 SQL DBIO 생성 위저드 테이블 리스트

6.2.3 프로매퍼 - IO 정의 및 매핑 정의 서비스/업무 모듈 IO 정의 및 연동 시 매핑 방법 정의(스마트 매핑 지원) ProMapper Studio에서는 고정 길이 메시지 뿐만 아니라 가변 길이 형식, XML 형식 등 다양한 유형의 메시지 형식 정의가 가능합니다.

6.3 주요기능 주요기능 서브기능 설명 DBIO 새Query작성 - Persist, View, ExecSql, DynamicSql 별 Query 작성 메타 연계 입/출력변수 자동생성 기능 Query 테스트 및 실행 Plan 정보 보기 기본쿼리작성 - Fetch, Insert, Update, Select, Delete 5가지 기본쿼리를 생성 프로매퍼 구조체 메타항목 검색 구조체항목순서 조정 Fix Length 설정기능 ( 메시지 생성 ) 구조체 include 기능 지정된 엑셀 형식에서 읽어와서 구조체 필드 생성, 또는 생성된 구조체 필드 엑셀로 산출기능. 메시지 전문에 대한 명세를 정의 맵 - structure간 매핑 정의

6.3 주요기능 주요기능 서브기능 설명 프로빌더 EMB디자이너 - 서비스 구현을 위한 모듈 작성 - 팔레트 제공 - Activity : Inner Module, Virtual Module, Loop Module 생성 - Resources : SM Call, Dbio Call, BM Call, Rule Call 연동 또는 호출 Batch : Batch Call 연동 폴딩기능 Call Depth 표시 코멘트 작성 컨버프, 컨텍스트, 구조체를 검색하여 정의할 수 있음 모듈 활성화/비활성화 기능 부분 또는 전체 복사 기능 다름이름으로 저장하기 기능로 신규 모듈로 등록 가능 화면 비율 변경 기능 산출물 내보내기 메타정보 내보내기 소스 생성 기능, 소스 검사 기능 제공 Check Out, Check In 기능으로 타 사용자 수정 가능 여부 설정 가능 전체 맵 정보 재구성 기능

6.3 주요기능 주요기능 서브기능 설명 프로빌더 네비게이터 - 서버에 존재하는 리소스 목록 열람 가능 - 사용자가 조건에 따라 필터링하여 원하는 리소스만 네비게이터에 보이도록 지정 가능 - 리소스 그룹별, 또는 리소스 종류별로 보여지도록 지정 가능 테스트프레임 - 개발되어진 서비스 모듈이나 비즈니스 모듈을 테스트 - 테스트한 케이스들을 저장하고 저장된 케이스들을 일괄적으로 테스트 로그뷰어 - 로그필터링( 전체/에러 ) - 로그보기/로그그만보기 기타기능 - 리소스별 권한 보기 - 노드들의 커맨트만 정렬해서 보여주기 - 간단한 검색 단어를 넣어서 원하는 리소스에 대한 정보를 검색가능 - 사용되는 변수들만 목록으로 출력하여 보여주기 - 해당 리소스에서 호출하고 있는 리소스들을 검색가능, 또는 호출되어지고 있는 리소스들 검색가능 리소스의 변경내역이 버젼별로 보여짐. 현재 소스와 각 버전 소스와 비교 가능 리소스히스토리를 통한 복구기능 체크인/체크아웃 기능

7 개발지원 관리자시스템 7.1 개요 http://pfm_address:port/pfmdevsvr/login.jsp ProFrame 4 C 설치 및 개발하려는 사용자와 관리자를 위한 시스템 자세한 사항은 별도 WebAdmin 매뉴얼을 참조한다. WebAdmin Login ProFrame 4 C WebAdmin URL은 아래와 같다. http://pfm_address:port/pfmdevsvr/login.jsp pfm_address: ProFrame 4 C 설치 IP_ADDRESS port: http_Listen Port (WEBMain.xml 파일 참조) WebAdmin 접속 시 기본적으로 ID/PW는 Tester/1234로 세팅되어 있으며 로그인 버튼을 클릭하여 접속한다.

7.2 화면구성 WebAdmin 구성 A: 서비스 등록 및 검색 B: WebAdmin Menu 메타관리 환경설정 공통 관리자 C: Nevigator D: Viewer

7.3 주요기능 ○ WebAdmin의 주요기능 Main Menu Sub Menu 설명 메타관리 메타시스템 Meta 관리 - Property 검색, 신규생성 및 삭제기능 CommBuff 관리 - ComBuff 검색, 신규생성 및 삭제기능 리소스 그룹 관리 – 리소스 그룹 검색, 신규생성 및 삭제기능 환경설정 기본환경설정 환경관리 - 기본환경 설정 검색, 신규생성 및 삭제기능 서버관리 - 서버 검색, 신규생성 및 삭제기능 배치서버관리 – 배치서버 검색, 신규생성 및 삭제기능 공통 공통시스템 공통코드 관리 - 공통코드 설정 검색, 신규생성 및 삭제기능 템플릿관리 - 템플릿 설정 검색, 신규생성 및 삭제기능 * 템플릿이란 자동 생성되는 각종 C 파일 및 make 파일로 설정이나 make 파일 작성 표준이 변경되면 그에 맞게 편집이 가능하다. 관리자 관리자시스템 부서관리 - 부서 설정 검색, 신규생성 및 삭제기능 사용자관리 - 사용자 설정 검색, 신규생성 및 삭제기능 액션관리 – WebAdmin 및 Studio에 대한 액션 설정 검색, 신규생성 및 삭제기능 롤관리 – 롤관리 및 롤에 대한 액션등록관리 메뉴관리 – 메뉴관리 및 메뉴에 대한 액션관리 그룹관리 - 그룹설정 검색, 신규생성 및 삭제기능, 사용자그룹관리 기능

7.4 테이블목록 ○ WebAdmin의 테이블 테이블명 설명 비고 DEV_ACTION WebAdmin/관리자/Action관리 DEV_COMMON_CODE WebAdmin/공통/공통코드관리 DEV_CONFIG WebAdmin/기본환경/기본환경관리 DEV_DEPT WebAdmin/관리자/부서관리 DEV_GROUP_INFO WebAdmin/관리자/그룹관리/그룹관리 DEV_GROUP_RESOURCE WebAdmin/관리자/그룹관리/그룹리소스관리/그룹별 리소스 권한 DEV_MENU_GROUP WebAdmin/관리자/메뉴관리/메뉴관리 DEV_MENU_GROUP_ACTION WebAdmin/관리자/메뉴관리/메뉴액션관리 DEV_PROPERTY Resource Property DEV_RESOURCE Studio 에서 생성한 모든 Resource DEV_ROLE_ACTION WebAdmin/관리자/롤관리/액션등록관리 DEV_ROLE_INFO WebAdmin/관리자/롤관리/롤관리 DEV_SERVER_INFO WebAdmin/기본환경설정/서버관리/서버관리 DEV_SERVER_SERVICE WebAdmin/기본환경설정/서버관리/서버별 서비스 관리 DEV_SERVER_USER WebAdmin/기본환경설정/서버관리/서버별 사용자 관리 DEV_TEMPLATE_INFO WebAdmin/공통/템플릿관리 DEV_USER_GROUP WebAdmin/관리자/그룹관리/사용자그룹관리 DEV_USER_INFO WebAdmin/관리자/사용자관리/사용자관리 DEV_USER_ROLE WebAdmin/관리자/사용자관리/유저롤관리

별첨 : 업무코드표 2007.9.14일 기준 업무명 업무구분 세부(서브)업무명 세부업무 대외 BH 대외업무 HU 외환 FE 국제금융 FN 시뮬레이션 테스트환경 TE 내국신용장 LO 장애관리 MA 송금 RM 대행 BA 국고수납 EE 무역공통 TG 국민주택채권 II 수입 IP 대학등록금 DD 수출 EX 받을어음 FF 외신 SW 법원대행 AA 외환공통 CO 보호예수 GG 환전 XC 예금보험대지급 BB 고객 CZ IC 지역개발공채 HH 공통정보 NC IM 판매대행 CC 공통지원 SP 국가보훈처보상금창구직불 JJ 상품 FT PD 공무원연금기여금수납 KK　 수수료 수신 SV 마이너스대출 LN CMS/펌/가상 BF CMS CM 별단 가상계좌 VI 수신공통 MM 실시간거래 RI 요구불예금 DE 펌뱅킹 FB 저축성 IC현금/직불/전자화폐 현금/직불/모바일카드 DC 수익증권 BE 전자화폐 EC 신탁 TS HB 퇴직연금 RP e-뱅킹 UB 기술인프라 TI 자동이체 AT UBI Service 프레임웍 FW PF 자동이체고유 자동화테스트 TN 장표지로 GR 데이터전환 DT

별첨 : 업무코드표 2007.9.14일 기준 업무명 업무구분 세부(서브)업무명 세부업무 여신계정 NL 결산 SS 여신심사 RC 공통(순수데이타성) OS 공무원/군인 학자금대부 KS 공통(심사접수번호) 공통지원 LS 관리자료 금리 GS 국민주택기금 HS 대출금 DS 금리결정시스템 RS 보증서 BS 기업모니터링 부채대책 FS 담보 상호지원기금 MS 신용여신한도관리 안내장 AS 신용조사 CS 어음/수표 부도관리 PS 인터넷대출 IS 여신자금 YS 조기경보 WS 이차보상 조합 개인심사 QS 전자결제 JS 조합 기업심사 NS 차입금/대여금 종합자금심사 통계정보 TS 중앙회 개인심사 한도 중앙회 기업심사 ES 감정 집단대출 개인모니터링 프로젝트금융 회계 HG 회계입지급 BO 마감 MG 공통 CO 모니터링/장애관리 MJ 회계관리_외환 FX 텔러 TL 결산관리_중앙회 GA 거래지원 결산관리_조합 GB 장부관리 JA 보고서관리 JB 계정 GY 계정처리 CC 금감원보고서 JC 계정처리_외환

별첨 : 금지함수 목록 금지함수 Proframe 기반 데몬(UCS) 금지 이유 대체 함수 온라인 Batch 출력 처리 함수  출력 처리 함수 putchar() 제한 온라인에서 fIle 핸들링을 할 경우 거래시간이 길어져 전체시스템을 불안정하게 만들 수 있으므로 금지함 putw() puts() putc() fputc() fputs() fwrite() vfprintf() fprintf() 허용 fprintf() 대체함수가 없음 printf() Memory Overwrite로 인한 Access Violation 발생위험 있음 PFM_DBG, PFM_ERR, PFM_LOG vprintf() sprintf() snprintf, SPRINTF  프로세스 제어 함수 fork() vfork() popen() pclose() execl() execle() execlp() execv() execve() execvp() exit() _exit() system()

별첨 : 금지함수 목록 금지함수 Proframe 기반 데몬(UCS) 금지 이유 대체 함수 온라인 Batch  스트링 문자열 처리함수 strcpy() 제한 Memory Overwrite로 인한 Access Violation 발생위험 있음 strncpy, STRCPY strcmp() strncmp, STRCMP strcat() strncat, STRCAT  자원 제어 함수 getrlimit() 온라인 프로그램에서 자원제어를 직접하게 되면 전체시스템을 불안정하게 만들 수 있는 위험이 있음  setrlimit() ulimit() nice() rtprio() rtsched()  권한제어 함수 setuid() 시스템 해킹 및 down시킬 위험이 있음 setgid() umask() 정보보안 금지함수 (위 중복항목 은 제외함) gets() fget() vsprintf() snprintf vscanf() 만약 부득이 사용하여야 한다면 최고의 버퍼 길이를 명시해야함 vsscanf() vfscanf() realpath() getwd() getopt() getpass() streadd() strecpy() strtrns() memcpy() 만약 부득이 사용하여야 한다면 함수 사용 직전에 버퍼에 들어 갈 길이를 검사한 후 함수사용 stat() lstat()

별첨 : 금지함수 목록 금지함수 Proframe 기반 데몬(UCS) 금지 이유 대체 함수 온라인 Batch 메모리 제어 함수  메모리 제어 함수 malloc() 제한 온라인에서 메모리를 직접 할당하는 것을 금지, memory leakage 발생가능성 있기 때문 function 내에서 지역변수 선언하여 사용, global 변수는 context 에 선언하여 사용 free() realloc() calloc() valloc() mallopt() mallinfo() memorymap() alloca() brk() sbrk()  signal 제어 함수 signal() 온라인 프로그램에서 시그널제어를 하게되면 시스템 halt 의 위험이 있음 sigset() sighold() sigrelse() sigignore() sigpause() kill() raise() sigaction() sigprocmask() sigqueue() sigspace() sigsuspend() wait() waitid() ptrace() sigpending() sigaltstack()

금지함수 Proframe 기반 데몬(UCS) 금지 이유 대체 함수 온라인 Batch  TP 함수 (TMAX / atmi.h) tpstart() 제한 허용 미들웨어를 손상시켜 불안정 하게 만들 수 있는 위험이 있어 금지함 Proframe 기반으로 개발 할 경우 TMAX에서 제공하는 DL 함수를 Call하여 사용하면 됨 tpend() tpalloc() tprealloc() tptypes() tpfree() tpcall() tpacall() tpgetrply() tpcancel() tpstrerror() tpconnect() tpdiscon() tpsend() tprecv() tpreturn() tpforward() tpadvertise() tpunadvertise() tpnotify() gettperrno() gettpurcode() tpsetctxt() tpgetctxt()  기타 금지 함수 sleep() 반복시간을 잘못 설정할 경우 시스템 성능 저하시킬 우려 있음 usleep() alarm() pause() getitimer() setitimer()