SAP ALE IDOC EDI-Kor_03.2.5 Outbound Interface – Partner Profile의 관리

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을 생성하라. 이렇게 하기 위해서 다음 작업들을 수행한다.

SAP ALE IDOC EDI-Kor_03.2.4 Outbound Interface – Output Determination

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]을 참조하라.

SAP ALE IDOC EDI-Kor_03.2.2 Outbound Interface – Customer Distribution Model의 설정 & Port의 정의

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을 사용할 수 있다는 사실에 주의하기 바란다.

SAP ALE IDOC EDI-Kor_03.2.1 Outbound Interface – Logical System의 관리

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을 사용하도록 하겠다.

SAP ALE IDOC EDI-Kor_03.1 Transaction Data 분배와 Interface 개요

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를 연결하기 위한 설정도 마찬가지로 간단하게 처리할 수 있다.

SAP ALE IDOC EDI-Kor_02.4.8 Interface 작동

.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을 생성해 보기로 하겠다.

SAP ALE IDOC EDI-Kor_02.4.7 Customer Distribution Model의 분배

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]을 참조하라.

SAP ALE IDOC EDI-Kor_02.4.6 수신시스템에서 수신용 Partner Profile의 생성

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 자료를 저장한다

SAP ALE IDOC EDI-Kor_02.4.5 RFC Port와 Partner Profile의 생성

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]를 참조하라.

SAP ALE IDOC EDI-Kor_02.4.4 RFC Destination의 관리

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]을 참조하라