저자 서문

ERP(Enterprise Resource Planning)의 출현과 함께, 강력한 interface 기술에 대한 필요성이 점차 증가하고 있고, 또한 중요하게 되었다. SAP R/3의 ALE(Application Link Enabling)와 EDI(Electronic Data Interchange) 기술은 여러 개의 R/3 시스템과 non-R/3 시스템에 걸쳐 기업의 업무 프로세스(process)를 확장하는데 있어서 중요한 역할을 한다. ‘더 좋게, 더 빠르게, 더 저렴하게’라는 구호아래, 회사들은 저마다 더욱 정교하게 통합된 업무 시스템(business system)을 원하게 되었다. SAP는 전체적으로 통합된 ERP Solution인 R/2 시스템과 R/3 시스템을 지금까지 매우 성공적으로 판매해 오고 있다. 하지만 어떤 회사에서는 기술적인, 실무적인, 또는 정치적인 한계로 인하여, 한 database만으로는 운영할 수 없는 경우도 있다. application 시스템이 분산되어 있거나 이종 시스템들이 함께 연결되어 사용되는 환경에서, ALE는 느슨한 연결방법(loosely coupled method)을 채택하여, 서로 분리되어 독립적으로 사용할 수 있도록 해주는 반면, 밀접하게 연결된(tightly coupled) 업무통합을 가능하게 해주는 해결책을 제공해 준다. EDI는 특정 회사가 거래 상대방과 업무서류를 서로 교환할 수 있도록 해 주는데, 업무 프로세스의 빠른 회전을 확보한다는 관점에서 볼 때, 이 기능은 때때로 매우 중요한 요소가 된다.

목차

서문

저자 서문

역자 서문

목차

Chapter 1 ALE와 EDI에 대한 소개

1.1 개요

1.2 ALE/EDI 개발에 대한 접근방법

1.3 이 책을 사용하는 방법

1.3.1 이 책에서 사용되는 관례(conventions)

1.4 ALE 구성 단위(Building Block)와 개념

1.4.1 Logical System

Chapter 1 ALE와 EDI에 대한 소개

1.1 개요

ALE(Application Link Enabling)는 두 개 또는 그 이상의 R/3 시스템 간이나, R/3 시스템과 외부시스템 간에 데이터 통신을 가능하게 해주는 SAP 고유의 기술이다. 많은 기업들이 R/3 시스템과 같은ERP(Enterprise Resource Planning)시스템을 설치할 때는, 그 ERP시스템이 기존 시스템들(legacy systems), 다른 ERP시스템들, 고객의 시스템들, 구매처의 시스템들, 은행의 시스템들과 interface해야 한다는 사실을 인식하는 것이 매우 중요하다. ALE와 EDI(Electronic Data Interchange)는 그것을 사용하는 고객들이 업무통합을 달성하면서도 application과 database를 분산할 수 있도록 해주는 지능적인 구조를 제공한다. ALE 기술을 이용하게 되면, application에 대한 프로토타입핑(prototyping)과 interface 개발 작업을 신속하게 처리할 수 있는데, 그럼으로써 설치작업에 필요한 시간과 노력을 절감할 수 있다. ALE와 EDI의 구성 요소들은 원래 SAP application과 밀접하게 통합되어 있으며, 성격상 견고한 구조를 가지고 있어서, 매우 신뢰할 수 있는 시스템을 구성해 낼 수 있다.

1.2 ALE/EDI 개발에 대한 접근방법

투자금액에 대해 최대한의 성과를 얻기 위해서는, 다른 모든 소프트웨어 개발과 마찬가지로 ALE와 EDI 개발에 있어서도 구조적인 접근방식을 따르는 것이 중요하다.

interface할 항목을 확인한 다음, 그 업무영역에 대하여 ALE/EDI 기능이 제공되는지를 확인해야 한다(이전에 이야기한 것처럼 SAP에서는 ALE가 지원되는 업무영역이 수백 개 이상 존재한다. 나중에 이러한 기능을 확인할 수 있는 몇가지 기법을 설명하겠다).

1.3 이 책을 사용하는 방법

이 책은 연습용과 참조용으로 동시에 사용될 수 있도록 디자인 되었다. 이 책은 여러분이 ALE와 EDI를 구성하는 기본 구성 단위(building block)를 이해하는 것에서부터 시작하여, 다양한 시나리오에서 ALE/EDI interface를 작동시키기 위해서 필요한, 모든 설정 작업(필요한 경우 프로그래밍도 포함해서)들을 단계적으로 하나씩 이해할 수 있도록 인도해 줄 것이다. 기본적인 개념과 설정 작업 상의 처리방법에 대한 다양한 차이점에 대하여는 필요한 시점에 맞추어 설명할 것이다. 사실 여러분이 ALE/EDI에 친숙해지게 되면, 이 책의 목차를 ALE/EDI interface를 구성하는데 있어서의 점검목록으로 사용할 수도 있을 것이다. ALE interface를 구축하는데 사용되는 모든 단계의 작업들은, 별도 이야기가 없는 한, EDI interface에서도 동일하게 적용될 수 있다는 사실을 주목할 필요가 있다.

1.4 ALE 구성 단위(Building Block)와 개념

이 절에서는 ALE/EDI의 기본적인 구성 단위(building block)들 및 그들과 연관되는 개념들을 소개하고 있다. 여기서 소개되는 용어는 이 책의 전체에 걸쳐서 계속 사용될 것이며, 그 개념들이 해당 내용과 관련이 있거나 추가적인 설명이 필요한 시점에 더욱 상세하게 설명될 것이다. 이러한 구성 단위(building block)들은 ALE/EDI의 가장 기초가 되고, 이러한 것들을 생성하고, 연결하고, 설정함으로써, ALE/EDI interface를 구축하게 되는 것이다.

1.4.1 Logical System
Logical System(LS)은 특정 R/3 시스템이 다른 R/3 시스템이나 외부시스템과 서로 자료를 주고 받기 위해서 그 R/3 시스템 내에서 정의되는 것으로, 그 특정 R/3 시스템이나 다른 R/3 시스템, 또는 외부시스템을 나타내는 표현 방식이다(원래 R/3 내에서 오고 가는 여러 가지 다양한 system data들을 구분하기 위해서 SAP R/3 내에서 logical system이란 개념을 도입하였다). ALE/EDI에서 사용되는 모든 R/3 client에는 그 client 자체를 의미하는 Base Logical System이 정의되어 있어야 한다. 이 base logical system은 outbound message에 대해서는 ‘송신자’가 되고, inbound message에 대해서는 ‘수신자’가 된다. 이러한 base logical system과 함께, ALE interface에서 사용되는 모든 R/3 시스템과 외부시스템에 대하여 각각 하나씩의 logical system이 그 R/3 시스템 내에 생성되어 있어야 한다. 그래서 inbound ALE interface의 경우에 base LS(수신자)의 관점에서 보면, 이 logical system은 송신자(다른 R/3나 외부시스템)가 된다. 반대로 outbound ALE interface의 경우에는 base logical system(송신자)의 관점에서 보면, 이 logical system은 수신자인 다른 R/3나 외부시스템을 나타내는 것이다. logical system을 관리하는 방법은 다음 장에서 설명될 것이다.

1.4.10 Message Control과 Output Type

R/3 시스템에서 Message Control은 selection criteria, requirement, sequence에 근거하여 문서를 생성해 내는 구조체계이다. message control은 문서 유형(documet type), 생성 시점(timing), 문서의 수, 문서 매체(medium-인쇄, 팩스, ALE, EDI, 기타 등)을 결정한다. SD(Sales and Distribution)와 MM(Material Management, Purchasing)에서의 outbound message는 message control record에 의해서 생성되고, 처리된다. output 자료는 table NAST에 보관된다.

message control은 ‘condition technique’을 사용한다. condition table에는 output message를 생성하는 조건이 저장되어 있는데, 이 table에는 application field/table의 catalog에서 선택된 selection field들이 포함되어 있다. 어떤 업무 문서에 대해 output를 생성할 수 있는 조건이 충족되는지를 결정하기 위해서 access sequence, output procedure, requirement를 이용하는 search strategy가 사용된다. 일단 output을 생성해야 하는 조건이 충족되면, message control module은 condition type또는 output type에서 지정된 parameter를 사용하여 그 message에 대한 전송 시점(timing)과 문서 매체(medium)를 결정하게 된다. 또한 output type에는 output을 생성할 때 호출할 프로그램이나 module이 지정되어 있다.

1.4.11 Partner Profile

Partner란 message를 주고받기 위해서 사용되는 어떤 한 시스템에 대한 이름이다. Partner Profile은 특정 partner와 어떠한 message를 어떠한 방식으로 주고 받을 것인지를 규정하고 있다. SAP에서는 네 가지 종류의 partner profile이 있다: (1) 고객(customer)에 대해 사용되는 KU, (2) 구매처(vendor)에 사용되는 LI, (3) 은행(bank)에 대해 사용되는 B, (4)logical system에 대해 사용되는 LS가 그것이다. 여러분이 인식했겠지만, KU, LI, B는 EDI Partner에서 사용되고, LS는 ALE 통신을 위해서 사용된다. ALE에서 사용되는 모든 partner profile은 이미 정의되어 있는 logical system에 근거하여 정의되어야 한다.

여러분이 장차 배우게 되겠지만, partner profile에는 두 개 또는 그 이상의 시스템들 간의 통신 parameter들을 정의하기 위해서 필요한, ALE와 EDI의 여러 항목들이 함께 포함되어 있다. 일반적인 정보 이외에 inbound parameter, outbound parameter, message control등에 대한 정보를 정의해야 한다. 중요한 parameter로는 message type, IDOC type, process code, partner function, application identifier, message function, output type, port 등이 있다. 또한 처리방식(processing option)과 오류처리 방법을 결정하는 parameter도 있다.

1.4.2 Message Type
Message Type은 특정 R/3 시스템과 다른 R/3 시스템 간이나 특정 R/3 시스템과 외부시스템 간에 오고 가는 업무 상의 message을 표현하는 용어이다. message type은 시스템들 간에 송수신되는 실제 자료의 내용을 규정하고 있으며, IDOC type(다음 설명을 참조하라)이라는 자료 구조와 서로 연관되어 있다. 예를 들면 MATMAS는 Material Master에 대한 message type이고, INVOIC는 대금 청구서(invoice)에 대한 message type이다. SAP R/3 내에는 ALE가 지원되는 이러한 message type이 수백 개 존재하고 있다. 이것은 SAP 내에서 ALE 기능이 지원되는 업무영역이 수백 개나 된다는 것을 의미한다. SAP에서 기본적으로 지원하고 있는 message type 목록을 보려면 부록 B를 참조하기 바란다. 여러분은 제 5장에서 새로운 message type을 어떻게 생성하는지에 대해서 배우게 될 것이다.

1.4.3 IDOC Type과 IDOC

IDOC Type(Intermediate Document Type)이란 message type과 연관되어 있는 자료의 구조를 표현하는 용어이며(message type DEBMAS에 대응되는 DEBMAS05—Customer Master, message type WMMBXY에 대응되는 WMMBID02—자재이동 등), 반면 IDOC은 그 안에 특정 message type의 자료를 포함하고 있는 object를 의미한다. IDOC은 지능적으로 작동하는 data container이다. 각각의 IDOC은 단 하나의 business object만 포함하고 있다는 것을 이해하는 것이 중요하다. 다시 말하면, IDOC type이 SHIPMNT01이고, message type이 SHPMNT인 IDOC은 단 하나의 shipment 문서 자료만 포함하고 있다는 것이다. 나중에 배우게 되겠지만, 일반적으로 이야기 하면, IDOC의 구조는 message type과는 독립적인데, 이것은 ALE가 모든 message type에 대해서 IDOC 구조를 재정의할 수 있는 능력을 가지고 있기 때문이다.

1.4.4 Customer Distribution Model

R/3 시스템에서 Customer Distribution Model은 여러 시스템들 간에 오고 가는 message flow에 관한 정보를 보관하는 도구이다. customer distribution model은 SAP가 제공하는 Distribution Reference Model에 기반을 두고 있다. (customer distribution model은 distribution reference model에 저장되어 있는 것과는 다른 분배 시나리오를 가질 수 있다. 간단히 말하면, customer distribution model은 어떤 logical system으로 어떤 message(message type)들이 전달되는가를 규정하는 자료를 저장하고 있다. 여러 개의 message들이 하나의 logical system으로 전달될 수도 있고, 반대로 하나의 message가 여러 logical system으로 전달될 수도 있다. filter object와 listings을 사용하여(다음에 나오는 설명을 참조하라), model 내에서 특정 logical system에 대하여 filtering정보를 지정할 수가 있다. customer distribution model은 해당 client의 base logical system을 기준으로 정의하게 되는데, outbound인 경우에는 base logical system을 ‘송신자’로 하고, inbound인 경우에는 base logical system을 ‘수신자’로 하여 정의하게 된다.

1.4.5 Filter Object Type과 Filter Objects

Filter Object Type은 customer distribution model에서 특정 logical system으로 전송되는 message(type)에 대한 선택조건을 지정하기 위해서 사용된다. 실제의 선택조건 값이 지정되어 있는 filter object type을 Filter Object 라고 부른다. 예를 들면 BUKRS(company code)는 message type DEBMAS(Customer Master)에서 사용 가능한 filter object type이다. Customer Master자료 중에서company code가 “1001”인 자료만 특정 logical system으로 분배하려고 하면, filter object type BUKRS를 사용할 수 있는데, 이때는BUKRS=”1001”를 값으로 가지는 filter object를 생성하면 된다. 여러분은 특정 logical system에 지정되어 있는 동일 message type에 대하여 값이 다른 여러 개의 filter object를 지정할 수 있다는 것을 명심해야 한다. customer distribution model에 따라 특정 message에 대한 수신자를 결정할 때, ALE는 filtering정보를 이용하여 object filtering을 실행한다. customer distribution model과 마찬가지로, filter object는 단지 ALE에서만 사용할 수 있다.

1.4.6 Listing

Listing은 특별한 형태의 filter object type으로서 master data를 분배할 때 선택조건을 규정하기 위해서 사용된다. listing은 기본적으로 classification system(class와 characteristics)에 근간을 두고 있으며, 단지 Material Master, Customer Master, Vendor Master 자료에만 적용할 수 있다. ALE 설정 메뉴를 이용하여, 특정 classification 정보에 기초를 둔 list를 생성하고, 그것을 원하는logical system과 연결시킨다. 이렇게 처리하고 나면, 그 logical system에 지정되어 있는 message type에 대하여 filter type “distribution via classes”를 이용한 filter object를 생성하는데 그 listing을 사용할 수 있다.

1.4.7 Change Pointers

Change Pointer는 SAP master data에 대한 변경사항을 나타내 주는, R/3에 있는object이다. change pointer는 shared master data(SMD)라는 도구 속에 있는 관리체계에 의해서 관리되며, change document(CD) object에 기반을 두고 있다. SAP application에서 change document object는 master data에 대한 변동사항을 field 수준까지 기록해 준다. 이러한 변동 사항들은 table CDHDR(header table)과 CDPOS(detail table)에 저장된다. change document object와 change pointer는 ALE 설정에 의해서 서로 연결된다. 그러면 내부적인 체계에 따라 changer pointer에 대한 자료를 저장하고 있는 table BDCP와 table BDCPS를 갱신해 준다. change document object는 application 자료별로 관리되고, change pointer의 처리상태는 message type별로 관리된다는 사실을 주목하는 것이 중요하다. ALE에서 change pointer를 사용하기 위해서는 change pointer가 생성될 수 있도록 활성화(activate)되어 있어야 하는데, 이를 위해서는 먼저 general level에서 활성화(activate)되고, 다음으로 message type level에서 활성화(activate)되어야 한다(상세한 내용은 제 2장의 해당 부분을 참고하기 바란다).

1.4.8 Port

Port는 IDOC 형태의 자료를 전송할 때 사용하는 통신경로를 표현하는, SAP안에서의 논리적인 표현이다. R/3에서 정의할 수 있는 port에는 다음 6가지 유형이 있다: (1) transactional RFC(Remote function Call), (2) File, (3) R/2, (4) Internet, (5) ABAP-PI, 그리고 (6) XML가 그것이다. ALE는 위의 모든 종류의 port를 이용하여 IDOC를 분배할 수 있지만, EDI는 일반적으로 file port를 사용한다. transactional RFC port와 file port는 RFC destination으로 연결되고, 이는 다시 R/3와 R/3 간의 통신이나 TCP/IP와 같은 통신 경로로 연결된다. port를 RFC destination과 연결시킴으로써, EDI subsystem, IDOC mapping 소프트웨어, FTP, 기타 등를 호출해 주는 script를 가동시킬 수 있다.

1.4.9 Process Code

Process Code는 ALE와 EDI에서 후속 처리에서 호출되어야 할 function module이나 API를 지정하기 위해서 사용된다. inbound interface에서는 판매(고객)주문(process code—ORDE), Material Master record(MATM), 수송(SHIP) 등과 같은 SAP의 application object에 inbound IDOC을 반영해주는 application module을 결정하기 위해서 process code를 사용한다. outbound interface에서는 message control(다음에 나오는 설명을 참조하라)을 사용하는 application인 경우에만 process code를 사용한다. 이 경우에 process code는 application자료를 이용하여 IDOC을 생성해 낼 application module을 결정해 주는 역할을 한다. 각각의 process code는 하나의 message type과 연결되어 있다. outbound process code는 table TEDE1에 저장되어 있고, 반면 inbound process code는 table TEDE2에 저장되어 있다.

1.5 ALE 시나리오 예제들

이 절에서는 몇 가지 ALE 시나리오에 대하여 살펴보자. 처음 예제는 ALE 기술을 이용하는, 외부 창고관리 시스템과의 몇 가지 interface를 설명하고 있고, 두 번째 시나리오는 두 개 또는 그 이상의 시스템들 간의 master data분배를 그리고 있다. 이러한 시나리오들은 R/3에서 처리할 수 있는 수많은 ALE interface들 중 몇 개의 예제에 불과하다. 지난번에 이야기한 것처럼, SAP R/3 내에는 ALE가 지원되는 message가 수백 개 존재하고 있다.

1.6 EDI 시나리오 예제

이전에 이야기 한 것처럼, EDI(Electronic Data Interchange)는 기업에게 은행, 구매처(vendor), 고객(customer)과 같은 그들의 거래처와 업무 자료나 문서를 전자적으로 주고 받을 수 있는 기능을 제공해 준다. 이렇게 거래처들과의 연결을 더욱 빠르게 함으로써, 회사의 업무처리 프로세스나 거래처와의 거래에 대한 회전율을 대폭 향상시킬 수 있다. SAP R/3는 EDI에 대한 산업표준인 UN/EDIFACT와 ANSI X12를 지원하고 있다.

Chapter 2 Master Data 분배와 Interface

2.1 개요

이 장에서 우리는 ALE를 이용하여 master data를 분배하는 방법과 master data에 대한 interface를 구축하는데 필요한 여러 가지 작업들에 대하여 공부할 것이다. SAP를 설치할 때, 다른 R/3 시스템이나 외부시스템으로 master data를 보내야 하는 경우가 많이 있다. 예를 들면 R/3밖에 있는 기존 시스템(legacy system)에서 돌아가고 있는 어떤 응용시스템이 transaction자료를 처리하기 위해서 Customer Master 자료를 필요로 할 수도 있고, 또는 분산환경에서 판매조직용 R/3 시스템의 Customer Master를 본사에 있는 R/3 시스템의 Customer Master자료와 일치시킬 필요가 있을 수도 있다. SAP에서 master data라고 하면 그 범위가 매우 넓은데, 예를 들면 Material, Customer, Vendor, Class, Classification, Bill of Material, Pricing Condition, General Ledger, Cost Element 등이 모두 이 범주에 포함된다. R/3에서 ALE 서비스를 사용하여 master data를 분배할 수 있는 message type이 50개 이상 존재한다.

2.2 기본 설정

R/3 시스템에서 ALE 기능을 활용하기 위해서는, 여러분이 시스템의 가장 기본적인 몇 가지 항목을 설정해야 한다. 이러한 작업은 ALE 설정 메뉴([그림 2-2]를 참조하라)를 이용하여 처리할 수 있다. 이 메뉴를 호출하기 위해서는 transaction SALE를 사용하거나, IMG à [Basis Components] à [Application Link Enabling (ALE)]를 사용하면 된다.

2.3 Non-R/3 시스템과의 Interface

여기서는 외부의 non-R/3 시스템에 대한 master data interface를 구축해 보도록 하자. 우리는 message type MATMAS와 IDOC type MATMAS03을 사용하여 Material Master를 전송하고자 한다. 우리는 R/3 시스템이 change pointer를 이용하여 변경사항을 포착하고, master data IDOC을 생성할 뿐만 아니라, 자재(material) 자료를 ‘전송’하도록 설정할 것이다.

2.3.1 Logical System의 정의

먼저 외부의 non-R/3 시스템을 표시하기 위해서, 앞에서 설명한 것처럼 logical system을 생성하라. 우리는 그것을 “EX1MATMAS3”라고 부르자. 이 logical system은 IDOC type MATMAS03 에 대하여 수신 logical system(LS)이 될 것이다.

2.3.2 Customer Distribution Model 설정

customer distribution model은 한 시스템에서 다른 시스템으로 가는 message flow를 표현하는 것이다. 여기서는 어떤 logical system이 base logical system과 송수신하는 message type을 규정할 뿐만 아니라, filter object를 이용하여 서로 통신하는 자료에 대하여 filtering 조건을 지정한다. 이전에 언급한 것처럼, 이러한 개념은ALE에서만 적용할 수 있다.

customer distribution model을 설정하려면 다음 작업을 실행한다. 그[림 2-8]과 [그림 2-9], 그리고 [그림 2-10]을 참조하라.

2.3.3 Change Pointer 활성화(Activation)

change pointer는 master data에 대한 변경사항을 반영해 주는 object이다. 이것은 change document service 와 shared master data 도구를 통하여 활용할 수 있다. ALE 프로그램들과 API들은 해당 message type에 대하여 IDOC 자료를 만들어 내야 하는, 변경된 master data를 가려 내기 위해서 change pointer를 사용한다. change pointer는 table BDCP와BDCPS에 저장되어 있다. table BDCPS에는 고유한 change pointer 식별자(Identifier)와 message type을 key로 하여 change pointer 처리상태에 대한 자료를 관리하고 있다. change pointer가 일단 처리되면, table BDCPS의 PROCESS field는 “X” 값으로 표시된다.

change pointer의 생성여부는 general level과 message type level 양쪽에서 모두 활성화(activate)되어야 한다. 이렇게 하기 위해서는 transaction SALE에서 다음 작업들을 실행한다. [그림 2-11]과 [그림 2-12]를 참조하라.

2.3.4 Communication : Port정의

Port는 IDOC 통신을 위한 경로(channel)이다. SAP R/3에서는 6 가지 종류의 port를 사용할 수 있다: (1) transactional RFC(Remote Function Call), (2) file, (3) CPI-C, (4) Internet, (5) ABAP-PI, (6) XML이 그것이다. 우리의 예제에서는 Material Master IDOC을 외부시스템으로 전송하기 위해서, 우리는 file port를 정의할 것이다. 이렇게 함으로써, 우리는 file형태의 IDOC을 생성할 수가 있게 된다.

port를 정의하기 위해서는, transaction WEDI à [IDOC] à [Port definition]을 사용하거나, transaction WE21을 사용하면 된다. [그림 2-13]과 [그림 2-14]를 참조하라.

2.3.5 Communication: Partner Profile

partner profile은 서로 통신하고 있는 상대 시스템에 대한 식별자(identifier)이다. ALE에서 사용하는 partner profile은 사전에 정의되어 있는 logical system에 기초를 두고 있다. partner profile은 ALE에 대한 여러 가지 요소들을 함께 포함하고 있으며, 시스템들 간의 접근경로(gateway)의 역할을 한다. 우리는 outbound Material Master interface를 위한 partner profile을 생성해 보도록 하겠다

partner profile을 정의하기 위해서는 transaction WEDI à [IDOC] à [Partner Profile]을 실행하거나 또는 transaction SALE à [Modeling and Implementing Business Processes] à [Partner Profiles and Time of Processing] à [Maintain Partner Profile Manually]을 사용하여 다음 작업을 수행한다. [그림 2-15]와 [그림 2-16]을 참조하라.

2.3.6 Interface 작동

이제까지 outbound Material Master interface를 위한 ALE 설정을 완료했으므로, 지금부터 우리는 interface를 테스트해보는 흥미로운 작업를 진행해 나갈 것이다. 이 interface를 작동해 보는 방법에는 몇가지가 있다. 즉 우리가 Material Master IDOC을 직접 ‘송신’하는 방법을 사용하거나, 아니면 master에서 발생하는 변동사항을 포착하고, 그 변동사항을 IDOC으로 변환하는 방법을 사용할 수도 있다. 그외에 세 번째 방안으로 master data를 끌어 오는 방법이 있는데, 이 방법에서는 참조 R/3 시스템에게 Material Master자료를 송신해 주도록 요청하는 방법을 사용한다. 이 방법에서는 message type MATFET를 사용한다.

2.4 R/3와 R/3 간의 Interface

우리는 이 절에서 두 개 또는 그 이상의 R/3 시스템들 간의 interface를 구축하는 방법에 대하여 배우게 될 것이다. R/3와 R/3간의interface나 R/3와 외부시스템들 간의 interface는 기본적인 개념은 거의 동일하지만, 통신방식에서의 개념적인 차이뿐만 아니라 설정과정에서도 몇 가지 중요한 차이점이 있다. 우리는 한 R/3 instance에서 다른 R/3 instance로 characteristics와 class정보를 분배하는 예제를 가지고 이야기를 진행해 나갈 것이다. material, customer, vendor, 기타와 같은 object를 사용할 때, 그들의 속성을 보다 상세히 기술하고, 한 object를 다른 object와 구분하기 위해서, 이들 object들을 분류할(classify) 필요가 종종 발생한다. 이러한 개념을 Classification이라고 한다. SAP에서는 이들 object들을 분류하기 하기 위해서 characteristics와 class라는 개념을 사용한다. Characteristics는 object를 더욱 상세히 설명해 주는 속성이다. 예를 들면 화학물질의 온도 민감도, 고객상점에 있는 선반의 넓이 등은 SAP R/3 classification system 내에서 관리될 수 있는, object에 대한 characteristics이다. Class는 material, vendor, 기타와 같은 class type에 따라 정의된 characteristics 그룹을 말한다. Classification Data라는 용어는 characteristics에 부여되어 있는 실제 값을 의미하는 반면에, class와 characteristics는 설정 자료로 간주할 수 있다. SAP에서는 CTS(Correction and Transport System)를 통하여 class와 characteristics정보를 시스템들(개발, 테스트, 운영) 간에 전송할 수 없다. ALE는 class와 characteristics, classification data를 다른 시스템으로 분배해 주는 message type, IDOC type, function module을 기본적으로 제공해 주고 있다. 이 장의 목적은 한 R/3 시스템에서 다른 R/3 시스템으로 characteristics와 class를 분배하는 interface를 구축하는 것이다.

2.4.2 Customer Distribution Model의 설정

이전 장에서 설명한 방식에 따라, 필요한 message type에 대한 message flow을 지정하기 위해서 customer distribution model을 설정해 보기로 하자.

n transaction BD64를 실행한다.

n 그러면 [Display Distribution Model] 화면이 나타난다. 변경작업을 할 수 있도록 화면 위에서 [Switch between display and edit mode] 버튼을 눌러 [Change Distribution Model] 화면으로 전환한다.

n 화면 위에서 [Create model View] 버튼을 누른다.

n 그러면 팝업화면이 나타나는데, 여기서 [Short text] 필드에 “Send Characteristics and Class”와 같이 customer distribution model에 대한 설명을 입력하고, [Technical name] 필드에는 “CHRCLSMODL”와 같이 model에 대한 ID를 입력하고, [Start date]와 [End date] 필드에는 유효일자를 입력한 다음, [Enter] 키를 누른다.

2.4.3 수신시스템의 CPIC user 생성

원격지에 있는 시스템과 message를 송수신하고 처리하기 위해서, SAP는 수신시스템 상의 user ID를 사용한다.—이 user ID는 CPIC 유형으로 정의되어야 한다. 그 user는 정상 dialog user를 사용할 수도 있지만, ‘최대 logon 수 초과’와 같은 성능 상의 문제를 사전에 방지하기 위해서 반드시 CPIC user로 정의할 필요가 있다. BASIS 관리자에게 요청하여 이러한 방식으로 user ID를 설정하도록 하라. 또한 그 user ID가 R/3 시스템에서 Characteristics Master와 Class Master에 대한 database를 갱신할 수 있는 모든 권한을 가지고 있는지를 확인해 보기 바란다.

2.4.4 RFC Destination의 관리

R/3와 R/3 간의 통신에는 Transactional RFC라는 방식을 사용한다. RFC란 용어는 통상 원격지에 있는 시스템에서 transactional하거나 비동기적인 작업을 하기 위해서 function module을 호출할 때 사용되는 Remote Function Call을 말한다. RFC 앞에 붙어 있는 transactional이란 단어는, 단지 그 function들이 logical unit of work단위로 호출된다는 것을 표시하는 것인데, 이는 간단히 말하면, 하나의 Material Master, 하나의 납품(delivery), 하나의 송장(invoice)과 같은 것이다. SAP의 tRFC와 aRFC는 packet 단위로 자료를 송수신하는 과정을 추적해 주고, 그들의 진행상태에 대한 정보를 관리해주는, 보다 진보된 체계를 가지고 있다. 예를 들어, 자료를 확실히 전달하기 위해서, 자료의 송수신이 성공적으로 끝날 때까지 tRFC call을 반복적으로 호출해 준다. 우리는 제 10장 “ALE 최적화”에서 RFC와 RFC의 최적화에 대하여 더 상세히 토론할 것이다. 우리의 interface에서 필요한 RFC destination을 설정하기 위해서, 다음 작업을 수행한다. [그림 2-28]을 참조하라

2.4.5 RFC Port와 Partner Profile의 생성

이전에 설명한 R/3와 외부시스템과의 interface에서, 우리는 port와 partner profile을 수작업으로 정의하였다. 우리는 여기서 SAP에서 제공하는 기능을 사용하여 R/3와 R/3 간의 interface에서 사용할 RFC port와 partner profile을 자동으로 생성하는 방법에 대하여 배울 것이다. 앞으로 여러분이 보게 되겠지만, port는 이전 단계에서 우리가 생성한 RFC destination에 근거하여 정의되는 반면, partner profile은 이미 생성된 port뿐만 아니라 우리가 생성한 customer distribution model에 근거하여 생성된다. 이러한 object들을 생성하기 위해서는 다음 작업을 수행한다. [그림 2-29]를 참조하라.

2.4.6 수신시스템에서 수신용 Partner Profile의 생성

우리는 이제 송신시스템에서 보내오는 message를 수신하기 위하여, 수신시스템에서도 logical system과 partner profile을 생성해야 한다. 이러한 작업은 송신시스템에서 정의했던 동일한 항목을 수신시스템에서도 정의하되, 송신시스템에서 정의한 것과는 반대의 형태로 정의하는 것이다. 이러한 작업을 하기 위해서는 다음 작업을 수행한다.

n 수신시스템에서 logical system FSTCLNT100을 생성한다.

n 수신시스템에서 partner number FSTCLNT100에 대한 partner profile을 생성한다.

n partner profile에서 inbound parameter를 입력한다. message type CHRMAS에 대하여 [Process code] 필드에 “CHRM”를 입력하고, [Processing by function module] 필드에 “Trigger by background program”를 선택한다. message type CLSMAS에 대해서도 [Process code] 필드에 “CLSM”, [Processing by function module] 필드에 “Trigger by background program”를 선택한다. [그림 2-30]을 참조하라.

n 자료를 저장한다

2.4.7 Customer Distribution Model의 분배

customer distribution model CHRCLSMODL은 송신시스템에서 생성되었다. 이것은 다른 시스템으로 전송되는 특정 message(여기서는 CHRMAS와 CLSMAS)의 flow를 결정하고 통제한다. 수신시스템이 inbound IDOC을 받아 들이고 처리할 수 있도록 하기 위해서는, 이러한 정보가 수신시스템에게도 전달되어야 한다(참고 : 수신시스템에서 송신시스템과 동일한 내용의 customer distribution model을 설정하는 방법에는 두 가지가 있다. 첫 번째는 송신시스템에서 했던 것처럼 수신시스템에서 직접 설정하는 것이고, 두 번째는 송신시스템에서 작업한 customer distributio model을 수신시스템으로 전송하는 것이다). R/3의 ALE는 customer distribution model을 상대편 시스템으로 분배할 수 있는 도구를 제공해 준다. customer distribution model을 분배하기 위해서는 다음 작업을 수행한다. [그림 2-31]을 참조하라.

.4.8 Interface 작동

지금까지 우리는 R/3와 R/3 간을 interface하기 위해서 필요한 시스템 설정을 완료했으므로, 이제는 이 interface를 실제로 실행하고, 그 결과를 이해하는 방법에 대하여 공부해 보기로 하자. 또한 우리는 통신상태를 monitoring해 볼 수 있는 기술을 배울 것이며, 나중에는 R/3와 R/3 간에 ALE 통신을 할 때의 performance문제에 대해서도 토론할 것이다.

● 자료의 송신:

SAP는 IDOC을 송신해 주고, 처리해 주는 표준 프로그램을 기본적으로 제공해 준다. 우리가 수신시스템으로 자료를 보낼 때 사용할 프로그램은 Characteristics Master를 송신하는 프로그램 RBDSECHR과 Class Master를 송신하는 프로그램 RBDSECLS이다. 여기서 한 가지 유념해야 할 것은, characteristics은 class에 포함되어 있기 때문에, 즉 class는 characteristics를 포장한 것과 같기 때문에, Class Master보다 Characteristics Master자료가 먼저 송신되어야 한다는 것이다. 먼저 첫 번째 단계로, 송신시스템에서 characteristics IDOC을 생성해 보기로 하겠다.

Chapter 3 Transaction Data 분배와 Interface

3.1 개요

이 장에서 우리는 transaction data를 처리하는 몇 개의 ALE 시나리오에 대한 interface를 구축하려고 한다. 비록 우리가 이전의 장들에서 배운 개념들이 이러한 ALE interface에서도 계속적으로 사용되기는 하겠지만, transaction data interface에서만 적용될 수 있는 새로운 개념들을 몇 가지 배울 것이다. Interface 과정에서 master data와 transaction data 간의 주요한 차이점은 output을 발생시키는가 하는 것이다. master data는 change pointer와 같은 구조체계를 가지고 있으며, 또한 필요한 시점에 자료를 송신할 수 있는 능력이 있는 반면에, SD와 MM같은 업무영역에 속하는 transaction data는 message control과 output determination에 그 기반을 두고 있다. 몇몇 다른 업무영역에서는 특별한 별도 프로그램을 이용하여 output을 생성(IDOC을 생성)하기도 한다. 이 장에서는 inbound interface와 outbound interface 모두에 필요한 여러 단계의 설정들을 보여줄 것이다. 여기서 설명하는, 이러한 interface들에 대한 설정사항은 외부의 non-R/3 시스템과의 통신을 위한 설정들이지만, 우리가 이전 장에서 배운 설정들을 기초로 하면, R/3와 R/3를 연결하기 위한 설정도 마찬가지로 간단하게 처리할 수 있다.

3.2 Outbound Interface

앞에서 언급한 것처럼, 우리는 먼저 outbound 구매주문(purchase order)을 프로토타입(prototype)해 볼 것이다. 이 구매주문(purchase order)은 Material Management(MM) module 내에 있는 ‘구매(purchasing)’ 업무영역의 기능이다. 우리는 message control과 output determination을 설정하여, 구매주문(purchase order)에 변동사항(생성, 변경, 구매품목 삭제)이 발생하면, IDOC type ORDERS05라는 구매주문(purchase order) IDOC을 생성해 주는 output이 생성될 수 있도록 할 것이다. 이 message type은 ORDERS이고, 이와 관련된 process code는 ME10이다.

3.2.1 Logical System의 관리

이전 장에서 설명한 절차에 따라, 우리가 구매주문(purchase order)을 전달하고자 하는 외부시스템을 나타내는 새로운 logical system을 생성하라. 이 logical system을 “ZPOCHG0001”이라고 하자. 이 시스템은 외부시스템을 대표하는 수신시스템이고, 반면에 FSTCLNT100은 우리가 이전의 장에서 생성하고, 할당한 송신시스템이다. 다른 message type을 전송하고자 할 때도 이전에 생성된 logical system을 그대로 사용할 수 있다는 것에 주의하기 바란다. 하지만 보다 더 이해를 쉽게 하고, 혼란을 사전에 방지하기 위해서, 프로토타입(prototype)하는 각각의 업무 영역에 대하여 우리는 새로운 logical system을 사용하도록 하겠다.

3.2.2 Customer Distribution Model의 설정

customer distribution model을 생성하고 관리하기 위해서는 transaction BD64을 이용하라. 우리는 여기서 새로운 model, 즉 “POMODEL001 을 생성하고, base logical system FSTCLNT100이 logical system ZPOCHG001로 message type ORDERS를 전송하게끔 한다. 우리가 여기서 사용할 수 있는 filter object type이 두 개 있는데, EBELN(구매주문 번호)와 LIFNR(구매처 번호)가 그것이다. 혹시 필요할지 모르겠지만, 특정 구매처(vendor)에 대하여 logical system과 port가 별도로 구분되어 있고, 그 구매처(vendor)에 대한 구매주문(purchase order) IDOC을 그 logical system으로 송신하고자 한다면, LIFNR을 filter object로 사용할 수 있다. 우리는 여기서 단순히 그 filter object에 값만 입력하여 지정함으로써, 해당 구매처(vendor)에 대한 구매주문(purchase order)을 구분할 수 있다. 우리는 동일한 logical system이나 또는 다른 logical system에서 다른 종류의 message type을 전송하고자 할 때도, 동일한 customer distribution model을 사용할 수 있다는 사실에 주의하기 바란다.

3.2.3 Port의 정의

transaction WE21을 사용하여, 구매주문(purchase order) IDOC에 대하여 file이 생성되도록 file port를 생성하도록 하자. port이름은 “POPORT0001”이라고 부르자. [Outbound file] 탭에 있는 parameter에서 directory path와 file이름 또는 file 이름형식을 지정하라. port를 정의하는 동안에 [Access test] 버튼을 이용하여 해당 server로 ping이 되는 지를 확인함으로써, 지정된 directory와 server에 접근할 수 있는지를 확인하라. 필요하다면, logical RFC destinatio에 있는 shell script를 호출하기 위해서 [Outbound : trigger] 탭에서 command file에 대한 항목을 정의할 수도 있다. 이 기능은 원격지 server 상에 있는 FTP 프로세서를 구동해야 할 필요가 있을 때 특별히 유용하다. 여러분은 transaction SM59을 사용하여 RFC destination을 정의할 수 있다. 여기서 우리가 정의한 port는 다음 단계에서 우리가 설정할 partner profile에서 참조될 것이다.

3.2.4 Output Determination

Message Control은 SD와 MM 업무영역에서 구매주문(purchase order), 송장(invoice), 납품 문서(delivery note), 선적통지(shipment notification) 등과 같은 output 문서에 대하여 생성조건, 시기(timing), 매체(medium) 등을 결정해 준다. Output determination이란 condition table, access sequence, output type, output determination procedure, condition record와 같은 application object와 개념들이 복잡하게 서로 연결되어 있는 것이다. 우리는 구매주문(purchase order)에서 사용할 message control을 설정하기 위해서 거쳐야 하는 여러 가지 단계들을 하나씩 처리해 갈 것이다. [그림 3-1]을 참조하라.

3.2.5 Partner Profile의 관리

우리가 앞에서 배운 것처럼, 외부시스템에 대한 식별자(Identifier) 역할을 하는 partner profile을 설정할 필요가 있다. partner profile에는 ALE interface에 대한 여러 가지 설정항목들이 함께 포함되어 있으며, 통신을 위한 접근경로(Gateway)의 역할을 한다. SD와 MM에서 transaction data를 interface하는 경우에는, 우리가 앞에서 설정했던 output determination과 함께 추가적인 parameter를 정의해야 한다.

먼저, logical system ZPOCHG001, partner Type LS에 대한 partner profile을 생성하라. 이렇게 하기 위해서 다음 작업들을 수행한다.

3.2.6 Interface 작동

구매주문(purchase order) outbound IDOC을 생성하기 위해서 필요한 모든 설정을 완료했기 때문에, 이제는 interface를 테스트해보는 흥미로운 작업를 진행해 나갈 것이다. 이러한 작업은 세 가지 단계로 이루어진다.

1. 구매주문(purchase order)을 생성하거나 수정한다. output type ZNEU에 대하여 output(message)이 생성되어 있는지를 확인하라.

2. IDOC을 생성하기 위해서 앞에서 생성된 output을 처리한다.

3. 생성된 IDOC을 외부시스템으로 전송한다.

구매주문(purchase order)을 생성하기 위해서는 transaction ME21N을 사용하거나, SAP의 시작메뉴 [Logistics] à [Material Management] à [Purchasing] à [Purchasing Order] à [Create] à [Vendor/Supplying Plant Known]을 실행한다. 또한 여러분은 transaction ME25(Vendor unknown)을 사용할 수도 있다. 구매주문(purchase order)을 생성할 때는 message control에서 지정한 그 Document Type을 사용한다. 다른 말로 하면, output determination 설정에서 condition record를 생성할 때 사용된 구매주문(purchase order)의 Document Type을 사용한다. 구매주문(purchase order)에 대하여 자재 번호, 물량, plant, storage location, 단가, 기타 이와 유사한 것들을 입력한다. 이때 구매품목(line item)이 accept되었는지를 반드시 확인할 필요가 있다. output record가 생성되었는지를 확인하기 위해서는 다음 작업을 수행한다. [그림 3-14]를 참조하라.

3.3 Inbound Interface

이 절에서 우리는 inbound interface를 프로토타입(prototype)할 것인데, 그 내용은 외부 창고관리 시스템(Warehouse Management System)에서 SAP R/3의 재고관리(Inventory Management) module로 자재이동(goods movement)에 대한 transaction을 interface하는 것이다. 여기에서 사용되는 ALE message type은 WMMBXY이고, 이에 대응되는 IDOC type은 WMMBID02이다. 이러한 기능은 원래 창고재고에 대한 mobile data를 SAP에 있는 Warehouse 시스템으로 입력하기 위해서 만들어 졌다. mobile terminal에 자료가 입력됨과 동시에, 외부 소프트웨어가 그 자료를 지정된 server로 전송하면, 그기서 그 자료를 IDOC 형태로 변환하고, 이를 tRFC을 사용하여 SAP R/3안으로 전송하여 application에 반영하는 것이다. 여러분이 이해하고 있는 것처럼, ALE는 transactional RFC 연결(connection)을 사용하여, 외부시스템이나 다른 R/3 시스템에 대하여 실시간(real-time)이나 준 실시간(real-time) 형태로 자료를 interface할 수 있는 능력을 가지고 있다. 여기서 설정하고, 테스트할 자재이동(goods movement) interface는 여러분의 요구사항에 따라 여러 가지 다른 방식으로 설정될 수 있을 것이다. WMMBXY는 강력한 message type으로써, 많은 종류의 이동유형(movement type)과 자재이동(goods movement)을 처리해 주는 transaction들을 지원해 주는데, 여기에는 구매주문(purchase order)을 이용한 자재입고, 구매주문(purchase order)을 이용하지 않는 자재입고, 생산지시(production order)에 대한 자재입고, 재고 손실/이익 발생, 재고 상태 변동(inventory status change)과 같은 것들을 처리해 주는 transaction들이 모두 포함되어 있으며, 또한 여기에 한정되지 않는다.

3.3.1 Logical System의 관리

외부시스템을 나타내는 logical system을 생성한다. 이 경우 외부시스템을 나타내는 logical system은 송신시스템이 되고, 반면에 base logical system(FSTCLNT100)은 수신시스템이 될 것이다. 이렇게 하기 위해서는 다음 작업들을 수행한다.

n transaction SALE à [Sending and Receiving Systems] à [Logical Systems] à [Define Logical System]을 실행한다(이 작업은 client-independent한 사항이다).

n [New entries] 버튼을 누른다.

n [Logical system] 필드에 “GOODSMVT01”와 같이 logical system 이름을 입력하고, 설명을 입력한다.

n 자료를 저장한다.

3.3.2 Partner Profile의 관리

절차상 다음 단계는 우리가 설정한 logical system에 근거하여 외부시스템에 대한 partner profile을 생성하는 것이다. 이 partner profile은 여러 가지 ALE object들과 설정사항들을 한데 묶어 주고, 통신경로(gateway)를 제공해 준다. 우리의 예제에서는 message control과 outbound parameter가 필요하지 않으므로, inbound parameter만 설정하기로 한다. 여러분은 여러 개의 inbound message와 outbound message에 대하여 하나의 partner profile(그리고 하나의 logical system)만 사용할 수 있다는 것을 유념해야 한다. 다음에 제시된 절차를 따르기 바란다([그림 3-15]를 참조하라).

3.3.3 Interface 작동

interface에 대한 ALE 설정이 완료되었으므로, 이제는 그것을 테스트해보는 흥미로운 작업을 시작하겠다. outbound interface의 경우에는 SAP 내에 자료가 이미 있거나, 최소한의 노력으로 자료를 생성할 수 있으므로, 설정내용을 테스트해보는 것이 아주 용이했다. 하지만 inbound ALE interface의 경우는 IDOC을 생성해서 SAP 안으로 전송하는 추가적인 작업를 해야 한다. 테스트와 프로토타입핑(prototyping) 목적을 위해서, 간단한 ABAP/4 프로그램을 작성하여 file형태의 IDOC를 생성해 내고, 이것을 정상적인 방법으로 SAP 안으로 전송하면, 이러한 목적을 간단히 달성할 수 있다. Interface를 프로토타입(prototype)한 다음에는, 외부시스템의 record layout과 IDOC type을 비교하여 mapping 문서를 만들어 내는 것이 매우 중요하다. 외부시스템의 record를 IDOC으로 변환시켜주는 mapping 도구이나 translator 소프트웨어를 사용할 수도 있다. ALE/EDI interface에 대하여 SAP에서 인증 받은(certified) mapping 소프트웨어제품들이 많이 있다. 이들 제품들은 또한 외부시스템을 R/3 시스템과 연결시켜주는 ‘ALE Adapter’ 기능을 가지고 있어서, 외부시스템과 R/3 시스템 간의 interface을 완벽하게 처리해 줄 수도 있다. 우리는 mapping 도구의 역할에 대하여 제 6장에서 논의할 것이다.

Chapter 4 ALE Enhancement: IDOC Extension과 Reduction

4.1 개요

지금까지 진행해 온 과정을 통하여, 우리는 ALE 방식으로 master data interface와 transaction data interface를 프로토타입(prototype)하는데 익숙해졌기 때문에, 이제는 ALE 기능을 enhance하는데 필요한 여러 가지 기법들에 대하여 주의를 돌려 보기로 하겠다. 특정 application 영역에서 사용되는 ALE interface를 프로토타입(prototype)해 본 후에 그 결과를 검토해 보면, SAP가 기본적으로 제공해 주는 기능이 여러분의 요구사항을 충분히 만족시키지 못하고, 원하는 결과와 일정한 정도의 GAP이 존재하는 경우가 있을 수 있을 것이다. 이런 경우에 여러분은 IDOC과 관련된 ALE function module에 기능을 추가할 수 있다. 예를 들어, outbound interface에서 전송되는 IDOC type이 여러분이 외부시스템으로 전달하고자 하는 모든 자료를 포함하고 있지 않다는 사실을 발견하는 경우, 여러분은 ‘IDOC extension’이라는 방법을 사용하여 추가 field를 포함시키고, ALE function module을 enhance하여 그 추가된 field에 대하여 값을 보충할 수가 있다. 이와 유사하게, inbound interface에서 추가 field를 R/3 application에 반영해야 한다면, 여러분은 역시 IDOC type을 확장(extend)하여 외부시스템이나 translator, 또는 다른 R/3 시스템이 자료를 보충하여 전송할 수 있도록 하고, inbound ALE function module을 enhance하여 추가된 자료를 R/3의 application에 반영할 수가 있다.

4.2 IDOC Extension

IDOC type DEBMAS05는 Customer Master 자료를 송수신하기 위해서 사용된다. 이 IDOC type을 정밀하게 검토해 보면(transaction WE60을 사용하라), 여러분은 그 속에 여러 개의 계층적인 segment들이 있고, 그 각각의 segment 안에 있는 field들에는 고객(customer)과 고객(customer)의 속성들을 설명해주는데 필요한, 거의 모든 자료가 포함되어 있다는 것을 알 수 있을 것이다. 하지만 SAP 내에서 Customer Master프로그램을 이용하여(transaction XD01—Create, XD02—Change, XD03–Display), 고객(customer) 정보, 특히 customer contact person 화면([그림 4-1]을 참조하라)에 있는 정보를 변경해 보면, SAP application에는 contact person의 business address를 입력하여 저장할 수 있는 화면이 있지만([그림 4-2]를 참조하라), IDOC type DEBMAS05에는 contact person의 business address자료를 주고 받을 수 있는 segment나 field가 없다는 것을 인식하게 될 것이다. 이런 경우, 여러분의 업무 상의 필요에 따라 Customer Master에 있는 이러한 business address가 ALE interface를 통하여 다른 시스템으로 전송되어야 한다면, 그때 우리는 DEBMAS05 IDOC type을 extend하고, 그에 대응되는 ALE function module을 enhance해야 한다.

4.2.1 새로운 Segment와 Extension Type의 생성

먼저 table ADRC에 있는 field들 중에서 우리의 새로운 segment Z1ADRCX에 추가하고자 하는 field를 결정하자. 우리는 name, street, city, region, 그리고 country에 대한 field를 추가하고자 한다. contact person의 business address을 구성하는 이러한 기본적인 field에 추가하여, address number를 파악하기 위한 몇 개의 field를 추가하고자 한다. ADRNR은 address 자체를 식별해주는 고유한 key로서, table ADRC와 같은 SAP table 상에 있는 field이다. 이 field는 다른 table에서 address에 대한 전체의 내용을 얻기 위해서 table ADRC을 참조할 때도 상호 참조된다. 여기서 정의되는 segment는 master data에 대한 IDOC type에 있는 segment이기 때문에, 새로운 segment의 처음 field로 MSGFN(message function)을 사용할 것이다. Message function field는 수신시스템에게 그 segment에 대하여 어떠한 조치를 취해야 하는지를 알려주는 역할을 한다(더 상세한 내용에 대해서는 제 2장을 참조하기 바란다). 새로운 segment에 값을 보충해 주기 위해서 앞으로 우리가 작성할 프로그램 코드를 보면 알 수 있겠지만, 이 새로운 segment에 있는 message function의 값은 parent segment인 E1KNVKM의 그것과 동일하다. 결국 segment Z1ADRCX에는 모두 합하여 11개 field가 들어가도록 할 것이다. 그 field들에 대한 상세내용에 대해서는 [표 4-1]을 참조하기 바란다.

4.2.2 IDOC Type을 Message Type에 연결하기

다음 단계는 앞에서 우리가 생성한 새로운 IDOC type을 그에 대응되는 message type에 연결하는 것이다. 이러한 연결관계는 partner profile에 있는 parameter에서 특정 상대시스템에 대하여 사용될 message type과 IDOC type을 지정해 줄 때 참조되기 때문에, 이 연결작업은 매우 중요하다. message type을 연결하기 위해서는 다음 작업들을 수행한다. [그림 4-7]을 참조하라.

4.2.3 IDOC Extension Type 점검

extension type이 일관성(consistency)있게 정의되어 있는지를 점검하기 전에, 반드시 그 extension type을 ‘release’하는 것이 매우 중요하다. 이렇게 하기 위해서는 다음 작업들을 수행한다.

n transaction WE30을 실행을 실행하거나, transaction WEDI à [Development] à [IDOC Types]을 실행한다.

n [Object name] 필드에 “ZDEBMASX”를 입력하고, “Extension type” 선택버튼을 선택한다.

n 메뉴 [Edit] à [Set Release]를 실행한다.

n release할 것인지를 물어오는 팝업화면이 나타나면, [Yes] 버튼을 누른다.

n 이제 extension type이 release되었다.

4.3 ALE Function Module의 Enhancement

지금까지 inbound와 outbound 업무영역에서 사용될 IDOC에 추가 field를 포함시키기 위해서 IDOC type을 extend했으므로, 이제는 outbound인 경우에는 추가된 segment에 자료를 보충해 주고, inbound인 경우에는 추가된 segment자료를 application에 반영해 주는 ALE function module의 enhancement 작업을 진행해 보기로 한다. 여러분이 application과 주고 받는 IDOC 자료를 수정할 필요가 있는 경우에는, IDOC extension이 발생하지 않은 상황에서도 ALE function module을 enhance해야 할 필요가 있을 수도 있다는 것을 유념하기 바란다. 여기서 논의되는 접근방식은 위의 어느 경우에나 적용될 수 있는 것이다.

4.3.1 Transaction CMOD를 이용한 Project생성

우리가 SAP enhancement와 그 component를 사용할 때는, Project라고 불리는 SAP object를 이용하여 이들을 관리해야 하는데, 이것은 선택된 enhancement와 그 속에 있는 component들을 내부적으로 관리해 주는 포장자(envelope)과 같은 것으로서, component들의 실행 여부를 통제할 수 있도록 해주고, CTS를 통하여 SAP 내에 있는 다른 instance/client로 전송할 수 있도록 해준다. 기본적으로 이 작업과정에는 project를 생성하고, 원하는 enhancement와 component를 포함시키고, component를 편집하고, 그 다음으로 project를 활성화(activate) 하는 작업이 포함되어 있다. IDOC extension에 대한 우리의 예제인 Customer Master IDOC에 대하여 project를 생성하는 작업를 진행해 보자. [그림 4-10]을 참조하라.

4.3.2 Customer Function Enhancements

이전에 언급한 것처럼, customer function(function exit)은 ALE function module에 삽입되어, outbound에서 있어서는 IDOC의 생성과 변경에 영향을 주고, inbound인 경우는 추가되거나 변경된 IDOC 자료를 R/3 application에 반영하기 위해서 사용할 수 있다. 이러한 function module은 일반 function module과 비슷하며, import/export parameter, table(internal table) parameter, exception parameter를 가지고 있다. customer function을 개발하는 과정에서 고려해야 할 두 가지의 중요한 요소는 (1) ALE function module에서 function exit이 발생하는 시점과 (2) IDOC의 방향에 따라(inbound/outbound), outbound에서는 IDOC 생성시에 추가 보충되거나 변경되어야 하고, inbound에서는 R/3 application에 추가적으로 반영되어야 할, 해당 자료를 customer function에서 사용할 수 있는가 하는 것이다. 여러 개의 customer function을 가지고 있는 function module이 있기 때문에, 우리가 원하는 특정 enhancement에 꼭 맞는 적절한 function exit을 선택하는 것이 매우 중요하다. function exit이 원래 의도했던 목적이 아닌 다른 목적에 function exit을 사용하려고 시도하지 않기를 바란다.

4.4 IDOC Reduction

우리가 다른 시스템, 즉 다른 R/3 시스템이나 외부시스템으로 master data를 분배하거나 송수신할 때, 통신 경로를 통하여 실제로 전송되는 자료의 양이 매우 대량일 수가 있다. 이러한 경우 처리성능에 문제가 발생할 수 있고, 디스크 공간이나 전송대역폭과 같은 자원을 과도하게 사용할 가능성도 있다. master data에 대한 Basic IDOC type을 면밀히 검토해 보면, 많은 segment자료들이 서로 중복되거나, 또는 전혀 사용되지 않을 수도 있다. 이러한 경우에, 이 IDOC은 IDOC Reduction이라고 불리는 기법을 적용할 수 있는 좋은 대상이 된다. R/3는 Basic IDOC type에서 사용되지 않는 segment나 segment 중에서 필요 없는 field를 제거할 수 있는 기능을 우리에게 제공해 준다. 이것을 적용하는 절차는 상대적으로 간단하고, 적용하기가 매우 쉽다. IDOC reduction은 단지 몇 개의 message type에서만 적용할 수 있는데, message type DEBMAS, CREMAS, GLMAST, MATMAS, 그리고 일부 POS message들이 그기에 해당한다.

Chapter 5 새로운 Basic IDOC Type과 ALE기능 생성하기

5.1 개요

앞에서 언급한 것처럼, R/3 시스템에는 ALE와 EDI interface에서 사용될 수 있는 message type이 수백 개 제공되고 있다. 이러한 message type들은 R/3 시스템의 전체 application module에 걸쳐 있고, 대부분의 업무영역에서 ALE/EDI 기능이 지원된다. 하지만 ALE/EDI 기능이 지원되지 않는 업무영역도 존재하며, 이러한 곳에서는 완전히 새로운 ALE/EDI 기능을 구축할 수가 있다. 이 절에서는, SAP의 ALE 기능이 지원되지 않는 master data application 영역 중의 하나인 SD의 Customer Hierarchy를 예로 들어 설명하기로 한다. Customer Hierarchy는 어떤 회사의 고객에 관한 조직자료나 계층구조를 표현하고자 할 때 사용된다. 예를 들면, 어떤 회사가 고객의 상점에 제품을 배송하고 판매하는 경우에, customer/sales organization/distribution channel/division의 조합에 근거하여 그 고객에 대한 조직 구조와 보고체계에 대한 정보를 구축할 필요가 있을 수도 있다. 이러한 각각의 조합은 hierarchy node로서 간주되고, 이는 다른 hierarchy node에 지정(assign)되며, 이렇게 해서 hierarchy chain을 구성하게 되는 것이다. 이러한 지정(assignment)은 또한 그 node에 대한 partner function에 근거를 두고 있는데, 이들 각각의 지정은 유효 기간을 가지고 있다. SAP에서는 미래일자로 지정하거나, 여러 개를 동시에 중첩하여 지정하는 것을 포함하여, 복잡한 chain과 연관관계를 구축할 수 있다. Customer Hierarchy는 transaction VDH1을 통해서 관리할 수 있고, transaction VDH2를 이용하여 조회할 수 있다.

5.2 새로운 Basic IDOC Type 생성하기

우리가 알고 있는 것처럼, IDOC type은 R/3에서 application 자료를 송수신하기 위해서 사용하는 지능적인 data container이다. 새로운 Basic IDOC type을 구축하기 위해서는, 그 application object에 대한 다양한 자료항목들이 포함될 IDOC segment를 정의해야 하고, 그러기 위해서는 그 application을 면밀히 검토해야 한다. SD Customer Hierarchy의 경우는, 하나의 table KNVH를 이용하여, 고객들과 hierarchy node들 간의 계층적인 관계를 모두 표현하고 있다는 것을 발견하게 될 것이다. customer hierarchy node에 대한 기본 자료들은 Customer Master table에 저장되어 있고, 이들은 SAP가 제공하는 IDOC type인 DEBMAS05와 message type DEBMAS를 이용하여 다른 시스템으로 전송될 수 있다. table KNVH는 16개의 field로 구성되어 있는데, 이들은 hierarchy type, 유효기간 시작(start of validity), 유효기간 종료(end of validity), 상위의 고객, sales organization, distribution channel, division, rebate와 pricing을 위한 구분자, hierarchy level number등이다. Customer Hierarchy를 잘 이해하게 되면, table KNVH의 구조가 그 자체로 customer node들 간의 계층적인 연관관계를 완벽하게 표현하고 있다는 것을 알 수 있을 것이다. 이러한 정보 이외에, 우리는 Customer Hierarchy에 변경을 가한 작업의 종류를 나타내는 “message function” field를 segment에 추가할 필요가 있다.

5.3 새로운 Message Type 생성하기

다음 단계는 새로운 message type을 생성하는 것이다. message 기반 구조(message-based-architecture)인 ALE에서, Message Type은 IDOC interface를 통해서 송수신되는 정보의 종류를 나타낸다. 우리는 SD Customer Hierarchy Master 자료를 나타내는 새로운 message type을 정의하고, 이미 우리가 생성한 IDOC type과 이것을 연결시켜야 한다. 이 message type은 나중에 우리가 생성할 ALE function module을 호출하기 위해서 사용될 것이다. 따라서, message type은 ALE interface에서 중요한 역할을 담당하고 있다. 이 단계의 작업을 진행해 보자. [그림 5-1]을 참조하라.

5.4 IDOC Type과 Message Type 연결하기

다음 단계는 우리가 생성한 두 개의 object인 Basic IDOC type과 message type을 서로 연결하여, 그 message type에 연결되어 있는, 앞으로 우리가 생성할 ALE function module이 IDOC segment에 정확한 application자료의 값을 채울 수 있도록 하는 것이다. 이것은 다음과 같은 작업을 통하여 쉽게 처리할 수 있다. [그림 5-2]를 참조하라.

n transaction WE82을 실행하거나 transaction WEDI à [Development] à [IDOC Type / Message]을 실행한다.

n [Display ßà CHANGE] 버튼을 눌러 변경화면으로 전환한다.

n 화면 위에 있는 [New entries] 버튼을 누른다.

n [Message type] 필드에 “ZDEBHI”를 입력하고, [Basic IDOC type] 필드에는 “ZKNVHM01”을 입력한다. [Extension type] 필드는 공란으로 둔다. [Release] 필드에는 여러분의 SAP release 번호를 입력한다.

5.5 Change Document Object/Update function module 생성

Change Document Object는 R/3 시스템에서 master data, table, application object에서 발생하는 변경사항을 포착해 낸다. SAP는 시스템 내에서 수 백개 정도의 object에 대하여 변경사항을 포착해 낼 수 있을 정도로 change document service를 광범위하게 사용하고 있는데, 이러한 서비스는 change document object와 Change Document Update Function Module/Program이라고 알려진 구성요소를 통하여 이루어진다. CD(change document) object에 근거한 change document는 table CDHDR(CD header정보)와 CDPOS(CD detail정보)에 저장된다. 대부분의 change document는 변경사항에 대한 정보를 field수준까지 기록해 준다. Change document는 table name과 field name 이외에, 입력, 변경, 삭제와 같은 변경의 성격에 대한 정보뿐만 아니라, table에 대한 key정보를 동시에 저장하고 있다. 앞에서 우리가 배웠듯이, ALE는 change pointer라고 알려진 object를 이용하여, master data에서 발생하는 변경사항을 포착하기 위해서 shared master data(SMD)를 통하여 change document service를 이용한다. table BDCP와 table BDCPS에 저장되어 있는 change pointer는 실제로 application의 change document update function module에 의해서 생성된 change document를 가리키고 있다. ALE API는 이러한 정보를 수집하고, 그 table에 대한 key값과 변경 유형에 따라 IDOC segment를 생성해 낸다. 이렇게 해서 생성된 IDOC이 통신 계층(communication layer)를 통하여 분배되는 것이다.

5.6 SAP Application 프로그램 Enhancement

우리가 생성한 function module KUNHIER_WRITE_DOCUMENT은 실제로 Customer Hierarchy 자료를 관리하는 SAP application 프로그램과 하나로 통합될 필요가 있다. transaction VDH1(maintenance)와 VDH2에 의해서 호출되는 프로그램 RVKNVH00 이 Customer Hierarchy자료를 처리하는 과정에서, 적절한 시점에 그 update function module을 호출하도록 해야 한다. 프로그램 RVKNVH00을 살펴보면, SAP가 VDH1의 해당 session에서 발생한 변경사항을 table KNVH에 갱신해주는 function module CUSTOMER_HIERARCHY_UPDATE을 호출한 직후에, 이 update function module을 호출할 수 있다는 것을 알 수 있다. 여러분은 이 호출이 “IN UPDATE TASK” 방식으로 처리되고 있고, 또한 우리의 update function module도 “IN UPDATE TASK” 방식으로 처리할 필요가 있다는 것에 주의하라. 프로그램 RVKNVH00 은 두 개의 internal table XVKNVH와 YVKNVH를 이용하여 customer hierarchy 자료에 대한 새로운 자료와 이전 자료를 보관하고 있다. 우리는 update function module을 호출하여 table CDHDR과 CDPOS를 갱신하기 위해서 이 두 개의 internal table을 이용할 것이다.

5.7 ALE Function Module의 생성

Customer Hierarchy에 대하여 change document를 생성해 낼 수 있도록 SAP application프로그램을 enhance 했으므로, 이제는 Customer Hierarchy와 관련된 change pointer를 읽어서, 우리가 이미 생성한 IDOC type ZKNVHM01에 값을 채워서 IDOC을 생성해 내는 ALE function module을 작성할 필요가 있다. 대부분의 master data에 대한 ALE function module은 표준적인 접근방식을 따르고 있는데, 이들은 먼저 필요한 자료를 수집하고, IDOC이 필요로 하는 값을 채워서 IDOC을 만들고, 만들어진 IDOC을 분배하는 절차를 거친다. 먼저, 특정 message type에 대해서 아직까지 처리되지 않은 모든 change pointer자료를 수집하고, 그 각각에 대하여 key값을 찾아서 internal table로 만들어 주는 표준 function module이 있다. 이렇게 해서 생성된 internal table은 다른 function module로 전달되어, 그에 대응하는 IDOC type에서 필요로 하는 값을 결정하여 IDOC을 생성하게 되고, 이렇게 생성된 IDOC은 표준 ALE function module을 사용하여 통신계층(communication layer)으로 전송되는 것이다.

5.8 Change Pointer 생성 활성화(Activation)와 기타 ALE 설정사항

앞에서 우리는 SAP application 프로그램에서 change document를 생성해 내는 프로그램 코드를 작성하는 방법에 대하여 배웠다. ALE 목적상, 이러한 change document field에 대하여 change pointer가 생성되도록 처리되어야 한다. 더 나아가, 우리는 IDOC field를 change document field에 할당해야 한다. 또한 앞에서 설명한 것처럼, 우리가 생성한 message type을 그에 대응되는 ALE function module과 연결시켜서, RBDMIDOC과 같은 프로그램이 실행될 때, 우리가 생성한 function module이 호출되어 IDOC을 생성하고 분배해 줄 수 있도록 해야 한다. 이를 위해 우리는 다음 세 가지 항목을 설정해야 한다.

1. change document field에 대하여 change pointer가 생성되도록 활성화(activate)한다.

2. IDOC field를 change document field에 할당한다.

3. function module을 message type에 연결한다.

5.9 Interface 작동

우리가 여기서 하는 작업은, Customer Hierarchy와 관련하여 우리가 구축하고 연결시킨 모든 구성요소들이 원래 의도했던 대로 정확하게 작동하여, master data상에 발생하는 변동사항에 근거하여 IDOC을 생성해 내는지를 점검하는 것이다. 새로운 Basic IDOC type이 생성되었고, 새로운 message type이 그것에 연결되었다. 기존에 이미 존재하는 change document object에 근거하여 change document update function module을 생성하고, SAP의 application 프로그램에 그것을 삽입하였다. 새로운 message type에 대한 change pointer 정보를 수집하고, IDOC을 생성하여 분배해 주는 기능을 가진 두 개의 ALE function module이 작성되었다. IDOC segment field와 change document field를 연결시키는 설정과 함께, change document field에 대하여 change pointer가 생성될 수 있도록 활성화(activate)하는 ALE 설정이 이루어졌다. 우리는 실제 구동되는 ALE function module을 새로운 message type과 연결시켜, change pointer가 처리될 때 호출될 수 있도록 하였다. 마지막으로, 우리는 logical system, customer distribution model, port, partner profile, change pointer 활성화(activation)에 대하여 정의하고, 서로 연결함으로써, ALE 설정을 완료하였다.

Chapter 6 EDI(Electronic Data Interchange)

6.1 개요

Electronic Data Interchange(EDI)는 특정 기업이 은행이나 고객, 구매처와 같은 그들의 거래 상대방들과 업무문서를 서로 주고 받을 수 있는 능력을 제공해 주는 기술이다. 이러한 전자문서 Format은 EDIFACT와 ANSI X12와 같은 EDI 산업표준에 의해서 결정된다. EDI는 업무들 간의 상호 연결성을 상당히 향상시켜 주고, 업무 프로세스를 자동화하여, 빠르게 회전할 수 있도록 해 준다. SAP R/3는 R/3 의 다른 application들과 완전히 통합되어 있는 완전한 EDI system을 고객들에게 제공해 준다. 예를 들어, 특정 회사는 자기 고객들에게 EDI 대금청구서(invoice)를 보낼 수 있으며, 구매처(vendor)/고객(customer)과 구매주문(purchase order)/판매주문(sales order)을 주고 받을 수 있으며, 거래하는 구매처(vendor)로부터 납품통지(dispatch advice)를 수신할 수 있고, 거래 은행과 송금통지(remittance advice)를 교환할 수 있다(예제 시나리오에 대해서는 이 책의 도입부를 참조하기 바란다). 사실 그 회사의 거래 상대방과 주고 받는 업무 문서 중에서 비록 전부는 아닐지라도, 거의 대부분에 대하여 EDI를 구축할 수 있다.

6.2 Output Determination 설정

SD와 MM module에서 message(output) determination은 output 생성여부를 결정하고, 그 output에 대하여 매체(medium), 시점(timing), 유형(type) 등과 같은 세부사항을 결정하기 위해서 condition technique을 사용한다. 이 output은 SD와 MM module에서 transaction data에 근거하여 output 문서를 생성해 내는데 사용된다. output determination 설정에는 일반적으로 condition table, access sequence, output type, output determination procedure, 그리고 output procedure assignment에 대한 준비작업 등이 포함되어 있다. SAP는 대부분의 경우에 사용할 수 있는 condition table과 access sequence를 기본적으로 제공해 주고 있으며, SAP가 제공하는 output type들을 사용하면 table NAST에 원하는 output record를 생성하고자 하는 요구사항을 대부분 충족시켜 줄 것이다. 하지만 새로운 요소들을 만들어서 동일한 작업을 처리할 수도 있다. 다음은 output determination을 설정하는데 필요한 여러 단계들이다.

6.3 Port와 Partner Profile설정

우리는 application에서 output determination 설정을 완료했기 때문에, 이제 EDI에 대한 기술적인 설정을 진행해 보기로 하자. 이러한 작업에는 port정의, partner profile 생성, external partner number에 대한 상호참조를 위하여 table EDPAR에 자료를 입력하는 작업 등이 여기에 포함되어 있다.

6.3.1 EDI Subsystem 호출과 Output Mode

outbound 시나리오에서 SAP port와 EDI subsystem 간의 통신에 대한 기본개념을 이해해 보자. port 정의에서 우리가 처리한 설정사항은 file이 전송되는(생성되는) 시점, file이 생성되는 위치, file 이름 등을 동기식 RFC(synchronous RFC)를 통하여 EDI subsystem에게 알려주는 역할을 한다. SAP는 이미 동일한 이름의 file이 있으면, 기존의 IDOC file에 새로운 자료를 append하지 않고 기존 자료를 덮어 쒸우기 때문에, 동적인 file 이름(dynamic file name)을 사용하는 것이 좋다. 이러한 동적인 파일 이름을 사용하게 되면, outbound port 정의에서 지정된 function module에 따라 원하는 형태의 file이름이 생성될 수 있다.

6.4 Interface 작동

우리는 outbound EDI 대금청구서(invoice, ANSI X12 “810”)에 대하여 필요한 설정을 모두 완료했기 때문에, 이제 IDOC을 생성하고, 그들을 EDI subsystem으로 전송하는 테스트 작업을 해보자. 이 작업을 완료하기 위해서, 먼저 우리는 특정 고객(customer), 임의의 자재(material)와 수량으로 판매주문(sales order)(transaction VA01)을 하나 생성한다. 그 다음으로 그 판매주문(sales order)에 대하여 납품(delivery, transaction VL01)을 생성한다. 납품 품목(delivery item)에 대하여 picking 작업을 완료하고 “post goods issue”를 처리한다. transaction VF01을 실행하여, 앞에서 우리가 생성한 납품 번호(delivery number)에 대하여 대금청구 문서(billing document)를 생성한다. 일단 transaction VF01에서 SD 문서, 즉 위의 납품 번호(delivery number)가 “processed” 상태가 되면, 대금청구 문서(billing document) 화면에서 메뉴 [Hearder] à [Output]으로 가라. 앞에서 우리가 설정한 대로, output type ZBIL에 대하여 output record가 생성되어 있는지를 점검하라. [그림 6-9]을 참조하라. 여러분은 output type ZBIL에 대하여, [Medium] 필드에는 “6”, [Partner function] 필드에는 “PY”, [Partner] 필드에는 payer의 고객 번호(customer number)가 지정되어 있고, output에 대한 status가 표시되어 있는 자료를 볼 수 있을 것이다. [Status] 필드는 세 가지 값을 가질 수 있다 : “0”은 아직 처리되지 않았음을 나타내고, “1”은 성공적으로 처리되었음을 나타내며, “2”는 처리되었지만 오류가 발생한 것을 나타낸다.

6.5 Mapping과 Mapping 도구

ALE나 EDI interface에서 성공을 좌우하는 중요한 항목은, outbound인 경우는 IDOC structure를 외부의 format에 정확히 mapping하고, inbound인 경우는 외부의 format을 IDOC structure에 정확히 mapping하는 것이다. 자료 mapping은 R/3와 서로 자료를 정확하게 주고 받는데 있어서 중요한 역할을 한다(물론 tRFC를 통한 R/3와 R/3 간의 ALE interface의 경우, IDOC에서 application으로의 자료변환은 SAP의 ALE function module에 의하여 자동적으로 실행된다). 사실 자료 mapping 작업은 개발과정에서 가장 중요한 부분으로, 프로젝트 진행과정상 프로토타입핑(prototyping)과 차이 분석(gap analysis) 단계에서 반드시 함께 실행해야 한다.

Chapter 7 주기적인 처리(Periodic Processing)

7.1 개요

지금까지 ALE/EDI interface에 필요한 설정과 구축작업을 완료했기 때문에, 여러분은 이제 그 interface를 실제의 운영환경에서 실행될 수 있도록 구현하고, interface에 대한 사후 보완작업을 할 수 있는 준비가 되었다. SAP는 ALE와 EDI interface를 실행하고 관리하는데 필요한, 다양한 기능을 수행해 주는 여러 가지 프로그램들을 기본적으로 제공해 주고 있다. 이러한 프로그램들은 scheduling job으로 만들어 주기적으로 실행할 수도 있고, 필요하다면, online으로 실행할 수도 있다. ALE와 EDI 프로그램들은, 다른 SAP 프로그램들과 마찬가지로, 적절한 variant를 사용하여 SAP의 job이나 job stream으로 만들 수 있다. 이 장은 inbound 처리, outbound 처리, 기타 기능으로 분류하여, 여러 가지 ALE/EDI 프로그램과 그들에 대한 사용법에 대하여 상세히 설명하고 있다. “기타”의 프로그램 중에는 tRFC/aRFC monitoring, ALE audit, 특정 ALE database table에 대한 정리(reorganization), IDOC 추적(trace), 기타의 기능을 제공해 주는 프로그램들이 있다.

7.2 Outbound 처리

ALE/EDI outbound처리에서 SAP가 기본적으로 제공하고 있는 기능 중의 하나는 IDOC을 생성해 주는 것인데, 여기에는 IDOC을 통하여 master data를 송신하고, 생성된 IDOC을 port로 보내고, 처리과정에서 오류가 발생하면 IDOC을 재처리하는 작업들이 포함되어 있다.

프로그램 RBDMIDOC은 change pointer에 근거하여 master data IDOC을 생성하기 위해서 사용된다. [그림 7-1]을 참조하라. 이 프로그램은 master data에 대한 message type을 유일한 parameter로 사용한다. 특정 message type에 대하여 이 프로그램을 실행하면, 그 message type에 대한 change pointer에 근거하여 IDOC을 생성해 내고, 수신시스템으로 IDOC을 전송해 준다. 앞에서 이야기한 것처럼, changer pointer란 SAP 시스템에 있는 특정 application자료에서 발생하는 변경사항을 기록해 주는 object이다. 수신시스템은 customer distribution model에 의해서 결정된다. 수신시스템을 나타내는 logical system에 대해서 유효한 partner profile이 정의되고, 그 outbound parameter에서 message type, 그에 대응되는 IDOC type, port 등에 대한 정보가 정확하게 정의되어 있어야 한다. 만약 여러분이 어떤 master data message type에 대하여 ‘IDOC reduction’을 위한 설정을 하고, 그것을 활성화(activate)하였다면, 이 프로그램을 이용하여 ‘reduction message type’에 대한 IDOC을 생성할 수도 있다는 것에 유의하라(제 4장에 있는 IDOC reduction을 보라). 프로그램 RBDMIDOC이 일단 지정된 message type에 대한 change pointer를 처리한 후에는, 그 change pointer를 “processed” flag로 표기한다. 여러분이 아는 것처럼, 이 flag는 table BDCPS에서 관리되고 있다. 그리고 난 다음, 이 프로그램은 생성된 ‘master IDOC’과 ‘communication IDOC’의 숫자에 대한 안내 메시지를 보여 줄 것이다. 실제로 생성된 communication IDOC의 숫자와 master IDOC의 숫자는 customer distribution model의 message flow에서 지정된 logical system과 filter object에 따라 서로 달라질 수 있다는 것에 유의하라. 이 프로그램은 transaction BD21를 사용하거나, transaction BALE à [Services] à [Change Pointers] à [Process]를 통해서도 실행할 수 있다. 프로그램 RBDMIDOC은, 지정된 message type에 대한 모든 change pointer를 모아서 IDOC이 한꺼번에 생성할 수 있도록 하기 위해서, scheduling job으로 만들어 주기적으로 실행할 수도 있다. 이 작업은 master data에서 발생하는 모든 변동사항을 다른 R/3 시스템이나 외부시스템으로 전송하여, 시스템들을 서로 동기화할 필요가 있는 경우에 더욱 유용하다.

7.3 Inbound 처리

SAP는, online에서 실행하거나 batch 방식으로 주기적으로 실행하여, inbound 처리를 용이하게 해주는 여러 가지 프로그램을 제공해 주고 있다. 이러한 기능에는 IDOC을 application에 반영하고, 오류상태인 IDOC을 재처리하고, 편집된 IDOC을 처리하는 프로그램들이 포함되어 있다.

프로그램 RSEINB00은 IDOC을 포함하고 있는 file을 SAP 시스템 내부로 전송하기 위해서 사용된다. 이 프로그램은 inbound IDOC이 text file에 포함되어 있는 경우에만 사용될 수 있다. RSEINB00은 path와 file name을 입력할 수 있는 단 하나의 parameter만 가지고 있다. IDOC을 내부로 전송하는 과정에서, 그 IDOC의 EDIDC record에서 partner number, message type, 기타 다른 모든 관련 control정보들이 수집된다. partner profile의 inbound parameter에 있는 처리방식(processing option)에서 선택된 값이 “Trigger by background program” 인지 “Trigger immediately”인지에 따라서, 오류가 없는 경우 status “64”의 상태로 생성되거나, 또는 생성과 동시에 즉시 application에 반영될 것이다. 오류가 발생하는 경우는 partner profile에서 지정한 수신자의 inbox로 workflow Item이 보내진다. transaction WE16을 이용해도 동일한 처리를 할 수 있다. [그림 7-7]을 참조하라.

7.4 기타의 ALE 프로그램

IDOC에 대한 inbound 처리와 outbound 처리를 위한 프로그램 이외에, ALE 처리과정에 대하여 여러 가지 사항을 알려주고, monitor할 수 있도록 해주고, 정리(reorganize)할 수 있게 해주는 등 다양한 중요 기능을 수행해 주는 프로그램들이 여러 가지 있다. 여기에는 RFC 실행에 대한 status 점검, audit confirmation, change pointer와 audit database의 정리(reorganization), ALE audit에 대한 통계적인 분석, 여러 시스템에 걸친 IDOC 처리결과 추적, tRFC와 aRFC 통신에 대한 monitoring 등을 위한 프로그램들이 포함되어 있다. 이러한 프로그램들은 실제의 운영환경에서 ALE interface를 유연하게 운영하는데 있어서 매우 중요한 역할을 하고, scheduling job으로 만들어 주기적으로 실행하면, ALE 처리상태를 보고받을 수 있고, 그 내용을 확인할 수 있다는 것을 인식하는 것이 중요하다.

Chapter 8 Workflow를 이용한 ALE와 EDI 오류처리

8.1 개요

우리는 ALE와 EDI interface를 준비하고, 여러가지 처리 프로그램을 scheduling하는데 필요한 작업들에 대하여 배웠기 때문에, 이제 오류 처리와 관리에 우리의 관심을 기울여 보자. ALE와 EDI에서는 Workflow라고 알려진 SAP 기술을 이용하여 오류를 손쉽게 처리할 수 있다. SAP의 Business Workflow는 여러 업무영역과 작업영역에 걸쳐서 고객의 고유한 업무 프로세스 흐름을 조정하고, 통제할 수 있도록 해주는 기술이다. 이 기술은 SAP R/3 시스템과 완전하게 통합되어 있으며, 표준 R/3 시스템에서 제공되는 application 기능들을 보완하기 위해서 version 3.0에서 처음 소개되었다. 예를 들어, 구매처(vendor)에 대한 지급문서(payment)를 release하는 과정이 Business Workflow에 대한 하나의 시나리오가 될 수 있다. 회계의 line item에서 payment block이 설정될 수 있다. 이렇게 되면, 사전에 정해진 일련의 작업절차들이 시작하게 하고 , 그렇게 하여 그 line item에 대해서 승인권한이 있는 담당자에게 그 지급문서(payment) 자료가 제시된다. 일단 승인이 나면, 그 지급문서(payment)는 다음 처리를 진행할 수 있도록 release된다. 이것은 R/3 내에서 설정할 수 있는 많은 Business Workflow 시나리오 중에서 아주 간단한 하나의 예이다. workflow 기능을 이용하여 ALE와 EDI의 오류를 처리하는 것은 SAP Business Workflow의 많은 기능 중에서 하나의 예에 불과하다. 이 장에서, 우리는 workflow를 이용한 ALE와 EDI 오류처리에 대해서만 초점을 맞출 것이며, ALE와 EDI에서의 오류처리를 위한 workflow 설정과 관련된 여러 가지 작업들에 대하여 배울 것이다. 설정을 해나가면서, 우리는 workflow의 개념과 용어에 대하여 익숙해 질것이다. 하지만 이 장은 Business Workflow의 내용, 개념, 내부적인 동작체계에 대하여 상세하게 설명하고자 하는 것은 아니다.

8.2 Workflow 설정

아래에 제시된 단계들을 따라 감으로써, ALE/EDI interface에서의 오류처리를 위한 workflow 설정을 완료하고, 활성화할 수 있다. 이 설정은 오류처리를 위한 기본적인 시나리오를 지원하고 있지만, 대부분 application의 목적에도 적합할 것으로 생각한다. ALE의 기술적인 오류를 처리하기 위해서 사전에 준비되어 있는 task 이외에, ALE와 EDI의 일반 application 시나리오에서 사용할 수 있는 task도 많이 있다. 앞에서 언급한 것처럼, 오류의 유형이 다르면, 서로 다른 work item이 다른 organizational unit/job/position/person에게 발송되는 결과를 가져온다. 이 장에서 사용된 예제는, 기본적인 시나리오에 대해서 뿐만 아니라, 복잡한 상황에서의 오류처리 대해서도 하나의 template로 사용될 수 있을 것이다. workflow를 활성화하는 것 이외에, 대부분의 object와 설정 내용은 CTS(Correction and Transport System)을 통하여 다른 곳으로 전송될 수 있다.

Chapter 9 IDOC Archiving

9.1 개요

ALE/EDI interface를 개발하고, 테스트하고, 나중에 실제로 운영하게 되면서, 여러 가지 message type에 대하여 많은 양의 IDOC들이 SAP database 상에서 생성된다. 이러한 IDOC은 outbound interface에서 수신시스템으로 전송되거나, inbound interface에서 여러분의 시스템 내에서 처리가 완료되면, 이러한 IDOC에 대한 효용가치는 거의 없거나 전혀 없어지게 된다. 또한 이러한 IDOC들을 통제나 조정의 목적을 위해서 보관하고 있어야 할 필요가 있을 수도 있다. 어떠한 경우든, 이러한 IDOC을 R/3 database에서 떼어내서 다른 저장장치에 보관하거나, 심지어 그 시스템에서 영원히 삭제할 필요도 있다. 이러한 작업은 SAP가 제공하는 archiving이라는 체계를 사용하여 처리할 수 있는데, 이것은 SD, MM, FI, 기타 다양한 application에 속해있는 대부분의 SAP object에서도 동일하게 사용할 수 있다. ALE와 EDI에서 사용되는 IDOC은 archive될 수 있는 object이다. 사실 archiving object type 자체가 “IDOC”으로 정의되어 있다. SAP에서 archiving은 Archiving Development Kit 또는 ADK를 통해서 작동될 수 있다. SAP는 판매주문(sales order), 대금청구서(invoice), 기타의 많은 SAP object를 archive하는데 사용할 수 있는 여러 가지 프로그램과 function module을 기본적으로 제공해 주고 있다. IDOC에 대한 ‘archiving class’는 release 3.0에서 처음 SAP에 소개되었다. 필요하다면 ADK를 사용하여 archiving을 위한 자체적인 프로그램을 개발할 수도 있다. 시스템에서 IDOC을 삭제하기 위해서는 그들이 먼저 archive되어야 한다는 것을 명심하라. 또한 archive된 IDOC을 reload하는 것도 가능하다.

9.2 사전 설정

archiving프로그램들을 실행하기 위해서는 여러 가지 parameter들이 사전에 준비되어 있어야 한다. 처음 단계는 특정 IDOC status에 대하여 archiving이 작동되도록 지정하는 것이다. 특정 status code 집합에 해당하는 IDOC만 archive되도록 하기 위해서 이러한 작업을 한다. 예를 들어 status “64”인 IDOC들은 아직 application에 반영되지 않았기 때문에, archiving에서 제외되어야 한다. 이 설정은 transaction WE47을 사용하거나 transaction WEDI à [Control] à [Maintain Status Values]를 사용하여 처리할 수 있다. status “03”과 같은 것을 선택하고, 상세내용을 조회한다. 다음 화면에는 [Archiving] 필드에서 “possible” 또는 “excluded”를 선택할 수 있는 선택버튼이 있다. IDOC status에 따라 적절한 값을 선택하라. [그림 9-1]을 참조하라.

9.3 IDOC Archiving 프로그램

archiving 작업의 중심 transaction인 SARA를 통해서 IDOC archiving 기능들을 실행할 수 있다. 이 transaction은 SAP 시작메뉴 [Tools] à [Administration] à [Administration] à [Archiving]을 통해서도 실행할 수 있다. 이 transaction을 실행하고, [Object name] 필드에 “IDOC”을 입력하고, [Enter] 키를 누른다. 그러면 Action 항목에서 [Archive], [Delete], [Reload], [Analyze], 그리고 [Management]를 선택할 수 있는 버튼이 나타난다. [그림 9-3]를 참조하라.

Chapter 10 ALE 최적화(Optimization)

10.1 개요

앞의 여러 장을 읽어 오면서, 여러분은 ALE와 EDI interface를 프로토타입(prototype)하고, 개발하고, 테스트하고, 실제 구현할수 있는 준비가 되어 있을 것이다. 하지만 이러한 interface가 얼마나 효율적으로 구현되었느냐 하는 것은 그것들이 작동되었을 때의 처리성능에 많이 좌우된다. 여러분이 ALE와 EDI interface를 최적의 상태가 될 수 있도록 설정하여 구현하려고 노력하면, 실제로 운영될 때 발생할 수 있는 처리성능 상의 문제를 사전에 방지할 수 있고, 반면에 처리속도를 최대화하고, 자원의 사용을 최소화할 수 있다. 설정이 적절하게 되어 있지 않거나, 적절한 처리방식(processing option)이 선택되지 않으면, 이러한 interface로 인하여 병목현상을 초래하여, R/3 시스템의 정상적인 기능에 영향을 줄 수 있다. 이 장에서, 우리는 성능과 관련된 문제를 대해서 탐구하고 공부할 것이며, 유연하게 작동하는 interface를 빠르게 구현하기 위해서 필요한 최적의 parameter들과 설정사항 및 처리방식(processing option)에 관하여 이해하게 될 것이다.

10.2 통신

ALE 처리에는 세 가지 주요 단계가 있다.

단계 1은 송신자 측의 처리인데, 여기서 application과 ALE 서비스는 그 application object에서 필요로 하는 모든 자료를 포함하고 있는 master IDOC을 memory에 생성한다. 이 master IDOC으로부터, ALE의 설정에서 정의된 각각의 수신자에 대하여 communication IDOC이 생성되고, 이것이 IDOC database에 저장된다. customer distribution model에서 설정된 filter object 집합에 따라 수신자가 달라지면 각자 다른 자료를 수신할 수도 있다. application은 자체적인 format으로 master data나 transaction data를 제공해 주지만, ALE function module은 이들 자료를 IDOC 형태로 변환할 책임이 있다.

10.2.1 Transactional Remote Function Call(tRFCs)

transactional RFC 통신의 경우에, 송신시스템에서 프로세서가 시작되면, 하나의 message가 tRFC Queue에 기록된다. 그 다음 tRFC queue에 있는 자료는 네트워크를 통하여 수신시스템으로 전송되는데, 수신시스템에도 tRFC queue가 있어서, 그 자료는 그곳에 기록된다. 송신시스템에서의 tRFC queue는 table ARFCSSTATE와 table ARFCSDATA로 구성되어 있고, 수신시스템에서는 table ARFCRSTATE와 table ARFCRDATA로 구성되어 있다. table xxxSTATE는 송신시스템과 수신시스템 각각에 있어서 tRFC call에 대한 status정보를 포함하고 있고, 반면 table xxxDATA는 호출되어야 하는 function module 목록과 그들에 대한 parameter 값을 함께 포함하고 있다.

10.2.2 File Transfer Protocol(FTP)

또 다른 통신방식은 File Transfer Protocol(FTP)이다. outbound 시나리오에서 프로그램 RSEOUT00을 실행하면, IDOC database 상에 모아져 있던 IDOC을 file형태로 만들어 낸다. 이렇게 하면 ASCII file형태의 IDOC이 생성되는데, 이 file은 FTP를 통하여 외부시스템으로 전송될 수 있다. 여러분은 이를 위해 file port를 정의해야 한다는 것을 유념하기 바란다. inbound 처리인 경우에, 프로그램 RSEINB00을 사용하거나 transaction WE16을 사용하여, file형태의 IDOC을 SAP 내부로 전송할 수 있는데, 이렇게 하면 IDOC database 상에 IDOC이 생성되게 된다. 그런 다음, 다른 inbound function module을 사용하여 IDOC 자료를 application에 반영하게 된다. 테스트 목적으로 outbound file형태의 IDOC을 inbound file형태의 IDOC으로 변환하고자 하면, transaction WE12를 사용하거나 transaction WEDI à [Test] à [Inbound Processing of Modified Outbound File]를 사용할 수 있다. [그림 10-5]를 참조하라. 앞에서 배운 것처럼, file을 이용한 통신은 기본적으로 EDI에서 사용된다.

10.3 IDOC 처리방식(Processing Option)

SAP는 우리에게 inbound에서 뿐만 아니라 outbound에서 IDOC을 처리하는데 사용할 수 있는 여러 가지 처리방식을 제공해 준다. 이러한 처리방식은 ALE interface의 처리성능에 있어서 중요한 역할을 하고 있다. 우리가 사용할 수 있는 처리방식(processing option)은 크게 보면 세 가지 분류할 수 있는데, (1) 처리시점(dispatch control), (2) 처리순서(Processing Mode), (3) 처리단위(Unit of Transfer)가 그것이다. 처리시점(Dispatch Control)이란 생성된IDOC을 어느 시점에 처리하느냐 하는 것이다. 처리순서(Processing Mode)란 생성된 IDOC을 순차적으로 처리하느냐, 아니면 병렬적으로 처리하느냐 하는 것이다. 처리단위(Unit of Transfer)란 생성된 IDOC을 처리하는 단위가 몇 개이냐 하는 것이다. 이러한 처리방식(processing option)들에 대하여 탐구해 보자.

10.4 요약

ALE interface의 처리성능에 대한 정밀 조정에서 사용할 수 있는 다양한 처리방식에 대하여 논의를 했으므로, 이제는 앞에서의 논의를 요약해 보기로 하자

n IDOC에 대한 처리시점(dispatch control)에서는 송신시스템이나 수신시스템 모두에서, 가능하다면, 즉시처리(Immediately processing)를 사용하지 말고, 예약처리(scheduled processing)를 사용하라.

n RFC 통신 오류에 대하여 batch job을 자동 생성하는 기능을 사용하지 마라.

n 가능하다면, 송신시스템이나 수신시스템 모두에서 IDOC packet를 사용하라.

n SAP R/3에서 외부시스템으로의 outbound통신인 경우, 외부 프로그램을 SAP에 등록하여(register) 사용하라. 외부시스템에서 multi-tasking이 가능하다면, 여러 번 등록하라.

n batch processor와 dialog processor의 사용정도에 근거하여, 대량의 IDOC에 대한 전송이나 변경작업은 한가한 시간을 이용하도록 하라.

n 프로그램 RBDCPCLR을 이용하여 change pointerd에 대한 database를 정기적으로 정리(reorganize)하라.

n 정기적으로 IDOC을 archive하라

n 송신시스템과 수신시스템 양쪽에서 충분한 숫자의 dialog work process를 제공하라. 송신시스템에서 사용할 work process 숫자는 수신이 제공할 수 있는 work process 숫자보다 많아서는 안된다.

n 프로그램 RBDAPP01을 이용한 예약 inbound 처리(scheduled inbound processing)에서 뿐만 아니라 master data를 직접 전송할 때, RFC server group을 활용하여 병렬처리를 하라

11.1 자주 사용되는 ALE/EDI Transactions

다음은 자주 사용되는 ALE and EDI transactions 목록이다. 시작메뉴에서 다음 transaction을 그대로 사용하거나, 특정 화면을 종료하고, 원하는 transaction을 실행하려면 /N + transaction (example /nBALE)의 형태을 사용하거나 또는 새로은 session을 열어 원하는 transaction을 실행하려면 /O + transaction (example /oBD21) 형태를 사용하라.

11.2 Message Type과 IDOC Type

SAP에서 지원하고 있는 message type 목록을 확인하려면, transaction WE81 을 실행하거나 또는 transaction WEDI à Development à Message Types을 실행해 보면 된다. SAP 상에서 IDOC type에 대한 message type 할당 내용을 확인해 보려면 transaction WE82 을 실행하거나 또는 transaction WEDI à Development à IDoc Type / Message 을 실행해 보면 된다. 이러한 Messge Type 및 IDOC type의 숫자는 SAP Version이 올라감에 따라 점차 증가할 것이다.

다음 목록은 SAP에 있는 내용 중 일부를 예로서 제시하는 것이며, 여기에 제시되지 않은 것은 위에서 제시된 방법을 이용하여 SAP R/3에서 직접 그 내용을 확인해 볼 수 있다.

11.3 Status Codes

다음은 status codes 목록과 그들에 대한 설명이다.

전달방향(direction): 1 = Outbound,

2 = Inbound

처리계층(processing Layer): A = SAP application

I = IDOC Interface

S = External system / EDI subsystem

11.4 ALE & EDI의 Authorization (Security) Objects

다음은 ALE와 EDI 개발에 사용되는 몇가지의 authorization objects 목록이다. ALE와 EDI 작업을 하기 위해서 여러분의 user ID에 필요한 것을 권한을 설정하기 위해서 Basis 관리자와 의논해 보기 바란다.

Object ALE/EDI: Maintaining logical systems

Authorization B_ALE_LS_ALL

11.5 Control, Data, Status Record

11.5.1 Control record

■ General

IDoc control record for the IDoc interface of the SAP System R/3 to an external system.
The control record for Release 4.0 has the structure EDI_DC40. Each IDoc is initiated by exactly one control record. The record contains control information about outgoing and incoming IDocs as well as their processing in the SAP system and an external system.

11.5.2 Data record

■ General

IDoc data record from the IDoc interface in the SAP R/3 System to an external system.
The data record for Release 4.0 has the structure EDI_DD40. Each IDoc consists of exactly one control record, which is followed by several data records. The data record has organizational information in the first fields, which determines the syntactical construction of an IDoc and assigns the data record to an IDoc. The record also contains structural information about the application data. The field SDATA includes application data (up to 1000 bytes), interpretation occurs field by field via the segment. The segment is in the field SEGNAM.

11.5.3 Status record

■ General

IDoc status record from the IDoc interface in the SAP R/3 System to an external system. The record contains information about the processing status of an IDoc.

■ Status record structure

· TABNAM : Name of table structure

internal data type : CHAR
Internal length : 000010 characters
Position in Segment : 001, Offset : 0000. external length : 000010

11.6 IDOC Type Structures 예제

11.6.1 Structure of basic type ALEAUD01

■ Confirmations of the processing status of inbound IDocs

· E1ADHDR : Message Type etc. of Confirmed IDocs

Status : Essential
min. number : 1 , max. number : 9999999999

o E1STATE : Status Information of IDoc for ALE Audit

Status : Essential
min. number : 1 , max. number : 99999

§ E1PRTOB : IDoc number and application object in receiving system

Status : Optional
min. number : 1 , max. number : 1

11.6.2 Structure of basic type WMMBID02

■ Stock movements from ext. systems

· E1MBXYH : Goods movements for mobile data entry (header data)

Status : Essential
min. number : 1 , max. number : 1

o E1MBXYI : Add goods movement from external system: Item

Status : Essential
min. number : 1 , max. number : 9999

§ E1MBXYJ : Create Goods Movement from Non-SAP System: Item++

Status : Optional
min. number : 1 , max. number : 1

1.6.3 Structure of basic type ZKNVHM01

■ Customer Hierarchy

· Z1KNVHM : Customer Hierarchy

Status : Essential
min. number : 1 , max. number : 1

■ Segment structures

· Z1KNVHM : Customer Hierarchy