SAP ALE IDOC EDI-Kor_10.3 IDOC 처리방식(Processing Option)

Posted on by realomega

출판된 한글판 도서

ERP SAP R/3 ALE, EDI & IDOC 기술

Original Book Contents

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.3.1  Outbound 처리방식

 

먼저 처리시점(dispatch control)에 대하여 이야기 해보자. SAP에서는 [그림 10-6]에서 볼 수 있는 것처럼, IDOC이 생성과 동시에 즉시 전송(dispatch)되거나, 나중에 scheduling job에 의해서 전송될 수 있다. 생성된 IDOC이 한군데 모아져 있다가, 나중에 프로그램 RSEOUT00을 scheduling job으로 만들어 실행할 때 IDOC이 송신되는 경우는, 그러한 IDOC이 생성될 때는 tRFC가 생성되지 않는다. 이렇게 하면, 여러 개의 IDOC을 packet으로 만들어 처리할 수 있기 때문에, 처리성능을 향상시킬 수 있는 장점이 있다(이것이 unit of transfer이다). IDOC의 생성과 IDOC의 송신간에는 시간차이가 있어서, 시간적으로 처리 부담을 분산하는 효과가 있다. 만약 IDOC이 생성과 동시에 즉시 수신시스템으로 전송된다면, packet을 만들 수 있는 기회가 없고, 이는 또한 결과적으로 처리속도를 떨어뜨리게 될 것이다. 하지만 업무상이나 자료처리 상의 필요 때문에, IDOC을 반드시 즉시 전송하는 것이 필요할 수도 있다는 것에 주의를 기울어야 한다. 이 처리방식은 partner profile의 outbound parameter에서 설정할 수 있다.

 

outbound interface의 경우에는 처리순서(processing mode)에 대해서 선택의 여지가 없다. 즉시 처리방식나 scheculing처리방식에 상관없이 IDOC이나 IDOC packet은 비동기적인 tRFC call을 생성하게 된다.

 

처리단위(unit of transfer)에 대한 선택방안은 ALE 최적화에서 매우 중요한 역할을 한다. outbound IDOC에 대하여 IDOC을 수신시스템으로 보낼 때, 여러 개의 IDOC을 모아서 packet형태로 만들 수 있다. 이 경우에 여러 개의 IDOC을 포함하고 있는 packet이 한번의 tRFC call로  전송된다. 이렇게 하는 데는  두 가지 장점이 있는데, (1) 처리 프로세서는 여러 개의 IDOC을 포함하고 있는 하나의 packet에 대하여, 수신시스템에 단지 한번만 logon하면 되고, (2) 여러 IDOC을 포함하고 있는 하나의 packet에 대하여 이러한 IDOC을 처리하는 프로그램은 단지 한번만 메모리 상에 load되면 된다는 것이다. 이 방식은 IDOC을 한데 모아서, 나중에 한꺼번에 전송하는 경우에만 사용할 수 있다. 이 경우 프로그램 RSEOUT00은 message type별로 IDOC을 그룹으로 묶어서, partner profile의 outbound parameter에서 지정한 packet 크기에 따라 packet를 만들게 된다. packet형태의 IDOC은 IDOC type이 동일한 여러 IDOC을 포함하고 있다. 프로그램 RSEOUT00은 IDOC을 처리할 때 마지막 packet 크기가 지정된 것보다 적은 경우에도 모든 IDOC을 전송할 것이다. [그림 10-7]을 참조하라.


그림 10‑6 Outbound 처리방식(Processing Option)

 

 


 

여러분이 알고 있는 것처럼, 처리시점(dispatch control)은 partner profile의 outbound parameter에서 지정한다. 이러한 처리방식은 수신 logical system과 message type별로 독립적으로 지정할 수 있다. 프로그램 RSEOUT00은 개별 IDOC이나 IDOC packet를 순차적으로 처리하고, 전송 자체는 tRFC를 통하여 실행된다. 이것은 그 프로세서에서는 aRFC가 전혀 사용되지 않는다는 것을 의미한다. 또한 그 tRFC를 처리하기 위해서는 새로운 dialog work process가 사용되고, 개별 IDOC이나 IDOC packet이 처리되고 나면, 다음 IDOC 단위(개별 IDOC 또는 IDOC packet)가  그 dialog work process에 의해서 처리된다. 실제로 tRFC가 소비하는 시간은 IDOC의 크기와 지정 packet에 포함되어 있는 IDOC의 숫자에 따라 많이 좌우된다. packet 크기를 크게 하면 처리속도가 증가할 수 있지만, 너무 큰 packet를 사용하게 되면, 메모리 부족을 초래할 수 있는데, 이는 바람직한 현상이 아니다. packet 크기는 1000을 넘지 않도록 해야 하고, 30~50의 범위에 있는 것이 일반적이다. 앞에서 언급한 것처럼, 모든 상황에 꼭 들어 맞는, 마법과 같은 정확한 숫자는 없다.


그림 10‑7 Dispatch Control과 Outbound IDOC에 대한 Packet Size

 


 

10.3.2  Inbound 처리방식

 

우리가 선택하는 inbound 처리방식들은 ALE 최적화에서 중요한 역할을 한다. outbound에서와 마찬가지로 (1) 처리시점(dispatch control), (2) 처리순서(processing mode), (3) 처리단위(unit of transfer)의 세 가지 유형의 처리방식(processing option)이 있다. [그림 10-8]을 참조하라

 

처리시점(dispatch control)에 대하여 먼저 살펴보자. partner profile의 inbound parameter에서 이 처리방식이 “background”로 되어 있으면, 송신시스템으로부터 IDOC을 수신하면 그 IDOC을 한곳에 모아 둔다. 이러한 IDOC들은 나중에 프로그램 RBDAPP01을 이용하여 처리되어야 한다. 이 경우에는 IDOC이나 IDOC packet을 수신할 때, aRFC가 전혀 사용되지 않는다. 이러한 방식을 이용하면, 두 가지면에서 장점이 있다.  (1) IDOC의 수신과 프로그램 RBDAPP01의 실행 사이에는 시간적으로 차이가 있기 때문에, 작업부하가 시간적으로 분산된다는 것이다. 이렇게 되면, IDOC을 처리하기 위해서 보다 적은 dialog work process가 사용되고, 이렇게 절약된 것은 실제의 tRFC 전송 프로세서에 사용할 수 있게 된다. 이렇게 하면, 송신시스템이 work process를 사용하지 못하는 사태를 미연에 방지할 수 있다. 또 다른 이점은, 한곳에 모여진 IDOC을 처리할 때, 이제 여러분이 packet 크기를 지정할 수 있는 기회가 있다는 것이다. 또한 여러분은 RFC server group을 이용하여 IDOC이나 IDOC packet을 병렬적으로 처리하는 것이 가능하다는 것이다(다음 절을 보라). 여러분이 앞에서 배운 것처럼, 송신시스템으로부터 IDOC을 수신할 때, 수신시스템이 그 IDOC을 성공적으로 수신하여 IDOC database에 저장했다면, 그 IDOC의 status가 “64”로 되어 있을 것이다. [그림 10-9]을 참조하라.

 

만약 partner profile의 inbound parametr에서 IDOC 처리방식이 “immediately”로 되어 있으면, function module INBOUND_IDOC_PROCESS는 IDOC이나 IDOC packet를 수신한 후에, 즉시 inbound 처리를 해주는 function을 호출하게 된다. inbound 처리를 work process로 넘겨주기 위해서 aRFC call이 사용된다.

 

IDOC에 대한 처리순서(processing mode)는 순차적(sequential)이거나 병렬적(parallel)으로 설정할 수 있다. 순차적인 처리는 처리시점(dispatch control)이 “background”(collect IDOCs)으로 지정되어 있는 경우에만 사용할 수 있다. 프로그램 RBDAPP01은 IDOC이나 IDOC packet를 기본적으로 순차적으로 처리한다. 이러한 처리방식에서는 aRFC call이 전혀 사용되지 않는다. 모든 처리는 단일 dialog work process에 의한 동기식 RFC에 의해서 처리된다. 프로그램 RBDAPP01 화면에서 [Parallel processing] checkbox를 check하면, 병렬처리(parallel processing)을 이용할 수 있다. [그림 10-10]와 [그림 10-11]을 참조하라. 이 경우에 IDOC이나 IDOC packet은 각기 다른 dialog work process에 의해서 aRFC call을 사용하여 처리된다. 이 처리방식을 사용하면, IDOC 처리 속도를 향상시킬 수 있다.

 

여러분이 inbound IDOC을 application에 반영할 때 처리단위(unit of transfer)를 지정할 수 있다. 여러분이 프로그램 RBDAPP01에서 packet 크기를 지정하면, 그에 해당하는 숫자의 IDOC이 하나의 logical unit of work(LUW)나 하나의 논리적인 단계(logical step)에서 처리된다. 만약 inbound function module이 mass update를 지원하는 기능이 있다면, 그 packet 내에 있는 모든 IDOC들이 단 한번에 처리된다. 설사 해당 function module이 단일 update만을 지원하는 경우에도  packet내의 각각의 IDOC에 대하여 반복처리가 이루어 지고, 그 전체 packet이 하나의 논리적인 단계(logical step)에서 처리되는 것이다. 만약 [Packet size] 필드가 “1”로 설정되어 있다면, 그 논리적 단계(logical step)에서는 한번에 단 하나의 IDOC만이 처리하게 될 것이다. 


그림 10‑8 Inbound 처리 Option

 

 


 


그림 10‑9 Inbound IDOC에 대한 Dispatch Control

 

 


 


그림 10‑10 프로그램 RBDAPP01 – Packet 크기


그림 10‑11 프로그램 RBDAPP01 –병렬처리

 

10.3.3  RFC Server Group과 병렬 처리

 

RFC Server Group은 하나의 ALE task에 대한 작업부하를 분산하기 위해서 사용하는 application server의 집합이다. RFC server group은 특정 outbound ALE application과 inbound IDOC 처리에서만 사용할 수 있다. outbound 시나리오에서 대량의 master data IDOC을 다른 시스템으로 분배하고자 할 때, RFC server group을 사용할 수 있다. inbound IDOC에서 처리방식이 “Collect IDOC”(partner profile의 inbound parameter에서 “background” 방식으로 지정되어 있는 경우)으로 되어 있는  경우에만 RFC server group을 사용할 수 있는데, 이 경우에는 나중에 프로그램 RBDAPP01을 실행하여 후속 처리가 이루어 진다.

 

RFC server group을 정의하기 위해서는 transaction SM59 à 메뉴 [RFC] à [RFC Group]이나 transaction RZ12을 사용하라. server group을 생성하고, 사용할 수 있는 일부 또는 전체 application server를 그 group에 연결하라. 사용할 server를 결정하기 위해서는 여러분의 Basis 관리자와 접촉해 보라. server들 간에 작업 부하가 분산되고, work process들이 RFC 처리를 위해서 사용되는지를 확인하라. [그림 10-12]을 참조하라

 

ALE를 이용하여 master data를 분배할 때는, 송신시스템에서 IDOC을 ‘직접 전송’하는 경우에만 RFC server group을 지정할 수 있다. 예를 들어, Customer Master IDOC을 전송하는 프로그램 RBDSEDEB(transaction BD12)에서는 “parallel processing” 부분에서 RFC server group과 work process당 IDOC(고객-customer)의 수를 지정할 수 있다. 그 프로그램이 실행되면, RFC serve group에서 정의되어 있는 여러 application server 상에 있는 복수의  work process 상에서 aRFC call을 호출하게 된다.  이 방식은 송신시스템에서의 IDOC 처리속도를 상당히 향상시켜준다. [그림 10-13]를 참조하라.

 

프로그램 RBDAPP01을 통하여 inbound 처리를 하는 경우, RFC server group이 지정되어 있지 않으면, 특정 한 server의 work process들만 RFC 처리를 위해서 사용될 것이다. 그러면 그 프로그램이 그 server의 모든 dialog work process를 차지할 수도 있다.  예를 들어, 모든 처리 프로세서들이 number range table로부터 application object number를 획득해야 한다면, 그 number range는 buffer로 읽혀져야 하고, 이 작업을 하려면 work process를 필요로 한다. 하지만 work process를 더 이상 사용할 수 없기 때문에, 그 프로세서는 교착상태(deadlock)에 빠지게 되고, 그 자원을 사용할 수 있을 때까지 무한정 기다리게 될 것이다. 이러한 처리 성능 상의 병목현상을 방지하기 위해서, 여러분이 RFC server group을 사용하도록 제시하는 것이다.

 


 


그림 10‑12 RFC Server Group의 정의


그림 10‑13 Master data를 직접 전송할 때의 병렬 처리

 

10.3.4  Monitoring

 

ALE interface에 대한 최적화 작업을 성공적으로 수행하기 위해서, 여러분은 잠재적인 문제점과 처리성능 상의 병목현상에 대하여 주의깊게 monitor해야 한다. SAP는 ALE 프로세서의 처리상태를 monitor해 볼 수 있는 transaction과 프로그램, 도구들을 제공해 준다. 여기서 언급되는 transaction들 중의 일부는 R/3 시스템 상의 다른 프로세서에서도 동일하게 적용될 수 있는 것이다.

 

transaction WE05(IDOC List)를 사용하여, 지정된 선택조건에 맞는 IDOC 목록을 조회해 볼 수 있다. 여러분은 여기서 IDOC 생성에 대한 ‘시간적인 분산’ 자료를 얻을 수 있다. 이 화면은 여러분에게 그 시스템으로부터의 IDOC 처리용량에 대한 단서를 제공해 줄 것이다. 여러분은 또한 이러한 통계자료를 그래프로 나타낼 수도 있을 것이다. [그림 10-14]을 참조하라.


그림 10‑14 IDOC 생성에 대한 시간 분산 그래프

 

 


 

또 다른 유용한 IDOC 도구는 IDOC trace이다. 이 기능은 transaction BDM2을 통하여 실행할 수 있다. 이 프로그램을 실행하면, 지정된 message type, 생성일자, 수신시스템에 대하여 cross-system IDOC report를 여러분에게 제시해 줄 것이다.  평균/최대/최소 전송시점에 대하여 주의깊게 살펴보기 바란다. 이러한 값들은 송신시스템과 수신시스템에 있는 status record의 time stamp를 이용하여 계산된다. 이 통계자료는 수신시스템이 IDOC을 즉시(immediately) 처리하는 경우에만 유용하게 사용될 수 있는데, 이 말은 scheduling 방식으로 처리하는 경우에는 cross-system IDOC report가 유용하지 않다는 것을 의미한다.

 

여러분이tRFC를 monitor하고자 하면, transaction SM58을 실행하거나, transaction WEDI à [Idoc] à [Display Status] à [Transactional tRFC]를 사용하라. 이 프로그램에서 나타나는 자료는 아직 처리되지 않았거나, 처리도중에 오류가 발생한 것들 뿐이다. Workflow 시스템도 tRFC 방식을 사용하기 때문에, workflow에 대한 항목을 볼 수도 있을 것이다. 각각의 tRFC 항목은 transaction ID를 가지고 있는데, 이는 전 세계에 걸쳐 고유한 번호이며, 그 IDOC과 서로 연결되어 있다. IDOC 조회나 monitoring 화면에서 보면, 송신시스템의 IDOC status가  “03”인 status record message에서 tRFC에 대한 transaction ID를 볼 수 있을 것이다. [그림 10-15]를 참조하라.

 

시스템 상에서 실제 실행되고 있는 프로세서를 monitor해 보기 위해서는, transaction SM50 또는 transaction SM51을 사용하라. 여러분은 프로그램 SAPLERFC에 대한 항목으로 송신시스템과 수신시스템 모두에 대한 tRFC call을 확인할 수 있다. 수신시스템에서의 aRFC call은 프로그램 SAPLARFC에 대한 항목으로 확인할 수 있다. 후속 inbound 처리는 그들 개별 module에 대한 실행항목에 의해서 확인할 수 있다. 만약 프로그램 RSEOUT00(송신시스템에서)과 프로그램 RBDAPP01(수신시스템에서)이 scheduling job으로 만들어져서 실행되고 있다면, 그기에 대하여batch work process에 대한 항목이 모니터 상에서 나타날 것이다. [그림 10-16]를 참조하라.

 

transaction SM37(Job Overview)은 batch job을 monitor하기 위해서 사용할 수 있다. 이 job overview을 이용하면, 통신오류가 발생할 경우에 자동적으로 scheduling된 aRFC job에 대한 목록들을 조회할 수도 있다. 

 

 


 


그림 10‑15 tRFC Monotoring


그림 10‑16 실행중인 프로세서 Monitoring