EAI 구축사례와 효과 분석

서영석/한국사이베이스 차장

EAI 인프라를 필요로 했던 초기의 상황을 볼 때 두가지 분야에서 출발했다고 할 수 있다.

첫번째 분야는 ERP 도입으로 업무시스템을 통합하고자 했던 전통적인 제조업분야에서의 ERP와 기존 시스템의 연동이라고 할 수 있고, 두번째는 금융권에서 자동화 프로세싱을 통한 STP 구축이라고 할 수 있다. 전자가 주로 경영정보통합을 중심으로 이루어 졌다면 후자는 운영계시스템의 실시간 통합이라고 할 수 있다.

먼저 ERP의 대명사인 SAP R/3와 Non SAP시스템을 연동하는 사례를 자세히 알아보자. SAP R/3와 인터페이스하기 위한 형식은 다음의 세 가지로 정리할 수 있다.

△IDOC(Intermediate Document): Inbound to SAP, Outbound from SAP.

△BAPI(Business API)/RFC(Remote Function Call): Request & Reply.

△ABAP: From SAP(Data).

그리고 SAP 관점에서 보면 SAP에서 Non-SAP, Non-SAP에서 SAP로 나누어 생각할 수 있다.

이같은 사례에서는 일반적으로 EAI인프라 구축을 위해 가장 많이 사용되는 R/3 어댑터, DB 어댑터, 포맷터, 룰 엔진, 트랜스포트 MW, 모니터링 툴 등이 활용되고 있다. 어댑터 프로세스가 처리할 각각의 인터페이스별 메시지를 처리하기 위해서는 기본환경이 설정되어 있어야 한다. 기본환경은 설계단계에서 이미 시스템들을 고려해 구현되었다고 본다.

먼저 송수신 시스템과 중앙 허브간의 메시징 인프라를 구현하고 정상적으로 작동하는지를 테스트한다. 각 시스템에 트랜스포트 MW를 설치하고 오브젝트 생성 및 테스트를 끝낸 후 데이터 프로세스를 정한다.

최근 들어 데이터 포맷으로 XML을 많이 지원하는데 DB 어댑터가 XML형식으로 메시지를 생성하여 R/3 어댑터와 맵핑 작업을 하기 위해 EAI서버로 전송한다면 고정된 길이로 변환하여 사용할 수 있다.

R/3의 IDOC, BAPI, RFC는 R/3 어댑터의 관리GUI를 통해 메타데이터 형식으로 포맷리파지토리에 로딩된다. 이때의 IDOC은 고정된 길이로 BAPI/RFC는 태그+데이터+구분자 형식으로 생성되며 선택적으로 BAPI/RFC는 XML 형식으로 인터페이스가 가능한 DTD를 생성할 수도 있으며 인터페이스에 필요한 스키마를 불러오는 것으로 스키마모드로 설계되어 있다. 만약 DB 어댑터에서 RFC DTD에 맞게 데이터를 편성하여 전송할 수 있다면 포맷터에서 약간의 맵핑만으로도 RFC 인터페이스가 가능해 진다. ABAP의 경우 별도의 데이터 형식을 제공하지는 않고 고정된 길이로 1 스트림 스트링 데이터만 전송할 수 있다. 한편 R/3에서 MQ시리즈와 인터페이스하기 위해 별도의 프로그램을 개발할 필요 없이 R/3 어댑터의 기능을 사용해 전송할 수 있도록 지원한다. 이 경우에 포맷터에서 정의된 길이로 데이터를 파싱하여 대상시스템에 맞는 포맷으로 맵핑해야 한다.

R/3 어댑터는 논리적으로 하나의 어댑터가 여러 개의 SAP 시스템을 운영할 수 있도록 설계되어 있다. 즉 SAPRFC. INI 파일에 각각 SAP에 대한 정보를 인터페이스별로 목적시스템을 정의하여 사용하도록 되어 있다. 간단하게 보면 타입=A는 To SAP 방향, 타입=R은 From SAP임을 알 수 있다. DEST는 각각의 어댑터 프로세스 구성 파일에 명시해야 하는 값과 동일해야 한다. 프로그램ID는 R/3의 TCP/IP구성에 사용되는 프로그램 아이디와 동일해야 한다. 프로그램ID는 주로 From SAP 방향의 인터페이스에 사용된다. ASHOST는 연결할 R/3 시스템의 IP정보며 나머지 사용자ID나 패스워드 같은 접속정보는 각 프로세스별 구성 파일에 기입해야 한다. RFC_TRACE 파라메터를 통해 RFC 연결에 대한 트레이스를 확인할 수 있다.

<그림1> SAP R/3 통합 솔루션

<그림2> FIX 기반의 STP 구축

<그림3> EAI 구축에 의한 절감효과

STP구축 사례

그럼 두번째 사례인 STP에 대해 알아보자. 이미 언급했듯이 금융권의 EAI인프라 도입은 초기 생각보다는 많이 지연되고 있다. 이유로는 대체로 고객들이 원하는 수준의 운영시스템 통합이 어렵다고 판단되기 때문이다. 그러므로 금융권에서 정보계업무가 아닌 운영계업무에 대한 통합은 STP로 어느 정도 범위를 한정시켜 추진할 필요가 있다. 그럼 이미 세계적으로 많이 사용되고 있고 국내에는 최근에 도입이 추진되고 있는 FIX프로토콜을 이용한 STP구축 사례에 대해 자세하게 알아보자.

FIX프로토콜의 도입 배경은 사람에 의해 개입되어 이루어지는 정보교환, 거래 및 체결, 분배, 결제 등을 시스템으로 자동화하여 거래기간을 단축하고 오류를 배제하는 한편 다른 시스템과의 연동을 통해 실시간 대응이 가능해 진다. FIX는 최초 살로몬 브라더스와 피델러티가 두 회사간의 거래 주문을 위해 만든 프로토콜로 실제 업무를 위한 응용레벨과 데이터 전송을 위한 통신레벨로 구성돼 있다. 두 부분 모두 실제로는 ‘태그=가치’로 구성돼 있으며 최신버전에서는 XML로 표시되기도 한다.

FIX와 같은 국제표준 프로토콜을 도입하고자 할 경우 가장 어려운 점은 아마도 현재 사용하고 있는 주문관리시스템의 데이터 포맷과 거래유형일 것이다. 이런 점에서 STP가 범위는 EAI와 차이가 있지만 구축에 있어서는 비슷한 점이 많다.

우선 데이터 전송을 위한 통신레벨은 FIX엔진에서 담당해 준다고 보고 실제 사용자가 사용할 부분인 응용레벨의 메시지셋 세 가지를 중심으로 설명하도록 하겠다. 먼저 FIX프로토콜의 뉴오더싱글로 상대 회사로부터 주문을 받는다. 자사 주문관리시스템에서 사용되는 주문1이라는 자체 주문포맷으로 변환을 위해 메시지브로커를 사용한다. 대체로 FIX가 포함하고 있는 필드들은 범용성을 위해서 많은 선택필드를 포함하고 있고 실제 금융기관에서 자체 개발한 포맷은 필수요소들만 포함하고 있을 가능성이 크다.

뉴오더싱글이 주문1으로 맵핑되면 고객이 FIX로 주문을 내면 그 주문을 받아 자체포맷으로 변환하고 원장과 Fep를 통해 거래소로 주문이 나가게 된다. 거래소에서 거래가 체결되면 체결내용을 담은 데이터를 Fep를 통해 받아 원장을 거치고 주문관리시스템으로 전달된다.

이때 실행1이라는 체결 메시지는 FIX의 실행리포트로 맵핑되서 상대방에게 보내진다. 상대고객은 체결내용을 근거로 올로케이션을 하고 주문완료를 보내는 것으로 일련의 과정을 마치게 된다.

EAI의 정성·정량 효과

EAI인프라의 구축효과는 정성효과와 정량효과 두 가지로 볼 수 있다. 정성효과는 수치화하기는 힘들지만 대외적인 효과와 구축으로 얻게되는 각종 노하우 등을 들 수 있다. 그러나 때로는 정성효과에 치우쳐 경영층에 EAI인프라 구축의 정당성을 설득하지 못하는 경우도 발생한다. 정량적 효과는 수치화 가능한 효과로 비용절감 효과와 경영정보의 질적 향상을 통한 효과 등이 있다. 비용절감적 측면에서는 복잡하고 어려운 인터페이스를 통합가장 크다는 것을 알 수 있다. 또 응용프로그램보다는 ERP 등 블랙박스와 같은 패키지를 통합할 때 가장 높은 투자대비 효과를 얻을 수 있다.

가장 중요한 것은 솔루션 자체보다는 장기적인 전사적 통합인프라를 위한 계획과 구축의 정당성 확보 그리고 환경에 맞는 솔루션 판단이라고 할 수 있다.

구성파일(BAPI/RFC)

sap

rfc.destination=BAPIRFC

client=170

user= abcd

password= xxxxxx

language=E

Adapter

adapter=sap38MsgGen

mode=PROCESS

data=NDO

------a 여기까지가 어댑터가 어떤 프로세스, 어떤 모드로 구동되는지 정보를 기입

transport.context.name=ADKContext

transport.out.name=OUTQ

transport.in.name=INQ

transport.failure_store_name=FAIL.Q

maximum.transport.retries=0

transport.wait.time=0

transport.wait_time_milli=false

transport.exit_if_empty=false

enter.quiet.state=0

----a 여기까지가 MQ시리즈에 대한 정보를 적음, 어떤 큐에 들어온 데이터를 SAP으로 보내고 어떤 큐로 리턴값을 받을 것인지, 에러 발생시 데이터를 어떤 큐에 저장 할 건지, 큐에 데이터가 없으면 바로 종료할 것인지 아니면 더 조회 해볼 것인지 등등

#NCF Serializer

Output.Serializer.Factory=NCFSerializer_Factory

Output.Serializer.Library=adk38ncfsd

Input.Serializer.Factory=NCFSerializer_Factory

Input.Serializer.Library=adk38ncfsd

#NCF Serializer

Output.Serializer.Factory=NCFSerializer_Factory

Output.Serializer.Library=adk38ncfsd

Input.Serializer.Factory=NCFSerializer_Factory

Input.Serializer.Library=adk38ncfsd

#XML Serializer

#Output.Serializer.Factory=XMLSerializer_Factory

#Output.Serializer.Library=adk38xmlsd

#Input.Serializer.Factory=XMLSerializer_Factory

#Input.Serializer.Library=adk38xmlsd

-a 여기는 RFC 프로세스에만 존재.. XML인터페이스를 사용할 것인지 아니면 NCF 인터페이스를 사용할 것인지..

Session.ADKSession

NNOT_SHARED_LIBRARY = dbt23mqs

NNOT_FACTORY_FUNCTION = NNMQSSessionFactory

NNMQS_SES_OPEN_QMGR = SWCCPD03

Transport.INQ

NNOT_SHARED_LIBRARY = dbt23mqs

NNOT_FACTORY_FUNCTION = NNMQSQueueFactory

NNOT_TIL_OPEN_SESSION_ID = ADKSession

NNOT_TIL_OPEN_TSI = RFCIN.SWCCPD03.LQ

Transport.FAIL

NNOT_SHARED_LIBRARY = dbt23mqs

NNOT_FACTORY_FUNCTION = NNMQSQueueFactory

NNOT_TIL_OPEN_SESSION_ID = ADKSession

NNOT_TIL_OPEN_TSI = RFCIN.FAIL.RQ

a 메시지 송수신에 사용될 큐의 상세 정보를 적는다. R/3 어댑터는 MQ시리즈 외에도 다른 트랜스포트 미들웨어를 지원하기 때문에 옵션을 다양하게 주기 위해서 트랜스포트 타입별로 여러가지 파라미터가 존재함.

제공 : DB포탈사이트 DBguide.net