anylink online 게이트웨이 안내서 · 그림 목차 [그림 1.1] 게이트웨이 동작...

AnyLink

Online 게이트웨이 안내서

AnyLink v4.0

Copyright © 2012 TmaxSoft Co., Ltd. All Rights Reserved.

Copyright Notice

Copyright © 2012 TmaxSoft Co., Ltd. All Rights Reserved.

대한민국 경기도 성남시 분당구 서현동 272-6 우)463-824

Restricted Rights Legend

All TmaxSoft Software (Tmax AnyLink®) and documents are protected by copyright laws and the Protection Act

of Computer Programs, and international convention. TmaxSoft software and documents are made available under

the terms of the TmaxSoft License Agreement and may only be used or copied in accordance with the terms of

this agreement. No part of this document may be transmitted, copied, deployed, or reproduced in any form or by

any means, electronic, mechanical, or optical, without the prior written consent of TmaxSoft Co., Ltd.

이 소프트웨어(Tmax AnyLink®) 사용설명서의 내용과 프로그램은 저작권법, 컴퓨터프로그램보호법 및 국제 조약

에 의해서 보호받고 있습니다. 사용설명서의 내용과 여기에 설명된 프로그램은 TmaxSoft Co., Ltd.와의 사용권 계

약 하에서만 사용이 가능하며, 사용권 계약을 준수하는 경우에만 사용 또는 복제할 수 있습니다. 이 사용설명서의

전부 또는 일부분을 TmaxSoft의 사전 서면 동의 없이 전자, 기계, 녹음 등의 수단을 사용하여 전송, 복제, 배포, 2

차적 저작물작성 등의 행위를 하여서는 안 됩니다.

Trademarks

Tmax ProBus®, JEUS® and Tmax AnyLink® are a registered trademark of TmaxSoft Co., Ltd. Other products,

titles or services may be registered trademarks of their respective companies.

Tmax ProBus®, JEUS® and Tmax AnyLink®는 TmaxSoft Co., Ltd.의 등록 상표입니다. 기타 모든 제품들과 회사

이름은 각각 해당 소유주의 상표로서 참조용으로만 사용됩니다.

Open Source Software Notice

This product includes open source software developed and/or licensed by "OpenSSL," "RSA Data Security, Inc.,"

"Apache Foundation," and "Jean-loup Gailly and Mark Adler." Information about the aforementioned and the related

open source software can be found in the "${INSTALL_PATH}/license/oss_licenses" directory.

본 제품은 “OpenSSL”, “RSA Data Security, Inc.”, “Apache Foundation” 및 “Jean-loup Gailly와 Mark Adler”에 의

해 개발 또는 라이선스된 오픈 소스 소프트웨어를 포함합니다. 관련 상세 정보는 제품의 디렉터리 “${IN

STALL_PATH}/license/oss_licenses”에 기재된 사항을 참고해 주십시오.

안내서 정보

안내서 제목: AnyLink Online 게이트웨이 안내서

발행일: 2012-11-09

소프트웨어 버전: AnyLink v4.0

안내서 버전: v2.1.1

내용 목차

안내서에 대하여 ........................................................................................................................... ix

제1장 소개 ................................................................................................................................. 1

1.1. 개요 ............................................................................................................................ 1

1.2. AnyLink 게이트웨이와 Tmax 게이트웨이 비교 ................................................................ 2

1.3. 동작 구조 ..................................................................................................................... 3

1.4. 에러 처리 ..................................................................................................................... 4

제2장 TCP/IP 게이트웨이 ............................................................................................................ 5

2.1. 개요 ............................................................................................................................ 5

2.1.1. 통신 .................................................................................................................. 5

2.1.2. 통신헤더 유형 ................................................................................................... 7

2.1.3. 대외 송수신 방식 ............................................................................................... 8

2.1.4. 파싱 .................................................................................................................. 8

2.1.5. 타임아웃 및 지연 응답 처리 .............................................................................. 10

2.1.6. 장애 처리 ........................................................................................................ 10

2.1.7. 파일 로깅 ........................................................................................................ 12

2.1.8. 에러 로깅 ........................................................................................................ 14

2.1.9. DB 로깅 .......................................................................................................... 15

2.1.10. Cache 기능 ................................................................................................... 15

2.1.11. 백업(Backup) 게이트웨이 ............................................................................... 17

2.2. 환경설정 .................................................................................................................... 18

2.2.1. Tmax 환경설정 ................................................................................................ 18

2.2.2. 게이트웨이 등록 .............................................................................................. 19

2.2.3. 회선(Line) 등록 ................................................................................................ 20

2.3. 사용자 프로그램(custom.h, custom.c) .......................................................................... 22

2.3.1. custom.h ......................................................................................................... 22

2.3.2. custom.c ......................................................................................................... 25

2.3.3. 사용자 API ...................................................................................................... 43

2.4. 파싱 오류 서비스 ........................................................................................................ 63

2.5. 지연 응답 처리 서비스 ................................................................................................ 65

제3장 X.25 게이트웨이 .............................................................................................................. 67

3.1. 개요 ........................................................................................................................... 67

3.2. 환경설정 .................................................................................................................... 67

3.2.1. Tmax 환경설정 ................................................................................................ 67

3.2.2. 게이트웨이 등록 .............................................................................................. 67

3.2.3. 회선(Line) 등록 ................................................................................................ 68


3.3.1. custom.h ......................................................................................................... 74

3.3.2. custom.c ......................................................................................................... 74

3.4. 파싱 오류 서비스 ........................................................................................................ 74

AnyLink iii

제4장 SSL 게이트웨이 .............................................................................................................. 75

4.1. 개요 ........................................................................................................................... 75

4.2. 환경설정 .................................................................................................................... 76

4.2.1. Tmax 환경설정 ................................................................................................ 76

4.2.2. OPENSSL command line ................................................................................. 77

4.2.3. 게이트웨이 등록 .............................................................................................. 78

4.2.4. 회선(Line) 등록 ................................................................................................ 80


4.3.1. custom.h ......................................................................................................... 81

4.3.2. custom.c ......................................................................................................... 81

4.4. 파싱 오류 서비스 ........................................................................................................ 81

제5장 HTTP 게이트웨이 ............................................................................................................ 83

5.1. 개요 ........................................................................................................................... 83

5.2. 환경설정 .................................................................................................................... 83

5.2.1. JEUS 환경설정 ................................................................................................ 83

5.2.2. 게이트웨이 등록 .............................................................................................. 85

5.2.3. URL 등록 ........................................................................................................ 86

제6장 TCP/IP Multi-Thread 게이트웨이 ..................................................................................... 89

6.1. 개요 ........................................................................................................................... 89

6.1.1. 서버 모드 구조 ................................................................................................. 89

6.1.2. 서버 모드 동작 원리 ......................................................................................... 90

6.1.3. 클라이언트 모드 구조 ....................................................................................... 91

6.2. 환경설정 .................................................................................................................... 92

6.2.1. Tmax 환경설정 ................................................................................................ 92

6.2.2. 게이트웨이 등록 .............................................................................................. 93

6.2.3. 회선(Line) 등록 ................................................................................................ 94

6.3. 사용자 프로그램(usrmain.c) ........................................................................................ 94

6.3.1. Callback 함수 .................................................................................................. 94

6.3.2. 사용자 API ...................................................................................................... 95

6.3.3. 예제 .............................................................................................................. 101

6.4. TCP/IP Multi-thread 게이트웨이 호출 방법 ................................................................. 106

제7장 SSL Multi-thread 게이트웨이 ........................................................................................ 109

7.1. 개요 ......................................................................................................................... 109

7.2. 환경설정 .................................................................................................................. 109

7.2.1. Tmax 환경설정 .............................................................................................. 109

7.2.2. 게이트웨이 등록 ............................................................................................ 109

7.2.3. 회선(Line) 등록 .............................................................................................. 111

7.3. 사용자 프로그램(usrmain.c) ...................................................................................... 111

7.3.1. 사용자 API .................................................................................................... 111

7.3.2. 예제 .............................................................................................................. 113

제8장 IMS Connect 게이트웨이 ............................................................................................... 117

iv AnyLink Online 게이트웨이 안내서

8.1. 개요 ......................................................................................................................... 117

8.1.1. IRM Header ................................................................................................... 117

8.1.2. Response 모드 .............................................................................................. 118

8.1.3. Send-only 세션 .............................................................................................. 118

8.1.4. Resume-Tpipe 세션 ....................................................................................... 120

8.2. 환경설정 .................................................................................................................. 122

8.2.1. Tmax 환경설정 .............................................................................................. 122

8.2.2. 게이트웨이 등록 ............................................................................................ 123

8.2.3. 회선(Line) 등록 .............................................................................................. 124

8.3. 사용자 프로그램(custom.h, custom.c) ........................................................................ 125

제9장 CICS Connect 게이트웨이 ............................................................................................. 127

9.1. 개요 ......................................................................................................................... 127

9.2. 환경설정 .................................................................................................................. 127

9.2.1. Tmax 환경설정 .............................................................................................. 127

9.2.2. 게이트웨이 등록 ............................................................................................ 128

9.2.3. 회선(Line) 등록 .............................................................................................. 128

9.3. 사용자 프로그램(custom.h, custom.c) ........................................................................ 128

제10장 MQ Series 게이트웨이 ................................................................................................. 131

10.1. 개요 ....................................................................................................................... 131

10.1.1. 통신 ............................................................................................................ 131

10.1.2. 대외 송수신 방식 .......................................................................................... 132

10.1.3. 파싱 ............................................................................................................ 132

10.2. 환경설정 ................................................................................................................ 133

10.2.1. Tmax 환경설정 ............................................................................................ 133

10.2.2. 게이트웨이 등록 .......................................................................................... 134

10.2.3. 회선(Line) 등록 ............................................................................................ 135

10.3. 사용자 프로그램(custom.h, custom.c) ...................................................................... 135

10.3.1. custom.h ..................................................................................................... 136

10.3.2. custom.c ..................................................................................................... 136

10.4. 파싱 오류 서비스 .................................................................................................... 136

10.5. 지연 응답 처리 서비스 ............................................................................................. 136

제11장 ebXML 게이트웨이 ...................................................................................................... 137

11.1. 개요 ....................................................................................................................... 137

11.2. 환경설정 ................................................................................................................ 137

11.2.1. JEUS 환경설정 ............................................................................................ 137

11.2.2. ebXML MSH 환경설정 .................................................................................. 139

11.2.3. 게이트웨이 등록 .......................................................................................... 139

11.2.4. URL 등록 .................................................................................................... 140

11.3. ebXML 예제 ........................................................................................................... 141

11.3.1. 단방향 메시지 전송 ...................................................................................... 141

11.3.2. 동기식 메시지 전송 ...................................................................................... 143

AnyLink v

Appendix A. 오류 메시지 및 조치 방법 .................................................................................... 147

Appendix B. AnyLink 서버의 로그보는 방법 ............................................................................ 151

Appendix C. ebXML MSH ...................................................................................................... 155

C.1. ebXML MSH 설치 및 설정 ......................................................................................... 155

C.1.1. 설치 ............................................................................................................. 155

C.1.2. 설정 ............................................................................................................. 156

C.2. ebXML 애플리케이션 프로그래밍 .............................................................................. 161

C.2.1. Message Listener .......................................................................................... 161

C.2.2. Message Sender ........................................................................................... 162

C.3. 예제 애플리케이션 ................................................................................................... 162

C.3.1. 환경설정 ....................................................................................................... 162

C.3.2. 단방향 메시지 전송 테스트 ............................................................................. 164

C.3.3. 양방향 메시지 전송 테스트 ............................................................................. 170

C.3.4. 동기식 메시지 전송 테스트 ............................................................................. 173

C.3.5. Ack 메시지 도착 확인 테스트 .......................................................................... 175

C.4. Trouble Shooting ...................................................................................................... 178

C.4.1. Cannot locate channel ................................................................................... 178

색인 .......................................................................................................................................... 179

vi AnyLink Online 게이트웨이 안내서

그림 목차

[그림 1.1] 게이트웨이 동작 구조 ................................................................................................... 3

[그림 1.2] 게이트웨이 에러 처리 구조 ........................................................................................... 4

[그림 2.1] Packet Split의 매핑 구간별 적용 파라미터 ...................................................................... 6

[그림 2.2] packet split 과정 .......................................................................................................... 6

[그림 2.3] packet concatenate 과정 .............................................................................................. 7

[그림 2.4] 게이트웨이로 들어온 요청 전문 ................................................................................... 16

[그림 2.5] 게이트웨이에서 Mapper로 넘긴 요청 전문 ................................................................... 16

[그림 2.6] Base Mapping ........................................................................................................... 17

[그림 2.7] 백업(Backup) 게이트웨이 ........................................................................................... 17

[그림 4.1] SSL Handshake ......................................................................................................... 76

[그림 5.1] 게이트웨이 등록 예 .................................................................................................... 86

[그림 5.2] URL 설정 .................................................................................................................. 88

[그림 6.1] Multi-thread 게이트웨이 구조 ...................................................................................... 90

[그림 6.2] 리모트로부터 연결 요청이 들어왔을 때 처리 과정 ........................................................ 91

[그림 8.1] IMS Connect Send-only 세션 동작 원리 ..................................................................... 119

[그림 8.2] IMS Connect Send-only 세션 전달 메시지 구조 .......................................................... 119

[그림 8.3] IMS Connect IMS command 전달 메시지 구조 ........................................................... 120

[그림 8.4] IMS Connect Resume-Tpipe 세션 동작 원리 .............................................................. 121

[그림 8.5] IMS Connect Resume-Tpipe 수신 메시지 구조 ........................................................... 121

[그림 8.6] IMS Connect Resume-Tpipe RSM 메시지 수신 구조 .................................................. 122

[그림 8.7] IMS Connect IMS command 전달 메시지 구조 ........................................................... 122

[그림 8.8] IMS Connect custom.c에서 IRM Header 얻는 방법 ..................................................... 126

[그림 9.1] CICS Connect custom.c에서 CICS Request header 얻는 방법 .................................... 129

[그림 11.1] 단방향 메시지 전송 ................................................................................................ 141

[그림 11.2] 동기식 메시지 전송 ................................................................................................ 143

[그림 A.1] tmadmin 화면 .......................................................................................................... 147

[그림 C.1] 단방향 메시지 전송 흐름 .......................................................................................... 164

[그림 C.2] Sending EBXML Message ....................................................................................... 165

[그림 C.3] 양방향 메시지 전송 흐름 .......................................................................................... 171

[그림 C.4] 양방향 메시지 전송 테스트 결과 ............................................................................... 173

[그림 C.5] 동기식 메시지 전송 흐름 .......................................................................................... 174

[그림 C.6] 동기식 메시지 전송 테스트 결과 ............................................................................... 175

[그림 C.7] Ack 메시지 도착 흐름 ............................................................................................... 176

[그림 C.8] Ack 메시지 도착 확인 테스트 결과 ............................................................................ 177

AnyLink vii

안내서에 대하여

안내서의 대상

본 안내서는 Tmax AnyLink® (이하 AnyLink) Online 게이트웨이를 설치 및 설정하려는 사용자를 대상으로

기술한다.

안내서의 전제 조건본 안내서를 이해하기 위해서는 Tmax 및 Tmax 게이트웨이에 관한 기본적 지식이 필요하다.

● Tmax 및 Tmax 게이트웨이 관련 매뉴얼 참고

안내서에 대하여 ix

안내서 구성

본 안내서는 총11개의 장과 3개의 Appendix로 구성되어 있다.

각 장의 주요 내용은 다음과 같다.

● 제1장: 소개

AnyLink 게이트웨이의 구조 및 용도에 대해 설명한다.

● 제2장 : TCP/IP 게이트웨이

TCP/IP 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제3장 : X.25 게이트웨이

X.25 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제4장 : SSL 게이트웨이

SSL 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제5장 : HTTP 게이트웨이

HTTP 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제6장 : TCP/IP Multi-Thread 게이트웨이

TCP/IP Multi-Thread 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제7장 : SSL Multi-Thread 게이트웨이

SSL Multi-Thread 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제8장 : IMS Connect 게이트웨이

IBM Mainframe의 IMS 미들웨어와 TCP/IP 통신을 하는 게이트웨이의 기능 및 설정 방법을 설명한다.

● 제9장 : CICS Connect 게이트웨이

IBM Mainframe의 CICS 미들웨어와 TCP/IP 통신을 하는 게이트웨이의 기능 및 설정 방법을 설명한다.

● 제10장 : MQ Series 게이트웨이

IBM MQ Series를 통해서 전문을 송수신하는 온라인 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● 제11장 : ebXML 게이트웨이

ebXML 게이트웨이의 기능 및 설정 방법에 대해 설명한다.

● Appendix.A : 오류 메시지 및 조치 방법

오류 메시지 및 조치 방법에 대해 설명한다.

● Appendix.B : AnyLink 서버의 로그보는 방법

AnyLink 서버의 로그 보는 방법에 대해 설명한다.

● Appendix.C : ebXML MSH

ebXML MSH의 설치 및 설정에 대해 설명하고 애플리케이션 프로그래밍과 예제에 대해 설명한다.

x AnyLink Online 게이트웨이 안내서

안내서 규약

의미표기

프로그램 소스 코드의 파일명<AaBbCc123>

파일, 디렉터리 이름, 환경설정 변수Courier New

Ctrl과 C를 동시에 누름<Ctrl>+C

GUI의 버튼 또는 메뉴 이름[Button]

강조진하게

다른 관련 안내서 또는 안내서 내의 다른 장 및 절 언급" "(따옴표)

화면 UI에서 입력 항목에 대한 설명'입력항목'

메일계정, 웹 사이트, 다른 장 및 절 참고하이퍼링크

메뉴의 진행 순서>

하위 디렉터리 또는 파일 있음+----

하위 디렉터리 또는 파일 없음|----

참고 또는 주의사항참고

그림 이름[그림 1.1]

표 이름[표 1.1]

명령어 수행 후 화면에 출력된 결과물, 예제코드AaBbCc123

안내서에 대하여 xi

시스템 사용 환경

요구 사항

Microsoft Windows 2000/XP/2003/NT/VistaPlatform

Solaris

HP-UX

AIX

Linux

512MB 이상 메모리 공간 권장Hardware

500MB 이상 하드디스크 공간 필요

5.0 Update 4(JDK 1.5.0_12) 이상JDK

Oracle 9i 또는 10gDatabase

Tibero

DB2

xii AnyLink Online 게이트웨이 안내서

관련 안내서

설명안내서

AnyLink에 대한 간단한 소개와 기본적인 테스트 방법에 대해 설명한 안

내서이다.

AnyLink

소개 및 시작하기 안내서

AnyLink 서버와 AnyLink의 툴(Admin, 스튜디오)을 설치하는 방법에 대

해 설명한 안내서이다.

AnyLink

설치 안내서

AnyLink 스튜디오의 구성 및 기능에 대해 설명하고, 사용 방법에 대해

설명한 안내서이다.

AnyLink

스튜디오 안내서

AnyLink Admin의 구성 및 기능에 대해 설명하고, 사용 방법에 대해 설

명한 안내서이다.

AnyLink

Admin 안내서

참고 자료

● Tmax

– Tmax Getting Started Guide

– Tmax Administration Guide

– Tmax Reference Guide

– Tmax Gateway Guide(TCPIP)

– Tmax Gateway Guide(TCPIP-Thread )

– Tmax Gateway Guide(X.25)

● JEUS

– JEUS Web Container 안내서

안내서에 대하여 xiii

연락처

Korea

TmaxSoft Co., Ltd

272-6, Seohyeon-dong, Bundang-gu,

Seongnam-si, Gyeonggi-do, 463-824

South Korea

Tel: +82-31-8018-1000

Fax: +82-31-8018-1115

Email: [email protected]

Web (Korean): http://www.tmax.co.kr

기술지원: http://technet.tmaxsoft.com

USA

TmaxSoft, Inc.

560 Sylvan Avenue Englewood Cliffs, NJ 07632

U.S.A

Tel: +1-201-567-8266

Fax: +1-201-567-7339


Web (English): http://www.tmaxsoft.com

Japan

TmaxSoft Japan Co., Ltd.

5F Sanko Bldg, 3-12-16 Mita, Minato-Ku, Tokyo, 108-0073

Japan

Tel: +81-3-5765-2550

Fax: +81-3-5765-2567


Web (Japanese): http://www.tmaxsoft.co.jp

xiv AnyLink Online 게이트웨이 안내서

http://www.tmax.co.kr

http://technet.tmaxsoft.com

http://www.tmaxsoft.com

http://www.tmaxsoft.co.jp

China

TmaxSoft China Co., Ltd.

Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan,

Chaoyang District, Beijing, China, 100027

China

Tel: +86-10-6410-6145~8

Fax: +86-10-6410-6144


Web (Chinese): http://www.tmaxsoft.com.cn

안내서에 대하여 xv

http://www.tmaxchina.com.cn

제1장 소개

본 장에서는 AnyLink 게이트웨이의 구조 및 용도에 대해 설명한다.

1.1. 개요AnyLink 게이트웨이는 Mapper와 Non Tmax 서버(리모트 노드라 칭함) 간의 인터페이스를 담당하는 게이

트웨이이다. AnyLink는 대내외 시스템 간의 연계를 목적으로 하기 때문에 다양한 통신 프로토콜 및 통신

방식을 수용해야 한다. 그리하여 HTTP 게이트웨이가 추가되었고, GUI를 통한 제어 및 모니터링이 가능

하다.

온라인 게이트웨이와 배치 게이트웨이

게이트웨이에는 기능에 따라 온라인과 배치로 나뉜다.

● 온라인 게이트웨이

온라인 게이트웨이는 스튜디오에서 온라인 업무로 등록한 거래를 타 시스템으로 송수신하기 위한 것이

다.

온라인 게이트웨이에서 수용되는 통신 프로토콜은 TCP/IP, X.25, SSL, HTTP(SOAP)이 있으며, TCP/IP,

SSL의 경우 특수한 목적에서 사용되는 Multi-Thread 게이트웨이가 있다.

TCP/IP와 X.25는 실제로 하나의 게이트웨이로 Admin에서 프로토콜 등록 방법과 회선 설정 방식만 다

르다.

HTTP 게이트웨이는 WebToB의 light version 게이트웨이로 HTTP, SOAP으로 들어오는 전문을 받아주

는 기능을 수행한다. HTTP 게이트웨이의 회선은 URL이라고 하여 TCP/IP, X.25와는 별도의 방식으로

등록한다.

● 배치 게이트웨이

배치 게이트웨이는 파일 송수신을 위한 프로토콜이 구현되 있는 Multi-thread 형태의 게이트웨이이다.

배치 게이트웨이는 온라인 게이트웨이와 달리 스케줄러를 통해서 명령을 받는다. 대내 기관에서 개시

를 할 경우는 스케줄러가 명령을 내리고, 대외 기관에서 개시 전문이 올 경우는 배치 게이트웨이가 자체

적으로 일을 할 수 있는 thread를 할당해서 처리하도록 한다. 배치 게이트웨이는 여러 기관/업무를 한

서버 내에서 처리가 가능하며 서로 다른 배치 스타일 간에도 처리 가능하다.

참고

배치 게이트웨이에 대한 자세한 내용은 "AnyLink 배치 안내서"를 참조한다.

제1장 소개 1

External 게이트웨이와 Internal 게이트웨이

TCP/IP, X.25 게이트웨이에서 파싱 방식에 따라 Internal(대내), External(대외) 게이트웨이로 구분된다.

AnyLink 게이트웨이의 중요한 기능 중의 하나가 파싱인데 파싱이라는 것은 전문을 받아서 기관/업무/종

별/거래 코드를 찾아내고 이 정보를 Mapper로 전달하는 것이다. Mapper는 4개의 코드를 바탕으로 매핑,

로깅, 거래 제어를 수행한다.

● External 게이트웨이

대외 기관 전문의 구조는 전문종별 코드/거래구분 코드로 되어 있다. 게이트웨이는 기관/업무를 찾은 이

후에 종별/거래를 찾아내야 하는데, External 게이트웨이는 업무정보를 이용하여 종별 코드를 찾고, 종

별 코드 정보를 이용하여 거래구분 코드를 찾아낸다.

● Internal 게이트웨이

반면에 대내 측은(일반적으로 Core라 불림) 대외 기관 전문 체계와 달리 12자리 거래 코드, 또는 여러

코드를 조합해서 거래를 나타내는 등 다양한 구조로 되어 있다. 그러므로 대외 전문처럼 하나의 표준화

된 방식이 아닌 다른 형태로 찾아내야 하므로 Internal 게이트웨이의 파싱 방식은 다르다. 자세한 것은

“제2장 TCP/IP 게이트웨이”의 파싱 기능을 참조한다.

1.2. AnyLink 게이트웨이와 Tmax 게이트웨이 비교AnyLink 게이트웨이는 Tmax에서 제공되는 것들과는 다른 것으로, AnyLink Admin에 등록을 해야만 동작

한다.

기존 Tmax 게이트웨이들은 CLOPT 절에 설정을 하고 환경 파일을 생성하는 작업을 수행해야 했으나,

AnyLink 게이트웨이들은 Tmax 게이트웨이의 기능을 포함하면서 동시에 GUI 툴을 이용하여 설정할 수 있

도록 바뀌었다.

AnyLink 게이트웨이의 또 다른 특성은 AnyLink Admin을 통해서 모니터링을 수행할 수 있다는 점이다. 회

선의 상태, 거래 처리 건수 등을 실시간으로 모니터링이 가능하다.

AnyLink 게이트웨이는 전문을 받았을 때 파싱이라는 절차를 통해서 Mapper에 필요한 정보를 넘겨주게

된다. Mapper는 이 정보를 바탕으로 매핑에 필요한 정보를 얻어 처리를 수행한다.

HostLink의 경우, AnyLink와 직접 연계되지 않는다. 단, Tmax에서 지원되는 HostLink를 사용할 경우

Mapper와 연계가 되도록 기능을 지원한다.

2 AnyLink Online 게이트웨이 안내서

1.3. 동작 구조AnyLink 게이트웨이의 동작 구조는 다음과 같다.

[그림 1.1] 게이트웨이 동작 구조

AnyLink 게이트웨이는 인바운드, 아웃바운드 모드를 동시에 수행할 수 있다.

리모트 노드(Remote node)로부터 데이터가 들어오면 요청/응답 여부를 판단하고 전문을 파싱한다. 요청

전문일 경우, 파싱 정보와 함께 Mapper를 호출한다. Mapper가 서비스를 호출해서 응답이 돌아오면 송수

신 규칙에 맞는 회선으로 응답을 돌려준다. 응답 전문일 경우, 호출했던 서비스로 리턴한다.

제1장 소개 3

1.4. 에러 처리AnyLink 게이트웨이의 에러 처리 구조는 다음과 같다.

[그림 1.2] 게이트웨이 에러 처리 구조

AnyLink 게이트웨이에서 에러가 발생했을 때의 처리 방법은 AnyLink 내부로부터 tpcall/tpacall을 받았을

때와 그 외로 나뉘어진다.

리모트 노드(Remote node)로부터 요청 메시지가 들어오면 게이트웨이는 메시지 파싱을 한다. 파싱에 실

패하면 다음 단계로 진행할 수 없기 때문에 대신 파싱 오류 서비스를 호출한다.

게이트웨이에서 Mapper를 호출하면 대부분 응답을 받게 된다. 응답은 정상응답과 오류응답으로 나눠진

다. 오류응답이 오면 게이트웨이는 파싱 오류 서비스로 전달하여 사용자가 원하는 처리를 하게 된다. 정상

응답이 오면 리모트 노드로 응답을 전송하지만 이 과정에서 회선이 끊어져 있는 등의 문제가 발생할 수 있

다. 그렇게 되면 파싱 오류 서비스로 응답을 전송한다. 그리고 Mapper로부터 호출을 받았을 때에 오류가

발생하면 게이트웨이는 간단히 오류 리턴만 한다.


제2장 TCP/IP 게이트웨이

본 장에서는 TCP/IP 게이트웨이의 기능 및 설정 방법을 설명한다.

2.1. 개요본 절에서는 TCP/IP 게이트웨이의 특성에 대해 설명한다.

2.1.1. 통신

TCP/IP 게이트웨이의 통신 부분의 특성은 다음과 같다.

● 통신 방향성

특정 회선에 대해 입력/출력/양방향 등 방향성 설정이 가능하다. 상대방 기관이 송수신을 비동기로 처리

해서 송신 process와 수신 process가 분리된 경우에 송신은 1000번 포트로 수신은 1001번 포트로 할

수 있다. 이러할 경우에 사용되는 개념이다.

● 서버/클라이언트 모드

각 회선별로 서버/클라이언트 모드를 설정할 수 있다. Tmax 게이트웨이와 달리 하나의 게이트웨이에

서버 모드 회선과 클라이언트 모드 회선이 같이 있을 수 있다.

또한 클라이언트 모드의 경우 'client(수시)'라는 모드가 있다. 이 모드는 내부에서 대외로 보낼 때 사용

되는 것으로 보낼 전문이 있으면 그때 연결을 맺고 응답 전문을 받으면 연결을 끊는 모드이다. 이때는

sync 통신 밖에는 수행할 수 없다.

● 멀티 포트 Listen/connect 기능

AnyLink 게이트웨이는 멀티 포트 Listen(서버 모드)과 connect(클라이언트 모드)가 가능하다. 이 포트들

은 독립적으로 구성되며, 한 게이트웨이 내에서 서버 모드와 클라이언트 모드가 동시에 수행될 수 있다.

● 동기(Sync)/비동기(Async) 통신

AnyLink 게이트웨이가 요청 전문을 내보낼 경우 해당 세션으로 응답 전문을 받을 때까지 그 세션을 사

용하지 못하는 것이 동기(Sync) 통신이고, 응답 전문을 받기 전에 요청 전문을 보낼 수 있는 경우는 비

동기(Async)이다.

비동기 통신일 경우 응답 전문을 판단하기 위해, External 게이트웨이는 전문추적번호, Internal 게이트

웨이는 custom.c의 alinkusr_info_t 구조체의 uid를 이용해서 응답 전문을 판단해낸다.(“2.3.1. custom.h”

참조) 동기 통신은 응답이 오기 전까지 그 세션을 사용할 수 없기 때문에, 비동기 통신이 회선 사용 효율

이 높다.

제2장 TCP/IP 게이트웨이 5

● Packet Split

Mapper로부터 온 데이터가 업무에 등록된 패킷크기보다 클 경우, 전문을 여러 개로 나누어서 보내는

기능이다. 예를 들어 라우터를 통해서 TCP/IP로 보낸 것을 X.25로 변환하면 라우터로 보낼 때 4KB 단

위로 나눠서 보내야 하는 경우가 있다. 이러한 경우 사용되는 기능이다.

거래별로 패킷 크기와 헤더 크기를 재정의해서 나누어 보낼 수 있다. 특히 배열로 된 전문을 패킷 단위

로 나눌 경우, 배열 구조체의 크기와 한 패킷에 들어갈 배열 개수가 달라질 때 이 기능을 사용할 수 있다.

아래 그림과 같이 거래 측에 등록된 값을 우선으로 패킷을 나누는 기능을 수행한다. Request Input, Re

sponse Output 방향은 요청 방향 정보를 사용하고, Request Output, Response Input 측은 응답 방향 정

보를 사용한다.

[그림 2.1] Packet Split의 매핑 구간별 적용 파라미터

이와 같이 각 영역에 맞는 헤더 크기, 패킷 크기를 구하면, Packet split 하는 과정은 다음과 같이 Mapper

에서 넘겨준 전문을 헤더+패킷 크기 단위로 반복해서 자른다.

[그림 2.2] packet split 과정


게이트웨이는 put_msg_info 함수에서 max_num, cur_num 변수를 제공해서 max_num에는 총 split된

packet 수, cur_num은 현재 송신할 packet 순번(1부터 시작)을 알려준다. 위 그림에서 3번의 전문에 각

각 'max_num = 3'으로 해서 cur_num은 1,2,3으로 순서대로 넘겨주는 형태로 put_msg_info가 3번 호출

된다. 매번 호출되는 put_msg_info에서 이 번호를 이용하여 공통부에 건수 필드 등을 다시 설정해야 한

다.

● Packet Concatenate

packet split의 역으로 리모트로 부터 packet이 split되서 들어올 수가 있다. 게이트웨이는 이 나눠진

packet을 취합하는 기능을 수행한다. Packet 이 나눠졌는지 여부는 get_msg_info에서 사용자가 flags에

TPBLOCK flag를 켜주면 된다. TPBLOCK이 설정되어 있으면 다음에 그 세션으로 들어오는 데이터를

취합한다. 더 이상 flag가 켜져있지 않은 시점까지 취합한 후 파싱을 수행한다.

아래 그림에서 헤더부는 3회 반복되나 이것은 첫 번째 전문의 것이 채워지며 나머지 패킷 크기에 해당

하는 부분들이 뒤에 이어진다. 이 전문은 Mapper로 전달되는 전문으로 Mapper와 사용자 서비스에서

조작이 가능하므로 첫 번째 전문으로만 설정한다.

[그림 2.3] packet concatenate 과정

2.1.2. 통신헤더 유형

통신헤더 유형은 다음과 같이 3가지를 지원한다.

● TCP/IP 통신헤더

일반적으로 TCP/IP 통신을 할 경우, 전체 전문 길이를 알 수 없기 때문에 고정된 길이의 TCP/IP 통신헤

더를 전문 앞에 붙여서 보낸다.

TCP/IP 통신헤더는 통신헤더와 공통헤더로 구분이 된다. 통신헤더는 단순히 나머지 전문 길이를 알려

주기 위해 양단의 게이트웨이 사이에서만 정의된 구조체로 Mapper로 전달되지 않는다. 공통헤더는 전

문의 공통부내에 전체 전문 길이 정보가 있어서 별도의 통신단에 정의된 TCP/IP 헤더 없이 공통부를 활

용할 수 있는 경우이다. 이 경우는 받은 데이터 전체를 Mapper로 전달한다.

이와 같은TCP/IP통신헤더 방식에서는 get_msg_length 함수를 이용하여 통신헤더에 정의된 전문의 나

머지 길이를 알아낼 수 있다.


● 고정길이

모든 전문의 길이가 동일한 길이라면 통신헤더가 없이 처리가 가능하다. 게이트웨이는 고정길이만큼만

한 번에 읽어 들인다.

● END 문자

특정 문자 단위로 전문을 끊어 읽어야 할 경우에 해당된다. 통신헤더가 별도로 없으며, 게이트웨이는 고

정된 정해진 길이만큼 읽어내고 사용자가 get_end_msg함수를 통해서 전문의 길이를 알려줘야 한다.

만약, 정해진 길이보다 클 경우 음수를 리턴하면 다시 읽는 과정을 수행한다.

2.1.3. 대외 송수신 방식

스튜디오의 기관-업무정보에 '대외 송신 방식' 필드에 등록된 값으로 대외 기관과 송수신할 때 요청 전문

을 내보내는 규칙이나 응답 전문을 내보내는 규칙을 정의하는 것이다. 상대기관으로 먼저 요청 전문을 내

보낼 경우(Outbound)는 RoundRobin 방식을 따른다.

상대기관으로부터 요청 전문을 받는 경우(Inbound)는 다음의 3가지 유형으로 나뉜다.

● Self Session 방식

리모트 노드에서 요청 전문이 들어올 경우, 응답은 들어온 세션으로 나간다.

● RoundRobin 방식

요청 전문이 어느 세션으로 들어왔는지와 무관하게 순차적으로 열린 세션으로 전문을 보낸다. 3000~3010

번까지 그 기관-업무에서 사용한다고 하면 각각의 포트로 균등하게 내보낸다.

● Selection 방식

특정 회선으로 들어온 것은 출력 회선으로 등록된 회선으로 내보낸다. 예를 들어 3000번 포트로 들어온

것은 3001번으로 나가고, 3002번은 3003번으로 나간다. Selection인 경우 한 회선 안의 여러 세션들이

돌아가면서 사용되지 않고 한 두 가지만 사용될 가능성이 있다.

2.1.4. 파싱

입력 전문의 기관/업무/종별/거래 코드와 요청/응답 전문 여부를 알아내는 과정이다. 기관-업무 파싱을 수

행 후 게이트웨이 유형에 따라 대외/대내 파싱을 수행한다.

대내외 파싱 도중 에러가 발생하면 파싱 오류 서비스를 호출해서 응답 전문을 생성하여 리모트 노드로 전

달한다. 서비스가 등록되어 있지 않으면 버린다.

기관-업무 파싱

기관-업무 파싱은 현재 들어온 전문의 기관-업무를 찾는 과정으로 전문종별 코드, 거래구분 코드의 위치

를 찾기 이전에 수행되어야 하는 과정이다. 기관-업무파싱 중 에러가 발생하면 해당 전문은 버린다.

파싱 방식은 게이트웨이별, 회선별, 기관-업무 유일키를 이용한 방식 3가지가 있다.


설명구분

게이트웨이에 기관-업무를 할당하면 그 게이트웨이로 들어온 모든 전문은 그

기관-업무로 파싱된다.

게이트웨이별 파싱

회선에 기관-업무가 할당된 경우(기관-업무-회선 정보가 특정 회선에 대해 1

개의 기관-업무만 할당된 경우), 그 회선으로 들어온 전문은 모두 그 기관-업

무로 파싱된다.

회선별 파싱

한 회선에 여러 기관-업무가 할당된 경우(기관-업무-회선 정보가 특정 회선에

대해 여러 개의 기관-업무만 할당된 경우), 게이트웨이에 등록된 기관-업무

기관-업무 유일키 파싱

유일키 정보를 이용하여 TXID를 추출한 후 기관-업무에 등록된 TXID와 비교

하여 찾아낸다.

일단, 요청 TXID 중 비교하여 찾아내며, 없으면 응답 TXID를 찾는다. 요청

TXID를 찾아 대내외 파싱을 수행하는 도중 종별 코드가 응답종별일 경우는

다시 응답 TXID를 찾아 해당 기관-업무를 얻어내 다시 대내외 파싱을 수행한

다.

대외 파싱

대외 전문의 경우, 전문종별 코드/거래구분 코드 구조로 되어 있다. 파싱의 최종 결과는 기관/업무/종별/거

래를 찾아내는 것인데 기관-업무 파싱에서 찾지 못한 종별,거래 코드를 찾아내는 과정이다.

게이트웨이 유형이 'External'이면 대외 파싱 방식이 적용된다. 대외 파싱은 해당 업무에서 종별 코드 위치

정보로 종별 코드를 찾아낸 후, 종별 코드 정보에서 거래 코드 위치 정보로 거래 코드를 얻어낸다. 위치 정

보가 잘못됐거나 종별/거래정보가 디플로이되지 않은 경우 파싱 오류가 자주 발생한다.

대외 파싱은 파싱 일련의 과정이 스튜디오에 등록된 파라미터로만 이루어지므로 사용자 입장에서 coding

을 하지 않고 구현이 가능한 장점이 있다.

대내 파싱

대내 전문 구조가 대외 전문과 달리 종별 코드/거래 코드가 없는 형태로 구성되어 있을 경우를 위해 수행

하는 방식이다. 이 경우 일반적인 규칙이 없고, 예를 들어 12자리 거래 코드 하나만으로 정의되기도 하고,

여러 필드를 조합해야 거래를 구분해낼 수도 있다. 이 경우는 대외 파싱과는 다른 방식을 이용해야 한다.

게이트웨이 유형이 'Internal'이면 대내 파싱 방식이 적용된다. 대내 파싱은 업무 일반 정보에서 거래 코드

키 정보1,2,3에 등록된 키 정보를 전문 내에서 추출한다(최대 3개까지 등록 가능). 키 정보를 조합하여 스

튜디오에 등록된 종별/거래 코드 정보를 찾아낸다(이 종별/거래 코드는 대외 기관으로 나가는 전문과 관련

되어 있음). 즉, 거래-일반 정보에 거래 코드 키 값 정보로 들어가 있는 것과 일치하는 업무/종별/거래 코드

를 찾는다.

대내 파싱은 거래 코드를 먼저 찾은 후, 종별 코드 정보를 얻어내는 형태를 취한다. 키 정보 1,2,3로 부터

종별 코드가 수행하던 기능인 요청/응답 전문인지는 여부를 알아낼 수 없으므로 대내 파싱에서 요청/응답

여부는 get_msg_info에서의 리턴 값으로 확인한다.


비동기(Async) 통신(회선 재사용 여부가 'Yes'일 때)을 할 경우, 전문 추적번호 또한 없으므로 Mapper가

게이트웨이를 호출한 시점에 get_unique_id 함수를 통해서 유일 키를 추출해내고, 응답 전문이 오면

get_msg_info에서 info->uid에 설정되는 값을 통해서 유일 키를 얻어낸다.

대내 파싱은 사용자 로직이 개입할 여지가 좀 더 많아짐으로써 대외 파싱에 비해 광범위한 파싱 방식을 수

행할 수 있다.

파싱 오류

대내외 파싱 도중 오류가 발생할 경우(예를 들어, 종별/거래코드를 찾지 못한 경우), Mapper로 전문을 전

달할 수 없는 상황이 발생한다. 이렇게 되면 대외 기관으로 응답 전문을 매핑해서 넘겨줄 수 없다. 파싱 오

류는 일종의 포맷 오류로써 AnyLink 내에서는 Mapper를 호출할 수 없기 때문에 응답 전문을 돌려주기 위

해 사용자가 작성한 파싱 오류 서비스를 통해서 응답 전문을 생성해 낸다.

기관-업무 정보의 '파싱 오류 서비스명'에 등록하면 되며, 등록되어 있지 않으면, 에러 로그를 쌓은 후 전문

은 버린다. 에러 로그에 에러 구분이 파싱으로 되어 있는 코드들을 참조한다. 자세한 내용은 “2.4. 파싱 오

류 서비스”을 참고한다.

2.1.5. 타임아웃 및 지연 응답 처리

대외기관으로 요청전문을 보낼 경우, 네트워크 상태나 상대기관의 상태에 따라 응답전문이 응답 대기시

간 내에 오지 않을 수 있다.

타임아웃 처리는 이 응답 대기시간 내에 응답전문이 오지 않을 경우, 호출한 Mapper에서 TPFAIL로 re

turn(tpurcode값은 TPETIME)하게 된다. 타임아웃 처리가 된 이후에 들어온 응답전문은 지연응답 서비스

로 전달되어 지연응답에 대한 처리를 별도로 수행할 수 있다. 거래와 업무에 모두 서비스명을 등록하지 않

으면 전문은 버린다. 게이트웨이에서 지연 응답인지 판단은 파싱 도중에 발생한다.

응답전문 중 External 게이트웨이일 경우는 전문추적번호, Internal 게이트웨이는 info->uid에서 기존에 보

냈던 요청전문과 일치하는 것이 없을 때 지연응답으로 판단한다. 그러므로 요청전문을 보낸 적이 없는데

응답전문에 잘못된 UID 정보로 넘어올 경우도 지연응답으로 판단된다는 것에 유의한다. 지연응답처리 서

비스에서는 실제 지연응답인지 아니면 잘못된 전문인지에 대한 판단을 수행해야 한다.

자세한 내용은 “2.5. 지연 응답 처리 서비스”을 참고한다.

2.1.6. 장애 처리

TCP/IP 통신 도중 장애가 발생한 경우를 감지하고 게이트웨이를 재기동하지 않고 자동 복구할 수 있는 방

법을 제공한다.

특히 두 기관 사이에 라우터나 스위치(switch)가 있을 경우, FIN packet(종료 패킷)이 정상적으로 전달되

지 않아 상대 기관은 세션이 끊겼으나 반대 측에서는 살아 있는 것으로 유지될 수가 있다. 이러한 상황에

서 이 세션으로 데이터를 계속 보내서 FIN packet을 받으려고 하는 방법이 테스트 전문 송수신과 Health

데이터 송신이며, 장기간 데이터의 흐름이 없는 세션을 끊는 방법(New Session Accept, Session Timeout)


도 있다. 또는 장비가 직접 해당 정보를 알려주는 경우도 있는데(SNMP Trap) 현재 버전에서는 지원되지

않는다.

● 테스트 전문 송수신

두 기관 사이에 테스트 전문이 정의된 경우, 테스트 전문을 주고받으면서 상대 기관에서 응답이 오지 않

을 경우, 에러를 감지해낸다. 이 경우는 게이트웨이 단에서 지원되는 것은 없으며 다만 상대 기관의 장

애 상태를 찾아내는 것이 가장 좋은 방법이다.

● Health 데이터 송신

테스트 전문이 정의되지 않은 경우지만 통신헤더를 이용해서 주기적으로 데이터를 보내서 장비 이후

영역이 끊어졌을 때 FIN packet을 받을 수 있는 방법이다. 이때는 테스트 전문 송수신과 달리 상대 기관

에서 응답을 주지 않는다. 그러므로 이 기능은 상대 기관이 장애 상태인지를 즉각 파악할 수는 없고, FIN

packet을 받아내기 위해 보내는 것이다.

보내는 데이터는 사용자 프로그램의 set_connect_chkmsg라는 함수에서 설정한다.

● New Session Accept

이 옵션을 선택하지 않은 게이트웨이는 회선의 세션 개수를 초과해서 connect 해올 경우 바로 끊어버린

다. 그러나 이 옵션을 선택하면 새로 접속해온 것은 받고 기존에 가장 오랫동안 사용되지 않던(데이터의

흐름이 없던) 세션을 끊는 기능이다. 해당 회선이 서버 모드일 때만 가능하다.

● Session Timeout

정해진 시간 동안 세션이 사용되지 않으면 자동으로 끊는다.

● SNMP Trap

현재 지원되지 않는다.

● New session accept/Session timeout

회선에 설정된 최대 세션 개수만큼 모두 연결이 되어 있는 경우, 새로운 세션이 접속시도를 하게 되면

가장 오래도록 사용하지 않은 세션을 끊고 새로운 세션을 받아들이게 된다. 또한 설정된 세션 Timeout

시간을 초과한 경우 그 세션을 끊도록 한다. 기존의 New session accept 방식과 Session timeout 방식

을 동시에 사용할 수 있도록 하는 장애처리 방식이다. 해당 회선이 서버모드일 때만 가능하다. 3.2.5 이

상에서 지원된다.

● Session timeout(send check message)

Session timeout 시간동안 어떠한 전문 메시지도 해당 세션으로 송수신되지 않을 경우 check message

를 상대 기관으로 송신한다. 3.2.4 이상에서 지원된다.

● Session timeout(R/R)

회선이 self-session 방식으로 응답을 보내야 하는 경우 session timeout 시간이 지났다 하더라도 거래

타임아웃 시간 동안 세션을 끊지 않고 유지하도록 하는 장애 처리 방식이다. 거래 타임아웃 이후 해당

세션을 끊도록 한다. 3.2.4 이상에서 지원된다.

● 장애회선 block 및 자동 복구

비동기(async) 통신 방식의 회선에서 요청전문에 대한 응답전문이 일정 횟수만큼 그 회선으로 되돌아

오지 않았을 때를 장애로 판단하고 그 회선을 blocking 한다. 추가적인 요청전문은 연결된 다른 회선으


로 우회하여 들어가게 하며 blocking 된 회선은 다시 통신이 가능한 상태로 복구한다. 3.2.5 이상에서 지

원된다.

● Session timeout(after midnight)

00시 00분 00초부터 Session Timeout에 설정된 시간이 경과했음에도 불구하고 거래가 없는 회선을 모

두 찾아 연결을 끊도록 하는 방식이다. 3.2.5 이상에서 지원된다.

● Session close from new session accept:

Session timeout(after midnight)과 New Session Accept를 동시에 수행할 수 있는 방식이다. 즉, 00시 00

분 00초부터 Session Timeout에 설정된 시간이 경과했음에도 불구하고 거래가 없는 회선을 모두 찾아

연결을 끊거나 회선에 설정된 최대 세션 개수가 모두 채워진 상태에서 새로운 세션이 연결을 시도하면

때 현재 연결된 세션 중 가장 오랫동안 거래가 없는 세션을 끊어주고 새로운 세션을 연결하도록 한다.

해당 회선이 서버모드일 때만 가능하다. 3.2.5 이상에서 지원된다.

2.1.7. 파일 로깅

게이트웨이를 통해 송수신한 전문을 파일로 남긴다. Mapper와 남기는 형식은 동일하다.

파일 로깅을 남기려면 [기관-업무정보] 탭의 로그정보의 '파일 로깅'이나 [거래-일반 정보] 탭의 로그정보

의 '파일 로깅'에서 로그를 남기고 싶은 구간(게이트웨이 요청입력, 게이트웨이 요청출력, 게이트웨이 응

답입력, 게이트웨이 응답출력 중 1개 이상)을 설정하면 된다.

● 파일 경로

파일 로그 유형에 따라 다음의 순서로 먼저 등록된 값이 적용된다.

– 게이트웨이별

1. 노드에 있는 로그 파일 경로

2. $TMAXDIR/appbin

– 기관별, 기관-업무별, 종별

1. 기관-업무에 등록된 로그 파일 경로

2. 노드에 있는 로그 파일 경로

3. $TMAXDIR/appbin

● 파일명

기관-업무 정보의 '파일 로그 유형'에 따라 달라진다.

– 게이트웨이별

g.<서버명>.YYYYMMDD.log

– 기관별

g.<기관코드>.YYYYMMDD.log


– 기관-업무별

g.<기관코드><업무코드>.YYYYMMDD.log

– 종별

g.<기관코드><업무코드>.<종별코드>.YYYYMMDD.log

● 파일 구조

시:분:초:밀리초;기관코드;업무코드;종별코드;거래코드;log_id;log_point;header_size;

tx_uid;err_code;tx_time;res_flag;xid;tx_state;session_index;전문길이;전문데이터

– log_point

설명설정값

게이트웨이에서의 ReqIn1

Mapper에서 ReqIn2

Maper에서 ReqOut3

게이트웨이에서 ReqOut4

게이트웨이에서 ResIn5

Mapper에서 ResIn6

Mapper에서 ResOut7

게이트웨이에서 ResOut8

게이트웨이에서 응답 포맷 ReqIn9

Mapper에서 응답 포맷 ReqIn10

Mapper에서 응답 포맷 ReqOut11

게이트웨이에서 응답 포맷 ReqOut12

다음은 위 설명의 부연설명이다.

설명설정값

입력 요청 전문으로 요청 전문이 요청 매핑을 타기 전ReqIn

출력 요청 전문으로 요청 전문이 요청 매핑을 탄 후ReqOut

입력 응답 전문으로 응답 전문이 응답 매핑을 타기 전ResIn

출력 응답 전문으로 응답 전문이 응답 매핑을 탄 후ResOut


2.1.8. 에러 로깅

전문처리 도중 에러가 발생하여 정상적으로 Mapper로 전달할 수 없거나 리모트 노드로 전달되지 않을 경

우 에러 로그에 남는다.

에러 로깅은 파일 로깅과 달리 설정에 상관 없이 다음의 파일명으로 반드시 남긴다.

error.YYYYMMDD.log

파일 구조는 다음과 같다.

시:분:초:밀리초;에러코드;log_id;노드명;대내외구분;SERVER(게이트웨이)명;전문길이;전문데이터

● 에러코드

Online 게이트웨이 에러 코드는 다음과 같다.

원인후처리방법에러구분에러코드

기관 코드/업무 코드를 찾지 못했을 때버림파싱101

업무 코드를 찾지 못했을 때파싱오류호출파싱102

종별 코드를 찾지 못했을 때파싱오류호출파싱103

응답 포맷 에러 전문 입력버림104

대외 파싱 중 거래 코드를 못 찾았을 때파싱오류호출파싱105

대내 파싱 중 키 값들로 거래 코드를 찾지 못

했을 때

파싱오류호출파싱106

리모트 노드로 내보낼 회선이 없을 때버림(요청시)송신에러108

파싱오류호출 (응답

시)

write 에러나 session close일 때버림송신에러109

기존에 내보냈던 요청 전문 목록에 없을 경우

타임아웃으로 간주함

버림시스템110

게이트웨이가 Mapper를 호출한 결과가 실패

로 돌아왔을 때

버림시스템111

회선 재사용 여부가 'No'일 때 대외 기관에서

들어온 전문이 응답 전문이 아닐 경우

버림시스템112

버림시스템999 – malloc 에러

– put_msg_info에서 error return

– 0 Byte 데이터를 보내려 할 때

– 파싱, 송수신회선 선택 등의 처리를 마치고

리모트 노드로 송신하려고 할 때 에러 발생

한 경우


● 대내외 구분

설명구분

External1

Internal2

CMapper3

JMapper4

● SERVER 명

대내외 구분에 따라 다음의 내용이 저장된다.

설정값대내외 구분

게이트웨이 서버명1, 2

Mapper를 등록할 때 설정하는 서버명/컨테이너명3, 4

2.1.9. DB 로깅

3.2.5 이하의 버전에서는 Mapper에서만 DB 로깅을 할 수 있었으나 4.0 버전부터는게이트웨이를 통해 송

수신한 전문도 DB에 로깅될 수 있는 기능을 제공한다. 게이트웨이가 Master Log 서비스를 호출하면

Master Log 서비스가 ALMSTLOG라는 테이블에 로깅한다.

DB 로깅을 하려면 스튜디오에서 '기관-업무정보'의 '로그정보=>DB로깅'이나 '거래-일반정보'의 '로그정보

=>DB로깅'에서 로그를 남기고 싶은 로깅 구간(게이트웨이 요청입력, 게이트웨이 요청출력, 게이트웨이

응답입력, 게이트웨이 응답출력 중 1개 이상)을 선택하면 된다.

2.1.10. Cache 기능

Cache 기능은 대외로부터 받은 전문 중 일부를 잘라서 저장해두었다가 작업을 끝낸 후 다시 붙이는 기능

이다.

Cache 기능에는 기관-업무 정보에서 등록하는 Gateway Cache와 업무정보에서 등록하는 Mapper Cache

가 있다. Online Gateway에 해당하는 기능은 Gateway Cache이지만 Gateway Cache와 비교하여 Mapper

Cache와 Base Mapping에 대해서도 간략히 설명한다.

Gateway Cache

기관-업무 정보에서 등록하는 이 Cache는 주로 동일한 업무이나 기관마다 종별 코드 위치가 다를 경우 사

용한다. 실제 Cache가 일어나는 곳은 Mapper이지만 이 Cache의 주요 목적이 게이트웨이에서 파싱을 하

기 위한 것이기 때문에 Gateway Cache라고 한다.


[그림 2.4] 게이트웨이로 들어온 요청 전문

여러 기관이 같은 업무를 사용하는데 종별 코드 앞에 [그림 2.4]과 같이 기관마다 길이가 다른 임의의 데이

터가 들어오는 경우가 있다. 이런 경우, 기관마다 업무를 다시 등록하지 않고 파싱하기 위해서는 앞부분의

데이터(회색으로 표시된 부분)를 잘라낸 후 종별 코드, 거래 코드를 찾고 다시 잘라낸 데이터를 [그림 2.5]

과 같이 앞 부분에 붙여서 Mapper에게 넘겨준다.

[그림 2.5] 게이트웨이에서 Mapper로 넘긴 요청 전문

전문이 Mapper로 전달되면 Mapper는 Cache될 데이터를 잘라내고 요청 매핑을 한다. 그리고 요청에 대

한 응답 전문이 들어오면 응답 매핑을 한 후 Cache하고 있던 데이터를 다시 전문의 앞에 붙여서 게이트웨

이에게 넘겨준다. 게이트웨이가 Mapper로부터 응답 전문을 받으면 전문의 앞에 있는 Cache된 데이터를

다시 요청 전문의 형태로 위치를 옮겨서 대외로 응답 전문을 보낸다.

Cache되는 데이터는 위치와 내용이 변하지 않기 때문에 매핑에는 사용되지 않는 필드를 응답 전문에 그

대로 보내야할 경우에도 사용할 수 있다.

Mapper Cache

Mapper Cache의 기능은 게이트웨이에서 Cache에 대한 처리를 전혀 하지 않는다는 점에서 Gateway

Cache와 차이가 있다.

매핑에는 사용되지 않는 데이터지만 파싱에는 사용되기 때문에 Gateway Cache처럼 파싱 전에 잘라서 위

치를 옮겨 놓을 수 없는 경우에 사용된다. [그림 2.4]와 [그림 2.5]에서 회색으로 표시된 부분에 종별 코드

와 거래 코드 정보가 들어있는 경우이다. 대표적인 예로는 VO 클라이언트에서 수신된 전문이다.


Base Mapping

Base Mapping은 입력전문의 특정 필드를 그대로 보존하여 응답전문에 써서 내보낸다는 점에서 Gateway

Cache와 비교되는 기능이다.

Gateway Cache를 사용하면 요청전문에서 응답전문으로 나갈 때 하나의 필드를 그대로 내려 보낼 수 있

다. 그리고 Base Mapping을 사용하면 다수의 필드에 대해서 데이터를 그대로 응답전문에 사용할 수 있다.

[그림 2.6] Base Mapping

Base Mapping 이란 요청전문을 저장해 뒀다가 응답매핑을 할 때 바탕으로 사용하는 것이다. 그래서 응답

전문에서 그대로 사용하고자 할 때에 사용되는 기능이다.

2.1.11. 백업(Backup) 게이트웨이

게이트웨이는 회선을 통해서 대외계로 전문을 내보낸다. 그런데 게이트웨이에 등록된 모든 회선이 끊어

져 있다면 등록된 백업(Backup) 게이트웨이로 전문을 tpforward 한다.

[그림 2.7] 백업(Backup) 게이트웨이

백업 게이트웨이는 다른 노드에 있더라도 사용이 가능하다.


2.2. 환경설정본 절에서는 TCP/IP 게이트웨이의 환경설정에 대해 설명한다.

2.2.1. Tmax 환경설정

Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다.

● SERVER 절

– SVRTYPE을 CUSTOM_GATEWAY로 한다.

– 게이트웨이는 여러 개를 띄워서 처리할 수 없으므로 반드시 MIN, MAX를 1로 한다.

– CLOPT는 Tmax와 AnyLink, user callback 함수에 전달되는 옵션을 설정할 수 있다.

CLOPT = "<영역 1> -- <영역 2> -- <영역 3>"

영역1은 Tmax에 전달되는 옵션이고 영역 2는 AnyLink에 전달되는 옵션이다. 영역 3은 사용자 callback

함수인 init_algw_info에 전달되는 옵션이다. Tmax, AnyLink, 사용자 함수로 전달되는 옵션은 ‘--‘으로

구별되며, 위치가 다르게 설정될 경우 옵션을 읽어들일 수 없으므로 주의한다.

CLOPT는 다음과 같은 옵션을 설정할 수 있다.

설명옵션

파일을 로깅할 때 로그 Pool의 크기로 이 개수만큼 파일에 쌓이지 않고 대기하고 있을

수 있는 전문 수이다. (기본값: 500, 단위: 개)

g

relay 서비스명이다. 이 서비스가 Tmax 환경 파일에 설정되어 있지 않으면 Mapper가

게이트웨이를 호출했을 때 게이트웨이는 정상 리턴을 하나 Mapper에서 TPENOENT

가 떨어질 수 있으므로 주의해야 한다.(기본값 : MAPPRLYSVC, CMapper와 동일)

r

파일을 로깅할 때 Sync mode로 동작한다. 이 옵션을 사용할 경우 g 옵션은 무의미해

진다.

s

파일을 로깅할 때 특정 크기 단위로 나눈 파일 크기이다.n

클라이언트 회선이 특정 로컬 IP로 바인드되어 상대기관과 connect되길 원할 경우 설

정한다.

D

-l IP 주소를 등록하면 서버 회선에서 해당 IP 주소와 연결되었던 세션을 종료할 때 서

버 회선의 세션 종료 메시지가 출력되지 않도록 한다.

l(L의 소문자)

● SERVICE 절

해당 서비스명을 등록한다. 서비스명은 15자 이내 임의의 값으로 한 개만 등록한다.


2.2.2. 게이트웨이 등록

Admin에서 게이트웨이를 등록해야 한다.

● 등록 항목

해당 게이트웨이가 속한 노드를 선택한 후 컨텍스트 메뉴에서 [Gateway 추가]를 선택하거나 오른쪽 패

널에 있는 [Gateway 추가] 버튼을 클릭한다.

설명항목

Tmax 서버명을 등록한다.이름

선택한 노드명이 자동 입력되어 있다.노드명

Tmax 환경 파일에 설정한 서비스명을 등록한다.서비스명

회선 장애 발생의 경우 호출될 서비스명을 등록한다.백업 서비스명

'TCP/IP'를 선택한다.프로토콜

'온라인'을 선택한다.Type

파싱 방식을 선택하기 위해, 대외용(External), 대내용(Internal)을 등록한다.대내외구분

게이트웨이가 특정 기관-업무에만 종속된 경우에 값을 할당해주면 게이트웨이-

level 기관-업무 파싱을 수행한다.

기관코드/업무코드

여러 기관-업무가 등록된 회선이 있을 때, 기관-업무 유일키 파싱에 필요한 위치

정보를 등록한다.

기관-업무 유일키 off

set/length

TCP/IP통신 방식에 따라 선택한다.메시지 길이 지정

– 통신헤더 : 고정된 길이의 TCP/IP 통신헤더를 사용하는 경우

– 고정길이 : 전문의 길이가 거래와 상관없이 고정된 경우

– END 문자 : 특정 구분자 단위로 끊어서 읽는 경우

'메시지 길이 지정'이 '통신헤더'일 때 다음 중에 하나를 선택한다.통신헤더타입

– 통신헤더 : TCP/IP통신헤더를 Mapper로 전달하지 않는 경우

– 공통헤더 : TCP/IP통신헤더를 Mapper로 전달하는 경우

예를 들어, 라우터를 통해서 기관과 붙는 경우, 라우터 헤더가 붙을 수 있는데 이

경우는 '통신헤더'를 설정한다. 공통부 내에 전문 전체길이 정보가 있어서 그 부

분을 먼저 읽은 후 처리해야 할 경우 '공통헤더' 타입을 설정한다.

'메시지 길이 지정'에서 '통신헤더'로 등록된 경우에만 적용되는 TCP/IP 통신헤

더의 길이이다.

통신헤더길이

'통신헤더타입'이 '통신헤더'이면 TCP/IP 통신헤더길이, '공통헤더'이면 전문공통

부의 길이이다.

'메시지 길이 지정'이 '고정길이'일 때, 데이터의 길이이다. 그 외에는 사용하지

않는다.

메시지 길이


● 게이트웨이 등록 예 (대외기관용 TCP/IP 게이트웨이, 방카슈랑스 TCP/IP 게이트웨이)

설명항목

tcpgwext이름

TCPGWEXT서비스명

TCP/IP프로토콜

온라인Type

External대내외구분

통신헤더메시지 길이 지정

공통헤더통신헤더타입

160통신헤더길이

2.2.3. 회선(Line) 등록

Admin에서 회선(Line)을 등록해야 한다. 회선은 게이트웨이가 대외/대내 기관으로부터 요청/응답을 받는

논리적인 연결을 말하며 등록된 후에는 수정/삭제뿐 아니라 중지/재개될 수 있다.

● 등록 항목

설명항목

회선을 대표하는 symbol명이다. 통신 프로토콜과 무관하게 유일하게 지칭할 수

있는 명칭으로 정한다.

회선이름

회선이 포함된 노드명으로 기본값이 입력된다.노드명

회선이 포함된 게이트웨이명으로 기본값이 입력된다.Gateway 이름

각 모드별로 다음의 항목을 등록한다.회선명/IP주소

– 서버 모드 : 노드의 IP

– 클라이언트 모드 : 연결할 IP

각 모드별로 다음의 항목을 등록한다.LU이름/포트번호

– 서버 모드 : Listen할 포트

– 클라이언트 모드 : 연결할 포트

각 모드별로 다음의 항목을 등록한다.세션수

– 서버 모드 : 최대 수용할 세션 수

– 클라이언트 모드 : 연결할 세션 수

각 모드별로 회선을 선택 할 수 있다.TCP/IP C/S구분

– Server : 서버 모드인 경우

– Client : 클라이언트 모드인 경우


설명항목

– Client(수시) : 매번 요청 전문을 보내고 응답 받은 후 끊을 경우(이때는 '회선

재사용 여부'가 'NO'로 고정)

– Client(수시 Oneway)

– Client(On demand)

– Client (즉시연결복원)

– Client(MegaBox XOT)

– Client(MegaBox EOR)

자세한 내용은 "AnyLink Admin 안내서"를 참고한다.

회선의 뱡향성에 대한 설정이다.처리방식

– ANY_CHANNEL : 게이트웨이 기준으로 송수신이 가능한 경우

– OUT_CHANNEL : 송신만 할 경우

– IN_CHANNEL : 수신만 할 경우

클라이언트 모드일 때 세션이 끊어지고 난 후 재접속하는 주기이다. 만약, 이 값

을 입력하지 않을 경우, 장애가 발생하여 세션이 끊어지면 게이트웨이를 재기동

하기 전까지 재접속하지 않는다.

재접속 간격

리모트 노드와 비동기(Async) 통신을 할지 여부이다.회선 재사용 여부

– YES : 특정 세션으로 보냈을 때, 그 세션으로 응답이 오기 전에 또 보낼 수 있

는 비동기 방식으로 동작한다.

– NO : 요청 전문을 보내면 응답이 올 때까지 해당 회선을 사용불가. 'TCP/IP

C/S 구분'이 'Client(수시)'일 경우는 'NO'로 고정한다.

서버 모드인 경우에는 약간 다른 의미로 사용된다. 클라이언트가 AnyLink 게이

트웨이에 연결해서 요청을 보내고 끊어진 경우 회선 재사용 여부에 따라 다음과

같이 동작한다.

– YES : 다시 클라이언트가 연결이 되면(동일한 세션 번호) 그 클라이언트로 응

답을 내보내준다.

– NO : 게이트웨이가 응답을 받았을 때 동일한 세션 번호로 클라이언트가 연결

되어 있다 하더라도 에러로 처리한다.

스튜디오의 기관-업무정보에서 '대외송신방식'을 'Selection'으로 선택했을 경우,

이 회선으로 들어왔을 때 응답 전문을 내보낼 회선의 '회선이름'이다.

출력 회선 이름

해당 회선에 문제가 발생했을 때 연락처나 기타 용도로 사용할 수 있는 공간이

다.

물리 회선 정보


2.3. 사용자 프로그램(custom.h, custom.c)Tmax 게이트웨이와 마찬가지로 AnyLink 게이트웨이에서도 TCP/IP 게이트웨이는 라이브러리 형태로 배

포가 되며 사용자가 custom.h/custom.c를 작성해서 컴파일함으로써 완성이 된다.

libalgw.a(.so/.sl) 형태로 제공되는 라이브러리는 libalgwd가 디버그(Debug) 버전이고, libalgw가 릴리즈

(Release) 버전이다. 이 라이브러리는 TCP/IP와 X.25 공용으로, 컴파일 방식과 CallBack 함수의 프로토

타입이 동일하고, 각 함수를 작성하는 방법만 다르다. 또한, CallBack 함수에 EBCDIC 전문이 들어올 수

있기 때문에 ASCII ↔ EBCDIC 변환을 위한 함수도 제공된다.

2.3.1. custom.h

custom.h에는 다음과 같이 alinkusr_info_t라는 구조체가 정의되어 있다.

Tmax 게이트웨이의 경우, msg_info_t라는 구조체가 있었는데 이와 대응되는 구조체로써 사용자는 수정

해선 안된다.

Tmax 게이트웨이에는 msg_header_size, comm_header_size라는 변수를 선언하게 되어 있었으나, AnyLink

게이트웨이는 이 크기를 Admin의 게이트웨이 설정에서 “통신헤더길이”항목에 등록한다. 그러므로 이 변

수에 대한 선언이 필요없으나 msg_header_t 구조체의 크기와 Admin에 등록한 값이 일치되도록 주의한

다.

각 항목에 대한 설명은 “2.3.2. custom.c”의 함수 설정을 참조한다.

/* -------------- anylink gateway custom.h ----------------- */

#ifndef _CUSTOM_H_

#define _CUSTOM_H_

#include <usrinc/tmaxapi.h>

#include <usrinc/aladmapi.h>

/* --------------- constant, macro definitions ------------- */

#define ALCLIENT 0x80000000

#define ALGWCLOSE 0x40000000

/* request/reply type : do not modify*/

#define REQUEST_MSG 0

#define REPLY_MSG 1

#define DIRECT_RETURN_MSG 2

#define REQ_FRMT 3

#define RES_FRMT 4

/* length marcos : do not modify */

#define LEN_INST_CODE 4

#define LEN_APPL_CODE 4

#define LEN_KIND_CODE 8

#define LEN_TX_CODE 32


#define LEN_SEARCH_KEY LEN_APPL_CODE+LEN_KIND_CODE+LEN_TX_CODE

#define LEN_SEARCH_KEY_SIZE 64

/* ------------- structure definitions --------------------- */

/* custom information : do not modify */

typedef struct msg_info {

int err;

int len;

int msgtype;

int max_num;

int cur_num;

int flags;

int node_id;

int gateway_id;

int channel_id;

char uid[32];

char inst_code[LEN_INST_CODE + 1];

char appl_code[LEN_APPL_CODE + 1];

char kind_code[LEN_KIND_CODE + 1];

char tx_code[LEN_TX_CODE + 1];

char log_id[LEN_LOG_ID + 1];

} alinkusr_info_t;

/* Modifiable structures sample

* - Simulator Server G/W Header */

typedef struct msg_header {

char len[10]; /* length of data */

char inst_code[LEN_INST_CODE]; /* inst code */

char appl_code[LEN_APPL_CODE]; /* appl code */

char kind_code[LEN_KIND_CODE]; /* kind code */

char tx_code[LEN_TX_CODE]; /* tx code */

char type[2]; /* type */

char resvd[4]; /* reserved */

} msg_header_t;

#endif /* _CUSTOM_H_ */

/* custom appl info */

typedef struct appl_cust{

char appl_code[LEN_APPL_CODE + 1]; /* appl code */

int kind_code_offset; /* 전문종별코드 offset */

int kind_code_len; /* 전문종별코드 길이 */

int key_offset1; /* 거래를 찾기위한 offset 1 */

int key_len1; /* 거래를 찾기위한 length 1 */






int conv_type; /* message 변환 type: 1=AA, 2=AE, 3=EA, 4=EE */

}appl_cust_t;

/* custom kind info */

typedef struct kind_cust{

char appl_code[LEN_APPL_CODE + 1]; /* 업무코드 */

char rep_kind_code[LEN_KIND_CODE + 1]; /* 대표 종별코드 */

char norm_kind_code[LEN_KIND_CODE + 1]; /* 종별코드 */

char reqerr_kind_code[LEN_KIND_CODE + 1]; /* 요청에러종별코드 */

char equ_kind_code[LEN_KIND_CODE + 1]; /* 등가종별코드 */

int req_tx_code_offset; /* 요청 거래코드 offset */

int res_tx_code_offset; /* 응답 거래코드 offset */

int tx_code_len; /* 거래코드 길이 */







} kind_cust_t;

/* custom tx info */

typedef struct tx_cust{

char search_key[LEN_SEARCH_KEY + 1]; /* shared memory search key */

char appl_code[LEN_APPL_CODE + 1]; /* 업무코드 */

char rep_kind_code[LEN_KIND_CODE + 1];/* 대표 종별코드 */

char tx_code[LEN_TX_CODE + 1]; /* transaction code */

char key_val[LEN_SEARCH_KEY_SIZE + 1];/* 거래를 찾기위한 key value */

} tx_cust_t;

/*----------- exported function declarations ------------*/

int get_grpline_cnt(int id);

int get_grpline_info(int id, char *inst_code, char *appl_code, int *next_idx);

int search_appl(char *aappl_code, appl_cust_t *appl_cust);

int search_kind(char *aappl_code, char *akind_code, kind_cust_t *kind_cust);

int search_tx_by_keyval(char *aappl_code, char *akey_val, tx_cust_t *tx_cust);

int send_custom_response(int id, char *dp, int len);

char *get_symbname_from_channel_num(int i);

char *get_out_symbname_from_channel_num(int i);

int gw_session_connect_by_symbname(char *symbname);

int get_line_status(char *symbname);

int get_peer_ip_from_channel_num(int idx, char *ipaddr);

int al_my_svrinfo(TMAXSVRINFO* info);

int al_read_msg(int idx, char *ptr, int nbytes, int ms);

int al_write_msg(int i, char *ptr, int nbytes, int ms);

int get_alline_info(int idx, line_tab_t *linetab);


int set_tx_timeout(int gwi, int timeout);

int set_session_active(int gwi);

int gw_tpacall2(char *svc, char *idata, long ilenl, char **odata, long *olen, long

flagsl);

int get_log_id(char *log_id);

#endif /* _CUSTOM_H_ */

2.3.2. custom.c

함수들은 다음과 같이 기능별로 구분된다.

● 리모트 노드로부터 데이터를 받았을 때 “통신헤더” 방식은 헤더를 먼저 읽고 헤더에서 나머지 길이를

얻어내서 그 길이만큼 읽어내고, “END 문자” 방식은 구분자가 있는 곳까지 읽어내야 한다. 이때 길이를

얻어내거나 구분자까지 읽는 함수가 get_msg_length와 get_end_msg이다. '고정 길이'의 경우는 해

당 길이만큼만 읽어내면 되기 때문에 사용자 함수가 필요없다.

● 위 함수가 호출되고 난 후 get_msg_info가 불려서 Mapper로 전달되기 전에 처리를 수행한다. 리모트

노드로 보내기 전에 put_msg_info를 호출하며 송신 완료 후는 put_msg_complete가 불려 사용자에

게 정상 송신했음을 알린다.

● Mapper로부터 요청이 왔을 때는 Internal 게이트웨이의 경우는 get_unique_id 함수가 불리며 여기서

uid를 setting해야 응답 전문을 받았을 때 찾을 수 있다. set_connect_chkmsg 함수는 장애 처리를 위

해 추가된 함수로 3.1.0 이상에서는 반드시 만들어 줘야 한다.

● init_algw_info 함수는 게이트웨이가 기동될 때 호출되는 함수이다. 사용자는 이 함수에서 CLOPT절로

부터 파라미터를 받아서 처리할 수 있다. 3.1.1 이상에서는 반드시 생성해야 한다.

● done_algw_info는 tmdown되는 경우 호출되는 함수로 3.2.2 이상에서는 반드시 생성해야 한다.

● shutdown_algw_info는 tmdown되는 경우 호출되는 함수로 3.2.5 이상에서는 반드시 생성해야 한다.

다음은 custom.c의 예제이다.

/* ------------------ anylink gateway custom.c --------------- */

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <string.h>

#include <time.h>

#include <sys/timeb.h>

#ifdef _WIN32

#include <winsock2.h>

#include <windows.h>

#include <io.h>

#else

#include <sys/ipc.h>


#include <sys/shm.h>

#endif

#include <malloc.h>

#include "custom.h"

/* ----------------------------------------------------------- */

/* int get_msg_length(msg_header_t *hp) */

/* */

/* hp: received message header. */

/* returns: remaining data body length. */

/* negative value on fail */

/* ----------------------------------------------------------- */

int get_msg_length(msg_header_t *hp)

{

char buf[11];

int len;

if (hp == NULL)

return -1; /* parameter error */

/* message body length : essential part */

memset(buf, 0x00, sizeof(buf));

memcpy(buf, hp->len, 10);

len = atoi(buf);

/* returns remaining data length */

return len;

}

/* ----------------------------------------------------------- */

/* int get_end_msg(int len, char *data) */

/* */

/* len : received message length. */

/* data : received message */

/* */

/* returns 0 >= : data receive complete (return received ength)*/

/* 0 < : data receive continue */

/* ----------------------------------------------------------- */

int get_end_msg(int len, char *data)

{

#ifdef _DBG

printf("get_end_msg: len=[%d]\n", len);

#endif

/* check end msg */


return len;

}

/* ----------------------------------------------------------- */

/* int get_msg_info(msg_header_t *hp, */

/* char *data, alinkusr_info_t *info) */

/* */

/* hp : received message header. */

/* data : received message body. */

/* info : received data information. */

/* */

/* returns: message type. */

/* - REQUEST_MSG : request message */

/* - REPLY_MSG : reply message */

/* negative value on fail */

/* ----------------------------------------------------------- */

int get_msg_info(msg_header_t *hp, char *data, alinkusr_info_t *info)

{

if (memcmp(hp->type, "01", 2) == 0)

info->flags |= ALCLIENT;

return REQUEST_MSG;

}

/* ----------------------------------------------------------- */

/* int get_unique_id(char *data, alinkusr_info_t *info) */

/* */

/* data : sending message body. */

/* info : sending data information. */

/* */

/* returns: positive value on normal */

/* : negative value on fail */

/* ----------------------------------------------------------- */

int get_unique_id(char *data, alinkusr_info_t *info)

{

if ((info == NULL) || (data == NULL))

return -1;

/* make uid */

return 1;

}

/* ----------------------------------------------------------- */

/* int put_msg_info(msg_header_t *hp, */


/* char *data, alinkusr_info_t *info) */

/* */

/* hp : sending message header. */

/* data : sending message body. */


/* */

/* returns: total sending message length. */

/* : negative value or zero on fail */

/* ----------------------------------------------------------- */

int put_msg_info(msg_header_t *hp, char *data, alinkusr_info_t *info)

{

char buf[11];

if ((info == NULL) || (hp == NULL) || (data == NULL))

return -1;

sprintf(buf, "%.10d", info->len);

memcpy(hp->len, buf, 10);

memcpy(hp->inst_code, info->inst_code, LEN_INST_CODE);

memcpy(hp->appl_code, info->appl_code, LEN_APPL_CODE);

memcpy(hp->kind_code, info->kind_code, LEN_KIND_CODE);

memcpy(hp->tx_code, info->tx_code, LEN_TX_CODE);

return info->len;

}

/* ----------------------------------------------------------- */

/* int put_msg_complete(char *data, alinkusr_info_t *info) */

/* */

/* data : sending message data. */


/* */

/* ----------------------------------------------------------- */

int put_msg_complete(char *data, alinkusr_info_t *info)

{

return 1;

}

/****************************************************************

* int

* set_connect_chkmsg(char *data)

*

* data : a message pointer for checking connections

*

* returns a message length.


****************************************************************/

int set_connect_chkmsg(char *data)

{

int len = sizeof(msg_header_t);

if (data == NULL)

return -1;

memset(data, '0', len);

return len;

}

/****************************************************************

* int

* set_session_chkmsg(char *data)

*


*


****************************************************************/

int set_session_chkmsg(char *data)

{

int len = sizeof(msg_header_t);

if (data == NULL)

return -1;

memset(data, '0', len);

return len;

}

/********************************************************************

* int

* get_msg_content(char **data, alinkusr_info_t *info, int bufflen)

*


* info : received data information.

* bufflen : message buffer size

*


*******************************************************************/

int get_msg_content(char **data, alinkusr_info_t *info, int bufflen)

{

char *dp;

if (data == NULL)

return -1;

return info->len;

}


/********************************************************************

* int

* init_algw_info(int argc, char *argv[])

*

*******************************************************************/

int init_algw_info(int argc, char *argv[])

{

int i;

printf("init_algw_info:argc = %d\n", argc);

for (i = 0; i < argc; i++)

printf("init_algw_info:argv[%d] = %s\n", i, argv[i]);

return 1;

}

/********************************************************************

* int

* start_algw_info(int argc, char *argv[])

*

*******************************************************************/

int start_algw_info(int argc, char *argv[])

{

int i;

printf("start_algw_info:argc = %d\n", argc);

for (i = 0; i < argc; i++)

printf("start_algw_info:argv[%d] = %s\n", i, argv[i]);

return 1;

}

/********************************************************************

* int

* get_channel_num(char *data)

*

* data : a message pointer for selecting channel

*

* returns channel index(-1 : use gw config)

*******************************************************************/

int get_channel_num(char *data)

{

return -1;

}

/********************************************************************

* int


* shutdown_algw_info(void)

*

*******************************************************************/

int shutdown_algw_info(void)

{

return 1;

}

/********************************************************************

* int

* done_algw_info(void)

*

*******************************************************************/

int done_algw_info(void)

{

return 1;

}

/********************************************************************

* int

* al_session_open(int i)

*

* i : channel index

*

* returns init result(1 : accept channel, -1 : close channel)

*******************************************************************/

int al_session_open(int i)

{

return 1;

}

/********************************************************************

* int

* al_session_close(int i)

*

* i : channel index

*

*******************************************************************/

int al_session_close(int i)

{

return 1;

}

/********************************************************************

* int

* get_delayed_response(char **data, alinkusr_info_t *info, int bufflen);

*





*


*******************************************************************/

int get_delayed_response(char **data, alinkusr_info_t *info, int bufflen)

{

char *dp;

if (data == NULL)

return -1;

return info->len;

}

/********************************************************************

* int

* get_session_timeout(char *data, alinkusr_info_t *info)

*



*

* returns 0

*******************************************************************/

int get_session_timeout(char *data, alinkusr_info_t *info)

{

return 0;

}

/********************************************************************

* int

* get_clh_timeout(char **data, alinkusr_info_t *info, int bufflen)

*




*


*******************************************************************/

int get_clh_timeout(char **data, alinkusr_info_t *info, int bufflen)

{

char *dp;

if (data == NULL)


return -1;

return info->len;

}

/********************************************************************

* int

* get_error_call(char **data, alinkusr_info_t *info, int bufflen, int err_code);

*




* err_code: error message code

*


*******************************************************************/

int get_error_call(char **data, alinkusr_info_t *info, int bufflen, int err_code)

{

char *dp;

if (data == NULL)

return -1;

return info->len;

}

2.3.2.1. init_algw_info

게이트웨이를 부팅할 때 회선을 초기화하기 전에 호출되는 함수로 CLOPT절로부터 파라미터를 받아서

처리할 수 있다. CLOPT절에 다음과 같이 등록하면 세 번째 영역에 해당하는 부분을 argc, argv로 넘겨준

다.

CLOPT = "<영역1> -- <영역2> -- <영역3>"

<영역1>은 Tmax와 약속된 것, <영역2>는 AnyLink 게이트웨이의 옵션을 입력한다.

● 사용법


설명파라미터

main 함수의 argc와 같은 기능이다. 영역 3에 해당하는 파라미터들의 개수 + 1를 의

미한다.

argc

main 함수의 argv와 같은 기능이다. 영역 3에 있는 파라미터를 넘겨준다.argv

● 리턴값

리턴값은 체크하지 않는다. 0 이상의 값을 리턴한다.


2.3.2.2. start_algw_info

게이트웨이를 부팅할 때 회선을 초기화한 후에 호출되는 함수로 CLOPT절로부터 파라미터를 받아서 처

리할 수 있다. CLOPT절에 다음과 같이 등록하면 세 번째 영역에 해당하는 부분을 argc, argv로 넘겨준다.

(3.2.5 이상 지원)

CLOPT = "<영역1> -- <영역2> -- <영역3>"

<영역1>은 Tmax와 약속된 것, <영역2>는 AnyLink 게이트웨이의 옵션을 입력한다.

● 사용법

int start_algw_info(int argc, char *argv[])

설명파라미터


미한다.

argc


● 리턴값


2.3.2.3. shutdown_algw_info

게이트웨이가 다운(tmdown)된 경우 회선 연결을 종료하기 전에 호출되는 함수이다.

● 사용법

int shutdown_algw_info(void)

● 리턴값


2.3.2.4. done_algw_info

게이트웨이가 다운(tmdown)된 경우 회선 연결을 종료한 후에 호출되는 함수이다.

● 사용법

int done_algw_info(void)

● 리턴값


2.3.2.5. al_session_open

게이트웨이에서 리모트노드에 접속되어 세션이 확립되었을 때 호출되는 함수이다.

● 사용법


int al_session_open (int i)

설명파라미터

현재 연결된 게이트웨이 세션의 정보가 들어있는 구조체의 index이다.i

● 리턴값

함수에서 세션 상태를 확인하여 문제가 없을 경우 1을 리턴하고, 문제가 있거나 사용하지 않을 경우 -1

을 리턴하여 접속을 종료시킨다.

2.3.2.6. al_session_close

게이트웨이에서 세션을 종료시킬 때 호출되는 함수이다.

● 사용법

int al_session_close (int i)

설명파라미터

현재 연결된 게이트웨이 세션의 정보가 들어있는 구조체의 index이다.i

● 리턴값


2.3.2.7. get_msg_length

Anylink admin에서 ‘게이트웨이 추가’시 게이트웨이 옵션 중 ‘메시지 길이 지정’을 ‘통신헤더’로 선택하면

호출되는 함수로, 리모트 노드에서 요청이나 응답이 도착하게 되면, 해당 채널에서 (사용자가 해당 게이트

웨이에 맞게 만든) 통신헤더(msg_header_t)를 읽은 다음 호출되게 된다. 이 함수에서 돌려주는 리턴값으

로 실 데이터를 읽게 되기 때문에 일반적으로 통신헤더(msg_header_t)에 있는 실 데이터의 길이를 리턴

값으로 넘겨준다.

● 사용법

int get_msg_length(msg_header_t *hp)

설명파라미터

개발자가 custom.h에 정의할 수 있는 msg_header_t 구조체의 포인터이다. 일반적으

로, 해당 채널로 부터 데이터를 읽는 경우, 정해진 헤더의 크기 만큼 데이터를 읽은 후

hp

에 헤더에 설정되어 있는 데이터 길이 값을 얻어서 이를 바탕으로 다음 실 데이터를

읽을 수 있도록 되어있다.

이 hp는 TCP/IP 게이트웨이가 리모트 노드로 부터 읽은 헤더 데이터를 넘겨준다.


● 리턴값

리모트 노드로부터 읽어 들일 나머지 데이터의 길이를 리턴한다. 이 함수의 리턴값으로 TCPGW는 나

머지 데이터를 리모트 노드에서 읽게 된다.

2.3.2.8. get_end_msg

Admin에서 게이트웨이를 추가할 때 게이트웨이 옵션 중 '메시지 길이 지정'을 'END문자'로 선택하면 호출

되는 함수로, 리모트 노드로 부터 들어오는 전체길이를 모르는 요청이나 응답 메시지를 임의의 크기로 읽

어 들이면서 들어온 데이터에서 'END문자'를 찾아 계속 데이터를 읽어 들여야 할지 여부를 결정한다.

● 사용법

int get_end_msg (int len, char_t *data)

설명파라미터

리모트 노드로부터 읽어 들인 버퍼 길이이다. data 내에 이 길이까지만 유효한 값이

다.

len

리모트 노드로부터 읽어 들인 버퍼이다. 사용자는 이 버퍼에서 END 문자를 찾아내야

한다.

data

● 리턴값

들어온 데이터에서 ‘END문자’가 없을 경우 리모트 노드로부터 추가로 데이터를 받아야 되므로 리턴값

으로 ‘음수’를 리턴한다. 데이터에서 ‘END문자’를 찾았을 경우 데이터를 다 받은 것이므로 읽어 들인 데

이터의 크기(양수)를 리턴한다.

2.3.2.9. get_msg_info

이 함수는 리모트 노드로 부터 요청이나 응답이 도착하여 데이터를 읽은 후 이 데이터를 TMAX 서비스 프

로그램으로 다시 요청이나 응답를 전송하기 전에 해당 데이터 값을 가공하거나, 정보전송을 위한 여러 정

보(uid, len, flags, service명등)들을 TCP/IP Gateway library와 custom.c와의 interface역할을 하는 info를

참조, 또는 가공하는 함수이다.

● 사용법

int get_msg_info(msg_header_t *hp, char *data, alinkusr_info_t *info)

설명파라미터

리모트 노드로부터 읽어온 메시지 헤더 데이터에 대한 포인터이다.hp

get_msg_length에서 사용한 구조체와 동일하다.

리모트 노드로부터 읽은 데이터 부분이다.data

AnyLink 게이트웨이 라이브러리와 custom.c와 인터페이스 역할을 해주는 구조체에

대한 포인터이다.

info


설명파라미터

사용자가 수신받은 데이터를 기초로 해서 info 구조체의 항목에 각종 정보를 이 함수

에서 설정한다.

입력으로는 len, node_id, gateway_id가 주어진다.

– len : data 버퍼의 길이이다.

– node_id : 게이트웨이의 소속 노드의 ID를 넘겨준다.

– gateway_id : 게이트웨이의 ID를 넘겨준다. 이 값을 이용하여 전문의 필드를 채울

수 있고, unique ID를 만드는 데 사용되기도 한다.

출력으로는 len, flags, uid를 내보낸다.

– len : 사용자가 입력 길이 대신 재정의할 수 있다.

– flags : TPBLOCK을 설정한 경우 다음에 오는 데이터와 결합(concatenation)하는

용도로 사용된다.

– uid : Internal 게이트웨이일 때만 적용되는 것으로 data에서 uid string을 뽑아내서

setting해줘야 한다. External 게이트웨이는 전문추적번호를 뽑아내어 처리하므로

설정할 필요없다. uid의 길이는 27Byte 이하여야 한다는 점을 주의한다.

● 리턴값

요청인지 응답인지 판단한다.

– Internal 게이트웨이 : 요청전문이면 REQUEST_MSG, 응답전문이면 REPLY_MSG를 리턴한다.

– External 게이트웨이 : 파싱하는 과정에서 전문종별 코드로부터 자동 추출해내므로 음이 아닌 값을

리턴하면 된다.

처리 중인 데이터가 Health check data일 경우 -2를 리턴하도록 한다.

리모트 노드로부터 응답을 수신한 경우에는 반드시 UID 값을 info 구조체의 uid 항목에 지정해 주어야

한다. 그리고 기타 다른 값들을 상황에 맞게 주어야 한다.

2.3.2.10. get_unique_id

이 함수는 mapper가 Internal 게이트웨이를 tpacall했을 때 호출되는 함수이다. 게이트웨이는 내부적으로

생성한 uid를 전달하면 사용자가 이 값을 재정의할 수 있다. 게이트웨이 유형이 Internal, 회선 재사용여부

가 “Yes”이고, 해당 거래의 응답 유무가 “Yes”일 때 호출된다.

● 사용법

int get_unique_id(char *data, alinkusr_info_t *info)

설명파라미터

Mapper가 전달한 데이터이다.data

입출력으로 uid가 사용된다.info

– uid : 입력으로 게이트웨이가 uid string을 생성하는데, 사용자가 데이터에서 추출해

서 설정할 수도 있다.


● 리턴값

UID를 정상적으로 설정했을 경우 양수를 리턴하고, 그렇지 않을 경우 음수를 리턴한다.

2.3.2.11. put_msg_info

이 함수는 리모트 노드로 메시지를 전송하고자 할 때 호출되는 함수이다. 비동기형 통신인 경우에는 사용

자가 이 함수에서 UID를 메시지에 저장(Save)해야 한다.

UID는 info 구조체의 uid 항목의 값을 사용해도 되고, 또는 사용자가 임의의 UID를 생성해서 사용한 후에

info의 uid 항목에 넣어주면 된다. 또한, 사용자는 이 함수에서 msg_header_t의 구조체의 각각의 항목에

적절한 값을 저장해야 한다.

이 구조체는 사용자가 임의로 설정할 수 있는 항목이기 때문에 TCP/IP 게이트웨이에서는 msg_header_t

의 구조체 항목에 어떤 값도 저장하지 않는다. msg_header_t 구조체 영역 전부에 값을 저장하지 않는다

면 앞서 초기화를 하는 것이 좋다. 아닐 경우에는 값이 저장되지 않는 영역에 garbage 값이 들어가서 전송

될 수가 있다.

● 사용법


설명파라미터

리모트 노드로 보낼 메시지의 헤더이다.hp

리모트 노드로 보낼 데이터이다.data

리모트 노드로 보낼 데이터의 정보이다. 입력으로만 사용된다.info

– len : 통신헤더를 제외한 송신할 데이터 길이이다.

– uid : internal 게이트웨이일 때 get_unique_id에서 리턴한 uid 값이다.

– msgtype : 요청이면 REQUEST_MSG, 응답이면 REPLY_MSG으로 설정한다.

– max_num : packet split 기능과 관련된 것으로 총 송신할 packet 수이다. 나누지 않

았다면 1이다.

– cur_num : packet split 기능과 관련된 것으로 현재 송신할 packet 순번이다. 1부터

시작하며 max_num과 같으면 마지막 packet이다.

– inst_code,appl_code,kind_code,tx_code : 해당 기관/업무/종별/거래 코드를 알려준

다. Simulator 서버 게이트웨이와 통신할 때 통신헤더에 채워주는 항목으로 사용된

다.

● 리턴값

사용자는 이 함수에서 실제적으로 리모트 노드에 전송할 데이터의 통신헤더를 제외한 길이를 반환해야

한다. TMAX 게이트웨이의 put_msg_info함수는 통신헤더를 포함한 길이를 리턴하는 것에 비해 다른 점

이다.


2.3.2.12. put_msg_complete

이 함수는 리모트 노드로 메시지를 전송한 후에 호출되는 함수로서, 데이터가 완전히 리모트 노드에 전송

되었다는 것을 알려주기 위해서 호출되는 함수이다. 전송한 데이터를 확인하는 작업과 데이터를 보낸 리

모트 노드와 연결된 세션을 닫는 작업을 할 수 있다.

● 사용법

int put_msg_complete(msg_header_t *hp, char *data, alinkusr_info_t *info)

설명파라미터

리모트 노드로 보낸 메시지의 헤더이다.hp

리모트 노드로 보낸 데이터이다.data

리모트 노드로 보낸 데이터의 정보이다.info

– len : 송신한 데이터 길이이다.

– channel_id : 송신한 channel id이다.

● 리턴값

체크하지 않는다.

2.3.2.13. set_connect_chkmsg

이 함수는 Admin에서 '장애처리 방식'을 'health 데이터 송신'으로 적용했을 때 호출되는 함수로, Admin에

서 설정한 '재접속 간격' 동안에 노드간에 아무런 신호가 없을 경우 호출되며, 리모트 노드에 보낼 데이터

를 사용자가 직접 조립하는 함수이다.

● 사용법

int set_connect_chkmsg(char *data)

설명파라미터

상대기관으로 보낼 Health 데이터이다. 이 데이터는 앞에 별도의 통신헤더를 붙이지

않고 그대로 보낸다.

data

● 리턴값

보낼 데이터의 길이다. 통신헤더가 별도로 없으므로 실제로 보낼 길이를 리턴한다.

2.3.2.14. set_session_chkmsg

이 함수는 Admin에서 '장애처리 방식'을 'Session Timeout(send check message)'으로 적용했을 때 호출

되는 함수이다. Admin에서 설정한 'Session Timeout' 시간이 지나도 아무런 신호가 없을 경우 호출되며,

리모트노드에 보낼 데이터를 사용자가 직접 조립하는 함수이다. (3.2.4 이상 지원)


● 사용법

int set_session_chkmsg(char *data)

설명파라미터

상대기관으로 보낼 check message 데이터이다. 이 데이터는 앞에 별도의 통신헤더

를 붙이지 않고 그대로 보낸다.

data

● 리턴값

보낼 데이터의 길이다. 통신헤더가 별도로 없으므로 실제로 보낼 길이를 리턴한다.

2.3.2.15. get_channel_num

이 함수는 Mapper 에서 게이트웨이 로 tpacall 하였을 때 사용자가 나갈 회선을 지정할 때 사용되는 함수

이다. (3.1.2 이상 지원)

● 사용법

int get_channel_num (char *data)

설명파라미터

리모트 노드로 보낼 데이터이다.data

● 리턴값

나갈 session index를 리턴한다. 이 값은 get_max_channel_num API 함수를 통해 얻은 값보다 같거나

작고 0 보다 같거나 큰 값으로 리턴할 경우 게이트웨이 내부의 대외 송수신 방식이 아닌 사용자가 지정

한 세션으로 데이터를 보낸다. -1을 리턴할 경우는 게이트웨이 내부의 대외송수신 방식이 적용되며, -2

를 리턴하면 해당 전문을 에러로 Mapper에 돌려준다.

2.3.2.16. get_msg_content

내부 또는 외부 시스템에서 게이트웨이로 들어온 메시지를 정상적으로 파싱한 후에 호출되는 함수이다.

이 함수가 호출된 후에는 응답 메시지일 경우에는 대응되는 서비스를 호출하고, 요청 메시지일 경우에는

Mapper를 호출하게 된다. 이 함수 내에서는 필요에 따라 메시지를 확인, 수정하는 게 가능하다. (3.2.4 이

상 지원)

● 사용법

int get_msg_content(char **data, alinkusr_info_t *info, int bufflen)

설명파라미터

들어온 데이터 메시지의 첫 주소를 저장한 주소이다. 사용시에 데이터의 메시지를 받

아오기 위해서는 *data 형태로 사용해야 한다. 이 형태를 가짐으로써 들어온 데이터

메시지의 내용 뿐만 아니라 데이터의 메시지 크기도 재조정(realloc)할 수 있다.

data

custom.c에 수신 받은 데이터의 정보를 제공한다.info


설명파라미터

다음의 정보가 제공된다.

– inst_code : 기관 코드이다.

– appl_code : 업무 코드이다.

– kind_code : 종별 코드이다.

– tx_code : 거래 코드이다.


– msgtype : 메시지의 타입을 알려 준다. (요청 | 응답)

– node_id : 게이트웨이의 소속 노드의 id를 넘겨준다.

– gateway_id : 게이트웨이의 id를 넘겨준다. 이 값을 이용하여 전문의 필드를 채울

수 있고, unique id를 만드는데 사용되기도 한다.

메시지 버퍼의 길이이다.bufflen

● 리턴값

함수 내에서 변경된 데이터 메시지의 크기를 리턴값으로 돌려준다. 처리 중 에러가 발생했을 경우 -1을

리턴한다.

2.3.2.17. get_delayed_response

Timeout이 발생하여 관련된 정보가 삭제된 상태에서 응답전문이 수신되었을 경우 지연응답 서비스를 호

출하기 전에 지연된 응답 전문에 대한 정보를 확인하고 필요할 경우 변경하기 위한 함수이다. (3.2.5 이상

지원)

● 사용법

int get_delayed_response(char **data, alinkusr_info_t *info, int bufflen)

설명파라미터

지연 응답 메시지이다.data

들어온 데이터의 정보이다.info




– gateway_id : 게이트웨이의 id를 넘겨준다.


● 리턴값

메시지의 길이를 리턴한다.


2.3.2.18. get_error_call

파싱 오류 서비스를 호출하기 전에 오류 코드를 조회하고 파싱 오류가 발생한 메시지와 그에 대한 정보를

확인하고, 필요할 경우 수정하기 위한 함수이다. (3.2.5 이상 지원)

● 사용법

int get_error_call(char **data, alinkusr_info_t *info, int bufflen, int err_code)

설명파라미터

파싱 오류 메시지이다.data

data의 정보이다.info


파싱 에러 코드이다.err_code

● 리턴값

메시지의 길이를 리턴한다.

2.3.2.19. get_session_timeout

외부 세션으로 보낸 요청이 timeout 되었을 때 호출되는 함수이다. (3.2.5 이상 지원)

● 사용법

int get_session_timeout(char *data, alinkusr_info_t *info)

설명파라미터

Timeout이 된 메시지이다.data

Timeout이 발생된 데이터의 정보이다.info


– len : data의 길이이다.


– gateway_id : 게이트웨이의 id를 넘겨준다. 이 id를 이용하여 게이트웨이의 정보를

확인 할 수 있다.

● 리턴값

0을 리턴한다.

2.3.2.20. get_clh_timeout

내부 서비스를 호출하여 Timeout이 발생했을 경우 호출되는 함수로, Timeout이 발생한 내부 서비스를 호

출한 게이트웨이 정보와 데이터 정보를 이 함수에서 확인, 수정할 수 있다. 이 함수 호출 후 확인 또는 변

경된 데이터로 에러 서비스를 호출한다. (3.2.5 이상 지원)


● 사용법

int get_clh_timeout(char **data, alinkusr_info_t *info, int bufflen)

설명파라미터

Timeout된 메시지이다.data

Timeout이 발생된 데이터의 정보이다.info


– len : data의 길이이다.


– gateway_id : 게이트웨이의 id를 넘겨준다. 이 id를 이용하여 게이트웨이의 정보를

확인할 수 있다.


● 리턴값

함수 내에서 수정한 data의 크기를 리턴값으로 돌려준다.

2.3.3. 사용자 API

ASCII와 EBCDIC 간의 변환을 위한 함수들이 지원된다.

함수명에 ibm이 들어간 경우는 IBM EBCDIC으로 한글 변환을 수행하는 함수이고, fjt가 들어가면 FUJISTU

EBCDIC으로 한글 변환을 수행하는 함수이다.

2.3.3.1. unix_to_ibm

ASCII에서 EBCDIC으로 변환하는 함수이다. ASCII string 내에 전자(2 Byte 문자)가 있을 경우, EBCDIC

으로 변환할 때 연속된 전자 앞뒤로 so, si가 붙는다.

● 사용법

int unix_to_ibm(int len, unsigned char *source, unsigned char *target)

설명파라미터

source 버퍼 내에 변환할 길이이다.len

변환할 ASCII string 버퍼이다.source

변환된 EBCDIC string 버퍼이다.target

● 리턴값

변환된 target 버퍼 내의 데이터 길이이다.


● 사용예

다음은 8 Byte(한글 2자(4 Byte) + 반자 4자(4 Byte))에서 10 Byte(so, si 2 Byte 추가)로 변환되는 예제이

다.

애니link => (so)애니(si)link

● 역함수

ibm_to_unix

2.3.3.2. unix_to_ibm_nososi

ASCII에서 EBCDIC으로 변환하는 함수이다. ASCII 반자를 전자로 확장한 후 변환을 수행하는 데 so, si가

붙지는 않는다.

● 사용법

int unix_to_ibm_nososi(in len, unsigned char *source, unsigned char *target)

설명파라미터




● 리턴값


● 사용예

다음은 8byte(한글 2 자(4byte) + 반자 4자(4byte)에서 12byte(전자 6 글자 (12 byte))로 변환되는 예제이

다.

애니link => 애니ｌｉｎｋ

다음은 korean_com 유형의 변환에 해당하는 예제로 길이 변화는 없다.

애니ｌｉｎｋ => 애니ｌｉｎｋ

● 역함수

ibm_to_unix_nososi2

2.3.3.3. unix_to_ibm_nokorean

ASCII에서 EBCDIC로 변환하는 함수이다. ASCII 전자로는 별도의 변환을 하지 않고 그대로 놔두고 반자

만 변환한다.

● 사용법


int unix_to_ibm_nokorean(in len, unsigned char *source,

unsigned char *target)

설명파라미터




● 리턴값


● 사용예

다음은 길이 변화는 없고, EBCDIC 측 한글의 경우 ASCII 한글이 그대로 전달하는 예제이다.

(so)애니(si)link => (so)애니(si)link

● 역함수

ibm_to_unix_nokorean

2.3.3.4. unix_to_ibm_sosi_nodel

ASCII에서 EBCDIC로 변환하는 함수이다. ASCII에 so, si 문자가 있을 경우, 변환하지 않고 그대로 놔두고

2 Byte 한글 변환 시에 so, si를 별도로 붙이지 않는다. ASCII 문자가 sosi를 고려한 상태로 되어 있을 때에

사용되는 함수이다. (3.1.2 이상 지원)

스튜디오에 매핑하는 경우 'korean_nodel' 유형으로 등록했을 때 적용된다.

● 사용법

int unix_to_ibm_sosi_nodel(in len, unsigned char *source,


설명파라미터

Source 버퍼 내에 변환할 길이이다.len

변환할 ASCII String 버퍼이다.source

변환된 EBCDIC String 버퍼이다.target

● 리턴값

변환된 Target 버퍼 내의 데이터 길이이다.

● 사용예

다음은 길이 변화는 없고, nokrean과 달리 EBCDIC 한글은 EBCDIC 완성형으로 변환하는 예제이다.

(so)애니(si)link => (so)애니(si)link


● 역함수

ibm_to_unix_sosi_nodel

2.3.3.5. unix_to_ibm_sb

ASCII에서 EBCDIC로 변환하는 함수이다. 한글에 대한 고려 없이 무조건 한 Byte씩 변환한다. (3.2.2 이상

지원)

● 사용법

int unix_to_ibm_sb(in len, unsigned char *source,


설명파라미터




● 리턴값


● 역함수

ibm_to_unix_sb

2.3.3.6. com_sp_to_ibm

ASCII에서 EBCDIC으로 변환하는 함수이다. ASCII에 반자는 그 뒤에 space가 붙는다는 가정하에 변환을

수행한다. 반자는 전자로 확장되어 EBCDIC으로 변환된다. 한글은 그대로 변환되며, sosi는 붙이지 않는

다. (3.1.2 이상 지원)

스튜디오 매핑할 때 'korean_space' 유형으로 등록했을 경우에 적용된다.

● 사용법

int com_sp_to_ibm(in len, unsigned char *source,


설명파라미터




● 리턴값



● 사용예

다음은 길이 변화는 없고, 결과는 입력이 "애니LINK"일 때의 "korean" 유형 변환과 동일한 예제이다.

애니l^i^n^k^ => 애니LINK

● 역함수

ibm_to_com_sp

2.3.3.7. ibm_to_unix

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string내에 so, si가 붙은 영역은 ASCII 전자로 변환된

다. unix_to_ibm의 역에 해당하는 함수이다.

● 사용법

int ibm_to_unix(int len, unsigned char *source, unsigned char *target)

설명파라미터


변환할 EBCDIC String 버퍼이다.source

변환된 ASCII String 버퍼이다.target

● 리턴값


● 사용예

(so)애니(si)link =>애니link

(so)애니LINK(si) =>애니LINK

sosi 내의 전자는 반자로 바꾸지 않는다.

● 역함수

unix_to_ibm

2.3.3.8. ibm_to_unix_nososi

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string 내에 so, si가 붙은 영역을 변환 후 ASCII 반자

가 전자로 확장된 경우이면 ASCII 반자로 변환한다. unix_to_ibm_nososi의 역에 해당하는 함수이다.

● 사용법

int ibm_to_unix_nososi(int len, unsigned char *source,


설명파라미터



설명파라미터



● 리턴값


● 사용예

(so)애니(si)link =>애니link

(so)애니ｌｉｎｋ(si) =>애니link

sosi 내의 전자는 반자로 바꾸는 점에 ibm_to_unix와 다르다.

● 역함수

unix_to_ibm_nososi

2.3.3.9. ibm_to_unix_nososi2

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string전체에 so, si가 붙었다고 가정하고 변환 후 ASCII

반자가 전자로 확장된 경우이면 ASCII 반자로 변환한다.

● 사용법

int ibm_to_unix_nososi2(int len, unsigned char *source,


설명파라미터




● 리턴값


● 사용예

다음은 전자는 반자로 변경하는 예제이다.

애니ｌｉｎｋ =>애니link

ibm_to_unix_nososi 함수와의 차이점은 전체에 sosi가 붙은 것으로 간주하고 처리한다는 점이다.

● 역함수

unix_to_ibm_nososi


2.3.3.10. ibm_to_unix_sosi_nodel

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string내에 so, si가 붙은 영역은 ASCII 전자로 변환된

다. so, si를 변환 후 제거하지 않고 그대로 유지하는 점이 unix_to_ibm와 다르다.

● 사용법

int ibm_to_unix_sosi_nodel(int len, unsigned char *source,


설명파라미터




● 리턴값


● 사용예

다음은 sosi 내의 전자는 반자로 바꾸지 않고 sosi를 변경하지 않는 예제이다. 길이변화는 없다.

(so)애니(si)link =>(so)애니(si)link

(so)애니LINK(si) =>(so)애니LINK(si)

● 역함수

unix_to_ibm_sosi_nodel

2.3.3.11. ibm_to_unix_nokorean

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string 내에 so, si가 붙은 영역은 변환하지 않는다. so,

si를 변환 후 제거하지 않는다. unix_to_ibm_nokorean의 역에 해당하는 함수이다.

● 사용법

int ibm_to_unix_nokorean(int len, unsigned char *source,


설명파라미터




● 리턴값



● 사용예

다음은 길이 변화는 없고, ASCII 측 한글의 경우 EBCDIC 한글이 그대로 전달되는 예이다.

(so)애니(si)link =>(so)애니(si)link

● 역함수

unix_to_ibm_nokrean

2.3.3.12. : ibm_to_unix_sb

EBCDIC에서 ASCII로 변환하는 함수이다. 한글에 대한 고려 없이 무조건 1Byte씩 변환한다. (3.2.2 이상

지원)

● 사용법

int ibm_to_unix_sb(int len, unsigned char *source,


설명파라미터




● 리턴값


● 역함수

unix_to_ibm_sb

2.3.3.13. ibm_to_com

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string전체에 so, si가 붙었다고 가정하고 변환 후 ASCII

반자로 변환하지 않고 전자로 유지하는 점이 ibm_to_unix_nososi2와 다르다. (3.1.2 이상 지원)

스튜디오 매핑 시 'korean_com' 유형으로 등록했을 때 적용된다.

● 사용법

int ibm_to_com(int len, unsigned char *source,


설명파라미터





● 리턴값


● 사용예

애니LINK =>애니LINK

ibm_to_unix_nososi2 함수와의 차이점은 전체에 전자를 반자로 바꾸지 않는 것이다. 이렇게 되면

ibm_to_unix에 전체 sosi가 붙었다고 가정하고 처리하는 것과 동일하다.

● 역함수

unix_to_ibm_nososi

2.3.3.14. ibm_to_com_sp

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string전체에 so, si가 붙었다고 가정하고 변환하되 전

자를 반자로 바꿀 때 반자 뒤에 space를 1Byte씩 붙여서 전체 길이가 변하지 않도록 한다. (3.1.2 이상 지

원)

스튜디오 매핑 시 'korean_space' 유형으로 등록했을 때 적용된다.

● 사용법

int ibm_to_com_sp(int len, unsigned char *source,


설명파라미터




● 리턴값


● 사용예

애니LINK =>애니l^i^n^k^

전체 길이의 변화가 없다.

● 역함수

com_sp_to_ibm

2.3.3.15. unix_to_fjt

ASCII에서 EBCDIC으로 변환하는 함수이다. ASCII string 내에 전자(2 Byte 문자)가 있을 경우, EBCDIC

으로 변환 시 연속된 전자 앞뒤로 so, si가 붙는다. (3.1.2 이상 지원)


● 사용법

int unix_to_fjt(int len, unsigned char *source, unsigned char *target)

설명파라미터




● 리턴값


2.3.3.16. fjt_to_unix

EBCDIC에서 ASCII로 변환하는 함수이다. EBCDIC string 내에 so, si가 붙은 영역은 ASCII 전자로 변환된

다. unix_to_fjt의 역에 해당하는 함수이다. (3.1.2 이상 지원)

● 사용법

int fjt_to_unix (int len, unsigned char *source, unsigned char *target)

설명파라미터




● 리턴값


2.3.3.17. get_grpline_cnt

회선에 할당되어 있는 기관-업무의 수를 리턴한다. (3.1.2 이상 지원)

● 사용법

int get_grpline_cnt(int id)

설명파라미터

세션의 번호이다.id

● 리턴값

세션이 속해 있는 회선에 할당된 기관-업무의 수를 반환한다.


2.3.3.18. get_max_channel_num

get_channel_num 함수에서 channel index를 얻어내기 위해 호출하는 함수로 channel index의 최대값을

리턴해서 loop를 돌면서 channel index를 찾는 데 사용된다. (3.1.2 이상 지원)

● 사용법

int get_max_channel_num()

● 리턴값

channel index의 최대값이다.

2.3.3.19. get_symbname_from_channel_num

get_channel_num 함수에서 channel index를 얻어내기 위해 호출하는 함수로 channel index를 파라미터

로 넘겨주면 그에 해당하는 Admin에서 등록한 회선명(symbname)을 리턴한다. 사용자는 이 회선명을 바

탕으로 나갈 회선의 index를 선택할 수 있다. (3.1.2 이상 지원)

● 사용법

char *get_symbname_from_channel_num(int channel_id)

설명파라미터

Channel index이다.channel_id

● 리턴값

channel index에 해당하는 회선명이다.

NULL이 리턴될 경우는 해당 channel이 삭제되었거나 중지 또는 연결되지 않았을 때이므로 반드시 확

인해서 스케줄링해야 한다.

2.3.3.20. get_grpline_info

회선에 할당된 기관-업무의 코드 값을 알아내는 함수이다. 하나 이상의 기관-업무가 할당되어 있을 경우

반복적으로 호출하여 다음 기관-업무의 코드를 알아낼 수 있다. (3.1.2 이상 지원)

● 사용법

int get_grpline_info(int id, char *inst_code, char *appl_code, int *next_idx)

설명파라미터

세션의 번호이다.id

기관 코드의 값이다.inst_code

업무 코드의 값이다.appl_code

다음 검색 때 사용할 index이다.next_idx


● 리턴값

회선에 할당된 기관-업무를 찾았을 경우에는 1을 리턴하고, 찾지 못한 경우에는 -1을 리턴한다.

2.3.3.21. search_appl

업무 코드를 알고 있을 경우 업무 정보로부터 종별 코드, 거래 코드를 알아내기 위한 정보를 가져오는 함

수이다. (3.1.2 이상 지원)

● 사용법

int search_appl(char *appl_code, appl_cust_t *appl_cust)

설명파라미터


업무 코드에 해당하는 업무의 정보가 리턴되는 구조체이다.appl_cust

● 리턴값

에러 발생의 경우에는 -1을 리턴하고, 정상적으로 업무 정보를 찾은 경우에는 1을 리턴한다.

2.3.3.22. search_kind

업무 코드와 종별 코드를 알고 있을 경우 종별 정보로부터 거래 코드를 알아내기 위한 정보를 가져오는 함

수이다. (3.1.2 이상 지원)

● 사용법

int search_kind(char *appl_code, char *kind_code, kind_cust_t *kind_cust)

설명파라미터


종별 코드의 값이다kind_code

업무 코드, 종별 코드에 해당하는 종별의 정보가 리턴되는 구조체이다.kind_cust

● 리턴값

에러 발생의 경우에는 -1을 리턴하고, 정상적으로 종별정보를 찾은 경우에는 1을 리턴한다.

2.3.3.23. search_tx_by_keyval

업무 코드와 거래 코드의 키 값을 알고 있을 경우 거래에 대한 정보를 가져오는 함수이다. (3.1.2 이상 지

원)

● 사용법

int search_tx_by_keyval(char *appl_code, char *key_val, tx_cust_t *tx_cust)


설명파라미터

업무코드의 값이다.appl_code

거래코드를 찾기 위한 키 값이다.key_val

해당하는 거래의 정보가 리턴되는 구조체이다.tx_cust

● 리턴값

에러 발생한 경우에는 -1을 리턴하고, 정상적으로 종별정보를 찾은 경우에는 1을 리턴한다.

2.3.3.24. get_lu_no_from_channel_num

Channel idx로부터 lu번호를 알아내는 함수이다. (3.1.2 이상 지원)

● 사용법

int get_lu_no_from_channel_num (int i)

설명파라미터

Channel index이다.i

● 리턴값

Channel index가 범위를 벗어난 경우에는 -1을 리턴하나, 나머지의 경우에는 해당 회선의 lu 번호를 리

턴한다.

2.3.3.25. send_custom_response

게이트웨이가 기본적으로 리모트 노드에 전달하는 전문정보 외에 사용자가 임의로 특정 채널로 메시지를

전송하는 함수이다. (3.2.2 이상 지원)

● 사용법

int send_custom_response(int id, char *dp, int len)

설명파라미터

Channel index 이다.id

전송하려고 하는 데이터이다.dp

전송할 데이터의 길이이다.len

● 리턴값

데이터가 NULL이거나 전송할 데이터 길이가 0 이하인 경우, Channel index 범위를 벗어나는 경우, 리

모트 노드로의 데이터 전송에 실패한 경우에는 -1을 리턴한다. 나머지 경우에는 리모트 노드로 전송한

데이터 길이를 리턴한다.


2.3.3.26. gw_session_close

특정 세션을 임의로 끊을 수 있다. (3.2.2 이상 지원)

● 사용법

int gw_session_close(int i)

설명파라미터

Channel index 이다.i

● 리턴값

항상 1이 리턴된다.

2.3.3.27. get_out_symbname_from_channel_num

Channel idx로부터 해당 회선의 회선명을 얻어온다. (3.2.2 이상 지원)

● 사용법

char *get_out_symbname_from_channel_num(int i)

설명파라미터

Channel index 이다.i

● 리턴값

Channel idx가 잘못되어 회선을 찾을 수 없으면 NULL이 리턴되고, 나머지 경우는 모두 회선명의 포인

터가 리턴된다.

2.3.3.28. gw_session_connect_by_symbname

회선명으로 특정 회선을 연결한다. 이때 회선은 반드시 클라이언트 모드(클라이언트 수시도 안됨)여야 한

다. (3.2.2 이상 지원)

● 사용법

int gw_session_connect_by_symbname(char *symbname)

설명파라미터

회선명이다.symbname

● 리턴값

회선 연결에 성공하면 1이 리턴되고, 실패하면 -1이 리턴된다.


2.3.3.29. get_line_status

회선명으로 특정 회선을 연결한다. 이때 회선은 반드시 클라이언트 모드(클라이언트 수시도 안됨)여야 한

다. (3.2.2 이상 지원)

● 사용법

int get_line_status(char *symbname)

설명파라미터

회선명이다.symbname

● 리턴값

회선명에 해당하는 회선이 없다면 NULL이 리턴되고, 정상적인 경우 회선의 상태가 리턴된다.

2.3.3.30. al_my_svrinfo

게이트웨이에에 대한 서버명, 서버 그룹명 등의 서버 정보를 조회한다. (3.2.4 이상 지원)

● 사용법

int al_my_svrinfo(TMAXSVRINFO* info)

설명파라미터

서버명, 서버 그룹명 등 서버에 대한 정보이다.info

● 리턴값

info가 NULL일 경우 -1, info에 서버 정보를 설정했을 경우 1이 리턴된다.

2.3.3.31. al_read_msg

세션 접속시점에 업무 개시, 사용자 인증 처리와 같은 특정 요건에 필요한 메시지를 수신하기 위한 함수이

다. al_session_open() Callback 함수에서 호출하도록 한다. (3.2.4 이상 지원)

● 사용법

int al_read_msg (int idx, char *ptr, int nbytes, int ms)

설명파라미터

세션 번호이다.idx

읽어들일 데이터가 저장될 공간의 포인터이다.ptr

read할 사이즈이다.nbytes

read가 안되는 경우 waiting time이다. (단위: ms)ms


● 리턴값

메시지를 정상적으로 읽었을 경우 실제로 read한 사이즈를 리턴하고, 그 외의 경우에는 음수를 리턴한

다.

2.3.3.32. al_write_msg

세션 접속시점에 업무 개시, 사용자 인증 처리와 같은 특정 요건에 필요한 메시지를 송신하기 위한 함수이

다. al_session_open() Callback 함수에서 호출하도록 한다. (3.2.4 이상 지원)

● 사용법

int al_write_msg (int idx, char *ptr, int nbytes, int ms)

설명파라미터


내보낼 데이터가 저장된 공간의 포인터이다.ptr

write 할 사이즈이다.nbytes

write가 안될 경우 waiting time이다. (단위: ms)ms

● 리턴값

메시지를 정상적으로 보냈을 경우 실제로 write한 사이즈를 리턴하고, 그 외의 경우에는 음수를 리턴한

다.

2.3.3.33. get_alline_info

세션이 속한 회선의 정보를 조회하기 위한 함수이다. al_session_open() Callback 함수에서 호출하도록

한다. (3.2.4 이상 지원)

● 사용법

int get_alline_info(int idx, line_tab_t *linetab)

설명파라미터


회선 정보를 저장할 포인터이다.linetab

● 리턴값

회선 정보를 정상적으로 조회할 수 있을 경우 양수를 리턴하고, 그 외의 경우에는 음수를 리턴한다.

2.3.3.34. get_channel_id

현재 전문이 처리되고 있는 세션의 인덱스 번호를 조회하기 위한 함수이다. get_msg_length (),

get_end_msg() Callback 함수에서 호출하도록 한다. (3.2.5 이상 지원)


● 사용법

int get_channel_id ()

● 리턴값

현재 전문이 처리되고 있는 세션의 인덱스 번호를 리턴한다.

2.3.3.35. get_fd_from_cur_sess_idx

현재 세션에 대한 fd값을 조회하기 위한 함수이다. get_msg_info() Callback 함수에서 호출하도록 한다.

(3.2.5 이상 지원)

● 사용법

int get_fd_from_cur_sess_idx ()

● 리턴값

현재 세션에 대한 fd값을 리턴한다.

2.3.3.36. get_peer_ip_from_channel_num

세션 번호를 설정하여 호출하면 리모트의 IP 주소를 조회할 수 있는 함수이다. al_session_open() Callback

함수에서 호출하도록 한다. (3.2.2 이상 지원)

● 사용법

int get_peer_ip_from_channel_num(int idx, char *ipaddr)

설명파라미터

조회할 세션 번호이다.idx

세션과 접속 중인 리모트의 IP 주소이다.ipaddr

● 리턴값

리모트의 IP주소 조회에 성공했을 경우 1, 조회할 수 없을 경우 0, 세션 번호에 할당된 fd가 없을 경우 -

2, 그 외의 경우 -1을 리턴한다.

2.3.3.37. gw_getpeer_addr

세션 번호를 설정하여 호출하면 리모트의 IP 주소, 포트 번호를 조회할 수 있는 함수이다. get_msg_info()

Callback 함수에서 호출하도록 한다. (3.2.5 이상 지원)

● 사용법

int gw_getpeer_addr (int idx, int *portno, char *ipaddr)

설명파라미터

세션의 인덱스 번호이다.idx


설명파라미터

리모트의 포트 번호이다.portno

리모트의 IP 주소이다. 조회가 불가능할 경우 'unknown'이 설정된다.ipaddr

● 리턴값

리모트의 IP주소, 포트 번호를 조회할 수 있을 경우 1, 리모트 정보를 조회할 수 없을 경우 0, 그 외의 경

우에는 음수를 리턴한다.

2.3.3.38. tcpgw_getpeer_addr

fd값을 설정하여 호출하면 리모트의 IP 주소, 포트 번호를 조회할 수 있는 함수이다. get_msg_info() Callback


● 사용법

int tcpgw_getpeer_addr (int fd, int *serv_port, char *serv_ip)

설명파라미터

조회할 fd값이다.fd

리모트의 포트 번호이다.serv_port

리모트의 IP 주소이다. 조회가 불가능할 경우 "unknown"이 설정된다.serv_ip

● 리턴값

리모트의 IP주소, 포트 번호를 조회할 수 있을 경우 1, 리모트 정보를 조회할 수 없을 경우 0, 그 외의 경

우에는 음수를 리턴한다.

2.3.3.39. tcpgw_get_local_addr_by_fd

fd값을 설정하여 호출하면 로컬의 IP 주소, 포트 번호를 조회할 수 있는 함수이다. get_msg_info() Callback


● 사용법

int tcpgw_get_local_addr_by_fd (int fd, int *clnt_port, char *clnt_ip)

설명파라미터

조회할 fd값이다.fd

리모트의 포트 번호이다.clnt_port

리모트의 IP 주소이다. 조회가 불가능할 경우 'unknown'이 설정된다.clnt_ip

● 리턴값

로컬의 IP주소, 포트 번호를 조회할 수 있을 경우 1, 리모트 정보를 조회할 수 없을 경우 0, 그 외의 경우

에는 음수를 리턴한다.


2.3.3.40. get_log_id

get_msg_length(), get_end_msg() Callback 함수에서 log_id를 조회하기 위해 호출하는 함수이다.

get_msg_info(), get_msg_content ()와 같이 alinkusr_info_t *info가 파라미터에 포함되어 있는 함수의 경

우에는 3.2.5 이상의 버전부터 alinkusr_info_t 안에 log_id항목이 추가되어 있으므로 get_log_id ()를 호출

하여 log_id를 조회할 필요가 없다. (3.2.5 이상 지원)

● 사용법

int get_log_id(char *log_id)

설명파라미터

조회될 log_id이다.log_id

● 리턴값

log_id가 조회될 경우 1, NULL일 경우 0을 리턴한다.

2.3.3.41. gw_tpcall

Tmax 서비스를 tpcall로 호출시 사용하는 함수이다. get_msg_info(), put_msg_info() Callback 함수에서

호출하도록 한다. (3.2.4 이상 지원)

● 사용법

int gw_tpcall (char *svc, char *idata, long ilenl, char **odata,

long *olen, long flagsl)

설명파라미터

Tmax 서비스명이다.svc

Tmax 서비스에 전달할 데이터가 저장된 버퍼 포인터이다.idata

Tmax 서비스에 전달할 데이터 길이이다.ilenl

Tmax 서비스에서 처리 결과를 받을 버퍼 포인터이다.odata

처리 결과의 데이터 길이가 저장될 포인터이다.olen

tpcall시 설정할 flag 정보이다.flagsl

● 리턴값

tpcall 처리가 정상적으로 되었을 경우 양수, 그렇지 않을 경우 음수를 리턴한다.

2.3.3.42. gw_tpacall

TMAX service를 tpacall로 호출할 경우 사용하는 함수이다. 이 함수는 내부적으로 TPNOREPLY flag가 설

정되기 때문에 응답을 받아오는 용도로 사용할 수 없다. get_msg_info(), put_msg_info() Callback 함수에

서 호출하도록 한다. (3.2.4 이상 지원)


● 사용법

int gw_tpacall(char *svc, char *idata, long ilenl)

설명파라미터




● 리턴값

tpacall 처리가 정상적으로 되었을 경우 양수, 그렇지 않을 경우 음수를 리턴한다.

2.3.3.43. : gw_tpacall2

gw_tpacall에 TPBLOCK 기능이 추가된 함수이다. get_msg_info(), put_msg_info() Callback 함수에서 호

출하도록 한다. (3.2.5 이상 지원)

● 사용법

int gw_tpacall2 (char *svc, char *idata, long ilenl, char **odata,

long *olen, long flagsl)

설명파라미터




Tmax 서비스에서 처리 결과를 받을 버퍼 포인터이다.odata

처리 결과의 데이터 길이가 저장될 포인터이다.olen

tpacall시 설정할 flag 정보이다.flagsl

● 리턴값

tpacall 처리가 정상적으로 되었을 경우 양수, 그렇지 않을 경우 음수를 리턴한다.

2.3.3.44. set_session_ready

장애처리방식이 '장애회선 block및 자동복구'로 설정되어 있을 때 세션이 Block되면 set_connect_chkmsg()

에 정의된 테스트 전문이 주기적으로 전송된다. 테스트 전문에 대한 응답전문을 수신하게 되면 응답전문

의 내용을 판단하여 회선의 Block 상태를 해제해도 될 경우 세션의 상태를 READY로 변경하는 함수이다.

따라서 get_msg_info(), get_msg_content() 등의 Callback 함수에서 호출해야 한다. (3.2.5 이상 지원)

● 사용법

int set_session_ready (int gwi)


설명파라미터

세션 번호이다.gwi

● 리턴값

BLOCK 상태를 READY 상태로 정상적으로 변경했을 경우 양수, 그렇지 않을 경우 음수를 리턴한다.

2.4. 파싱 오류 서비스파싱 오류 서비스명 설정은 스튜디오의 기관-업무정보에 '파싱 오류 서비스명'에 등록한다. err_svc_t 구조

체 다음에 에러가 발생한 전문이 전달된다.

다음은 alparsing.h 헤더 파일로, 에러 코드 및 err_svc_t 구조체가 정의되어 있다. 해당 파일은

$TMAXDIR/usrinc에 위치한다.

#ifndef _ANYLINK_PARSING_H_

#define _ANYLINK_PARSING_H_

/* -------------- include files ------------------ */

#include <usrinc/atmi.h>

#include <usrinc/alerrcode.h>

/* ------------ constant, macro definitions --------------- */

/* define for sr_type */

#define INT_EXT_MSG 1

#define EXT_INT_MSG 2

/* ------------ structure definitions --------------------- */

typedef struct {

int err_code; /* 에러코드 */

int ext_type; /* 대내외구분: 1=EXTERNAL, 2=INTERNAL */

int sr_type; /* 처리 방향: 1=대내 => 대외 */

/* 2=대외 => 대내 */

/* 0=delay service */

int data_len; /* data length */

char gwname[LEN_SERVER_NAME]; /* 게이트웨이명 */

char inst_code[LEN_INST_CODE]; /* 기관코드 */

char appl_code[LEN_APPL_CODE]; /* 업무코드 */

char kind_code[LEN_KIND_CODE]; /* kind code */

char tx_code[LEN_TX_CODE]; /* tx code */

} err_svc_t;

#endif /* _ANYLINK_PARSING_H_ */


실제 서비스는 다음과 같이 일반적인 TCS 서비스 형태로 개발한다.

#include <stdio.h>

#include <usrinc/allen.h>

#include <usrinc/alparsing.h> /* 파싱오류서비스 헤더 */

PERRSVC(TPSVCINFO *msg)

{

err_svc_t *ehp; /* 파싱오류서비스 구조체 */

char *datap; /* 전문 데이터 */

char *sndbuf;

int sndlen;

/* 파싱오류서비스 구조체 및 전문 데이터 추출 */

ehp = (err_svc_t *)msg->data;

datap = (char *)(ehp + 1);

switch(ehp->err_code) {

case ERR_KIND_PARSING:

case ERR_TX_CODE_NOTFOUND: /* external G/W */

case ERR_TX_PARSING: /* internal G/W */

sndbuf = (char *)tpalloc("CARRAY", NULL, 4096);

if (sndbuf == NULL) {

printf("tpalloc fail\n");

tpreturn(TPFAIL, 0, NULL, 0, 0);

}

/* 포맷오류 전문 생성 : 0200 => 9200 */

memcpy(sndbuf, datap, ehp->data_len);

sndbuf[14] = '9';

sndlen = 160;

break;k

case ERR_RES_FRMT:

case ERR_INST_PARSING:

case ERR_GRP_PARSING:

case ERR_APPL_PARSING:

case ERR_ERR_SVC_CALL:

case ERR_NO_SESSION:

case ERR_SESSION_CLOSE:

case ERR_TIMEOUT:

case ERR_SERVICE_FAIL:

case ERR_SYSTEM_ERR:

default:

/* 대외기관으로 전문을 내보내지 않을 경우 */

sndbuf = NULL;

sndlen = 0;

break;

}


tpreturn(TPSUCCESS, 0, sndbuf, sndlen, 0);

}

2.5. 지연 응답 처리 서비스파싱 오류 서비스와 작성 방법은 동일하다. err_svc_t 구조체의 err_code에 ERR_TIMEOUT으로 리턴되

며 기관/업무/종별/거래코드 모두를 넘겨준다.

지연 응답 처리 서비스는 파싱 오류 서비스와 달리 TPNOREPLY로 호출되기 때문에 tpreturn시 응답 데이

터를 조립해서 리턴할 필요가 없다.

실제 서비스는 다음과 같이 일반적인 TCS 서비스 형태로 개발한다. 서비스명은 업무나 거래별로 등록한

다.

#include <stdio.h>

#include <usrinc/allen.h>

#include <usrinc/alparsing.h> /* 파싱오류서비스 헤더와 같음 */

DLYSVC(TPSVCINFO *msg)

{

err_svc_t *ehp; /* 파싱오류서비스 구조체 */

char *datap; /* 전문 데이터 */

char *sndbuf;

int sndlen;

/* 파싱오류서비스 구조체 및 전문 데이터 추출 */

ehp = (err_svc_t *)msg->data;

datap = (char *)(ehp + 1);

/* TODO : 지연응답 처리 */

…

/* TPNOREPLY로 호출되기 때문에 아래와 같이 return함 */

tpreturn(TPSUCCESS, 0, NULL, 0, 0);

}


제3장 X.25 게이트웨이

본 장에서는 X.25 게이트웨이의 기능 및 설정 방법을 설명한다.

3.1. 개요X.25 게이트웨이는 X.25 프로토콜로 데이터를 송수신할 때사용하는 게이트웨이이다.

X.25에서는 프로토콜 특성상 멀티 LU를 관리가 가능하고, 다른 X.25 회선일지라도 하나의 게이트웨이에

서 처리가 가능하다. X.25 프로토콜 특성상 송신한 데이터 길이를 알 수 있으므로, TCP/IP 게이트웨이의

통신헤더 유형관련 기능은 없다.

TCP/IP 게이트웨이와 동일한 라이브러리를 사용하며(libalgw/libalgwd), 기능 및 설정 방법도 유사하다. 본

장에서는 차이점 위주로 설명하므로 TCP/IP 게이트웨이의 기능을 먼저 숙지하기 바란다.

3.2. 환경설정본 절에서는 X.25 게이트웨이의 환경설정에 대해 설명한다.


Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다. 등록 방식은 TCP/IP 게이트웨이와 동일하므로

본 절에서는 설명을 생략한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.


Admin에서는 게이트웨이를 등록해야 한다.

● 등록 항목

해당 게이트웨이가 속한 노드를 선택 후 컨텍스트 메뉴에서 [Gateway추가]를 선택하거나 오른쪽 패널

에 있는 [Gateway추가] 버튼을 클릭한다.

설명항목




회선 장애 발생의 경우 호출될 서비스명을 등록한다.백업 서비스명

제3장 X.25 게이트웨이 67

설명항목

'X.25'를 선택한다.프로토콜


파싱 방식을 선택하기 위해, 대외용(External), 대내용(Internal)을 등록

한다.

대내외구분

게이트웨이가 특정 기관-업무에만 종속된 경우 값을 할당해주면 게이트

웨이-level 기관-업무 파싱을 수행한다.


여러 기관-업무가 등록된 회선이 있을 때 기관-업무 유일키 파싱에 필요

한 위치 정보를 등록한다.

기관-업무 유일키 offset/length

미입력메시지 길이 지정

미입력통신헤더타입

미입력통신헤더길이

미입력메시지 길이

● 게이트웨이 등록 예 (대외기관용 X.25 게이트웨이, HP용 게이트웨이)

설명항목

x25gw01이름

X25GW01서비스명

X.25프로토콜

온라인Type



Admin에서 회선(Line)을 등록한다.

● 등록 항목

회선 등록 방법은 X.25 게이트웨이를 시용하는 Machine에 따라 조금씩 차이가 있다. 그러므로 사용자

는 Machine별 채널 정보를 정확히 등록해야만 리모트 노드와 원할한 통신이 이루어 짐으로 채널 정보

등록의 각각의 항목에 대해서 명확히 이해해야 한다.

설명항목

회선을 대표하는 symbol명이다. 통신 프로토콜과 무관하게 유일하게 지

칭할 수 있는 명칭으로 정한다.

회선이름

회선이 포함된 노드명으로, 기본값이 입력된다.노드명

회선이 포함된 게이트웨이명으로, 기본값이 입력된다.Gateway 이름


설명항목

X.25 회선명을 등록한다.회선명/IP주소(line_name)

HP의 경우 기존에 디바이스명에 넣었던 디바이스 아래에 X.25 카드명을

입력한다. NCR에서 사용한다.

NCR과 DEC Machine만 사용되는 것으로 LCN(LU)별로 로컬명이 존재하

기 때문에 LCN별로 Local명을 별도로 지정해야만 한다.

LU이름/포트번호(lu_name)

이 항목은 아래의 LCN이 속해 있는 Link 번호를 등록한다. 하나의 Link에

는 많은 LCN(LU)를 가질 수 있다. 즉, 많은 LCN이 하나의 Link를 공유하

여 리모트 노드와 통신한다. IBM, SUN에서 사용한다.

X.25 회선번호(line_no)

X.25 게이트웨이의 디바이스명을 지정하는 항목이다. IBM, SUN에서만

사용한다.

X.25 장치명(dev_name)

논리적인 번호로, 하나의 물리적인 Link를 많은 Logical LU로 분할하여 리

모트 노드와 LU별로 통신할 수 있다. 이 항목에 LU 번호를 입력한다. HP,

IBM, SUN에서만 사용한다.

X.25 시작LU번호(lu_no)

LCN 개수를 등록한다. 위의 X.25 LU번호부터 세션 수 만큼 LU를 등록한

다. HP, IBM, SUN에서만 1보다 큰 값을 등록할 수 있다. NCR 및 DEC은

반드시 1로 등록한다.

세션수

항상 'Client'이다.TCP/IP C/S구분

회선의 뱡향성에 대한 설정이다. (TCP/IP와 동일)처리방식




세션이 끊어지고 난 후 재접속하는 주기이다.재접속 간격

X.25 게이트웨이와 리모트 노드 간에 송수신하는 가장 큰 메시지의 사이

즈이다. X.25 게이트웨이에서는 이 옵션에서 지정한 사이즈만큼 메모리

를 확보하여 수신받기 때문에 넉넉한 사이즈를 지정해야 한다.

nsdu

X.25 게이트웨이와 리모트 노드 간에 한 번에 송수신 할 수 있는 사이즈를

지정한다. Nsdu로 정의한 전체 메시지를 nidu에서 지정한 사이즈 단위로

송수신한다. IBM, SUN에서만 사용한다.

nidu

리모트 노드와 비동기(Async) 통신을 할지 여부이다. (TCP/IP와 동일)회선 재사용 여부

– YES : 특정 세션으로 보냈을 때, 그 세션으로 응답이 오기전에 또 보낼

수 있는 비동기 방식

– NO : 요청 전문을 보내면 응답이 올 때까지 해당 회선 사용불가

스튜디오의 기관-업무정보에서 '대외송신방식'을 'Selection'으로 선택했

을 경우, 이 회선으로 들어왔을 때 응답 전문을 내보낼 회선의 '회선이름'이

다. (TCP/IP와 동일)



설명항목

해당 회선에 문제가 발생했을 때 연락처나 기타 용도로 사용할 수 있는 공

간이다. (TCP/IP와 동일)


Tmax X.25 게이트웨이 환경설정과 회선 등록 비교

Tmax X.25 게이트웨이는 Tmax 환경 파일의 SERVER 절 해당 서버 등록 부분의 CLOPT 항목에 등록하

고, 채널 환경 파일을 통해 해당 LU들을 등록하는 형태로 구성되었다.

● CLOPT 절 옵션 비교

다음은 Tmax X.25 게이트웨이와 AnyLink 게이트웨이를 비교 정리한 표이다.

AnyLink 게이트웨이 등록기능구 옵션

재연결을 무한반복, 기본값과 동일재연결 횟수r

회선 등록 시 NSDU에 등록가장 큰 메시지 크기N

회선 등록 시 NIDU에 등록한 번에 보낼 수 있는 크기n

게이트웨이 등록 시 재접속 간격에 설정재접속 간격t

지원 안함사용자 공유 메모리 확보k

GUI 등록으로 인해 불필요환경 파일명F

게이트웨이 내부에서 파싱하여 서비스를 찾아내므

로 불필요

Relay 서비스명S

Mapper의 Cache 기능으로 수용 가능Cache 기능H/h

회선 등록 시 '회선 재사용 여부'를 'Yes'로 설정비동기 통신a

지정 송수신 기능으로 수용 가능사용자 채널 설정u

지원 안함재처리 서비스 등록Y

● 채널 환경 파일 기능

채널 환경 파일과 AnyLink Admin 등록 방식의 차이점이다.

다음은 Tmax X.25 게이트웨이와 AnyLink 게이트웨이의 채널 환경 파일의 기능을 비교 정리한 표이다.


Admin에서 GUI로 등록 가능여러 게이트웨이 등록Gateway 번호

X.25 회선 번호에 등록LCN에 속해 있는 Link 번호 등록Link 번호

X.25 LU 번호에 등록LU의 시작 번호 등록시작 LCN 번호

세션 수에 등록시작 LCN 번호부터 접속할 LU 개

수 등록

LCN 개수

회선에 처리 방식을 등록IN/OUT 속성 설정채널 타입



지정 송수신 기능으로 수용 가능응답 LU 지정응답 타입

X.25 장치명에 등록하며 Machine별로 다름디바이스 명

Machine별 회선 설정

본 절에서는 Machine별 회선 설정 항목에 대해 설명한다.

● SUN/IBM Machine

다음은 출력 회선이 sunx25line05인 LU의 입력회선에 대한 설명이다.

설정값항목

/dev/x25pkt디바이스명

10link 번호

7시작 LCN 번호

4LCN 개수

4096NSDU

4096NIDU

30초재접속 간격

위와 같은 환경에서 회선은 다음과 같이 등록한다. "적용안됨"이라 표시한 부분은 실제로는 사용되지

않지만 Admin에서 필수 항목이므로 임의의 값을 입력한다.

설정값항목

sunx25line01회선이름

/dev/x25pkt (적용안됨)회선명/IP주소(line_name)

/dev/x25pkt (적용안됨)LU이름/포트번호(lu_name)

10X.25 회선번호(line_no)

/dev/x25pktX.25 장치명(dev_name)

7X.25 시작LU번호(lu_no)

3세션 수

IN_CHANNEL처리방식

30재접속 간격

4096nsdu

4096nidu

Yes회선 재사용 여부

sunx25line05출력 회선 이름


● HP Machine

다음은 HP Machine의 회선에 대한 설명이다.

설정값항목

cisl00카드번호

3시작 LCN 번호

2LCN 개수

4096NSDU


위와 같은 양방향 회선인 LU에 대한 설정은 다음과 같다.

설정값항목

hpx25line01회선이름

cisl00회선명/IP주소(line_name)

cisl00(적용안됨)LU이름/포트번호(lu_name)

0(적용안됨)X.25 회선번호(line_no)

cisl00(적용안됨)X.25 장치명(dev_name)

3X.25 시작LU번호(lu_no)

2세션 수


ANY_CHANNEL처리방식

20재접속 간격

4096nsdu

4096(적용안됨)nidu


(미입력)출력 회선 이름

● NCR Machine

다음은 NCR Machine의 회선에 대한 설명이다.

설정값항목

/dev/x25pkt디바이스명

xxxxlink Local명

7LCN 번호

4096NSDU


설정값항목


위와 같이 출력 회선인 LU에 대한 설정은 다음과 같다.

설정값항목

ncrx25line01회선이름

/dev/x25pkt회선명/IP주소(line_name)

xxxxLU이름/포트번호(lu_name)


/dev/x25pkt(적용안됨)X.25 장치명(dev_name)

0(적용안됨)X.25 LU 번호(lu_no)

항상 1개이다.세션 수


OUT_CHANNEL처리방식

60재접속 간격

4096nsdu




● DEC Machine

다음 DEC Machine 회선에 대한 설명이다.

설정값항목

xxxxlink Local명

4096NSDU


위와 같은 출력 회선인 LU에 대한 설정은 다음과 같다.

설정값항목

decx25line01회선이름

(적용안됨)회선명/IP주소(line_name)

xxxxLU이름/포트번호(lu_name)


(적용안됨)X.25 장치명(dev_name)


설정값항목

0(적용안됨)X.25 LU 번호(lu_no)

항상 1개이다.세션 수


OUT_CHANNEL처리방식

60재접속 간격

4096nsdu




3.3. 사용자 프로그램(custom.h, custom.c)TCP/IP 게이트웨이와 동일한 방식으로 작성한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

3.3.1. custom.h

X.25에서는 별도의 통신헤더가 없으므로 msg_header_t 구조체는 의미가 없으므로 형태만 남겨둔다.

3.3.2. custom.c

다음의 함수들을 수정 내용에 따라 수정한다.

수정 내용함수명

X.25 게이트웨이에서 호출되지 않으므로 형태만 남겨둔다.get_msg_length

X.25 게이트웨이에서 호출되지 않으므로 형태만 남겨둔다.get_end_msg

HP로 넘어온 데이터는 사용하지 않는다.get_msg_info

TCP/IP 게이트웨이와 동일하게 작성한다.get_unique_id

HP로 넘어온 데이터는 사용하지 않는다.put_msg_info

HP로 넘어온 데이터는 사용하지 않는다.put_msg_complete

3.4. 파싱 오류 서비스TCP/IP 게이트웨이와 동일하게 작성한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.


제4장 SSL 게이트웨이

본 장에서는 SSL 게이트웨이의 기능 및 설정 방법을 설명한다.

4.1. 개요SSL 게이트웨이는 보안 통신을 하기 위해 SSL 프로토콜을 구현한 AnyLink용 게이트웨이이다. SSL 프로

토콜은 TCP 위에 구현된 프로토콜이기 때문에 내부적으로는 TCP/IP 게이트웨이와 비슷하다. 따라서 본

절에서는 TCP/IP 게이트웨이와의 차이점을 위주로 설명하며 먼저 TCP/IP 게이트웨이의 사용법을 숙지해

야 한다.

SSL 프로토콜의 특징은 다음과 같다.

● 경계가 없는 데이터 전송

TCP/IP 통신의 경우에는 데이터의 경계가 정해져 있지 않기 때문에 여러 번에 나눠 보낸 데이터를 한

번에 받을 수도 있고 한 번에 보낸 데이터를 여러 번에 걸쳐 받을 수 있다.

하지만 SSL 통신에서는 한 번에 보낸 데이터는 반드시 한 번에 수신해야 한다. 그리고 이 점이 SSL 게

이트웨이의 성능을 저하시킬 수 있다. TCP/IP 게이트웨이의 경우 데이터 전송 속도가 느려서 전문이 일

부만 도착했다면 도착한 부분만을 읽어들인 후 다른 거래를 처리할 수 있지만, SSL 게이트웨이의 경우

에는 전문의 나머지 부분이 도착할 때까지 다른 거래를 처리할 수 없기 때문이다. 이러한 이유로 성능이

중요시되는 곳에 SSL 프로토콜을 사용해야 한다면 Online 게이트웨이보다는 Thread 게이트웨이를 적

용해야 한다.

● Handshake

SSL 프로토콜에서 데이터를 주고받기 전에 상대방을 확인하고 암호화 하기 위해 필요한 세션 키를 생

성하는 과정을 Handshake라고 한다. 디버그 모드를 사용하면 다음의 과정을 로그에서 확인할 수 있다.

제4장 SSL 게이트웨이 75

[그림 4.1] SSL Handshake

4.2. 환경설정본 절에서는 SSL 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다. 등록 방식은 TCP/IP 게이트웨이와 동일하므로

본 절에서는 설명을 생략한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

Server 등록할 때 CLOPT에는TCP/IP 게이트웨이에서 사용하는 옵션과 더불어 다음의 옵션을 추가로 지

정할 수 있다.

설명옵션

SSL connect를 위한 Handshake과정에서의 timeout 시간을 설정하는 옵션으로 "-t 시

간(초)"로 지정한다.

t


4.2.2. OPENSSL command line

SSL 프로토콜의 경우 인증서와 개인키가 필수적이며 경우에 따라 파라미터 파일이 추가적으로 필요할 수

도 있다.

● 인증서, 개인 키 생성

인증서를 생성할 경로는 다음을 기본으로 한다.

/usr/local/ssl/certs

난수를 생성하기 위한 seed(PRNG)가 필요한데, '.profile'에 RANDFILE 환경변수를 정의하거나 $HOME

이나 현재 디렉터리에 '.rnd' 파일을 생성하여 적당히 입력한다. 파일 내용이 부족할 경우 PRNG가 필요

하다는 에러 메시지가 출력된다.

그 후 다음과 같이 rootca.cnf, anyPem.sh의 2개의 파일을 생성한다.

– rootca.cnf

[ req ]

default_bits = 1024

default_keyfile = privkey.pem

default_md = sha1

prompt = no

distinguished_name = req_distinguished_name

x509_extensions = v3_ca

[ req_distinguished_name ]

countryName = KR

stateOrProvinceName = SEOUL

localityName = BUNDANG

organizationName = TMAX

organizationalUnitName = DEV

commonName = TMAX_CA

emailAddress = 담당자 E-mail

[v3_ca]

basicConstraints = CA:true

– anyPem.sh

PATH=$PATH:./

export PATH

/usr/local/ssl/bin/openssl req -x509 -rand openssl -config rootca.cnf \

-newkey rsa -keyout rootkey.pem -out rootcert.pem -outform Pem

openssl 경로는 알맞게 수정한다.

anyPem.sh를 실행시키면 rootkey.pem(개인키), rootcert.pem(인증서, 이 경우에는 발급 기관의 인증

서도 됨) 2개의 파일이 생성된다.


● Ephemeral keying 파라미터 파일

Ephemeral keying이란 세션 키를 동적으로 바꿔서 보다 보안적인 통신을 가능하게 해주는 기법이다.

Ephemeral keying을 하기 위해서 dh512.pem, dh1024.pem의 2개의 파일을 생성해야 한다. 생성 방법

은 다음과 같다.

$ /usr/local/ssl/bin/openssl dhparam -check -text -5 512 -out dh512.pem

$ /usr/local/ssl/bin/openssl dhparam -check -text -5 1024 -out dh1024.pem

이것을 실행하기 위해서도 인증서를 생성할 때처럼 PRNG가 필요하다.

참고

인증 기관에서 발급받은 인증서, 개인 키가 있다면 그것을 사용하는 것이 바람직하다. 그렇지 않을

경우에 오픈 소스인 OPENSSL 라이브러리를 설치한 후 command line을 이용해서 생성할 수도 있

지만 권장사항은 아니다.


SSL 게이트웨이의 Admin 등록 방식은 다음과 같다.

등록 방식은 TCP/IP 게이트웨이와 대부분 동일하나 메시지 길이, 통신헤더에 대한 내용은 입력하지 않으

며 몇 개의 항목이 추가된다.

● 등록 항목



설명항목




회선 장애가 발생하는 경우 호출될 서비스명을 등록한다.백업 서비스명

'SSL'을 선택한다.프로토콜



한다.

대내외구분

게이트웨이가 특정 기관-업무에만 종속된 경우에 값을 할당해주면 게이

트웨이-level 기관-업무 파싱을 수행한다.


여러 기관-업무가 등록된 회선이 있을 때, 기관-업무 유일 키 파싱에 필

요한 위치 정보를 등록한다.




설명항목




인증서의 절대 경로이다. Handshake 과정에서 사용되며, 통신 상대에

게 자신을 확인시키기 위해서 필요하다.

인증서

인증서의 비밀번호이다.인증서 비밀번호

인증서 발급 기관의 인증서의 절대 경로이다. 인증서와 혼돈이 있을 수

있는데, 인증서를 발급한 기관도 신뢰할 수 있어야 하기 때문에 필요하

다.

인증서 발급기관의 인증서

개인 키의 절대 경로이다.개인키

엄격한 보안이 필요할 때에 선택적으로 사용할 수 있다.Ephemeral keying 사용여부

Ephemeral keying을 하기 위한 파라미터 파일들의 위치이다.Ephemeral keying 파일 경로

● 게이트웨이 등록 예

다음은 위의 “4.2.2. OPENSSL command line”에서 설명한 OpenSSL command line으로 인증서와 개인

키를 생성한 경우를 가정한 예이다.

설명항목

sslgwext이름

SSLGWEXT서비스명

SSL프로토콜

온라인Type


/usr/local/ssl/certs/rootcert.pem인증서

/usr/local/ssl/certs/rootcert.pem인증서 발급기관의 인증서

anylinkpwd인증서 비밀번호

/usr/local/ssl/certs/rootkey.pem개인키

사용안함Ephemeral keying 사용여부




● 등록 항목

회선 등록하는 방법은 TCP/IP 게이트웨이와 동일하다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참

고한다.

설명항목

회선을 대표하는 symbol명이다. 통신 프로토콜과 무관하게 유일하게 지칭할

수 있는 명칭으로 정한다.

회선이름

회선이 포함된 노드명으로 기본값이 입력된다.노드명

회선이 포함된 게이트웨이명으로 기본값이 입력된다.Gateway 이름

서버 모드일 때는 노드의 IP, 클라이언트 모드일 때는 연결할 IP을 등록한다.회선명/IP주소

서버 모드일 때는 Listen할 포트, 클라이언트 모드일 때는 연결할 포트를 등

록한다.

LU이름/포트번호

서버 모드일 때는 최대 수용할 세션 수, 클라이언트 모드일 때는 연결할 세션

수를 등록한다.

세션수

서버 모드일 때는 'Server', 클라이언트 모드일 때는 'Client'를 선택한다. 매번

요청 전문을 보내고 응답 받은 후 끊을 경우는 'Client(수시)'를 선택한다. 이

때는 '회선 재사용 여부'가 'NO'로 고정된다.

C/S구분





클라이언트 모드일 때 세션이 끊어지고 난 후 재접속하는 주기이다. 만약 이

값을 입력하지 않을 경우, 장애가 발생하여 세션이 끊어지면 게이트웨이를

재기동하기 전까지 재접속하지 않는다.

재접속 간격

리모트 노드와 비동기(Async) 통신을 할지 여부이다. (TCP/IP와 동일)회선 재사용 여부

– YES : 특정 세션으로 보냈을 때, 그 세션으로 응답이 오기 전에 또 보낼 수

있는 비동기 방식

– NO : 요청 전문을 보내면 응답이 올 때까지 해당 회선을 사용불가. 'TCP/IP

C/S 구분'이 'Client(수시)'일 경우는 'NO'로 고정

스튜디오의 기관-업무정보에서 '대외송신방식'을 'Selection'으로 선택했을

경우, 이 회선으로 들어왔을 때 응답 전문을 내보낼 회선의 '회선이름'이다.


해당 회선에 문제가 발생했을 때 연락처나 기타 용도로 사용할 수 있는 공간

이다.



4.3. 사용자 프로그램(custom.h, custom.c)TCP/IP 게이트웨이와 동일한 방식으로 작성한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

4.3.1. custom.h

SSL에서는 X.25와 같이 별도의 통신헤더가 없으므로 msg_header_t 구조체는 의미가 없으므로 형태만

남겨둔다.

4.3.2. custom.c

다음의 함수들을 수정 내용에 따라 수정한다.

수정 내용함수명

SSL 게이트웨이에서 호출되지 않으므로 형태만 남겨둔다.get_msg_length

SSL 게이트웨이에서 호출되지 않으므로 형태만 남겨둔다.get_end_msg

TCP/IP 게이트웨이와 동일하게 작성한다. SSL 통신에서는 통신헤더가 없으

므로 첫 번째와 두 번째 파라미터로 넘어온 주소값이 동일하다는 것에 유의

한다.

get_msg_info

TCP/IP 게이트웨이와 동일하게 작성한다.get_unique_id



한다.

put_msg_info



한다.

put_msg_complete



제5장 HTTP 게이트웨이

본 장에서는 HTTP 게이트웨이의 기능 및 설정 방법을 설명한다.

5.1. 개요HTTP 게이트웨이는 HTTP 프로토콜로 전문을 송수신할 때 사용되기 위해 JEUS 웹 컨테이너 버전으로

개발된 AnyLink 전용 게이트웨이이다. HTTP, SOAP, ebXML 등의 형태로 들어오는 데이터에 대해 파싱

과정을 거쳐 JMapper를 호출한다. CMapper는 XML 데이터를 처리하지 못하므로 반드시 JMapper를 사

용한다.

HTTP 게이트웨이의 기관-업무 파싱 과정은 간단하다. 데이터가 들어온 URL에 등록된 기관/업무를 찾아

내어 JMapper로 전달한다.

5.2. 환경설정본 절에서는 HTTP 게이트웨이 환경설정에 대해 설명한다.

5.2.1. JEUS 환경설정

JEUS 웹 컨테이너 환경 파일에 <http-listener>를 등록하고 웹 애플리케이션을 등록한다.

<http-listener > 설정

WEBMain.xml에 <http-listener>를 설정한다. 포트는 URL 설정과 동일한 포트를 사용한다. 다음은 설정

예제이다.

<http-listener>

<listener-id>alinkhttpgw</listener-id>

<port>30868</port>

<thread-pool>

<min>30</min>

<max>30</max>

<max-queue>100</max-queue>

</thread-pool>

</http-listener>

참고

<http-listener> 설정에 대한 자세한 내용은 "JEUS Web Container 안내서"를 참고한다.

제5장 HTTP 게이트웨이 83

웹 애플리케이션 설정

웹 애플리케이션의 등록은 다음의 2개의 파일을 설정해야 한다.

● jeus-web-dd.xml 설정

<context-path>를 Admin의 URL을 설정할 때 지정한 context로 지정한다(ex: /httpgw). 다음은 설정 예

제이다.

<?xml version="1.0" encoding="UTF-8"?>

<jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<context-path>/httpgw</context-path>

<enable-jsp>true</enable-jsp>

<auto-reload>

<enable-reload>false</enable-reload>

<check-on-demand>false</check-on-demand>

</auto-reload>

<max-instance-pool-size>-1</max-instance-pool-size>

<session-config>

<url-rewriting>false</url-rewriting>

</session-config>

<webinf-first>false</webinf-first>

</jeus-web-dd>

● web.xml 설정

<servlet> 태그의 <servlet-name>을 AnyLinkHttpReceiver로 설정하고 <servelt-class>를 anylink.en

gine.servlet.AnyLinkHttpReceiver로 설정한다. <servlet-mapping>의 <servlet-name>을

AnyLinkHttpReceiver로 설정하고 <url-pattern>은 Admin의 URL 설정 시에 사용한 패턴을 입력한다.

다음은 설정 예제이다.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems,

Inc.//DTD Web Application 2.2//EN"

"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">

<web-app>

<servlet>

<servlet-name>AnyLinkHttpReceiver</servlet-name>

<servlet-class>anylink.engine.servlet.AnyLinkHttpReceiver</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>AnyLinkHttpReceiver</servlet-name>

<url-pattern>/soap-receiver</url-pattern>

</servlet-mapping>

</web-app>



Admin에서 게이트웨이를 등록한다.

● 등록 항목



설명항목


선택한 노드명이 자동 입력된다.노드명


'HTTP'를 선택한다.프로토콜

'HTTP'를 선택한다.Type

HTTP 게이트웨이에서 대내외구분에 따른 기능의 차이는 없으므로 의미상으

로만 구분한다.

대내외구분

미입력, HTTP 게이트웨이는 URL정보에 의해서만 기관-업무 파싱을 수행한다.기관코드/업무코드






● 게이트웨이 등록 예 (대외 기관용 HTTP 게이트웨이)

[그림 5.1] 게이트웨이 등록 예

5.2.3. URL 등록

Admin에서 URL을 등록한다. TCP/IP 게이트웨이, X25 게이트웨이의 회선에 해당하는 개념으로 회선 이

름 대신 URL이 키가 된다.

참고

자세한 내용은 "AnyLink Admin 안내서"의 "URL추가"를 참고한다.


● 등록 항목

다음은 URL 등록 항목에 대한 설명이다.

설명항목

HTTP를 위한 URL이다. 'http://'를 제외한 부분을 등록한다.URL

다음의 경우에 따라 설정한다.타입

– Inbound : 리모트 노드에서 요청전문이 들어올 경우

– Outbound : Mapper가 요청할 경우

'Inbound'일 경우는 HTTP 게이트웨이가 Listen하고, 'Outbound'일 때는 연결

한다.


해당 HTTP 게이트웨이의 서버명이 자동 입력된다.Gateway 이름

'타입'의 설정값에 따라 다음과 같이 설정한다.IP 주소 / 포트번호

– 'Inbound' 모드일 때 : Listen할 포트

– 'Outbound' 모드일 때 : 연결할 IP 주소 및 포트

예를 들어, '타입'이 'Inbound'일 때 http://192.168.1.10:8989/<context>로 호

출하는 경우(192.168.1.10은 HTTP 게이트웨이의 IP 주소) 포트 번호는 8989

값으로 입력한다.

'타입'의 설정값에 따라 다음과 같이 설정한다.세션 수

– 'Inbound' 모드일 때 : 최대 수용할 세션의 수

– 'Outbound' 모드일 때 : 연결할 세션의 수

해당 URL과 연결된 기관/업무를 등록한다.기관 / 업무

'Inbound'일 경우에는 하나의 URL에 대해 여러 기관/업무가 할당되지 못한

다. 이 정보는 HTTP 게이트웨이가 요청 전문이 들어온 상태에서 URL로 기

관/업무를 찾아내기 위한 정보로 사용되므로 반드시 등록한다.

미입력기관코드 필드명

미입력서버명

미입력Parameter

미입력Username / Password

RealReal/Backup 구분

메시지의 타입에 따라서 XML과 SOAP을 구분하여 설정한다.XML/SOAP 구분


● URL 설정 예

다음은 URL 설정에 대한 예제이다.

[그림 5.2] URL 설정


제6장 TCP/IP Multi-Thread 게이트웨이

본 장에서는 TCP/IP Multi-thread 게이트웨이의 기능 및 설정 방법을 설명한다.

6.1. 개요TCP/IP Multi-thread 게이트웨이는 앞에 설명된 Online 게이트웨이와 같이 Request/Response 구조의 전

문 처리가 아닌 플로우가 있는 거래에 대해 처리하기 위해 개발된 게이트웨이이다.

주로 단말 장치와 직접 붙을 경우 처음에 연결이 된 이후에 인증이나 로그인 과정을 거치고 거래에 필요한

데이터를 주고받고, ACK/NACK를 보내는 등의 플로우가 있는 거래에 대해서는 Online 게이트웨이에 등

록해서 매핑으로 처리하기에는 시스템이 복잡해지고 비효율적이 된다.

카드 단말이나 통신 단말 장비와 연결되는 시스템에 적합하다. 또한 보안 모듈을 이용한 게이트웨이를 개

발하려고 할 때 인증 과정 등을 TCP/IP Multi-thread 게이트웨이에서 처리가 가능하므로 사용자가 임의의

보안 모듈을 붙여서 게이트웨이를 생성할 수 있다.

AnyLink용 TCP/IP Multi-thread 게이트웨이는 서버/클라이언트 모드 모두 지원된다.

6.1.1. 서버 모드 구조

서버 모드 TCP/IP Multi-thread 게이트웨이를 구성하는 요소로써 Listener와 핸들러 프로세스가 있다.

● Listener

TCP/IP 포트를 Listen하고 있다가 연결 요청이 들어오면 해당 세션을 핸들러로 넘겨주는 역할을 한다.

핸들러로 전달할 때 Round Robin 스케줄링 방식을 이용한다.

● 핸들러

Multi-thread로 구성되어 있으며, 핸들러 내의 여러 개의 Worker-thread pool을 관리하며 Tmax와 연결

되어 있는 Main-thread와 실제 거래를 처리하는 Worker-thread가 있다.

Listener로부터 넘겨받은 세션을 Main-thread가 받으면, Worker-thread에 스케줄링해서 거래를 수행한

다.

제6장 TCP/IP Multi-Thread 게이트웨이 89

[그림 6.1] Multi-thread 게이트웨이 구조

6.1.2. 서버 모드 동작 원리

Listener가 등록된 포트를 Listen하고 있는 상태에서 대외 기관에서 연결 요청이 들어오면(connect), 해당

연결을 받아들인 후, Listener와 연결된 핸들러들에 Round Robin 방식으로 넘겨준다.

이때 Admin에서 회선 접근 제어 설정을 통해 허용/차단 클라이언트 목록을 설정했을 경우, 정책에 따라

접속 여부를 결정한다. 등록된 회선만 허용하고 클라이언트 목록을 등록할 경우, edicated 모드로 동작한

다. Dedicated 모드는 핸들러를 tp(a)call로 호출할 때 특정 IP 주소를 지정하여 호출이 가능한 모드이다.

핸들러 Main-thread는 Listener가 넘겨준 연결을 Worker-thread pool에서 선택해서, 일하지 않고 있는

Work-thread에 연결을 할당한다. Work-thread는 이 시점부터 거래를 수행하며 거래가 완료되면 연결을

종료하고, 다시 Worker-thread pool로 돌아간다.

새로운 연결이 들어올 때마다 위 과정을 반복한다.


[그림 6.2] 리모트로부터 연결 요청이 들어왔을 때 처리 과정

6.1.3. 클라이언트 모드 구조

클라이언트 모드 TCP/IP Multi-thread 게이트웨이를 구성하는 요소로써 클라이언트 매니저(Client Manager)

와 핸들러(Handler) 프로세스가 있다.

● 클라이언트 매니저(Client Manager)

클라이언트 모드 핸들러를 Admin에 등록할 때 해당 서버를 등록한다. 매니저는 Client-dedicated 모드

일 때 공유 메모리를 할당하는 역할을 수행한다.

클라이언트 회선들을 등록하며 회선 개수가 여러 개이고, 세션 수가 1개씩 할당된 경우 Dedicated 모드

로 동작한다.

● 핸들러(Handler)

서버 모드에서와 동일한 역할을 수행한다.


6.2. 환경설정본 절에서는 TCP/IP Multi-Thread 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일에 Listener, 핸들러의 서버와 서비스를 등록한다. Tmax Multi-thread 게이트웨이 설정 방

법을 참고한다.

Listener/Client Manager

Listener와 클라이언트 매니저에 대한 설정은 다음과 같다.

● SERVER 절

SVRTYPE을 CUSTOM_GATEWAY로 한다. 게이트웨이는 여러 개를 띄워서 처리할 수 없으므로 반드

시 MIN, MAX를 1로 한다.


설명옵션

이 옵션을 사용하면 Dedicated 모드로 동작한다. 해당 옵션은 구 버전 호환성을 위해서

지원하는 것으로써, 가능한 위에 언급된대로 Admin 회선 접근 제어 기능을 사용하도록

한다.

F

● SERVICE 절

해당 서비스명을 등록한다. 서비스명은 15자 이내 임의의 값으로 1개만 등록한다. 등록한 서비스명이

Tmax 설정과 Admin에 등록한 게이트웨이의 서비스명과 일치하지 않으면 동적 디플로이가 되지 않을

수 있으므로 주의한다.

핸들러(Handler)

핸들러(Handler)에 대한 설정은 다음과 같다.

● SERVER 절

SVRTYPE을 CUSTOM_GATEWAY로 한다. 게이트웨이는 여러 개를 띄워서 처리할 수 없으므로, 반드

시 MIN, MAX를 Admin에 등록한 핸들러 개수와 일치시킨다.

CPC는 각 핸들러에 할당된 Thread 개수와 일치해야 한다. 만약 이보다 적을 경우 핸들러에서 Tmax 서

비스를 호출할 때 에러가 발생할 수 있다.


설명옵션

핸들러가 속해 있는 Listener 서버명을 등록한다.L


설명옵션

이 옵션을 사용하면 Dedicated 모드로 동작한다. 해당 옵션은 구 버전 호환성을 위해서

지원하는 것으로써, 가능한 위에 언급된대로 Admin 에 클라이언트 모드 회선을 등록해

서 사용한다.

F

소켓 종료 후 "–t 시간(초)"을 세션 종료에 걸리는 시간으로 간주하여 옵션으로 설정한 시

간 이내에 클라이언트가 접속을 시도할 경우 remote reject 처리가 되도록 한다.

t

● SERVICE 절

해당 서비스명을 등록한다. 서비스명은 15자 이내 임의의 값으로 1개만 등록한다. 등록한 서비스명은

Tmax 서버에서 TCP/IP Multi-thread 게이트웨이를 호출할 때 사용되는 서비스명이다.


Admin에서 게이트웨이에 Listener를 등록한다.

● 등록 항목



설명항목

Listener의 Tmax 서버명을 등록한다.이름


Tmax 환경 파일에 설정한 Listener 서비스명을 등록한다.서비스명

'TCP/IP'를 선택한다.프로토콜

'온라인 Thread'을 선택한다.Type

대내/대외 중 선택한다. 둘 중 어느 것을 선택해도 동작에는 차이가 없고,

단지 구분하기 위한 정보성 데이터이다.

대내외구분

해당 Listener에 핸들러를 몇 개 띄울 것인지를 등록한다. Tmax 설정의 핸

들러 서버의 MIN, MAX로 등록한 값과 동일해야 한다.

Thread G/W 핸들러 수

● 게이트웨이 등록 예 (TCP/IP Multi-thread 게이트웨이)

설명항목

thrgwlsn이름

THRGWLSN서비스명

TCP/IP프로토콜

온라인 ThreadType

대외대내외구분


설명항목

3Thread G/W 핸들러 수


Admin에서 Listen할 회선(Line)을 등록한다. TCP/IP 게이트웨이의 서버 모드 회선 등록과 동일하게 설정

하면 되므로 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

6.3. 사용자 프로그램(usrmain.c)핸들러의 Worker-thread는 사용자 로직으로 동작한다. 본 절에서는 이 Worker-thread를 작성하는 방법을

설명한다. Worker-thread는 Tmax의 TCP/IP Multi-thread 게이트웨이와 동일하게 작성하면 되므로 자세한

내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

사용자 프로그램은 UCS를 작성하듯이 처음에 핸들러를 기동할 때 호출되는 init_algw_info 함수와 thread

main loop에 해당하는 user_thrmain을 작성한다. 마치 UCS의 tpsvrinit과 usermain을 작성하는 것과 유

사하다.

user_thrmain은 다음과 같이 API를 조합하여 작성한다.

● user_thrmain에서 select loop를 돌면서 Tmax에서 온 데이터인지, 리모트에서 온 것인지에 따라 판단해

서 처리하는 loop를 작성한다. 이때 어느 방향에서 왔는지 판단하는 tpschedule 같은 함수인 tcpgw_select,

tcpgw_select2가 있다. tcpgw_select2가 더 큰 개념이며, 이 함수는 뒷 단이 Tmax가 아니라 다른 게이

트웨이일 때 리모트와 내부에 있는 게이트웨이를 연계하는 역할을 수행할 수 있다.

● Tmax 서비스로 요청을 하기 위한 함수로 tcpgw_tpcall, tcpgw_tpacall이 있으며, Tmax 측에서 요청이

들어온 경우는 tcpgw_get_svcdata로 수신하고, 응답은 tcpgw_tpreply로 돌려준다.

● 리모트와 통신할 때 리모트로 연결해야 할 필요가 있을 경우에는 tcpgw_network_connect로 연결하고,

데이터를 송신할 때는 tcpgw_write, 수신할 때는 tcpgw_read 함수를 통해서 수행한다. 이 API를 조합하

여 user_thrmain을 작성한다.

6.3.1. Callback 함수

Callback 함수는 init_algw_info와 user_thrmain 2개를 작성해서 핸들러 라이브러리와 함께 컴파일해야 한

다.

6.3.1.1. init_algw_info

TCP/IP Multi-thread 게이트웨이가 기동할 때 호출되는 함수이다. Worker-thread가 생성되기 이전 시점에

불린다. Thread를 생성하기 이전에 초기화 작업해야 할 것들을 수행하는 것이며, Online 게이트웨이에 있

는 함수와 동일하게 CLOPT 절에 있는 파라미터를 받아올 수 있다.


● 사용법


설명파라미터


미한다.

argc


● 리턴값

리턴값은 체크하지 않는다. 0이상의 값을 리턴한다.

6.3.1.2. user_thrmain

Worker-thread가 Main-thread로부터 세션을 할당받았을 때 호출되는 함수이다. 이 함수 내에서 거래 처리

종료까지 looping을 돌면서 처리해야 한다. 이 함수를 리턴하면 해당 Thread는 Thread pool로 돌아가 다

음 거래를 처리하게 된다.

● 사용법

Int user_thrmain(WORKTHRINFO *winfo, int server)

설명파라미터

WORKTHRINFO 구조체로 사용자 API에서 입력 파라미터로 사용되는 변수이다.winfo

해당 TCP/IP Multi-thread 게이트웨이가 서버 모드인지 클라이언트 모드인지를 나타

내는 값이다. 항상 서버 모드로 넘어온다.

server

● 리턴값

리턴값은 체크하지 않는다. 0이상의 값을 리턴한다.


본 절에서는 사용자 프로그램(usrmain.c)에서 사용되는 사용자 API에 대해 설명한다.

6.3.2.1. tcpgw_select

TCP/IP Multi-thread 게이트웨이에서 Tmax나 리모트로부터 데이터가 들어왔는지 감지하는 함수이다.

● 사용법

int tcpgw_select(WORKTHRINFO *wthrinfo, int sec, int usec)

설명파라미터

user_thrmain에서 넘겨준 WORKTHRINFO에 대한 포인터이다.wthrinfo


설명파라미터

select timeout in secondsec

select timeout in micro secondusec

sec와 usec 모두 0보다 같거나 작을 때는 무한 대기하며 그 외의 경우는 타임아웃이

적용된다.

● 리턴값

설명리턴값

에러 발생WTHR_SELECT_ERROR(-1)

select timeout 발생WTHR_SELECT_TIMEOUT(1)

Tmax에서 데이터 수신WTHR_TMAX_REQUEST(2)

리모트에서 데이터 수신WTHR_USER_REQUEST(3)

6.3.2.2. tcpgw_select2

TCP/IP Multi-thread 게이트웨이에서 Tmax나 리모트로부터 데이터가 들어왔는지 감지하는 함수이다.

tcpgw_select와의 차이점은 별도의 사용자가 지정한 소켓 번호를 같이 확인할 수 있다는 점이다.

이러한 형태는 TCP/IP Multi-thread 게이트웨이가 보안 모듈을 암호화화해서 대외 기관으로 보내고 내부

시스템으로 바로 TCP/IP로 송신해야 할 경우에 사용된다.

● 사용법

int tcpgw_select2(WORKTHRINFO *winfo, int *etcfd, int sec, int usec)

설명파라미터


별도의 사용자가 select에서 확인하고자 하는 소켓 번호를 줄 수 있다. 리턴값이 음이

아닐 때 *etcfd이 음이 아닌 수로 리턴되면 etcfd에 데이터가 들어왔음을 의미한다.

etcfd




적용된다.

● 리턴값

설명리턴값




설명리턴값



사용자가 지정한 소켓 번호에서 데이터 수신WTHR_ETC_REQUEST(4)

6.3.2.3. tcpgw_tpcall

TCP/IP Multi-thread 게이트웨이에서 Tmax 서비스를 tpcall로 호출할 때 사용하는 함수이다. 이 함수는

tpcall로 호출하기 때문에 호출하는 서비스의 서비스 타임아웃을 반드시 설정해야만 Thread가 block되지

않고 진행할 수 있다.

● 사용법

int tcpgw_tpcall(WORKTHRINFO *wthrinfo, char *svc, char *ptr,

long alen, char *optr, long *olen)

설명파라미터



Tmax 서비스에 전달할 데이터가 저장된 버퍼 포인터이다.ptr

Tmax 서비스에 전달할 데이터 길이이다.alen

Tmax 서비스에서 처리 결과를 받을 버퍼 포인터이다.optr

처리 결과의 데이터 길이가 저장될 long 포인터이다.olen

● 리턴값

Tmax 서비스를 처리할 때 오류가 발생하면 리턴값으로 오류 코드가 리턴된다.

리턴값이 –1인 경우에는 비정상적인 오류가 발생한 경우이다. 그 외의 –(minus)값은 Tmax 단에서 서비

스 처리 시 오류가 발생한 경우의 오류 코드이다.

6.3.2.4. tcpgw_tpacall

TCP/IP Multi-thread 게이트웨이에서 Tmax 서비스를 tpacall로 호출하는 경우 사용하는 함수이다. 이 함수

는 내부적으로 TPNOREPLY flag가 설정되기 때문에 응답을 받아오는 용도로 사용할 수 없다.

● 사용법

int tcpgw_tpacall(WORKTHRINFO *wthrinfo, char *svc, char *ptr, long alen)

설명파라미터




설명파라미터

Tmax 서비스에 전달할 데이터가 저장된 buffer 포인터이다.ptr

Tmax 서비스에 전달할 데이터 길이이다.alen

● 리턴값

Tmax 서비스를 처리할 때 오류가 발생하면 리턴값으로 오류 코드가 리턴된다.

리턴값이 –1인 경우에는 비정상적인 오류가 발생한 경우이다. 그 외의 –(minus)값은 Tmax 단에서 서비

스를 처리할 때 오류가 발생한 경우의 오류 코드이다.

6.3.2.5. tcpgw_tpreply

Tmax에서 서비스 요청이 먼저 온 경우, 리모트에서 서비스를 처리하고 그 결과를 Tmax에 전달하기 위해

서 사용하는 함수 이다.

● 사용법

int tcpgw_tpreply(WORKTHRINFO *wthrinfo, char *ptr, long alen, int err)

설명파라미터


Tmax 단에 전달할 처리 결과가 들어있는 buffer 포인터이다.ptr

처리 결과의 데이터 길이이다.alen

서비스를 처리할 때 오류가 발생할 경우 오류 코드이다.err

● 리턴값

리턴값이 –1인 경우에는 비정상적인 오류가 발생한 경우이다.

6.3.2.6. tcpgw_get_svcdata

Tmax에서 오는 데이터를 받기 위한 함수이다.

● 사용법

int tcpgw_get_svcdata(WORKTHRINFO *wthrinfo, char *ptr, int *err, int *flags)

설명파라미터


Tmax 단에 전달할 처리 결과가 들어있는 버퍼 포인터이다.ptr

서비스 처리 시 오류가 발생할 경우 오류 코드이다.err

Tmax에서 서비스를 요청할 때 응답을 받을 것인지 아닌지를 저장한다. 0이면 Tmax

단 서비스에서 응답을 기다리는 상태이고, 1이면 응답을 기다리지 않는 상태이다.

flags


● 리턴값

정상인 경우 리턴값으로는 데이터 길이가 반환되고, 오류인 경우에는 –1이 리턴된다.

6.3.2.7. tcpgw_network_connect

TCP/IP Thread 게이트웨이가 클라이언트 모드로 동작할 경우 리모트와 연결하기 위한 함수이다.

● 사용법

int tcpgw_network_connect(char *host, int port, int sec)

설명파라미터

리모트와 연결할 주소나 리모트 호스트명이다.host

'192.168.1.48' 처럼 IP 주소 string이 될 수도 있고, 노드명을 등록할 수도 있다.

리모트와 연결할 포트번호이다port

Connection timeout in secondsec

● 리턴값

정상인 경우 연결된 소켓 번호를 리턴하고, 오류이면 –1을 리턴한다.

6.3.2.8. tcpgw_worker_connect

TCP/IP Thread 게이트웨이가 클라이언트 모드로 동작할 경우 리모트와 연결하기 위한 함수이다.

● 사용법

int tcpgw_worker_connect(WORKTHRINFO *winfo, int sec);

설명파라미터



● 리턴값


6.3.2.9. tcpgw_read

리모트로부터 데이터를 수신하는 함수이다.

● 사용법

int tcpgw_read(int fd, char *ptr, int nbytes, int sec, int usec)

설명파라미터

리모트 소켓 번호이다.fd


설명파라미터

버퍼이다.ptr

리모트로부터 수신할 데이터 길이이다.nbytes




적용된다.

● 리턴값

정상인 경우 수신된 데이터 길이를 리턴하고, 오류이면 –1을 리턴한다.

6.3.2.10. tcpgw_write


● 사용법

int tcpgw_write(int fd, char *ptr, int nbytes)

설명파라미터

리모트 소켓 번호이다.fd

버퍼이다.ptr

리모트로 전송할 데이터 길이이다.nbytes

● 리턴값

정상인 경우 전송된 데이터 길이를 리턴하고, 오류이면 –1을 리턴한다.

6.3.2.11. tcpgw_portno_ipaddr

Argument로 입력 받은 포트번호와 리모트 주소를 얻는 함수이다.

● 사용법

int tcpgw_portno_ipaddr(WORKTHRINFO *winfo, char *ipaddr)

설명파라미터

리모트 주소가 저장될 버퍼이다.ipaddr

● 리턴값

포트번호를 리턴한다.


6.3.2.12. tcpgw_client_id

Thread에 할당된 게이트웨이 환경 파일에 입력한 ID를 얻어 오는 함수이다.

● 사용법

int tcpgw_client_id(WORKTHRINFO *winfo, char *id)

설명파라미터

Thread에서 넘겨준 WORKTHRINFO에 대한 포인터이다.winfo

ID가 저장될 버퍼이다.id

● 리턴값

항상 1이다.

6.3.3. 예제

본 절에서는 사용자 프로그램에 대한 기본적인 예제와 보안 라이브러리를 사용하는 예제를 설명한다.

기본 예제

다음은 사용자 프로그램(usrmain.c)의 예제이다.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <usrinc/alsvcapi.h>

#include <usrinc/althrgwapi.h>


{

printf("Gateway Started\n");

return 0;

}

int user_thrmain(WORKTHRINFO *winfo, int server)

{

if (server)

server_process(winfo);

return 1;

}

int server_process(WORKTHRINFO *winfo)

{

int n, len, flags;

char tmp[10];


memset(tmp, 0x00, sizeof(tmp));

while (1) {

/* Tmax 단에서 서비스 요청이 오는지 또한 Remote 클라이언트에서

데이터가 수신되는지를 동시에 감시, 사용자 프로그램은 대부분 아래

함수에서 대기 상태로 있어야만 서비스 요청 데이터를 수신할 수 있음 */

n = tcpgw_select(winfo, 0, 0);

if (n < 0)

return -1;

/* request from tmax service & client */

switch(n) {

/* Tmax 단 데이터 수신 */

case WTHR_TMAX_REQUEST:

len = tcpgw_get_svcdata(winfo, &rcvbuf[4],

&errflag, &flags);

if (len < 0) {

printf("service data read failed\n");

return -1;

}

/* 클라이언트에 서비스 요청 시 TPNOREPLY로 서비스 요청한

경우에는 먼저 handler에게 응답을 보내고 다음을 처리 */

if (flags)

n = tcpgw_tpreply(winfo, rcvbuf, n, 0);

sprintf(tmp, "%04d", len);

memcpy(rcvbuf, tmp, 4);

len += 4;

/* 클라이언트에 데이터 전송 : 송수신 헤더는 처음 4 Bytes가

데이터 길이로 했음 */

n = tcpgw_write(winfo->fd, rcvbuf, len);

if (n < 0) {

printf("remote client closed\n");

return -1;

}

printf("TMAX_REQUEST: remote write ok [%d]\n", n);

/* 클라이언트로부터 데이터 길이만 수신 */

n = tcpgw_read(winfo->fd, tmp, 4, 0);

if (n <= 0) {


return -1;

}

/* 데이터 길이를 계산하여 데이터가 없을 경우 */

len = atoi(tmp);


if (len <= 0)

break;

/* 실질적인 클라이언트 응답 데이터 수신 */

printf("TMAX_REQUEST: read length = %d\n", len);

n = tcpgw_read(winfo->fd, rcvbuf, len, 0);

if (n <= 0) {


return -1;

}

/* Tmax 단에서 서비스 요청시 TPNOREPLY로 call한 경우에는

이미 응답을 했으므로 서비스 요청을 하든지 아니면 버려야 함 */

if (flags) {

printf("USER_REQUEST: service call length"

"= %d\n", n);

flags = 1;

n = tcpgw_tpcall( winfo,"TESTSVC", rcvbuf, n,

rcvbuf, &rcvlen, 1);

}

else {

printf("TMAX_REQUEST: tpcall reply length"

"= %d\n", n);


}

if (n < 0) {

printf("tmax down\n");

return -1;

}

break;

case WTHR_USER_REQUEST:


n = tcpgw_read(winfo->fd, tmp, 4, 0);

if (n <= 0) {


return -1;

}


len = atoi(tmp);

if (len <= 0)

break;


printf("USER_REQUEST: read length = %d\n",

len);

n = tcpgw_read(winfo->fd, sndbuf, len);


if (n <= 0) {


return -1;

}

/* Tmax 단에 서비스 요청: 마지막 argument 값에 따라서

응답을 수신할 것인지를 결정 함 */

printf("USER_REQUEST: service call length = %d\n", n);

n = tcpgw_tpcall( winfo, "TESTSVC", sndbuf, n,


if (n < 0) {

printf("service failed: [%d]\n", n);

}

/* Tmax 서비스에서 응답 수신 */

sprintf(tmp, "%04d", rcvlen);

memcpy(sndbuf, tmp, 4);

memcpy(&sndbuf[4], rcvbuf, rcvlen);

len = rcvlen + 4;

/* 클라이언트에 전송 */

printf("USER_REQUEST: service reply length"

" = %d\n", len);

n = tcpgw_write(winfo->fd, sndbuf, len);

if (n < 0) {


return -1;

}

break;

case WTHR_SELECT_TIMEOUT:

/* timeout process */

break;

}

}

return 1;

}

보안 라이브러리를 사용하는 예제다음의 예제는 실제 사이트에 응용되고 있는 것으로, 대외 기관에서 암호화 모듈을 통해서 데이터를 받아

서 내부에 있는 배치 게이트웨이로 복호화해서 전달해 주고, 배치 게이트웨이에서 나온 전문을 암호화해

서 대외 기관으로 보내주는 시스템이다.

이와 같이 TCP/IP Multi-thread 게이트웨이는 암호화 모듈 중계 기능을 하는 서버로서 역할을 수행할 수

있다. 이 중계 서버로 인해서 내부 시스템은 별도의 암복호화 모듈에 상관없이 구축이 가능하다.


다음은 user_thrmain의 플로우만을 설명한 예제이다. tcpgw_select2에 대한 사용 예가 포함되어 있다.


{

if (server)


return 1;

}


{

int n, rcvlen, sndlen, declen, enclen, errflag, flags;

int state, batfd, etcfd;

msg_header_t header;

XECURE_CTX *ctx = NULL;

alinkhead_t *ahp;

state = SERVER_HELLO;

/* 1. 보안모듈 초기화 */

if (!(ctx = SF_New_Xecure_Ctx(

XT_OP_SELF_AUTH | XT_OP_PEER_AUTH | XT_OP_SELF_SIGN |

XT_OP_PEER_SIGN, SEED_128_HAS_IV)) ) {

printf("SF_New_Xecure_Ctx Failed : Insufficient memory\n");

goto FUNCTION_END;

}

/* 2. 내부 시스템 BATGW에 전달할 세션 연결 */

batfd = tcpgw_network_connect(_ip, _port, 0);

if (batfd < 0) {

printf("Cannot connect to batgw!\n");

return -1;

}

while (1) {

etcfd = batfd;

/* tcpgw_select2를 사용해서 remote fd와 BATGW fd를

동시에 select 가능함 */

n = tcpgw_select2(winfo, &etcfd, 0, 0);


if (n < 0)

goto FUNCTION_END;

/* BATGW fd를 먼저 check한다. etcfd가 음이 아닌 수로

return되면 BATGW에서 데이터가 온 것임 */

if ((batfd >= 0) && (etcfd >= 0)) {

if (batgw_request(winfo, batfd, ctx, state)

< 0)


goto FUNCTION_END;

}

/* remote에서 온 데이터를 check함 */

switch(n) {


if ( user_request(winfo, batfd, ctx, &state) < 0)

goto FUNCTION_END;

break;

case WTHR_TMAX_REQUEST: /* TMAX에서 오는 것은 없음 */

goto FUNCTION_END;


break;

}

}

/* 종료 시 보안 모듈 관련 자원 반환 */

if (ctx != NULL)

SF_Free_Xecure_Ctx(ctx);

if (batfd >= 0)

close(batfd);

return -1;

}

FUNCTION_END:

/* 종료 시 보안 모듈 관련 자원 반환 */

if (ctx != NULL)

SF_Free_Xecure_Ctx(ctx);

if (batfd >= 0)

close(batfd);

return -1;

}

6.4. TCP/IP Multi-thread 게이트웨이 호출 방법TCP/IP Multi-thread 게이트웨이를 tp(a)call로 호출할 때 다음과 같이 TPGWINFO_T를 전문 앞에 붙여서

호출한다.

호출할 때 svc라는 변수에 클라이언트 ID를 설정하면 Dedicated 모드에서 사용이 가능하다. Dedicated 모

드가 아닐 경우는 TPGWINFO_T의 공간만 설정해서 호출하면 된다.

#include <usrinc/hlinkapi.h>

…

TPGWINFO_T *gwinfo;

…

sndbuf = (char *)tpalloc("CARRAY", NULL, 4096);


return -1;

}


rcvbuf = (char *)tpalloc("CARRAY", NULL, 4096);


tpfree(sndbuf);

return -1;

}

memset(sndbuf, 0x00, 4096);

gwinfo = (TPGWINFO_T *)sndbuf;

strncpy(gwinfo->svc, "thrcli_01", XATMI_SERVICE_NAME_LENGTH);

sndlen = sizeof(TPGWINFO_T);

if (!term) {

memcpy(sndbuf + sizeof(TPGWINFO_T), snddata, strlen(snddata));

sndlen += strlen(snddata);

}

n = tpcall("THRCLI", sndbuf, sndlen, &rcvbuf, &rcvlen, 0);

if (n == -1) {

printf("tpcall failed tperrno[%d]\n", tperrno);

tpfree(sndbuf);

tpfree(rcvbuf);

return -1;

}

…


제7장 SSL Multi-thread 게이트웨이

본 장에서는 SSL Multi-thread 게이트웨이의 기능 및 설정 방법을 설명한다.

7.1. 개요SSL Multi-thread 게이트웨이는 앞 장에 설명된 TCP/IP Multi-thread 게이트웨이와 프로토콜적인 부분 외

에 큰 차이는 없다. 먼저 TCP/IP Multi-thread 게이트웨이를 숙지한 후에 살펴보기 바란다. 본 장에서는 차

이점 위주로 설명한다.

Listener와 핸들러 구조는 TCP/IP와 동일하다. 단, SSL 프로토콜로 인하여 Listener에서 핸들러로 연결을

넘겨주면 핸들러의 Main-thread는 SSL_accept 과정을 거쳐서 SSL의 Handshake 과정을 거친다. 그 다음

에 Worker thread를 선택해서 이후 작업을 thr_usermain을 통해 수행한다.

새로운 연결이 들어올 때마다 위 과정을 반복한다.

7.2. 환경설정본 절에서는 SSL Multi-thread 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일의 설정 방법은 “제2장 TCP/IP 게이트웨이”에서 설명한 내용과 동일하다.


Admin에서 게이트웨이에 Listener를 등록한다. 기본적으로 TCP/IP Multi-thread 게이트웨이와 동일하며,

SSL을 위한 추가 설정 사항은 “제4장 SSL 게이트웨이”를 참고한다.

● 등록 항목



설명항목

Listener의 Tmax 서버명을 등록한다.이름


Tmax 환경 파일에 설정한 Listener 서비스명을 등록한다.서비스명

제7장 SSL Multi-thread 게이트웨이 109

설명항목

'SSL'를 선택한다.프로토콜

'온라인 Thread'을 선택한다.Type

대내/대외 중 선택한다. 둘 중 어느것을 선택해도 동작에는 차이가 없고,

단지 구분하기 위한 정보성 데이터이다.

대내외구분

해당 Listener에 핸들러를 몇 개 띄울 것인지를 등록한다. Tmax 설정에

핸들러 서버의 MIN, MAX로 등록한 값과 동일해야 한다.

Thread G/W 핸들러 수

인증서의 절대 경로이다. Handshake 과정에서 사용되며, 통신 상대에

게 자신을 확인시키기 위해서 필요하다.

인증서

인증서의 비밀번호이다.인증서 비밀번호

인증서 발급 기관의 인증서의 절대 경로이다. 인증서와 혼돈이 있을 수

있는데, 인증서를 발급한 기관도 신뢰할 수 있어야 하기 때문에 필요하

다.

인증서 발급기관의 인증서

개인 키의 절대 경로이다.개인키

엄격한 보안이 필요할 때에 선택적으로 사용할 수 있다.Ephemeral keying 사용여부

Ephemeral keying을 하기 위한 파라미터 파일들의 위치이다.Ephemeral keying 파일 경로

● 게이트웨이 등록 예(SSL Multi-thread 게이트웨이)

인증서와 개인 키 등 SSL 프로토콜을 사용하기 위해 추가되는 항목들은 “제4장 SSL 게이트웨이”에서

사용한 예와 동일하다고 가정한다.

설명항목

sslthrgwlsn이름

SSLTHRGWLSN서비스명

SSL프로토콜

온라인 ThreadType

대외대내외구분

2Thread G/W 핸들러 수

/usr/local/ssl/certs/rootcert.pem인증서

/usr/local/ssl/certs/rootcert.pem인증서 발급기관의 인증서

anylinkpwd인증서 비밀번호

/usr/local/ssl/certs/rootkey.pem개인키

사용안함Ephemeral keying 사용여부



Admin에서 Listen할 회선(Line)을 등록한다. SSL 게이트웨이의 서버 모드 회선 등록과 동일하게 설정하

면 되므로 자세한 내용은 “제4장 SSL 게이트웨이”를 참고한다.

7.3. 사용자 프로그램(usrmain.c)대부분이 TCP/IP와 동일하며 차이점은 사용자 API에서 리모트와 관련된 것들이다.

tcpgw_select, tcpgw_network_connect, tcpgw_read, sslgw_write 대신 sslgw_select, sslgw_network_con

nect, sslgw_read, tcpgw_write가 각각 사용된다.


본 절에서는 사용자 프로그램(usrmain.c)에서 사용되는 사용자 API에 대해 설명한다.

7.3.1.1. sslgw_select

Multi-thread 게이트웨이에서 Tmax나 리모트로부터 데이터가 들어왔는지 감지하는 함수이다.

● 사용법

int sslgw_select(WORKTHRINFO *wthrinfo, int sec, int usec)

설명파라미터





적용된다.

● 리턴값

설명리턴값






7.3.1.2. sslgw_network_connect

SSL Thread 게이트웨이가 클라이언트 모드로 동작할 경우 리모트와 연결하기 위한 함수이다.

● 사용법

int sslgw_network_connect(WORKTHRINFO *winfo, char *host, int port, int sec)

설명파라미터

user_thrmain에서 넘겨준 WORKTHRINFO에 대한 포인터이다.winfo

리모트와 연결할 주소나 리모트 호스트명이다.host

'192.168.1.48' 처럼 IP 주소 string이 될 수도 있고, 노드명을 등록할 수도 있다.

리모트와 연결할 포트번호이다.port


● 리턴값


7.3.1.3. sslgw_read


● 사용법

int sslgw_read(WORKTHRINFO *winfo, char *ptr, int nbytes)

설명파라미터


버퍼이다.ptr

리모트로부터 수신할 데이터 길이이다.nbytes

● 리턴값

정상인 경우 수신된 데이터 길이를 리턴하고, 오류이면 –1을 리턴한다.

7.3.1.4. sslgw_write


● 사용법

int sslgw_write(WORKTHRINFO *winfo, char *ptr, int nbytes)

설명파라미터



설명파라미터

버퍼이다.ptr

리모트로 전송할 데이터 길이이다.nbytes

● 리턴값

정상인 경우 전송된 데이터 길이를 리턴하고, 오류이면 –1을 리턴한다.

7.3.2. 예제

다음은 TCP/IP Multi-thread 게이트웨이의 예제를 SSL 버전으로 수정한 예제이다. TCP/IP Multi-thread 게

이트웨이에 대한 예제는 “제6장 TCP/IP Multi-Thread 게이트웨이”를 참고한다.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <usrinc/alsvcapi.h>

#include <usrinc/althrgwapi.h>


{

printf("Gateway Started\n");

return 0;

}


{

if (server)


return 1;

}


{

int n, len, flags;

char tmp[10];

memset(tmp, 0x00, sizeof(tmp));

while (1) {

/* Tmax단에서 서비스 요청이 오는지 또한 Remote 클라이언트에서

데이터가 수신되는지를 동시에 감시, 사용자 프로그램은 대부분 아래

함수에서 대기 상태로 있어야만 서비스 요청 데이터를 수신할 수 있음 */

n = sslgw_select(winfo, 0, 0);

if (n < 0)

return -1;



switch(n) {

/* Tmax 단 데이터 수신 */

case WTHR_TMAX_REQUEST:

len = tcpgw_get_svcdata(winfo, &rcvbuf[4],

&errflag, &flags);

if (len < 0) {

printf("service data read failed\n");

return -1;

}

/* 클라이언트에 서비스 요청 시 TPNOREPLY로 서비스 요청한

경우에는 먼저 핸들러에게 응답을 보내고 다음을 처리 */

if (flags)


sprintf(tmp, "%04d", len);

memcpy(rcvbuf, tmp, 4);

len += 4;

/* 클라이언트에 데이터 전송 : 송수신 헤더는 처음 4 Bytes가

데이터 길이로 했음 */

n = sslgw_write(winfo, rcvbuf, len);

if (n < 0) {


return -1;

}

printf("TMAX_REQUEST: remote write ok [%d]\n", n);


n = sslgw_read(winfo, tmp, 4);

if (n <= 0) {


return -1;

}


len = atoi(tmp);

if (len <= 0)

break;


printf("TMAX_REQUEST: read length = %d\n", len);

n = sslgw_read(winfo, rcvbuf, len);

if (n <= 0) {



return -1;

}

/* Tmax 단에서 서비스 요청시 TPNOREPLY로 call한 경우에는

이미 응답을 했으므로 서비스 요청을 하든지 아니면 버려야 함 */

if (flags) {

printf("USER_REQUEST: service call length"

"= %d\n", n);

flags = 1;

n = tcpgw_tpcall( winfo,"TESTSVC", rcvbuf, n,


}

else {

printf("TMAX_REQUEST: tpcall reply length"

"= %d\n", n);


}

if (n < 0) {

printf("tmax down\n");

return -1;

}

break;



n = sslgw_read(winfo, tmp, 4);

if (n <= 0) {


return -1;

}


len = atoi(tmp);

if (len <= 0)

break;


printf("USER_REQUEST: read length = %d\n",

len);

n = sslgw_read(winfo, sndbuf, len);

if (n <= 0) {


return -1;

}

/* Tmax 단에 서비스 요청: 마지막 argument 값에 따라서

응답을 수신할 것인지를 결정 함 */

printf("USER_REQUEST: service call length = %d\n", n);

n = tcpgw_tpcall( winfo, "TESTSVC", sndbuf, n,



if (n < 0) {

printf("service failed: [%d]\n", n);

}

/* Tmax 서비스에서 응답 수신 */

sprintf(tmp, "%04d", rcvlen);

memcpy(sndbuf, tmp, 4);

memcpy(&sndbuf[4], rcvbuf, rcvlen);

len = rcvlen + 4;

/* 클라이언트에 전송 */

printf("USER_REQUEST: service reply length"

" = %d\n", len);

n = sslgw_write(winfo, sndbuf, len);

if (n < 0) {


return -1;

}

break;


/* timeout process */

break;

}

}

return 1;

}


제8장 IMS Connect 게이트웨이

본 장에서는 IBM Mainframe의 IMS 미들웨어와 TCP/IP 통신을 하는 IMS Connect라는 제품과 통신이 가

능한 게이트웨이의 기능 및 설정 방법을 설명한다.

8.1. 개요IMS Connect 게이트웨이는 IBM Mainframe의 미들웨어인 IMS와 TCP/IP 통신을 수행할 때 사용된다. IMS

Connect라는 Mainframe용 소프트웨어와 정의된 TCP/IP 통신을 수행해준다.

통신 모드는 비동기 통신이 가능하도록 send-only(HOST INBOUND, 회선의 처리방식 : OUT_CHANNEL)

세션과 resume-Tpipe(HOST OUTBOUND, 회선의 처리방식 : IN_CHANNEL) 세션을 두어서 호스트로 올

리는 전문은 send-only 세션으로 올린다. 호스트로 받는 전문은 resume-Tpipe 세션으로 받기 때문에 기존

에 비동기(Async) 방식으로 통신이 가능하고, 'client(수시)'처럼 Transaction 단위 connection'이 아닌

'Permanent connection'으로 맺어서 사용할 수 있기 때문에 효율적인 통신이 가능하다.

TCP/IP 게이트웨이와 동일한 바이너리를 사용하므로 파싱 및 로깅 등의 기본적인 기능은 동일하게 사용

이 가능하다. 본 장에서는 IMS Connect 게이트웨이의 특징 위주로 설명한다.

8.1.1. IRM Header

IRM(IMS Request Message) Header는 호스트 송신 데이터의 앞 부분에 붙여줘야 하는 구조체이다.

이 구조체 내에는 전체 전문 길이, Socket type(Permanent, Transaction connection), Timer value, Client

ID, Commit Mode, Sync Level, IMS Transaction Code, Datastore ID, Logical Terminal(LTERM) 등의 정

보를 설정해서 호스트로 전달함으로써 데이터를 송신할 때나, Resume-Tpipe connection을 맺을 때 사용

할 수 있다. 호스트로 전송하므로 EBCDIC으로 인코딩되어야 한다.

● Socket type

Permanent connection(client)이나 Transaction connection(client(수시))을 구분하는 타입으로 IMS

Connect 게이트웨이에서는 Permanent connection만 지원한다.

● Timer value

Resume Tpipe connection 시 해당 세션의 타임아웃 값을 설정해서 호스트로 전달한다. 설정하는 방법

은 "IMS Connect Manual"을 참조한다.

● Client ID

IMS Connect는 TCP/IP에서 서버 모드로만 동작하기 때문에 각 세션을 관리하기 위해서 호스트로 메시

지를 송신할 때 Unique한 ID를 설정해서 전달해야 한다.

제8장 IMS Connect 게이트웨이 117

특히, Resume-Tpipe 세션의 경우 동일한 Client ID로 등록되면 기존에 연결됐던 세션도 오동작하게 되

므로 Admin에 등록할 때 주의해야 한다.

Admin의 회선 정보에 등록하며 'Client ID for Data'는 send-only 세션과 resume Tpipe 세션의 데이터 송

수신용 세션에 사용되고, 'Client ID for IMS Command'는 resume-Tpipe 세션의 시작 및 종료 시 IMS

Command를 보내기 위한 Client ID이다.

● Commit Mode

Commit mode ‘0’, Commit mode ‘1’의 두 가지 유형이 있으며, response mode transaction, IMS command

는 Commit mode ‘1’이고, 나머지는 Commit mode ‘0’이다.

● Sync Level

None과 Confirm이 있으며, Confirm의 경우 응답을 받은 후 응답에 대한 ACK를 보내하고, None은 보내

지 않아도 된다. IMS Connect 게이트웨이에서는 None만 지원한다.

● IMS Transaction Code

IMS에서 인식할 수 있는 8Byte Transaction Code를 설정해서 올려준다. 이 값은 send-only 세션의 경

우, 스튜디오의 거래 파라미터 정보에 '호스트 정보->TXID'의 설정값이 되고, 그 외의 경우는 space(0x40)

을 입력해서 넘겨준다.

● Datastore ID

IMS destination ID라고도 불리며 Admin의 회선 정보에 'Data Store Name' 항목에 설정하면 된다. 이

값은 평일계/휴일계 마다 달라질 수 있으므로 평일계용 회선, 휴일계용 회선을 각각 등록한 후 'Data

Store Name'을 달리하고 일자에 따라 회선을 연결하거나 끊으면서 운영할 수 있다.

● Logical Terminal(LTERM)

해당 항목은 Admin의 회선 정보에 'Logical Terminal' 항목에 설정한다.

8.1.2. Response 모드

Sync 거래일 경우 요청한 세션으로 응답을 받는다. 이러한 경우를 Response 모드라고 하는데, 이 경우는

해당 세션을 회선 재사용 여부 'No'로 사용하기 때문에 대량의 거래가 집중될 경우 세션 수가 많아지게 되

어 부하를 감당하기 힘들다. 따라서 IMS Connect 게이트웨이에서는 해당 모드를 지원하지 않는다.

8.1.3. Send-only 세션

호스트로 데이터를 송신하기 위한 회선의 '처리 방식'이 'OUT_CHANNEL'로 요청/응답 데이터 송신 시 모

두 사용된다. 동작 원리는 다음과 같다.


[그림 8.1] IMS Connect Send-only 세션 동작 원리

데이터를 송신할 때 전달되는 데이터 구조는 다음과 같다.

[그림 8.2] IMS Connect Send-only 세션 전달 메시지 구조

맨 앞부분에 IRM Header가 붙고, 그 다음에 'll + zz' 이라고 하여 2 Byte씩 length field와 return code field

가 이어진다. 이 ll에 big endian 형식으로 전문의 2 Byte length를 설정한다. 그 다음에 전문이 오고, 맨 뒤

에 'll + zz'가 한 번 더 이어지는데 이 부분에 길이는 0으로 설정함으로써 데이터의 끝임을 알린다.

IRM Header를 put_msg_info에서 GET_IRM_HEADER macro를 통해서 얻어올 수 있으며, 이때 Transaction

ID 등을 재정의할 수 있다.


8.1.4. Resume-Tpipe 세션

호스트에서 데이터를 수신하기 위한 회선의 '처리 방식'이 'IN_CHANNEL'로 요청/응답 데이터를 수신할

때 모두 사용된다.

특이한 점은 호스트에서 내려오는 데이터지만 IMS Connect 게이트웨이 측에서 연결를 하는 방식으로

Permanent connection으로만 동작해야 한다. 또한, 맺고 끊을 때 별도의 세션으로 IMS command를 보내

서 시작과 종료를 해야 한다.

데이터를 수신할 때 전달되는 데이터 구조는 send-only 세션과 다르고, 동작 원리는 다음과 같다.

● Start Command

먼저 Resume-Tpipe 세션을 맺기 전에 IMS Command를 전송하여 Tmember를 start 시킨다.

[그림 8.3] IMS Connect IMS command 전달 메시지 구조

데이터에 해당하는 부분은 '/STA TMEMBER ICON2 TPIPE ICFL201'과 같은 형태로 구성된다. 이 명령

을 실행하면 IMS에 해당 Client ID로 붙겠다는 것을 알리게 된다.

/STA TMEMBER <Admin 회선 정보의 "IMS Connect Tmember">

TPIPE <Admin 회선 정보의 "client ID for Data">

정상적인 경우 다음과 같은 메시지를 응답으로 받는다.

DFS058I 18:07:15 START COMMAND COMPLETED


● Resume-Tpipe 세션 연결

[그림 8.4] IMS Connect Resume-Tpipe 세션 동작 원리

다음과 같이 맨 앞에 'll + zz'가 붙고, 데이터, 그 다음에 'll + zz' 다음에 '*CSMOKY*'라는 메시지가 오면

정상적인 경우이다.

[그림 8.5] IMS Connect Resume-Tpipe 수신 메시지 구조

그러나 다음과 같이 '*REQSTS*'가 오면 호출 시 에러가 발생해서 IMS Connect 단에서리턴된 것이다.

'*REQSTS*'를 RSM(Request Status Mode)라고 부르며 그 다음에 Return code와 Reason code가 전달

되서 오는데 이것을 IMS Connect 게이트웨이에서 출력되기 때문에 이 값을 바탕으로 호스트에서 어떠

한 에러가 발생했는지를 확인할 수 있다.


[그림 8.6] IMS Connect Resume-Tpipe RSM 메시지 수신 구조

● Stop Command

게이트웨이를 다운(down)시키거나 회선의 삭제 및 중지 등의 사유로 resume-Tpipe 세션을 강제로 끊

을 때는 IMS command를 보내서 중지할 수 있다. Start command와 유사하게 다음과 같이 수행하면 된

다.

[그림 8.7] IMS Connect IMS command 전달 메시지 구조

데이터에 해당하는 부분은 '/STO TMEMBER ICON2 TPIPE ICFL201'과 같은 형태로 구성된다. 이 명령

을 시행하면 IMS에 해당 Client ID로 붙겠다는 것을 알리게 된다.

/STO TMEMBER <Admin 회선 정보의 "IMS Connect Tmember">

TPIPE <Admin 회선 정보의 "Client ID for Data">

정상적인 경우 다음과 같은 메시지를 응답으로 받는다.

DFS058I 18:07:15 STOP COMMAND COMPLETED

8.2. 환경설정본 절에서는 IMS Connect 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다. Online 게이트웨이와 동일한 라이브러리를 사

용할 뿐 게이트웨이의 '프로토콜'만 다르게 등록하므로 TCP/IP 게이트웨이와 동일하게 설정한다.

● SERVER 절

IMS Connect Gateway에서는 CLOPT에 아래와 같은 옵션을 설정할 수 있다.

설명옵션

IMS connect 회선 중 IN CHANNEL을 사용할 때, IMS에서 전달된 REQSTS 메시지의 코

드에 따라 reconnect할 때 기본적으로 설정된 회선의 재접속 간격 외에 추가로 지연될 시

i

간을 정의한다. 이 값은 기본값과 코드별 값을 모두 지정할 수 있으며 지정되지 않은 경

우 즉시 회선을 복구한다.

IMS connect 회선을 사용할 때 IRM header 값 중 flag1, flag3 값을 정의한다. 옵션을 사

용하지 않은 경우 flag1에는 0x00이, flag3에는 0x01 값이 설정된다.

m




● 등록 항목



설명항목




회선 장애 발생 시 호출될 서비스명을 등록한다.백업 서비스명

'TCP/IP with IMS connect'를 선택한다.프로토콜



한다.

대내외구분

게이트웨이가 특정 기관-업무에만 종속된 경우에 값을 할당해주면 게이

트웨이-level 기관-업무 파싱을 수행한다.





프로토콜을 'TCP/IP with IMS connect'로 설정하면 '통신헤더'로 고정된

다.

메시지 길이 지정

프로토콜을 'TCP/IP with IMS connect'로 설정하면 '통신헤더'로 고정된

다.

통신헤더타입

프로토콜을 'TCP/IP with IMS connect'로 설정하면 '4'로 고정된다.통신헤더길이

● 게이트웨이 등록 예 (대내용 IMS Connect 게이트웨이)

설명항목

imsgwint이름

IMSGWINT서비스명

TCP/IP with IMS connect프로토콜

온라인Type

Internal대내외구분




● 등록 항목

회선은 게이트웨이가 대외/대내 기관으로부터 요청/응답을 받는 논리적인 연결을 말하며 등록된 후에

는 수정 및 삭제 뿐만 아니라 중지 및 재개도 가능하다.

설명항목



회선이름

회선이 포함된 노드명으로 자동 입력된다.노드명

회선이 포함된 게이트웨이명으로 자동 입력된다.Gateway 이름

호스트로 연결할 IP을 등록한다.회선명/IP주소

호스트로 연결할 포트를 등록한다.LU이름/포트번호

호스트로 연결할 세션 수를 등록한다.세션수

send-only 세션의 경우 'Client(on demand)'를 선택한다. Resume-Tpipe 세션

의 경우, 'Client'를 선택한다.

TCP/IP C/S구분


– OUT_CHANNEL : send-only 세션의 경우

– IN_CHANNEL : resume-Tpipe 세션의 경우

resume-Tpipe 세션의 경우 연결하지 못했을 때(resume-Tpipe step까지 제대

로 타지 못하고 끊어졌거나, 타임아웃이 발생하여 끊어진 이후 연결 시도에

바로 붙지 않았을 때) 재접속 시도하는 주기이다.

재접속 간격

만약, 이 값을 입력하지 않을 경우, 장애가 발생하여 세션이 끊어지면 게이트

웨이를 재기동하기 전까지 재접속하지 않는다.

'Yes'로 설정한다.회선 재사용 여부



resume-Tpipe 세션에서 응답을 줄 send-only 세션을 지정한다.



이다.


LTERM 필드를 채우기 위한 값으로 호스트로부터 할당받는다.Logical Terminal

resume-Tpipe 세션의 start/stop command 전송 시 사용되는 Tmember 이름

이다.

IMS CONNECT Tmem

ber

IRM header의 Datastore ID명을 설정할 때 사용한다.Data Store Name

send-only 세션의 경우 데이터를 송신할 때, resume-Tpipe 세션의 경우

'Cancel Timer', 'Resume Tpipe', 'ACK'를 보낼 때 사용한다.

Client ID for Data


설명항목

resume-Tpipe 세션에서 start/stop command를 전송할 때 IRM Header에 설

정하는 Client ID이다.

Client ID for IMS Com

mand

8.3. 사용자 프로그램(custom.h, custom.c)TCP/IP 게이트웨이와 동일한 라이브러리를 사용하며 custom.h, custom.c도 동일하게 사용한다. API도 모

두 사용할 수 있다. 단, 추가로 put_msg_info에서 아래의 기능을 사용할 수 있다.

custom.c에 $TMAXDIR/usrinc/hlotma.h를 include하도록 한다.

이 헤더 파일 내에 IRM 구조체를 이용해서 IRM Header를 얻어낼 수 있다. 이 값은 엔진이 이미 필요한 필

드들을 채운 구조체이며 사용자가 원하는 값으로 바꾸고자 할 경우에 사용된다. 예를 들어 trancode(IMS

Transaction Code)를 거래 코드 이하의 레벨에서 세부화할 경우에 사용될 수 있다.

struct base_irm_t {

int llll;

short ll;

short zz;

char msgid[8];

char reserved1[4];

unsigned char flag5;

unsigned char timer;

unsigned char soct;

unsigned char es;

char clientid[LEN_IMS_CLIENTID];

};

struct extend_irm_t {





char trancode[LEN_IMS_TXID];

char datastore[LEN_IMS_DATASTORE];

char lterm[LEN_IMS_LTERM];

char racf_userid[LEN_IMS_USERID];

char racf_gnm[LEN_IMS_GRNAME];

char racf_passwd[LEN_IMS_PASSWD];

};

struct irm_t {

struct base_irm_t base;

struct extend_irm_t extend;

};

typedef struct irm_t IRM;


Send-only 세션의 경우 마지막으로 데이터를 내보내기 전에 put_msg_info를 호출하는데, 이 시점에 전달

되는 데이터는 아래의 그림과 같은 구조이다. put _msg_info의 프로토 타입이 다음과 같을 때 IRM Header

는 hlotma.h에서 GET_IRM_HEADER macro를 통해서 얻을 수 있다.

int put_msg_info(msg_header_t *hp, char *data, …);

[그림 8.8] IMS Connect custom.c에서 IRM Header 얻는 방법

다음의 코드로 IRM Header를 얻어서 조작 가능하다.


{

IRM *irm;

char buff[LEN_IMS_TXID + 1];

/* IRM header 얻어오기 */

Irm = GET_IRM_HEADER(hp)

/* trancode에 설정하는 방법, null term 하지 않으므로

Memcpy를 사용할 것 */

/* EBCDIC으로 변환 후 세팅할 것, 단 CAP header에서 copy

할 경우는 이미 EBCDIC이므로 memcpy 하면 됨 */

unix_to_ibm(LEN_IMS_TXID, “AAAAAAAA”, buff);

memcpy(hp->len, buf, 10);

……

}


제9장 CICS Connect 게이트웨이

본 장에서는 IBM Mainframe의 CICS 미들웨어와 TCP/IP 통신을 하는 게이트웨이의 기능 및 설정 방법을

설명한다.

9.1. 개요CICS Connect 게이트웨이는 IBM Mainframe의 미들웨어인 CICS와 TCP/IP 통신을 수행할 때 사용된다.

IMS Connect 게이트웨이와의 차이점은 Permanent connection을 지원하지 않으며 reume-Tpipe 세션과

같이 복잡한 IN_CHANNEL 형태가 아닌 일반 TCP/IP 게이트웨이에서 사용하는 서버 모드 회선을 이용한

다는 것이다. 즉, mainframe 쪽에서 AnyLink로 connect를 하므로 복잡한 프로토콜이 필요없다.

TCP/IP 게이트웨이와 차이점은 호스트로 송신할 때 가장 앞부분에 50 Byte의 헤더를 붙여서 송신하는 것

이다. 그 외에는 모든 기능이 동일하다. TCP/IP 게이트웨이와 동일한 바이너리를 사용하므로 파싱 및 로

깅 등의 기본적인 기능은 동일하게 사용이 가능하다.

CICS Request Header

CICS Request Header는 호스트 송신 데이터의 앞 부분에 붙여줘야 하는 구조체이다. 이 구조체는 총 50

byte로 앞의 4 Byte는 Transaction Code를 채워주고 나머지는 EBCDIC space(0x40)로 채워준다.

● CICS Transaction Code

CICS에서 인식할 수 있는 4 Byte Transaction Code를 설정해서 올려준다. 스튜디오의 거래 파라미터

정보에 '호스트 정보->TXID'에 설정값이 입력된다.

9.2. 환경설정본 절에서는 CICS Connect 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다. Online 게이트웨이와 동일한 라이브러리를 사

용하고, 게이트웨이의 '프로토콜'만 다르게 등록하므로 TCP/IP 게이트웨이와 동일하게 설정한다. TCP/IP

게이트웨이 설정에 대한 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

제9장 CICS Connect 게이트웨이 127



● 게이트웨이 등록



다음의 프로토콜만 해당 값으로 설정하고, 나머지 항목은 TCP/IP 게이트웨이와 동일하게 설정한다.

TCP/IP 게이트웨이 설정에 대한 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

설명항목

'TCP/IP with CICS connect'를 선택한다.프로토콜


Admin에서 회선(Line)을 등록한다. TCP/IP 게이트웨이와 동일하게 설정한다. 자세한 내용은 “제2장 TCP/IP

게이트웨이”를 참고한다.

9.3. 사용자 프로그램(custom.h, custom.c)TCP/IP 게이트웨이와 동일한 라이브러리를 사용하며 custom.h, custom.c도 동일하게 사용한다. 또한, API

도 모두 사용할 수 있다. 단, 추가로 put_msg_info에서 아래의 기능을 사용할 수 있다.

custom.c에 $TMAXDIR/usrinc/hlotma.h를 include하도록 한다.

이 헤더 파일 내에 CICS_HEADER 구조체를 이용해서 CICS Request Header를 얻어낼 수 있다. 이 값은

엔진이 이미 필요한 필드들을 채운 구조체이며 사용자가 원하는 값으로 변경하고자 할 경우에 사용된다.

예를 들어, trancode(IMS Transaction Code)를 거래 코드 이하의 레벨에서 세부화할 경우에 사용될 수 있

다.

struct cics_header_t {

char trancode[LEN_CICS_TXID];

char filler[LEN_CICS_FILLER];

};

typedef struct cics_header_t CICS_HEADER;

호스트로 데이터를 내보내기 전에 put_msg_info를 호출하는데, 이 시점에 전달되는 데이터의 구조는 아

래의 그림과 같다. put _msg_info의 프로토 타입이 다음과 같을 때 hlotma.h에서 GET_CICS_HEADER

macro를 통해서 얻을 수 있다.

int put_msg_info(msg_header_t *hp, char *data, …);


[그림 9.1] CICS Connect custom.c에서 CICS Request header 얻는 방법

다음과 같은 코드로 CICS Request header를 얻어서 조작 가능하다.


{

CICS_HEADER *crh;

char buff[LEN_CICS_TXID + 1];

/* CICS Request header 얻어오기 */

crh = GET_CICS_HEADER(hp);

/* trancode에 설정하는 방법, null term.하지 않으므로

memcpy 를 사용할 것 */

/* EBCDIC 으로 변환 후 세팅할 것, 단 CAP header 에서 copy 할 경우는

이미 EBCDIC 이므로 memcpy 만 하면 됨 */

unix_to_ibm(LEN_CICS_TXID, "AAAA", buff);

memcpy(crh-> trancode, buff, LEN_CICS_TXID);

…

제9장 CICS Connect 게이트웨이 129

제10장 MQ Series 게이트웨이

본 장에서는 IBM MQ Series를 통해서 전문을 송수신하는 온라인 게이트웨이의 기능 및 설정 방법을 설명

한다.

10.1. 개요IBM MQ Series의 Queue를 회선 개념으로 생각하여 Online 게이트웨이 형태로 개발한 것으로 MQ Series

라이브러리가 설치되어 있다는 전제하여 동작한다.

MQ Series는 Queue 기반의 시스템인데, Queue를 Online 게이트웨이의 회선 개념으로 매핑하여 개발되

었기 때문에 TCP/IP 게이트웨이와 구조가 거의 유사하며, Mapper는 MQ로부터의 입출력인지 여부와 상

관없이 시스템을 구성할 수 있는 장점이 있다.

참고

타임아웃 및 지연 응답 처리 , 파일 로깅, 캐시 기능, 백업(Backup) 게이트웨이에 대한 설명은 “제2

장 TCP/IP 게이트웨이”를 참고한다.

10.1.1. 통신

MQ Series 게이트웨이의 통신 부분의 특성은 다음과 같다.

● 통신 방향성

Queue는 Get Queue와 Put Queue로 나뉘며, 하나의 Queue는 두 가지 역할을 수행할 수 없고 한 가지

모드로만 동작한다.

Get Queue는 게이트웨이로 전문을 넘겨주는 것이므로 IN_CHANNEL로 간주되고, Put Queue는 게이

트웨이가 전문을 내보내는 것이므로 OUT_CHANNEL로 간주한다. Get Queue에서 데이터를 얻어오는

MQ API는 MQGET, Put Queue로 데이터를 보내는 것은 MQPUT이다.

● 서버/클라이언트 모드

항상 클라이언트 모드로만 동작한다. MQ Series에 접속한 후 거래 처리되는 플로우는 다음과 같다.

1. Queue Manager Connect

2. 개별 Queue Open

3. MQGET, MQPUT(거래 수행)

4. 개별 Queue Close

5. Queue Mananger Disconnect

제10장 MQ Series 게이트웨이 131

● 멀티 포트 Listen/connect 기능

Get Queue는 한 게이트웨이당 한 개씩만 등록 가능하다. Get Queue의 경우 Queue에서 데이터를

MQGET할 때 대기시간만큼 기다려야 하므로 2개 이상일 경우 Non-block 형태로 게이트웨이 구성이 불

가하므로 Admin에 등록할 때 해당 사항을 제약하도록 되어 있다.

● 동기(Sync)/비동기(Async) 통신

일반적인 Online 형태의 거래처럼 요청/응답 전문 형태로 된 거래들은 거래일반정보의 응답 유무를

'Yes'로 설정할 경우 sync(동기 방식)로 동작한다. MQPUT한 후에 MQGET에서 CorrelId를 키로 응답을

찾아서 tpreturn한다. 또한 MQGET한 후에 tpreturn이 오면 MQPUT을 수행한다.

배치 형태로 여러 전문이 연속해서 들어오는 경우는 게이트웨이에서 Mapper를 호출할 때는 거래일반

정보의 응답 유무를 'No'로 설정해서 Async(비동기방식)로 동작하게 한다. 이때 응답 데이터도 요청 전

문으로 등록해 놓고 역시 응답유무를 'No'로 설정하면 각각이 별개의 거래로 처리된다.

게이트웨이에서 Mapper이외의 AP를 호출해서 처리하고자 하는 경우는 기관-업무정보의 대내외 파싱

여부를 'No'로 설정하면 거래일반정보의 응답유무를 'No'로 한 경우와 동일하게 동작한다. 다만 기관-업

무까지만 찾기 때문에 Mapper를 호출하는 데 사용할 수는 없다. 이렇게 설정하는 이유는 거래를 모두

등록하지 않아도 기관-업무만 등록되어 있으면 처리가 가능하므로 등록하는 양을 줄이기 위해서이다.

● 최대 처리건수 제한

다른 Online 게이트웨이들은 각 세션으로 들어오는 데이터를 들어오는 대로 Mapper로 전달하는 구조

였다. 이 경우는 세션이 끊어졌을 때 네트워크에 남아 있는 데이터들은 유실되므로 Mapper 측의

Queueing 여부와 상관없이 처리해도 무방하다. 하지만 MQ의 경우 queue와 접속이 끊어졌을지라도 향

후에 다시 붙게 되면 기존 데이터를 다시 읽어들일 수 있므으로 Mapper의 부하 여부와 상관없이 Mapper

에게 계속 넘길 경우 장애가 발생하면 많은 데이터가 유실될 수 있으므로 CLOPT절에 –M 옵션으로 최

대 처리건수를 제한할 수 있는 기능을 제공한다.

파싱을 하지 않거나 무응답 거래도 이 건수 제한에 계산이 된다. Mapper가 응답을 주지 않은 거래의 총

개수가 최대 처리건수를 초과할 경우 Get Queue에서 더 이상 데이터를 읽어오지 않는다.

10.1.2. 대외 송수신 방식

스튜디오의 기관-업무 정보에 '대외 송신 방식' 필드에 등록된 값으로 대외 기관과 송수신할 때 요청 전문

을 내보내는 규칙이나 응답 전문을 내보내는 규칙을 정의하는 것이다.

요청 전문을 내보낼 경우는 RoundRobin 방식을 따른다. 요청 전문을 받는 경우는 RoundRobin, Selection

방식으로 보낼 수 있다. Queue는 양방향 통신이 불가하므로 Self-session 방식으로 설정하면 안된다.

10.1.3. 파싱

파싱 방식은 TCP/IP 게이트웨이와 유사하다. 다만 MQ는 MQPUT 수행의 경우 CorrelId라는 전문 추적번

호 기능을 하는 항목을 데이터 이외에 별도로 넘겨주도록 되어 있다. MQGET의 경우에는 해당 CorrelId를

받으면 이 값을 키로 해서 요청/응답 유무의 판별이 가능하다.


● 기관-업무 파싱

기관-업무파싱 방식은 TCP/IP 게이트웨이와 동일하다.

● 대내/외 파싱

MQGET의 경우 CorrelId가 기존에 수신했던 것이면 응답 전문으로 처리하고, 없으면 요청으로 처리한

다. 그 외의 과정은 TCP/IP 게이트웨이와 동일하다.

● 파싱 오류

TCP/IP 게이트웨이와 동일한 파싱 오류 서비스를 호출한다. MQ의 경우 파싱 오류 서비스를 호출한 후

다시 응답을 줄 필요가 없기 때문에 파싱 오류 서비스는 tpacall<TPNOREPLY>로 호출된다.

10.2. 환경설정본 절에서는 MQ Series 게이트웨이 환경설정에 대해 설명한다.


Tmax 환경 파일에 게이트웨이 서버와 서비스를 등록한다.

● SERVER 절

– SVRTYPE을 CUSTOM_GATEWAY로 한다. 게이트웨이는 여러 개를 띄워서 처리할 수 없으므로 반

드시 MIN, MAX를 1로 한다.

– CLOPT는 다음과 같은 옵션을 설정할 수 있다.

설명옵션

파일을 로깅할 때 로그 풀의 크기로 이 개수만큼 파일에 쌓이지 않고 대기하고 있을 수

있는 전문 수이다. (기본값: 500, 단위: 개)

g

relay 서비스명이다. (기본값: ALINKRLYSVC)r

이 서비스가 Tmax 환경 파일에 설정되어 있지 않으면 Mapper가 게이트웨이를 호출했을

때 게이트웨이는 정상 리턴을 하지만, Mapper에서 TPENOENT가 떨어질 수 있으므로

주의해야 한다.

Tmax 설정의 MAXSACALL와 유사한 기능 설정으로 해당 게이트웨이의 tpreturn을 받지

못한 tpacall 개수가 해당 옵션에서 설정한 값 이상이 될 경우 Queue에서 get 해오지 않

는 기능이다. (기본값 : 1024)

M

파일을 로깅할 때 Sync 모드로 동작한다.s

파일을 로깅할 때 특정 크기 단위로 나눈 파일 크기이다.n

● SERVICE 절

해당 서비스명을 등록한다. 서비스명은 15자 이내 임의의 값으로 한 개만 등록한다.




● 등록 항목



설명항목




회선 장애가 발생할 경우 호출될 서비스명을 등록한다.백업 서비스명

'MQ Series'를 선택한다.프로토콜

'온라인'으로 고정된다.Type


한다.

대내외구분

게이트웨이가 특정 기관-업무에만 종속된 경우에 값을 설정하면 게이트

웨이-level 기관-업무 파싱을 수행한다.





해당 게이트웨이가 연결할 Queue Mananger명을 등록한다.MQ Manager명

● 게이트웨이 등록 예

설명항목

mqgw이름

MQGW서비스명

MQ Series프로토콜

온라인Type


MANAGER1MQ Manager명




● 등록 항목

회선은 게이트웨이가 대외/대내 기관으로부터 요청/응답을 받는 논리적인 연결을 말하며 등록된 후에

는 수정, 삭제 뿐만 아니라 중지 및 재개도 가능하다.

설명항목



회선이름

회선이 포함된 노드명으로 자동 입력된다.노드명

회선이 포함된 게이트웨이명으로 자동 입력된다.Gateway 이름

해당 회선에 할당된 Queue 이름을 등록한다.Queue 이름

항상 1로 고정된다.세션수

항상 'Client'로 고정된다.TCP/IP C/S구분

처리 방식을 설정한다. 경우에 따라 다음과 같이 설정한다.처리방식

– IN_CHANNEL : Get Queue의 경우

– OUT_CHANNEL : Put Queue의 경우

Queue open에 실패했을 때 open을 retry하는 간격으로 0일 경우는 실패한

이후에 재시도 하지 않는다.

재접속 간격

MQGET의 경우 대기시간을 설정한다.Timeout for Get Queue



'IN_CHANNEL'일 때만 의미가 있다.



이다.


10.3. 사용자 프로그램(custom.h, custom.c)TCP/IP 게이트웨이와 유사한 형태의 API를 제공한다. 라이브러리 형태로 배포가 되며 사용자가 cus

tom.h/custom.c를 작성해서 컴파일함으로써 완성이 된다. 다른 Online 게이트웨이와 다른 라이브러를 사

용한다는 점에 유의한다.

libalmqgw.a(.so/.sl) 형태로 제공되는 라이브러리는 libalmqgwd가 디버그(Debug) 버전이고, libalmqgw가

릴리즈(Release) 버전이다.


10.3.1. custom.h

custom.h는 TCP/IP 게이트웨이와 동일하다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.

10.3.2. custom.c

통신헤더가 필요 없으므로 길이를 얻어오기 위한 get_msg_length, get_end_msg 함수가 없다. 리모트 노

드로 보내기 전에 put_msg_info를 호출하며 put_msg_complete는 호출되지 않는다.

Mapper로부터 요청이 왔을 때 Internal 게이트웨이의 경우는 get_unique_id 함수가 불리며 여기서 uid를

설정해야 응답 전문을 받았을 때 찾을 수 있다. init_algw_info 함수는 게이트웨이가 기동할 때 호출되는 함

수이다. 사용자는 이 함수에서 CLOPT절로부터 파라미터를 받아서 처리할 수 있다. 3.1.1 이상에서는 반

드시 생성해야 한다. done_algw_info는 tmdown시 호출되는 함수로 3.2.5 이상에서는 반드시 생성해야 한

다.


10.5. 지연 응답 처리 서비스TCP/IP 게이트웨이와 동일하게 작성한다. 자세한 내용은 “제2장 TCP/IP 게이트웨이”를 참고한다.


제11장 ebXML 게이트웨이

본 장에서는 ebXML 게이트웨이의 기능 및 설정 방법을 설명한다.

11.1. 개요ebXML 게이트웨이는 ebXML로 전문을 송수신할 때 사용되기 위해 JEUS의 웹 컨테이너 버전으로 개발된

AnyLink 전용 게이트웨이이다. ebXML 게이트웨이는 HTTP 게이트웨이와 유사한 설정에 ebXML 게이트

웨이만의 설정 부분이 추가된다. ebXML 형태로 들어오는 데이터에 대해 파싱 과정을 거쳐 JMapper를 호

출한다. CMapper는 XML 데이터 처리를 하지 못하므로 반드시 JMapper를 사용한다.

기관-업무파싱

ebXML 게이트웨이의 파싱 과정 ebXML 게이트웨이로 전달받은 EXBML 문서의 CPA-ID,SERVICE,AC

TION,FROM-PARTYID를 통해 해당 거래의 유형을 파악한 뒤 해당 거래 유형에 따른 서블릿을 호출한다.

해당 서블릿에서는 들어온 URL에 등록된 기관/업무를 찾아내어 JMapper로 전달한다.

11.2. 환경설정본 절에서는 ebXML 게이트웨이의 환경설정에 대해 설명한다.

11.2.1. JEUS 환경설정

JEUS 웹 컨테이너 환경 파일에 <http-listener>를 등록하고 웹 애플리케이션을 등록한다.

<http-listener> 설정

WEBMain.xml에 <http-listener>를 설정한다. 포트는 URL 설정과 동일한 포트를 사용한다. 다음은 설정

예제이다.

<http-listener>

<listener-id>alinkhttpgw</listener-id>

<port>30868</port>

<thread-pool>

<min>30</min>

<max>30</max>

<max-queue>100</max-queue>

제11장 ebXML 게이트웨이 137

</thread-pool>

</http-listener>

참고

<http-listener> 설정에 대한 자세한 내용은 "JEUS Web Container 안내서"를 참고한다.

웹 애플리케이션 설정

웹 애플리케이션의 등록은 다음의 2개의 파일을 설정해야 한다.

● jeus-web-dd.xml 설정

<context-path>를 Admin의 URL을 설정할 때 지정한 context로 지정한다(ex: /ebxmlgw). 다음은 설정

예제이다.


<jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">

<context-path>/ebxmlgw</context-path>

<enable-jsp>true</enable-jsp>

<auto-reload>

<enable-reload>false</enable-reload>

<check-on-demand>false</check-on-demand>

</auto-reload>

<max-instance-pool-size>-1</max-instance-pool-size>

<session-config>

<url-rewriting>false</url-rewriting>

</session-config>

<webinf-first>false</webinf-first>

</jeus-web-dd>

● web.xml 설정

<servlet> 태그의 <servlet-name>을 AnyLinkEbxmlReceiver로 설정하고 <servelt-class>를

com.tmax.ebxml.trp.messaging.AnylinkEbxmlReceiver로 설정한다. <servlet-mapping>의 <servlet-

name>을 AnyLinkEbxmlReceiver로 설정하고 <url-pattern>은 Admin의 URL 설정 시에 사용한 패턴을

입력한다.

다음은 설정 예제이다.


<!DOCTYPE web-app PUBLIC "-//Sun Microsystems,

Inc.//DTD Web Application 2.2//EN"

"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">

<web-app>

<servlet>

<servlet-name>AnyLinkEbxmlReceiver</servlet-name>

<servlet-class>com.tmax.ebxml.trp.messaging.AnylinkEbxmlReceiver</servlet-class>


</servlet>

<servlet-mapping>

<servlet-name>AnyLinkEbxmlReceiver</servlet-name>

<url-pattern>/ebxml-receiver</url-pattern>

</servlet-mapping>

</web-app>

11.2.2. ebXML MSH 환경설정

ebXML MSH 설정은 웹 애플리케이션의 WEB-INF 경로에 msh-config.xml 파일과 cpas 디렉터리에 해당

CPA들로 설정된다. ebXML MSH 환경설정 및 설치에 대한 자세한 내용은 “Appendix C. ebXML MSH”를

참고한다.

● msh-conifg.xml 설정

기본적인 설정은 ebXML MSH 설정을 따른다. 포트는 URL 설정과 동일한 포트를 사용한다.

● CPA 설정

CPA 설정은 www.ebxml.org/specs/의 규정을 따른다.


Admin에서는 게이트웨이를 등록해야 한다. Admin에서의 ebXML 게이트웨이 설정은 HTTP 게이트웨이

설정과 동일하며 다만 URL의 'XML/SOAP 구분'을 항상 'SOAP'으로 선택해야 한다.

● 등록 항목



설명항목

게이트웨이명을 등록한다.이름


서비스명을 등록한다.서비스명

'HTTP'를 선택한다.프로토콜

'HTTP'를 선택한다.Type

ebXML 게이트웨이에서 대내외구분에 따른 기능 차이는 없으므로 의미상으

로만 구분한다.

대내외구분

미입력, ebXML 게이트웨이는 URL정보에 의해서만 기관-업무 파싱을 수행

한다.





www.ebxml.org/specs/

설명항목



● 게이트웨이 등록 예(대외기관용 ebXML 게이트웨이)

설명항목

ebxmlgw이름

EBXMLGW서비스명

HTTP프로토콜

HTTPType


11.2.4. URL 등록

TCP/IP 게이트웨이, X25 게이트웨이의 회선에 해당하는 개념으로 회선명 대신 URL이 키가 된다.

참고

자세한 내용은 "AnyLink Admin 안내서"의 "URL추가"를 참고한다.

● 등록 항목

다음은 URL 등록 항목에 대한 설명이다.

설명항목

ebXML을 위한 URL이다. 'http://'를 제외한 부분을 등록한다.URL

다음의 경우에 따라 설정한다.타입

– Inbound : 리모트 노드에서 요청전문이 들어올 경우

– Outbound : Mapper가 요청할 경우

'Inbound'일 경우는 ebXML 게이트웨이가 Listen하고, 'Outbound'일 때는 연

결한다.


해당 ebXML 게이트웨이의 서버명이 자동 입력된다.Gateway 이름

'타입'의 설정값에 따라 다음과 같이 설정한다.IP 주소 / 포트번호

– 'Inbound' 모드일 때 : Listen할 포트

– 'Outbound' 모드일 때 : 연결할 IP 주소 및 포트


설명항목

예를 들어, '타입'이 'Inbound'일 때 http://192.168.1.10:8989/<context>로 호

출하는 경우(192.168.1.10은 ebXML 게이트웨이의 IP 주소) 포트 번호는 8989

값으로 입력한다. 'Inbound'일 경우 포트 번호는 JEUS 환경설정에서 <http-

listener>에 설정한 포트 번호를 입력해야 한다.

'타입'의 설정값에 따라 다음과 같이 설정한다.세션 수

– 'Inbound' 모드일 때 : 최대 수용할 세션의 수

– 'Outbound' 모드일 때 : 연결할 세션의 수

해당 URL과 연결된 기관/업무를 등록한다.기관 / 업무

'Inbound'일 경우에는 하나의 URL에 대해 여러 기관/업무가 할당되지 못한

다. 이 정보는 ebXML 게이트웨이가 요청 전문이 들어온 상태에서 URL로 기

관/업무를 찾아내기 위한 정보로 사용되므로 반드시 등록한다.

미입력기관코드 필드명

미입력서버명

미입력Parameter

미입력Username / Password

RealReal/Backup 구분

SOAPXML/SOAP 구분

11.3. ebXML 예제

11.3.1. 단방향 메시지 전송

단방향 메시지 전송 방식은 OutBound JMapper 거래에서 파라미터 정보를 ebXML with CPA로 설정하여

CPA에 따라서 InBound ebXML 게이트웨이로 요청 메시지(Request Message)를 보내서 처리한다.

단방향 메시지 전송 방식의 흐름은 다음과 같이 나타낼 수 있다.

[그림 11.1] 단방향 메시지 전송


단방향 메시지 전송을 위해 다음과 같은 설정이 필요하다. 그 외의 나머지 설정은 SOAP TEST 설정과 동

일하다.

● OutBound JMapper 설정

● OutBound ebXML 게이트웨이 설정

● InBound ebXML 게이트웨이 설정

OutBound JMapper 설정

● 기관 - 업무 정보 설정

스튜디오에서 [기관-업무 정보] 탭의 ebXML 플래그 정보 영역에서 다음과 같이 설정한다.

설명항목

urn:eblOT-TestService:order서비스명

eblOT-CPA-ONEWAY2CPA ID

SEND2From Party ID

RECVTo Party ID

● 거래 - 일반 정보

스튜디오에서 [거래 - 일반 정보] 탭의 '응답 유무' 항목을 'No'로 설정하고, ebXML/SOAP Action 정보

영역에서 'Request Action'을 'EB_OW_Send2'로 설정한다.

● 파리미터 정보

스튜디오에서 [파라미터 정보] 탭의 '서비스 유형' 항목을 'ebXML with CPA'로 설정한다.

OutBound ebXML 게이트웨이 설정

msh-conifg.xml에 <cpa-override> 태그를 추가한다.

<cpa-overrides>

<cpa-override>

<cpa-id>ebIOT-CPA-ONEWAY2</cpa-id>

<party>

<party-id>RECV</party-id>

<endpoint>http://192.168.1.87:30868/ebxmlOneWay/OneWayRecv2</endpoint>

</party>

</cpa-override>

</cpa-overrides>

CPA 문서에 해당 항목들을 설정해야 한다. 'MessagingCharacteristics' 항목에 syncReplyMode="none"

이 설정되어야 OneWay 방식으로 동작하고, 'MessagingCharacteristics' 항목에 ackRequested="always"


duplicateElimination="always" 이 설정되고 해당 DocExchange에 <tp:ReliableMessaging> 항목이 있어야

RM 기능이 동작한다 (OneWay 만 RM지원)

InBound ebXML 게이트웨이 설정

InBound ebXML 게이트웨이를 설정하려면 msh-config.xml에 <listener>를 다음과 같이 설정한다.

<listener>

<class>

<one-way-listener>anylink.engine.servlet.AnyLinkEBXmlOneWayListener

</one-way-listener>

</class>

<selector>

<cpaid>ebIOT-CPA-ONEWAY2</cpaid>

<service>urn:ebIOT-TestService:order</service>

<action>EB_OW_Send2</action>

<from-partyid>SEND2</from-partyid>

</selector>

</listener>

11.3.2. 동기식 메시지 전송

동기식 메시지 전송 방식은 OutBound JMapper 거래에서 파라미터 정보는 ebXML with CPA로 설정하여

CPA에 따라서 InBound ebXML 게이트웨이로 요청 메시지(Request Message 를 보낸후 InBound JMAPPER

에서 응답을 받아 다시 OutBound JMapper까지 Response Message를 전달한다.

동기식 메시지 전송 방식의 흐름은 다음과 같이 나타낼 수 있다.

[그림 11.2] 동기식 메시지 전송

동기식 메시지 전송을 위해 다음과 같은 설정이 필요하다. 그 외의 나머지 설정은 SOAP TEST 설정과 동

일하다.

● OutBound JMapper 설정

● OutBound ebXML 게이트웨이 설정


● InBound ebXML 게이트웨이 설정

● InBound JMapper 설정

OutBound JMapper 설정

● 기관 - 업무 정보 설정

스튜디오에서 [기관-업무 정보] 탭의 ebXML 플래그 정보 영역에서 다음과 같이 설정한다.

설명항목

urn:eblOT-TestService:order서비스명

eblOT-CPA-REQRESP2CPA ID

SEND2From Party ID

RECVTo Party ID

● 거래 - 일반 정보

스튜디오에서 [거래 - 일반 정보] 탭의 '응답 유무' 항목을 'Yes'로 설정한다. ebXML/SOAP Action 정보

영역에서 'Request Action'을 'EB_RR_Send2'로 설정하고, 'Response Action'은 'EB_RR_Recv1'로

설정한다.

● 파리미터 정보

스튜디오에서 [파라미터 정보] 탭의 '서비스 유형' 항목을 'ebXML with CPA'로 설정한다.

OutBound ebXML 게이트웨이 설정

OutBound ebXML 게이트웨이를 설정하려면 msh-conifg.xml에 <cpa-override>를 추가한다.

<cpa-override>

<cpa-id>ebIOT-CPA-REQRESP2</cpa-id>

<party>

<party-id>RECV</party-id>

<endpoint>http://192.168.1.87:30868/ebxmlReqResp/ReqRespRecv2

</endpoint>

</party>

</cpa-override>

CPA 문서에 해당 항목들을 설정해야 한다. 'MessagingCharacteristics' 항목에 syncReplyMode=" Respon

seOnly" 이 설정되어야 ReqResp 방식으로 동작한다


InBound JMapper 설정

InBound ebXML 게이트웨이를 설정하려면 msh-config.xml에 <listener>를 다음과 같이 설정한다. 그 외의

나머지 설정은 SOAP TEST 설정과 동일하다.

● 기관 - 일반 정보 설정

스튜디오에서 [거래 - 일반 정보] 탭의 '응답 유무' 항목을 'Yes'로 설정한다. ebXML/SOAP Action 정보

영역에서 'Response Action'은 'EB_RR_Recv2'로 설정한다.

InBound ebXML 게이트웨이 설정

InBound ebXML 게이트웨이를 설정하려면 msh-config.xml에 <listener>를 다음과 같이 설정한다.

<listener>

<class>

<req-resp-listener>anylink.engine.servlet.AnyLinkEBXmlReqRespListener

</req-resp-listener>

</class>

<selector>

<cpaid>ebIOT-CPA-REQRESP2</cpaid>


<action>EB_RR_Send2</action>

<from-partyid>SEND2</from-partyid>

</selector>

</listener>


Appendix A. 오류 메시지 및 조치 방법

tmboot를 실행하면 시스템이나 사용자 오류에 따라 서버가 도중에 다운(Down)될 수 있다.

이런 비정상적인 서버 다운(Server Down)이 발생한 경우 다음과 같은 메시지가 콘솔에 출력된다.

(E) TMM2058 server abnormally closed: SVR, pid = 39436 [TMM0116]

조치 방법은 다음과 같다.

tmadmin으로 다운된 서버 확인

tmadmin 실행 후 si 명령을 입력한다.

[그림 A.1] tmadmin 화면

다운된 서버의 ulog 확인

다운된 서버의 ulog를 열어서 에러 메시지를 확인한다.

각 에러 메시지와 그에 따른 조치 방법은 다음과 같다.(tmboot 시 에러)

● SVR0013 anylink option is wrong

서버 옵션이 잘못된 경우에 발생한다.설명

해당 매뉴얼을 참조하여 잘못된 옵션을 수정한다.해결 방법

Appendix A. 오류 메시지 및 조치 방법 147

● SVR2013 database connect failed

$ANYLINK_DB_NAME, $ANYLINK_CONNECT_INFO 환경변수의 값이 잘못된 경우

에 발생한다.

설명

해당 매뉴얼을 참조하여 해당 데이터베이스에 유효한 형태로 값을 설정한다.해결 방법

● SVR0100 invalid shared memory key

SVF0091 can't open shared memory segment

SVR0090 can't attach shared memory segment

공유 메모리(Shared memory)를 가져오지 못하는 오류이다.설명

공유 메모리 키(Shared memory key)를 변경한다.해결 방법

● SVR2046 Engine version mismatch

엔진 버전이 맞지 않을 경우에 발생한다.설명

AnyLink 바이너리의 버전을 확인한다.해결 방법

● SVR2013 not found remote session

게이트웨이인 경우에 발생한다.설명

회선이 하나도 등록되어 있지 않았음을 의미한다.해결 방법

● ANYLINK1220 register to AMM error

컴포넌트를 AMM에 등록할 수 없는 경우에 발생한다. 등록되어 있지 않은 컴포넌트

이거나 공유 메모리 오프셋(Shared memory Offset)이 일치하지 않는 경우 발생한다.

설명

먼저, 등록되어 있는 컴포넌트인지를 확인한 다음 AMM 로그와 공유 메모리 오프셋

이 일치하는지를 확인한다.

해결 방법

● GW5005 Error loading certificate form file

게이트웨이에서 SSL 프로토콜을 사용할 경우에 인증서를 가져오다 실패했을 때 발

생한다.

설명

정해진 위치에 인증서가 있는지, 올바른 인증서인지 확인한다.해결 방법

● GW5006 Error loading private key from file

게이트웨이에서 SSL 프로토콜을 사용할 경우에 Private Key를 가져오다 실패했을 때

발생한다.

설명

정해진 위치에 Private Key가 있는지, 올바른 Private Key인지 확인한다.해결 방법


● GW5003 Error loading CA file and/or directory

게이트웨이에서 SSL 프로토콜을 사용할 경우에 발생한다.설명

CA 파일의 위치가 올바른지 확인한다.해결 방법

● GW5002 Error loading default CA file and/or directory

게이트웨이에서 SSL 프로토콜을 사용할 경우에 발생한다.설명

CA 파일이 올바른 인증서인지 확인한다.해결 방법

Appendix A. 오류 메시지 및 조치 방법 149

Appendix B. AnyLink 서버의 로그보는 방법

AnyLink 서버를 디버그 모드로 설치하면 ulog에 많은 정보를 출력한다.

본 부록에서는 게이트웨이의 ulog 중 중요한 부분만 정리했다. 게이트웨이는 외부 시스템과 연결되는 부

분이므로 AnyLink를 설치할 때 가장 주의해야할 컴포넌트이고, 로그를 통해 살펴봐야할 부분도 많다. 로

그를 볼 때는 본 부록의 내용을 참고한다.

본 부록에서는 다음의 경우에 대한 로그보는 방법을 설명한다.

● Boot할 경우의 로그

● 외부로부터 들어온 전문 처리 로그

● CLH로부터 들어온 전문 처리 로그

● 게이트웨이 정보 수정 로그

● 게이트웨이 회선 정보 수정 로그

Boot할 경우의 로그

AMM으로 연결한다.

connect(ibm5l, 0, 9268), fd = 3 fail




connect(ibm5l, 0, 9268), fd = 3 success

여러 번의 시도 끝에 연결되면 AMM에 등록한다.

ALINK.165192.140145.752: register_to_amm: shmkey[12340] shmsize[3795272]

AMM에 등록한 후 shared memory key를 가져오고 각 요소들의 offset을 가져온다.

ALINK.165192.140145.752: init_alshm_sub: shmkey=[12340] shmsize=[3795272] new!!

노드를 비롯한 나머지 offset 값은 AMM과 반드시 정확하게 일치해야 한다.

ALINK.165192.140145.752: node offset = 768

Appendix B. AnyLink 서버의 로그보는 방법 151

서버 모드 회선의 수를 구한다.

GATEWAY.165192.140145.753: get_listen_size: protocol_type[1] sidx[5]

서버 모드 회선의 포트를 열고 fd를 할당한다.

ALINK.165192.140145.753: init_listen: gwname[tcpgwext:tcpgwext2] connect_type=[1]

클라이언트 모드 회선의 세션 수를 구한다. 현재 outgw 값으로부터 클라이언트 회선은 없다는 것을 알 수

있다.

ALINK.165192.140145.755: get_session_size: outgw[0] session[5]

세션을 초기화한다.

ALINK.165192.140145.755: init_session: next_glidx[44]

클라이언트 모드 회선이 있을 경우 다음과 같은 로그가 남는다.

ALINK.186252.142109.744: connect_to_session_tcpip: line_idx[7] sess_idx[7]

host[192.168.1.31:4999]

열어놓은 서버 모드 회선에 연결 요청이 들어오면 요청을 받아들이고 세션에 연결한다.

ALINK.165192.140157.111: gw_add: gwl->line_idx[5]

외부로부터 들어온 전문 처리 로그

외부로부터 메시지가 들어왔다.

GATEWAY.165192.140157.112: request_from_session: ind = 0

메시지의 기관, 업무, 종별, 거래를 판별하기 위해 리모트 파싱을 수행한다.

GATEWAY.165192.140157.112: remote_req_message_parsing: len[113] cache_offset[0]

cache_len[0]

기관 코드 MST, 업무코드 APP1을 찾았다.

GATEWAY.165192.140157.112: remote_req_message_parsing: gwi[0] inst_code[MST]

appl_code[APP1] ext_type[1]

요청 메시지이다.

GATEWAY.165192.140224.934: external_remote: kind_type[1]

external 게이트웨이인 경우에는 external_remote 파싱을 추가적으로 실행해서 종별(APP1), 거래 코드

(0200)까지 찾는다.

GATEWAY.165192.140224.934: external_remote: appl_code[APP1] rep_kind_code[0200]

tx_code[54002]


하나의 전문이 여러 조각으로 나뉘어져 전송되어 온 경우 이 부분에서 하나로 취합한다.

GATEWAY.165192.140224.934: data_packet_reconstruct: ext_type[1] reqtype[1]

기관-업무 정보에 등록되어 있는 Mapper를 찾는다(CMAPPER)

search_mapper: max_mapper[8] mapper[CMAPPER]

CLH로 처리한 전문을 보낸다.(CLH는 CMAPPER로 보내게 된다)

GATEWAY.165192.140224.935: reply_to_clh complete: qcount[0]

CLH로부터 들어온 전문 처리 로그

CLH로부터 메시지가 들어왔다.

GATEWAY.89490.163650.299: request_from_clh: ind = 11

msgtype이 1004이므로 응답 메시지이다.

GATEWAY.89490.163650.299: msg from clh: msgtype[1004] seqno[0000400B] cd[1] len[113]

clhi[11]

CLH로부터 들어온 메시지는 local_message_parsing을 수행한다.

local_message_parsing으로 기관(MST), 업무(APP1), 종별(0200), 거래(54002) 정보를 찾았다.

GATEWAY.89490.163650.299: local_message_parsing_by_idx: inst_code[MST ] appl_code[APP1]

kind_code[0200 ] tx_code[54002 ]

전문을 여러 패킷으로 나눠서 전송할지 여부를 판단하고 필요하면 전문을 나눈다

ALINK.89490.163650.300: data_packet_split: hsize[0] comm_head_size[64]

comm_head_type[1]

세션으로의 전문 전송이 완료되었다.

GATEWAY.89490.163650.300: reply_to_session complete: max_num[1] cur_num[2]

게이트웨이 정보 수정 로그



43번이면 게이트웨이수정 메시지이다.

GATEWAY.15217.105019.300: msg from clh: anylink msgtype[43]

Appendix B. AnyLink 서버의 로그보는 방법 153

수정된 정보를 저장한다.

GATEWAY.15217.105019.300: set_gateway_info: inst_code[] appl_code[] gwname[tcpgwext]

comm_head_size[64]

게이트웨이 수정이 완료되었으면 CLH로 리턴한다.


게이트웨이 회선 정보 수정 로그



44이면 게이트웨이 회선 수정 메시지이다.

GATEWAY.15217.104900.670: msg from clh: anylink msgtype[44]

회선 정보를 수정한다.

GATEWAY.15217.104900.690: set_line_info: proc_type[2] idx[41] gwname[tcpgwext]

symbname[yoon00]

회선 정보 수정이 완료되면 CLH로 리턴한다.



Appendix C. ebXML MSH

본 장에서는 ebXML MSH의 설치 및 설정에 대해 설명하고 애플리케이션 프로그래밍과 예제에 대해 설명

한다.

C.1. ebXML MSH 설치 및 설정본 절에서는 Tmax ebXMLTM에 대하여 개괄적인 설명을 하고, 지원하는 주요 기능들에 대해서 설명한다.

C.1.1. 설치

설치 전 요구사항

EBXML MSH가 설치되어 동작하기 위해서는 다음과 같은 사항을 요구한다.

요구사항구분

JEUS 4.2.2.1 이상JEUS

jaxm.jar , ebXML.jar, ebXML-msh-config.jarTmax EBXML MSH

dom4.jarDom4J

jdbm-0.12.jar (http://jdbm.sourceforge.net)JDBM

log4j-1.2.8.jarLog4J

xmlsec-1.2.1.jar (http://xml.apache.org/security/)XML Security

xss4j.jar (http://www.research.ibm.com/trl/projects/xml/xss4j/)XSS4J

xbean.jar , xbean_xpath.jarApache XML Beans 1.0.4 -jdk1.3

디렉터리 구조

ebXML MSH는 JEUS에 웹 애플리케이션 형태로 설치한다. 다음은 설치된 웹 애플리케이션 디렉터리의

구조이다.

+--- $EBXML_HOME/

+--- EBXmlSend.jsp

|--- WEB-INF/

|--- web.xml

|--- msh-config.xml

+--- classes/

Appendix C. ebXML MSH 155

http://xml.apache.org/security/

http://www.research.ibm.com/trl/projects/xml/xss4j/

+--- cpa/

+--- jdbm/

+--- lib

$EBXML_HOME

ebXML을 설치한 디렉터리이다

EBXmlSend.jsp

EBXML 전송에 사용하기 위한 테스트 클라이언트이다.

WEB-INF

설명파일

Servlet Web Descriptor이다.web.xml

EBXML 설정 파일이다.msh-config.xml

classes

EBXML을 사용하는 애플리케이션을 설치하는 디렉터리이다.

cpa

CPA 문서를 저장하는 디렉터리로, msh-config.xml 파일을 통해서 변경가능하다.

jdbm

MSH가 송수신 문서를 저장하는 용도로 사용하는 File DB 디렉터리로, msh-config.xml 파일을 통해서

변경 가능하다.

lib

ebXML MSH 및 필요한 라이브러리(JAR 파일)가 포함된 디렉터리이다.

C.1.2. 설정

ebXML MSH의 설정 파일은 다음과 같다.

● web.xml

● msh-config.xml

web.xml 설정

다음은 web.xml 설정 예이다.


<web-app>

<servlet>

<servlet-name>sender</servlet-name>


<servlet-class>

com.tmax.ebxml.trp.messaging.EBXMLSendServlet

</servlet-class>

</servlet>

<servlet>

<servlet-name>msh</servlet-name>

<servlet-class>

com.tmax.ebxml.trp.messaging.EBXMLServlet

</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>sender</servlet-name>

<url-pattern>/sender</url-pattern>

</servlet-mapping>

<servlet-mapping>

<servlet-name>msh</servlet-name>

<url-pattern>/msh</url-pattern>

</servlet-mapping>

</web-app>

<servlet-class> 태그에 설정된 값에 대한 설명은 다음과 같다.

● com.tmax.ebxml.trp.messaging.EBXMLSendServlet

EBXML을 전송하는 테스트 클라이언트 서블릿이다.

● com.tmax.ebxml.trp.messaging.EBXMLServlet

EBXML 메시지를 수신하는 서블릿이다.

msh-config.xml 설정

msh-config.xml은 ebXML의 MSH 설정을 위해서 사용하는 파일이다. msh-config.xml의 schema는 CVS의

conf/msh-config.xsd 파일이다.

msh-config.xml의 예는 다음과 같다.

<?xml version="1.0" encoding="EUC-KR"?>

<msh-config xmlns="http://www.tmax.com/ebxml/msh/config">

<basedir>

C:\\jeus4\\webhome\\servlet_home\\webapps\\ebXML\\WEB-INF

</basedir>

<cpa>

<path>$BASEDIR/cpas</path>

<schema-validation>false</schema-validation>

<use-local-version>true</use-local-version>


</cpa>

<persistent>



<dbms>

<persistent-class>

com.tmax.ebxml.trp.rm.DBMSPersistenceManager

</persistent-class>

<export-name>anylink</export-name>

<send-table>ANYLINK.AL_SEND_TAB</send-table>

<recv-table>ANYLINK.AL_RECV_TAB</recv-table>

</dbms>

</persistent>

<listeners>

<listener>

<class>

<one-way-listener>

eb.interop.test.Test11Listener

</one-way-listener>

<req-resp-listener/>

</class>

<selector>

<cpaid>ebIOT-CPA</cpaid>


<action>I1_IBK_Receive</action>

</selector>

</listener>

</listeners>

<cpa-overrides>

<cpa-override>

<cpa-id>ebIOT-CPA</cpa-id>

<party>

<party-id>N03</party-id>

<endpoint>http://localhost:8089/ebxml/msh</endpoint>

</party>

</cpa-override>

<cpa-override>

<cpa-id>banca.03.N01.test</cpa-id>

<party>


<endpoint>http://192.168.1.63:8088/ebxml/msh</endpoint>

</party>

</cpa-override>

</cpa-overrides>

<message-log>

<targer-dir>

I:\jeus\Jeus42\logs\anylink

</targer-dir>

<level>true</level>

</message-log>

</msh-config>

각 태그에 대한 설명은 다음과 같다.

● <basedir>

ebXML MSH가 설치된 디렉터리로, 설정한 디렉터리는 msh-config.xml 파일에서 $BASEDIR이라는 이

름으로 사용할 수 있다.

● <cpa>

CPA 문서에 대해 설정한다.

설명태그

CPA 문서가 설치된 디렉터리이다.<path>

CPA 문서에 대한 schema validation을 수행할지 여부를 설정한다(true|false).<schema-validation>

CPA 문서에서 사용하는 schema validation 중에 참조하는 다른 schema en

tity에 대해서 로컬에 존재하는 schema 파일을 참조할지 아니면 인터넷에 접

<use-local-version>

속하여 schema를 가져올지 여부를 설정한다.. true로 설정하는 것이 성능면

에서 효율적이다.

로컬에 존재하는 schema 파일 디렉토리로, 설정하지 않는 경우 ebxml-msh.jar

에서 schema를 읽는다.

<local-schema-location>

● <persistent>

ebXML MSH가 메시지 저장을 위해서 사용하는 설정이다. Adapter, DBMS, jdbm을 지원한다.

– <adapter>

Reliable Message를 Adapter를 사용해 DB 저장에 사용한다.

설명태그

Adapter에서 사용하는 클래스이다.<persistent-class>

Adapter에서 ebXML 송신 시 저장할 DB Table명이다.<send-table>

Adapter에서 ebXML 수신 시 저장할 DB Table명이다.<recv-table>

– <dbms>

Reliable Message를 DBMS 저장에 사용한다.

설명태그

DBMS에서 사용하는 클래스이다.<persistent-class>

DBMS에서 사용하는 데이터소스이다.<export-name>

DBMS에서 ebXML 송신 시 저장할 DB Table명이다.<send-table>


설명태그

DBMS에서 ebXML 수신 시 저장할 DB Table명이다.<recv-table>

● <listeners>

ebXML 메시지를 받아서 처리하는 애플리케이션에 대한 설정이다. <listeners> 아래의 <listener> 태그

는 다음과 같은 하위 태그를 갖는다.

– <class>

설명태그

단방향 메시지를 받아서 처리하는 Listener 클래스명이다. javax.xml.messag

ing.OnewayListener 인터페이스를 구현한 클래스여야 한다.

<one-way-listener>

요청 메시지에 대해서 응답 메시지를 리턴하는 Listener 클래스명이다.

javax.xml.messaging.ReqRespListener 인터페이스를 구현한 클래스여야 한다.

<req-resp-listener>

단방향 메시지를 받아서 처리하는 Listener 클래스명이다. Acknowledgement만

을 처리한다.

<ack-listener>

단방향 메시지를 받아서 처리하는 Listener 클래스명이다. 에러 메시지만을 처리

한다.

<error-listener>

– <selector>

Listener에 대한 메시지 셀렉터를 설정한다. 메시지 셀렉터는 Listener로 전송할 메시지를 선택하는

조건을 기술한다. 아래 조건에 모두 일치하는 메시지가 해당 Listener로 전송된다.

설명태그

CPA ID ebXML메시지 중 MessageHeader/CPAId의 값이다.<cpaid>

서비스명으로, ebXML 메시지 중 MessageHeader/Service의 값이다.<service>

Action명으로, ebXML 메시지 중 MessageHeader/Action의 값이다.<action>

From Role명으로, ebXML 메시지 중 MessageHeader/From/Role의 값이다.<from-role>

From Role명으로, ebXML 메시지 중 MessageHeader/From/PartyId의 값이다.<from-partyid>

● <cpa-overrides>

ebXML 메시지를 받아서 처리하는 애플리케이션에 대한 설정이다. <cpa-overrides> 아래의 <cpa-override>

태그는 다음과 같은 하위 태그를 갖는다.

– <cpaid>

참조할 CPA ID이다.

– <party>

ebXML메시지를 전송할 party에 대한 정보를 저장한다.


설명태그

ebXML 메시지를 전송할 Party ID이다.<party-id>

ebXML 메시지를 전송할 Party ID의 endpoint이다.<endpoint>

● <message-log>

ebXML 메시지를 송수신하는 ebXML 메시지 로그 정보를 설정한다.

설명태그

ebXML 송수신 메시지 저장 경로를 설정한다.<targer-dir>

저장 여부를 설정한다(true|false).<level>

C.2. ebXML 애플리케이션 프로그래밍

C.2.1. Message Listener

Message Listener는 ebXML 메시지를 받아서 처리하는 애플리케이션을 의미한다. Message Listener는

다음과 같은 두 가지 종류가 있다.

● One-way Listener

메시지를 받는 기능만을 수행한다. 작성 방법은 다음과 같다.

public class Test11Listener implements OnewayListener {

public void onMessage(SOAPMessage msg) {

// implementation

}

}

● Request-Response Listener

메시지를 받아서 응답 메시지를 리턴하는 기능을 수행한다. 작성 방법은 다음과 같다.

public class Test31Listener implements ReqRespListener {

public SOAPMessage onMessage(SOAPMessage reqmsg) {

// implementation

}

}


C.2.2. Message Sender

ebXML 메시지를 생성해서 전송하는 방법은 다음과 같다.

public void sendMessage() {

String cpaId = "ebIOT-CPA";

String serviceName = "urn:ebIOT-TestService:order";

String actionName = "I1_IBK_Send";

String fromPartyId = "No3";

String toPartyId = "IBK";

ProviderConnectionFactory pcf

= ProviderConnectionFactory.newInstance();

EBXMLProviderConnectionImpl pc

= (EBXMLProviderConnectionImpl) pcf.createConnection();

MessageFactory mf = pc.createMessageFactory("ebxml");

SOAPMessage resmsg = ((EBXMLMessageFactory) mf).

createMessage(cpaId, fromPartyId, toPartyId,

serviceName, "I2_IBK_Receive", null, null );

pc.sendMessage(msg);

}

C.3. 예제 애플리케이션본 절에서는 ebXML 메시징에 사용되는 여러 시나리오에 대해서 예제 애플리케이션을 작성하고 실행하는

것에 대해서 설명한다

C.3.1. 환경설정

테스트 환경설정

Message Listener는 ebXML 메시지를 받아서 처리하는 애플리케이션을 의미한다.

ebXML MSH가 다음 두 개의 머신에 각각 설치되어 있고 두 개의 MSH는 공통의 CPA(ebIOT-CPA.xml)를

사용한다. 각 MSH가 CPA에서 사용하는 PartyID는 다음과 같다고 가정한다.

● Requester MSH 환경

설정값항목

192.168.12.205IP

IBKID

http://192.168.12.205/ebXML/mshMSHURL


● Responder MSH 환경

설정값항목

192.168.1.63IP

N03ID

http://192.168.1.63/ebxml/mshMSHURL

주의

CPA 문서의 tp:Transport/tp:Endpoint 아래의 endpoint URI를 실제 테스트 환경의 URI로 수정해야

한다.

환경설정

Message Listener는 ebXML 메시지를 받아서 처리하는 애플리케이션을 의미한다.

● Message Listener 설치

테스트에 사용할 Message Listener는 MSH가 설치된 context의 WEB-INF/classes에 설치되어 있어야

한다.

● CPA 설치

CPA 문서는 msh-config.xml에 지정한 cpa path에 설치가 되어야 한다.

● 테스트 payload

이 테스트에서는 payload로 다음과 같은 XML을 사용한다.

<?xml version="1.0" encoding="EUC-KR"?>



<TestRoot myName="attach0">

<TestElement>

<Test0 Conversation="A" SequenceNumber="0"/>

<Test1 test="1"/>

<Test2 test="2"/>

<Test3 test="3">

<TestChild child="attach0"/>

</Test3>

<Test4 test="4"/>

</TestElement>

</TestRoot>

C.3.2. 단방향 메시지 전송 테스트

Sender가 Receiver로 메시지를 1회 전송하고 종료하는 시나리오의 단방향 메시지 전송 테스트의 전송 흐

름은 다음과 같다.

[그림 C.1] 단방향 메시지 전송 흐름

테스트 항목

다음의 항목에 대해 테스트를 진행한다.

● Receiver가 추출한 payload는 Sender가 보낸 payload와 Byte수가 일치해야 한다.

● Receiver가 수신한 메시지의 CPAid, Service, Action, PartyId가 CPA에 명시된 것과 일치해야 한다.

● Sender와 Receiver 모두 에러를 발생하지 않아야 한다.

● Receiver가 HTTP 5XX 에러를 발생하지 않아야 한다.

C.3.2.1. 테스트 설정

테스트를 위해 msh-config.xml 파일에 다음과 같은 설정이 필요하다.

참고

msh-config.xml 파일의 변경 내용은 MSH를 재부팅해야 적용된다.

● Sender 설정

메시지를 모니터링 하기 위해서 Sender 측의 msh-config.xml 을 통해서 Sender가 실제로 메시지를 보

내는 주소를 override한다. Sender의 msh-config.xml 파일에 다음을 추가한다.

<cpa-overrides>

<cpa-override>

<cpa-id>ebIOT-CPA</cpa-id>

<party>



</party>

</cpa-override>

...


● Receiver 설정

Receiver의 msh-config.xml 파일에 다음과 같이 Listener를 설정한다.

<listeners>

...

<listerner>

<class>

<one-way-listener>


</one-way-listener>


</class>

<selector>



<action>I1_IBK_Send</action>

</selector>

</listener>

...

C.3.2.2. 테스트 수행

테스트를 위한 설정이 완료되면 다음과 같은 절차를 통해 테스트를 수행한다.

1. 웹 브라우저를 통해서 Sender MSH의 메시지 전송 테스트 화면에 접속한다. Sender의 MSH는

"http://192.168.12.205:8088/ebXML"에 설치되어 있다고 가정한다. 테스트 전송 화면의 URL은 다음과

같다.

http://192.168.12.205:8088/ebXML/EBXMLSend.jsp

2. 다음은 접속한 테스트 전송 화면이다. 각 항목을 입력한 후 [submit] 버튼을 클릭한다.

[그림 C.2] Sending EBXML Message


각 항목에 다음과 같이 입력한다.

설정값항목

ebIOT-CPACPAID

urn:ebIOT-TestService:orderService

I1_IBK_SendAction

IBKFromPartyId

N03ToPartyId

테스트 payload 파일Payload file in local

C.3.2.3. 테스트 결과

테스트 결과는 다음의 메시지 및 로그로 확인할 수 있다.

● ebXML 메시지

● Sender 로그

● Receiver 로그

ebXML 메시지

테스트 결과로 보여지는 요청 ebXML 메시지는 다음과 같은 형태이다.

POST /ebxml/msh HTTP/1.1

Content-Type: multipart/related; type="text/xml";

start="<458E1B5C3F377776F931A3CB938A056E>";

boundary=24669080.1110854807531.JavaMail.jjchoe.JJCHOE2

SOAPAction: "ebXML"

Content-Length: 2360

User-Agent: Java/1.4.2_05

Host: 192.168.1.63:8089

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive

--24669080.1110854807531.JavaMail.jjchoe.JJCHOE2

Content-Type: text/xml; charset=UTF-8

Content-Transfer-Encoding: binary

Content-Id: <458E1B5C3F377776F931A3CB938A056E>


<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header>


<eb:MessageHeader eb:id="MessageHeader-ID"

eb:version="2.0" soapenv:mustUnderstand="1"

xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/

msg-header-2_0.xsd">

<eb:From>

<eb:PartyId eb:type="ebIOT">IBK</eb:PartyId>

<eb:Role>http://www.ecom.or.jp/ebIOT#buyer</eb:Role>

</eb:From>

<eb:To>

<eb:PartyId eb:type="ebIOT">N03</eb:PartyId>

<eb:Role>http://www.ecom.or.jp/ebIOT#seller</eb:Role>

</eb:To>

<eb:CPAId>ebIOT-CPA</eb:CPAId>

<eb:ConversationId>IBK_N03_1110854807484</eb:ConversationId>

<eb:Service>urn:ebIOT-TestService:order</eb:Service>

<eb:Action>I1_IBK_Send</eb:Action>

<eb:MessageData>

<eb:MessageId>102a41b2fccc0a80ccdc9223301aa874c1a</eb:MessageId>

<eb:Timestamp>2005-03-15T02:46:47Z</eb:Timestamp>

</eb:MessageData>

<eb:DuplicateElimination/>

<eb:Description xml:lang="en-US">This is a ebXML

message.</eb:Description>

</eb:MessageHeader>

</soapenv:Header>

<soapenv:Body xmlns:eb="http://www.oasis-open.org/

committees/ebxml-msg/schema/msg-header-2_0.xsd"

xsi:schemaLocation="http://www.oasis-open.org/committees/

ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/

committees/ebxml-msg/schema/msg-header-2_0.xsd">

<eb:Manifest eb:id="Manifest-ID" eb:version="2.0"

xmlns:eb="http://www.oasis-open.org/committees/ebxml

-msg/schema/msg-header-2_0.xsd">

<eb:Reference eb:id="Reference-ID0"

xlink:type="simple" xlink:href="cid:payload-0"

xmlns:xlink="http://www.w3.org/1999/xlink"/>

</eb:Manifest>

</soapenv:Body>

</soapenv:Envelope>

--24669080.1110854807531.JavaMail.jjchoe.JJCHOE2

Content-Type: application/octet-stream

Content-Transfer-Encoding:

binaryContent-Id: <payload-0>




<TestRoot myName="attach0">

<TestElement>

<Test0 SequenceNumber="0" Conversation="A"/>

<Test1 test="1"/>

<Test2 test="2"/>

<Test3 test="3">

<TestChild child="attach0"/>

</Test3>

<Test4 test="4"/>

</TestElement>

</TestRoot>

--24669080.1110854807531.JavaMail.jjchoe.JJCHOE2--

응답 메시지는 다음과 같은 형태이다.

HTTP/1.1 204 No Content Date: Tue, 15 Mar 2005 02:48:00 GMT

Server: Jeus WebContainer/4.2.3.8 Connection: keep-alive

Transfer-Encoding: chunked

0

Sender 로그

테스트 결과로 보여지는 Sender 로그는 다음과 같은 형태이다.

(1) [2005-03-15 11:50:49] [DEBUG] Getting overrided endpoint

uri from configuration file. uri = http://localhost:8089/ebxml/msh

(2) [2005-03-15 11:46:47] [DEBUG] send: Message to http://localhost:8089/

ebxml/msh uid=102a41b2fccc0a80ccdc9223301aa874c1a-IBK_N03_1110854807484

(3) [2005-03-15 11:46:47] [DEBUG] Sending a msg Message to

http://localhost:8089/ebxml/msh

(4) [2005-03-15 11:46:47] [DEBUG] httpPost: Message to

"http://localhost:8089/ebxml/msh" content-length=2360 for

uid=102a41b2fccc0a80ccdc9223301aa874c1a-IBK_N03_111

0854807484

(5) [2005-03-15 11:46:49] [DEBUG] httpPostMessage:

returned getResponseCode=204 No Content for

msgid=102a41b2fccc0a80ccdc9223301aa874c1a

로그의 각 부분에 대한 설명은 다음과 같다.

● (1) : FromPartyId: IBK

● (2) ~ (4) : 해당 주소로 메시지를 전송한다. 메시지 uid는 "메시지id (<eb:MessageId>) + FromPar

tyID_ToPartyID_시간 "으로 구성된다.

● (5) : msgid에 대해서 HTTP 204 응답코드를 받았다.


Receiver 로그

Receiver의 로그를 확인하여 애플리케이션이 수행되었는지를 확인한다.

(1) [2005-03-15 11:47:57] [DEBUG] HTTP received POST URL =

"http://192.168.1.63:8088/ebxml/msh". SSL = false; From ip =

192.168.12.205.

(2) [2005-03-15 11:47:58] [DEBUG] HTTP received message had a

content-length header of 2360. Actual size of stream read was 2360.

(3) [2005-03-15 11:47:58] [DEBUG] getPayloadContainer: contentId:

payload-0; contentType=application/octet-stream ; size=314

[2005-03-15 11:47:58] [DEBUG] Received ebXML Header: Content

ID=4111A3ED13D3C3EECABC705A2EB26522; Content Type=text/xml

(4) [2005-03-15 11:47:58] [INFO ] Received ebXML Message message

id=102a41b2fccc0a80ccdc9223301aa874c1a; CPAId=ebIOT-CPA; conversation

id=IBK_N03_1110854807484

(5) [2005-03-15 11:47:58] [DEBUG] processMessage:

uid = 102a41b2fccc0a80ccdc9223301aa874c1a-IBK_N03_1110854807484;

CPAId = ebIOT-CPA;

serviceName = urn:ebIOT-TestService:order;

action = I1_IBK_Send

(6) [2005-03-15 11:47:58] [DEBUG] CPA document root directory: /home/

jjchoe/jeus4222/webhome/servlet_home/webapps/ebxml/WEB-INF/cpas

(7) [2005-03-15 11:47:58] [DEBUG] Getting CPA object, CPA id = ebIOT-CPA

(8) [2005-03-15 11:47:58] [DEBUG] Read CPA document file: /home/jjchoe/

jeus4222/webhome/servlet_home/webapps/ebxml/WEB-INF/cpas/ebIOT-CPA.xml

(9) [2005-03-15 11:47:59] [DEBUG] Cpa found in repository for cpaId=ebIOT-CPA

(10) [2005-03-15 11:47:59] [DEBUG] Local Channel is selected from

collaboration role. channel id = Party-Seller-chan001

(11) [2005-03-15 11:47:59] [DEBUG] RmHandlerImpl.receivedMessage:

uid = 102a41b2fccc0a80ccdc9223301aa874c1a-IBK_N03_1110854807484;

messageId = 102a41b2fccc0a80ccdc9223301aa874c1a;

refToMessageId = null;

conversationId = IBK_N03_1110854807484;

persistDuration = null;

default persistDuration = PT5M

(12) [2005-03-15 11:47:59] [DEBUG] RmSampleHandlerImpl.receivedMessage


New message. uid=102a41b2fccc0a80ccdc9223301aa874c1a-IBK_N03_1110854807484

(13) [2005-03-15 11:47:59] [DEBUG] processMessage: isMshOnlySyncReply=

false; isSyncReply=false; isOnceOnlyOnce=false

(14) [2005-03-15 11:48:00] [DEBUG] Submitting message to listener :


(15)

=========================================

Test 1-1

-----------------------------------------

cpaId = ebIOT-CPA

from partyid = IBK

to partyid = N03

service = urn:ebIOT-TestService:order

action = I1_IBK_Send

num of payloads = 1

payload byte size = 314

=========================================

로그의 각 부분에 대한 설명은 다음과 같다.

● (1) ~ (5) : 메시지를 수신했다.

● (6) ~ (10) : CPA 파일을 읽어서 파싱한다.

● (11) ~ (14) : 메시지에 대해서 Message Listener를 호출한다.

● (15) : Message Listener가 출력된다.

C.3.3. 양방향 메시지 전송 테스트

Requestor가 Responder에 메시지를 1회 전송하고 종료한다. Responding 애플리케이션은 수신한 메시지

를 바탕으로 새로운 메시지를 생성하고 새로운 커넥션을 사용하여 Requster에게 메시지를 전송한다. 새

메시지는 다음 요건을 만족해야 한다.

● 수신한 메시지의 ConversationId와 동일한 ConversationID

● 수신한 메시지의 MessageId와 동일한 RefToMessageID

● 수신한 메시지의 payload와 동일한 Payload


이와 같은 시나리오를 갖는 양방향 메시지 전송 테스트의 흐름은 다음과 같다.

[그림 C.3] 양방향 메시지 전송 흐름

테스트 항목


● Requester에서 받은 메시지의 ConverationId가 이전에 자신이 송신한 메시지의 ConverationId와 동일

한가?

● Requester에서 받은 메시지의 RefToMessageId가 이전에 자신이 송신한 메시지의 MessageId와 동일

한가?





참고


● Responder 설정

Responder의 msh-config.xml 파일에 다음과 같이 Listener를 설정한다.

<listeners>

<listerner>

<class>

<one-way-listener>


</one-way-listener>


</class>

<selector>


<cpaid>ebIOT-CPAI12</cpaid>


<action>I1_IBK_Send</action>

</selector>

</listener>

</listeners>

● Requester 설정

Requester의 msh-config.xml에서 CPAId ebIOT-CPA.xml의 N03에 대해서 다음과 같이 endpoint를

override한다.

<cpa-override>

<cpa-id>ebIOT-CPAI12</cpa-id>

<party>



</party>

</cpa-override>

이 시나리오에서는 Requester가 메시지를 받으므로 Requester의 msh-config.xml 파일에 다음과 같이

Listener를 설정한다. 여기에서는 받은 메시지를 출력만 할 것이므로 Test11Listener를 그대로 사용한

다.

아래 설정은 반드시 필요하지는 않지만, 설정이 없는 경우 Requester의 MSH는 받은 메시지를 처리할

수 없기 때문에 에러를 발생한다(이 에러는 Responder로 전송되지는 않는다).

<listeners>

<listerner>

<class>

<one-way-listener>


</one-way-listener>


</class>

<selector>



<action>I1_IBK_Receive</action>

</selector>

</listener>




1. 웹브라우저를 통해서 Sender MSH의 메시지 전송 테스트 화면에 접속한다. Sender의 MSH의 설치 경

로와 테스트 전송 화면의 URL은 단방향 메시지 전송 테스트와 동일하므로 “C.3.2.2. 테스트 수행”을 참

고한다.

2. 접속한 테스트 전송 화면에서 다음과 같이 각 항목을 입력한 후 [submit] 버튼을 클릭한다.

설정값항목

ebIOT-CPACPAID

ebIOT-TestService:orderService

I1_IBK_SendAction

IBKFromPartyId

N03ToPartyId



다음과 같은 형태의 Message Flow가 발생해야 한다.

[그림 C.4] 양방향 메시지 전송 테스트 결과

C.3.4. 동기식 메시지 전송 테스트

Requestor가 Responder에 메시지를 1회 전송한다. Responding 애플리케이션은 수신한 메시지를 바탕으

로 새로운 메시지를 생성하고 기존 HTTP 커넥션을 사용하여 HTTP Response로 Requster에게 메시지를

보낸다. 새 메시지는 다음 요건을 만족해야 한다.

● 수신한 메시지의 ConversationId와 동일한 ConversationID

● 수신한 메시지의 MessageId와 동일한 RefToMessageID


이와 같은 시나리오를 갖는 동기식 메시지 전송 테스트의 흐름은 다음과 같다.

[그림 C.5] 동기식 메시지 전송 흐름

테스트 항목


● Requester에서 받은 메시지의 ConverationId가 이전에 자신이 송신한 메시지의 ConverationId와 동일

한가?

● Requester에서 받은 메시지의 RefToMessageId가 이전에 자신이 송신한 메시지의 MessageId와 동일

한가?







<listeners>

<listerner>

<class>

<one-way-listener/>

<req-resp-listener>



</class>

<selector>



<action>I3_IBK_Send </action>


</selector>

</listener>

</listeners>



1. 웹 브라우저를 통해서 Sender MSH의 메시지 전송 테스트 화면에 접속한다. Sender의 MSH의 설치 경


고한다.


설정값항목

ebIOT-CPACPAID


I3_IBK_SendAction

IBKFromPartyId

N03ToPartyId




[그림 C.6] 동기식 메시지 전송 테스트 결과

C.3.5. Ack 메시지 도착 확인 테스트

Sender가 Receiver로 메시지를 1회 전송하고 종료한다. Receiver 메시지 수신 후 는 acknowledge 메시지

를 Sender로 전송한다.


이와 같은 시나리오를 갖는 Ack 메시지 도착 확인 테스트의 흐름은 다음과 같다.

[그림 C.7] Ack 메시지 도착 흐름

테스트 항목


● Sender는 수신한 Ack 메시지가 다음 조건을 만족하는지 검사한다.

– CPAId, ConversationID가 Sender가 송신한 메시지의 그것과 일치하는가?

– RefToMessageID가 Sender가 송신한 메시지의 MsgId와 일치하는가?

– Ack 메시지의 서비스의 값이 "urn:oasis:names:tc:ebxml-msg:service" 인가?

– Action의 값이 Acknowledgement 인가?

● Receiver는 Ack를 전송한 뒤에도 동일한 Request를 받지 않는지 검사한다.



참고




<listeners>

<listerner>

<class>

<one-way-listener>


</one-way-listener>


</class>

<selector>




<action>I4_IBK_Send_Ack</action>

</selector>

</listener>

</listeners>



1. 웹 브라우저를 통해서 Sender MSH의 메시지 전송 테스트 화면에 접속한다. Sender의 MSH의 설치 경


고한다.


설정값항목

ebIOT-CPACPAID


I4_IBK_Send_AckAction

IBKFromPartyId

N03ToPartyId




[그림 C.8] Ack 메시지 도착 확인 테스트 결과


C.4. Trouble Shooting

C.4.1. Cannot locate channel

Cannot locate channel Exception은 다음과 같은 형태로 발생한다.

com.tmax.ebxml.cpa.CpaException:Cannot locate channel: role =

http://www.ecom.or.jp/ebIOT#buyer, service URI = urn:ebIOT-

TestService:order, action = I1_IBK_Receive, endpoint URI =

http://192.168.12.205:8088/ebXML/msh

이 경우에는 CPA 문서에 role, serviceURI, action, endpoint URI의 값이 모두 존재하는지 확인한다. 일반

적으로 msh-config.xml에 endpoint를 override한 후 실제 CPA는 endpoint URI를 수정하지 않고 사용한 경

우가 있을 수 있다.


색인

Symbols<basedir>, 159

<cpa-overrides>, 160

<cpa>, 159

<local-schema-location>, 159

<path>, 159

<schema-validation>, 159

<use-local-version>, 159

<listeners>, 160

<listeners><cpa-override>

<cpaid>, 160

<party>, 160

<party><endpoint>, 161

<party><party-id>, 161

<listeners><listener>

<class>, 160

<class><ack-listener>, 160

<class><error-listener>, 160

<class><one-way-listener>, 160

<class><req-resp-listener>, 160

<selector>, 160

<selector><action>, 160

<selector><cpaid>, 160

<selector><from-partyid>, 160

<selector><from-role>, 160

<selector><service>, 160

<message-log>, 161

<level>, 161

<targer-dir>, 161

<persistent>, 159

<adapter>, 159

<adapter><persistent-class>, 159

<adapter><recv-table>, 159

<adapter><send-table>, 159

<dbms>, 159

<dbms><export-name>, 159

<dbms><persistent-class>, 159

<dbms><recv-table>, 160

<dbms><send-table>, 159

AANYLINK1220 register to AMM error, 148

anyPem.sh, 77

BBase Mapping, 17

CCICS Transaction Code, 127

Client ID, 117

Commit Mode, 118

DDatastore ID, 118

dh1024.pem, 78

dh512.pem, 78

EebXML MSH의 설정

msh-config.xml, 157

web.xml, 156

ebXML 게이트웨이

jeus-web-dd.xml 설정, 138

web.xml 설정, 138

WEBMain.xml 설정, 137

END 문자, 8

Ephemeral keying, 78

External 게이트웨이, 2

GGateway Cache, 15

GW5002 Error loading default CA file and/or directory,

149

GW5003 Error loading CA file and/or directory, 149

GW5005 Error loading certificate form file, 148

GW5006 Error loading private key from file, 148

색인 179

HHandshake, 75

HTTP 게이트웨이

jeus-web-dd.xml 설정, 84

web.xml 설정, 84

WEBMain.xml 설정, 83

IIMS Transaction Code, 118

Internal 게이트웨이, 2

IRM Header, 117

Jjeus-web-dd.xml, 84

LLogical Terminal(LTERM), 118

MMapper Cache, 16

Message Listener, 161

One-way Listener, 161

Request-Response Listener, 161

Message Sender, 162

OOne-way Listener, 161

PPacket Concatenate, 7

Packet Split, 6

RRequest-Response Listener, 161

rootca.cnf, 77

RoundRobin 방식, 8

SSelection 방식, 8

Self Session 방식, 8

SNMP Trap, 11

Socket type, 117

SSL Multi-thread 게이트웨이 사용자 API

sslgw_network_connect, 112

sslgw_read, 112

sslgw_select, 111

sslgw_write, 112

SVF0091 can't open shared memory segment, 148

SVR0013 anylink option is wrong, 147

SVR0090 can't attach shared memory segment, 148

SVR0100 invalid shared memory key, 148

SVR2013 database connect failed, 148

SVR2013 not found remote session, 148

SVR2046 Engine version mismatch, 148

Sync Level, 118

TTCP/IP Multi-thread 게이트웨이 Callback 함수

init_algw_info, 94

user_thrmain, 95

TCP/IP Multi-thread 게이트웨이 사용자 API

tcpgw_client_id, 101

tcpgw_get_svcdata, 98

tcpgw_network_connect, 99

tcpgw_portno_ipaddr, 100

tcpgw_read, 99

tcpgw_select, 95

tcpgw_select2, 96

tcpgw_tpacall, 97

tcpgw_tpcall, 97

tcpgw_tpreply, 98

tcpgw_worker_connect, 99

tcpgw_write, 100

TCP/IP 게이트웨이

: al_session_close, 35

al_session_open, 34

done_algw_info, 34

get_channel_num, 40

get_clh_timeout, 42

get_delayed_response, 41

get_end_msg, 36

get_error_call, 42

get_msg_content, 40


get_msg_info, 36

get_msg_length, 35

get_session_timeout, 42

get_unique_id, 37

init_algw_info, 33

put_msg_complete, 39

put_msg_info, 38

set_connect_chkmsg, 39

set_session_chkmsg, 39

shutdown_algw_info, 34

start_algw_info, 34

TCP/IP 게이트웨이 사용자 API

al_my_svrinfo, 57

al_read_msg, 57

al_write_msg, 58

com_sp_to_ibm, 46

fjt_to_unix, 52

get_alline_info, 58

get_channel_id, 58

get_grpline_cnt, 52

get_grpline_info, 53

get_line_status, 57, 59, 61

get_log_id, 61

get_lu_no_from_channel_num, 55

get_max_channel_num, 53

get_out_symbname_from_channel_num, 56

get_peer_ip_from_channel_num, 59

get_symbname_from_channel_num, 53

gw_getpeer_addr, 59

gw_session_close, 56

gw_session_connect_by_symbname, 56

gw_tpacall, 61

gw_tpacall2, 62

ibm_to_com, 50

ibm_to_com_sp, 51

ibm_to_unix, 47

ibm_to_unix_nokorean, 49

ibm_to_unix_nososi, 47

ibm_to_unix_nososi2, 48

ibm_to_unix_sb, 50

ibm_to_unix_sosi_nodel, 49

search_appl, 54

search_kind, 54

search_tx_by_keyval, 54

send_custom_response, 55

set_session_ready, 62

tcpgw_get_local_addr_by_fd, 60

tcpgw_getpeer_addr, 60

unix_to_fjt, 51

unix_to_ibm, 43

unix_to_ibm_nokorean, 44

unix_to_ibm_nososi, 44

unix_to_ibm_sb, 46

unix_to_ibm_sosi_nodel, 45

TCP/IP 통신헤더, 7

Timer value, 117

Wweb.xml, 84

<servlet-class>, 157

ㄱ

게이트웨이별 파싱, 9

고정길이, 8

기관-업무 유일키 파싱, 9

기관-업무 파싱, 8, 133

ㄷ

대내 파싱, 9

대내/외 파싱, 133

대외 파싱, 9

동기(Sync) 통신, 5, 132

ㅁ

멀티 포트 connect 기능, 5, 132

멀티 포트 Listen 기능, 5, 132

ㅂ

배치 게이트웨이, 1

비동기(Async) 통신, 5, 132

ㅅ

서버 모드, 5, 131

Listener, 89

색인 181

핸들러, 89

ㅇ

에러코드, 14

온라인 게이트웨이, 1

ㅈ

장애 처리

Health 데이터 송신, 11

New Session Accept, 11

New session accept/Session timeout, 11

Session close from new session accept:, 12

Session Timeout, 11

Session timeout(after midnight), 12

Session timeout(R/R), 11

Session timeout(send check message), 11

SNMP Trap, 11

장애회선 block 및 자동 복구, 11

테스트 전문 송수신, 11

ㅊ

최대 처리건수 제한, 132

ㅋ

클라이언트 모드, 5, 131

클라이언트 매니저(Client Manager), 91

핸들러 프로세스(Handler Process), 91

ㅌ

통신 방향성, 5, 131

ㅍ

파싱 오류, 10, 133

ㅎ

회선별 파싱, 9


anylink online 게이트웨이 안내서 · 그림 목차 [그림 1.1] 게이트웨이 동작...

Documents