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.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에 추가할 필요가 있다.
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를 이용하여 조회할 수 있다.
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들이 그기에 해당한다.
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.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 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.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해야 한다.
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에 반영할 수가 있다.
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장에서 논의할 것이다.