목차
인터페이스 설계 확인
인터페이스 설계 확인
인터페이스 기능
개념
내/외부 모듈 간 연계 기능을 통해 데이터 처리하는 일련의 방법
인터페이스 기능 확인 방법
- 상세 인터페이스 기능 : 인터페이스 설계서(정의서)를 통해확인
- 내/외부 인터페이스 기능 : 시스템 정적/동적 기능 분석을 통해 확인
- 인터페이스 되는 데이터 유형, 값의 범위, 예외 처리 규칙 확인
01 인터페이스 설계서를 통한 기능 확인
인터페이스 목록
- 내/외부 인터페이스 대상들을 리스트화
▶ 인터페이스 목록 사례
Interface Info | Source | Target | |||||||
id | name | type | pattern | system | ip | port | system | ip | port |
1 | 영업기회 | Online -Async |
DBtoDB | BPM | x.x.x.x | 23 | SCM | x.x.x.x | 24 |
2 | 상품연계 | Online -Sync |
FileToFile | Product | x.x.x.x | 12 | Product | x.x.x.x | 12 |
3 | 신용조회 | Instantly | WebService | Billing | x.x.x.x | 34 | Billing | x.x.x.x | 34 |
4 | 주문전송 | Batch -Schedule |
EAI | Order | x.x.x.x | 45 | Order | x.x.x.x | 45 |
인터페이스 설계서
- 인터페이스 목록에 정의된 리스트에 대해 만든 상세 설계서
- 이기종 시스템 또는 컴포넌트 간 데이터 교환 및 처리 위한 목적
- 각 시스템 교환 데이터 및 업무, 송/수신 주체 등이 정의되어 있음
- 인터페이스 목록과 인터페이스 설계서(=명세서, 정의서)가 있음
▶ 인터페이스 설계서 사례
구성요소 | 설명 | 사례 | |
인터페이스 번호 | 송신 시스템 인터페이스 일련번호 기입 | 01 | |
데이터 송신시스템 |
이름 | 송신 시스템명 기술 | BPM |
데이터 저장소명 | 인터페이스 송신과 관련된 엔티티 또는 파일명 기술 | M_01_tb | |
속성명 | 관련 엔티티 속셩명 또는 파일 항목명 기술 | invoiceName | |
데이터 타입 | 엔티티 속성 또는 항목 타입 기술 | Char | |
길이 | 데이터 길이 기술 | 50 | |
송신 프로그램ID | 송신에 해당하는 프로그램 ID 기입 | Pgm_01 | |
인터페이스 수행 |
Fetch Size | 송신 시스템에서 전송할 데이터를 한 번에 조회할 Size | 1,000 건 |
Commit Size | 송신 시스템에서 수신 시스템으로 전달하는 Size | 1,000 건 | |
Polling 주기 | 송신 시스템에 데이터 존재하는지 확인하는 주기 | 데이터 존재 0.1초 데이터 무존재 1초 |
|
Retry 횟수 | 전송 실패 시 재시도 횟수 | 3회 | |
전처리 Spec | 전송 수행하기 전까지의 조건 | 레코드 일련번호 값이 가장 적은 것부터 순차적으로 update | |
후처리 Spec | 전송 성공 후 처리 로직 | 전송 성공 데이터에 대해 인터페이스 테이블 상태 값 변경 | |
Retry 처리 | 전송 실패 시 예외 처리 로직 | 전송 측 인터페이스 테이블에서 전송 실패 데이터 추출 | |
데이터 수신시스템 |
데이터 저장소명 | 인터페이스 송/수신과 관련된 엔티티 또는 파일명 기술 | C_02_tb |
속성명 | 관련 엔티티 속성명 또는 파일 항목명 기술 | invoiceName |
인터페이스 흐름도
- 인터페이스 데이터 흐름을 시간 순서로 표현한 것
02 정적/동적 기능 분석을 통한 인터페이스 기능 확인
- 시스템 구성 요소 간 트랜잭션 분석하여 상호 교환하는 부분에서 인터페이스 기능 확인
인터페이스 데이터 표준
개념
연계가 되어야 할 범위 데이터들 형식과 표준을 정의하는 것. 송/수신 시스템 간 데이터 형식이 동일한 경우 공통 영역을 추출하여 표준화 할 수 있지만, 데이터 형식이 다를 경우 표준화 위해 일부 시스템 데이터 형식 변환 필요
인터페이스 데이터 표준 확인
- 인터페이스 구현 전 개발자는 인터페이스 데이터 표준 확인
- 인터페이스 구현 시 데이터 표준 준수하여 구현
- json, DB, XML 등 다양한 형태로 인터페이스 모듈 표현 가능
▶ 인터페이스 데이터 표준 사례
구분 | 전송 파라미터 | 데이터 표준 |
입력값 | 급여 코드 | 급여 지급 연월 명시 : 숫자 6자리 (ex. 202301) |
정규직 : R, 계약직 : T (ex. 202301R) | ||
급여 일자 | YYYYMMDD (ex. 20230131) | |
급여 계산 결과 | 각 직원별 급여 계산 결과 항목 : 사번, 근무 일수, 소속, 직급, 급여, 상여, 비과세 급여, 총 지급액, 소득세, 주민세, 공제 금액, 실 지급액 | |
급여 액 | 정수 - 3자리마다 쉼표 표현 (ex. 25,000원) | |
출력값 | 전표 일반 정보 | 발생 시기 : YYYYMMDD |
전표 구분 : 매입 AP, 매출 AR | ||
차변 대변 | 각 계정 별 마스터 정보 발생 (급여, 상여, 세금) | |
각 귀속 부서별 급여 합계액 | ||
거래처 정보 | 거래처(직원) : 사번_이름 형태 | |
계좌 정보 : 은행코드_계좌번호 |
송/수신 시스템간 코드 매핑
01 송신 시스템 코드를 수신 시스템 코드로 매핑 (Mapping)
- 송/수신 시스템간 데이터 표준화가 되어 있지 않다면 직접 코드 변환을 위한 코드 매핑 테이블 작성해야 함
▶ 송/수신 시스템 간 코드 변환을 위한 코드 매핑 테이블 사례
송신 시스템 코드 | 수신 시스템 코드 | ||||||
코드그룹 | 코드그룹명 | 코드 | 코드명 | 코드그룹 | 코드그룹명 | 코드 | 코드명 |
LICNS_ CODE |
자격코드 | 1001 | Database | COMMON _CODE _001 |
자격분야 | 1 | 컴퓨터 |
1002 | Operating System | 1 | 컴퓨터 | ||||
1003 | Network | 1 | 컴퓨터 | ||||
1004 | 보안 | 1 | 컴퓨터 | ||||
2001 | 청소년 상담사 | 8 | 청소년 및 사회복지 |
||||
2002 | 청소년 지도사 | 8 | 청소년 및 사회복지 |
||||
2003 | 사회 복지사 | 8 | 청소년 및 사회복지 |
||||
3001 | 변리사 | 25 | 경영 | ||||
3002 | 세무사 | 301 | 세무 | ||||
3003 | 손해평가사 | 3 | 회계 |
02 송/수신 시스템 코드를 통합하여 표준화 후 매핑 (Mapping)
- 송/수신 시스템 간 데이터 표준화가 되어 있다면 이를 기준으로 송/수신 시스템 간 코드 매핑 테이블 작성
▶ 송/수신 시스템 자격 코드를 통합하여 표준화한 테이블 사례
표준화 코드 | 송신 시스템 코드 | 수신 시스템 코드 | |||||
코드그룹 | 코드그룹명 | 코드 | 코드명 | 코드 | 코드명 | 코드 | 코드명 |
LICNS_ CODE |
자격코드 | 100 | 컴퓨터 | - | - | 1 | 컴퓨터 |
110 | 컴퓨터 | 1001 | Database | - | - | ||
120 | 컴퓨터 | 1002 | OS | - | - | ||
130 | 컴퓨터 | 1003 | Network | - | - | ||
140 | 컴퓨터 | 1004 | 보안 | - | - | ||
200 | 청소년 및 사회복지 | - | - | 8 | 청소년 및 사회복지 | ||
210 | 청소년 상담사 | 2001 | 청소년 상담사 | - | - | ||
220 | 청소년 지도사 | 2002 | 청소년 지도사 | - | - | ||
230 | 사회 복지사 | 2003 | 사회 복지사 | - | - | ||
300 | 회계 및 세무 | - | - | 3 | 회계 | ||
- | - | 301 | 세무 | ||||
310 | 세무사 | 3002 | 세무사 | - | - | ||
320 | 손해평가사 | 3003 | 손해평가사 | - | - | ||
400 | 일반 행정 및 경영 | - | - | 10 | 일반 행정 | ||
- | - | 25 | 경영 |
내 · 외부 인터페이스 기술
01 EA(Enterprise Application Integration) 방식
- 기업에서 운영되는 서로 다른 플랫폼 및 애플리케이션들 간 정보 전달, 연계, 통합을 가능하게 해주는 솔루션
유형 | 개념도 | 설명 | 특징 |
Point-to-Point | 중간에 미들웨어 두지 않고 각 애플리케이션 간 Point to Point 형태로 연결 | 솔루션 구매 없이 통합 | |
상대적 저렴하게 통합 가능 | |||
변경, 재사횽 어려움 | |||
Hub & Spoke | 단일 접점이 허브 시스템 통해 데이터 전송하는 중앙 집중적 방식 | 모든 데이터 전송 보장 | |
확장, 유지보수 용이 | |||
허브 장애 시 전체 영향 | |||
Message Bus | 애플리케이션 사이 미들웨어(버스) 두어 처리 | 어댑터가 각 시스템과 버스를 두어 연결하므로 뛰어난 확장성, 대용량 처리 가능 | |
미들웨어 통합 | |||
Hybrid | 그룹 내에는 Hub & Spoke 방식, 그룹 간에는 메시지 버스 방식 사용 | 표준 통합 기술, 데이터 병목 현상 최소화 |
02 EBS(Enterprise Service Bus) 방식
- 애플리케이션 간 통합 측면에서 EAI와 유사하다고 볼 수 있으나 애플리케이션보단 서비스 중심 통합을 지향하는 아키텍처
- 웹 서비스 중심으로 표준화된 데이터
- 버스를 통해 이기종 애플리케이션을 유연하게 (loosely coupled) 통합하는 핵심 플랫폼 기술
03 DB to DB 방식
DB 링크 (DB Link)
- 데이터베이스에서 제공하는 DB 링크 객체 이용
- 수신 시스템에서 DB 링크 생성하고 송신 시스템에서 해당 DB 링크를 직접 참조하는 방식
DB 연결 (DB Connection)
- 수신 시스템 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀 (DB Connection Pool) 생성하고 연계 프로그램에서 해당 DB 커넥션 풀명을 이용
320x100
'정보처리기사 > 필기' 카테고리의 다른 글
[정보처리기사] Part02-05-03. 인터페이스 구현 검증 (4) | 2023.01.21 |
---|---|
[정보처리기사] Part02-05-02. 인터페이스 기능 구현 (6) | 2023.01.20 |
[정보처리기사] Part02-04-03. 애플리케이션 성능 개선 (2) (5) | 2023.01.16 |
[정보처리기사] Part02-04-03. 애플리케이션 성능 개선 (1) (5) | 2023.01.16 |
[정보처리기사] Part02-04-02. 애플리케이션 통합 테스트 (13) | 2023.01.12 |
댓글