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]를 참조하라.
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]을 참조하라.
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하는 것도 가능하다.
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 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의 내용, 개념, 내부적인 동작체계에 대하여 상세하게 설명하고자 하는 것은 아니다.
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 처리상태를 보고받을 수 있고, 그 내용을 확인할 수 있다는 것을 인식하는 것이 중요하다.
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.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 시스템이나 외부시스템으로 전송하여, 시스템들을 서로 동기화할 필요가 있는 경우에 더욱 유용하다.
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), 기타의 기능을 제공해 주는 프로그램들이 있다.
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) 단계에서 반드시 함께 실행해야 한다.