SAP ALE IDOC EDI-Kor_10.2.1 Transactional Remote Function Call(tRFCs)

Posted on by realomega

출판된 한글판 도서

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

Original Book Contents

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 값을 함께 포함하고 있다.

 

다음은 송신시스템과 수신시스템에 있어서의 tRFC 통신 처리과정을 여섯 단계로 설명하고 있다. [그림 10-1]을 참조하라.

 

1.  수신시스템에서 inbound IDOC을 처리하기 위해서 실행되어야 할 function module은 INBOUND_IDOC_PROCESS이다(참고 : IDOC version에 따라서 사용되는 function module이 달라지는데, version 4.x IDOC을 처리할 때는 IDOC_INBOUND_ASYNCHRONOUS를 사용하고, version 3.x IDOC을 처리할 때는 INBOUND_IDOC_PROCESS을 사용한다). 따라서 수신시스템에서 호출되어야 할 이 function module을 그 parameter와 함께 송신시스템의 tRFC queue(송신시스템의 aRFC table, 즉 table ARFCSSTATE와 ARFCSDATA)에 기록한다.

2.  송신시스템의 instance에서, dialog work process가 function module ARFC_DEST_SHIP을 실행하여, 네트워크를 통하여 수신시스템으로 자료를 전송한다. 그 자료는 수신시스템의 tRFC queue(수신시스템의 aRFC table, 즉 table ARFCRSTATE와 ARFCRDATA)에 기록된다.

3.  송신시스템의 logical unit of work 내에 있는 COMMIT문장이 실행되면, 수신시스템 상의 dialog work process 내에서 function module ARFC_EXECUTE가 실행되고, 이것은 다시 tRFC queue에 저장되어 있던 function module INBOUND_IDOC_PROCESS를 호출하여, 전송된 IDOC을 수신시스템의 IDOC database에 저장하게 된다.

4.  수신시스템의 logical unit of work 상에 있는 COMMIT문장이 실행되면, 수신시스템의 tRFC queue에 있는 항목을 삭제하는 작업이 시작된다.

5.  수신시스템은 function module ARFC_DEST_CONFIRM을 사용하여, 송신시스템에게 수신했음을 통지한다.

6.  송신시스템에서는 이러한 통지를 수령하자 마자, 송신시스템의 tRFC queue에 있는 항목을 삭제하는 작업을 시작한다. 이렇게 해서 송신시스템에서의 전체적인 logical unit of work(LUW)가 완성되고, 자료 전송에 사용된 dialog work process는 release된다.


그림 10‑1 두 R/3 시스템들간의 tRFC 통신

 


 

IDOC이 송신시스템에서 전송되면, 그 IDOC은 status “03”(data passed to port OK)의 상태가 된다. tRFC가 성공적으로 실행되었는지를 확인하기 위해서는, 제 7장  “주기적인 처리”에서 설명한 것처럼, 프로그램 RBDMOIND를 scheduling job으로 만들어 주기적으로 실행할 필요가 있다. 이 프로그램은 tRFC의 상태를 점검한 다음, tRFC가 성공적이라면 그 IDOC에 status “12”(Dispatch OK) record를 추가해 준다. 여러분은 또한 transaction SM58을 실행하거나,  transaction WEDI à [IDoc Display Status] à [Transactional RFC]를 실행하여, tRFC를 monitor할 수 있다. 이 프로그램은, 아직 전송되지 않았거나 tRFC call을 실행하던 도중에 오류가 발생하여, 아직 tRFC queue에 남아 있는 자료만 보여준다.  tRFC가 실패하면, SAP는 batch job을 자동적으로 생성하여 그 자료를 재처리하려고 하는 체계를 가지고 있다. 그 batch job은 ID가 “ARFC:[transaction-ID]”형태로 되어 있고, 이들은 transaction SM58에서 대상 항목을 선택하고, 메뉴 [Information] à [Display planned job]을 이용하면, 그 내용을 자세히 조회할 수 있다([그림 10-2]를 참조하라). transaction SM59를 이용하여, 해당 RFC destination의 설정사항을 조정함으로써, 이러한 batch job의 속성과 생성여부를 통제할 수 있다. 이 작업을 하려면, transaction SM59에서 메뉴 [Destination] à [TRFC options]을 선택한다. 여러분은 그 RFC destination에 대하여 background job이 생성되지 않도록 완전히 억제하거나, 또는 재시도의 숫자와 전/후  재시도 사이의 시간 간격을 변경할 수 있는 선택권이 있다. 기본설정은, batch job을 자동으로 생성하고, 두 재시도사이에 15분 간격으로 30 번 재시도하는 것이다. 여러분이 직접 tRFC call을 재실행하기 위해서는, 프로그램 RSARFCEX를 scheduling job으로 만들어 실행해야 한다는 것을 명심하라. 또한 자동으로 생성된 batch job이 단지 실패한 tRFC만을 재실행하는 것과는 반대로, 이 프로그램은 남아있는 모든 tRFC call을 처리한다는 것을 명심하라. 경우에 따라, 이렇게 자동적으로 background job이  생성되는 것을 억제하는 것이 아주 유용할 때가 있는데, 이는 실패한 tRFC에 대하여, work process의 수용능력을 초과할 정도의 많은 job을 만들어 내고, 이것은 결과적으로 더 많은 batch job이 만들어지는 악순환을 초래할 수도 있기 때문이다. 따라서 대량의 자료를 처리하는 RFC destination에 대하여 batch job생성을 억제함으로써, 이러한 상황을 회피할 수 있다. [그림 10-3]를 참조하라.

 

 


 


그림 10‑2 RFC 통신을 위한 자동생성 Batch Job


그림 10‑3 RFC 통신을 위한 자동적인 Batch Job 생성에 대한 통제

 

앞에서 언급한 것처럼, tRFC 통신은 R/3 시스템에서 외부시스템으로 또는 외부시스템에서  R/3 시스템으로의 interface에서도 사용할 수 있다. outbound 통신, 즉 R/3 시스템에서 외부시스템으로의 통신 성능을 향상시키기 위해서, R/3 gateway를 통하여 외부 프로그램을 R/3 시스템에 사전에 등록(register)하는 방법이 제시되고 있다. 만약 그 프로그램이 등록되어 있지 않으면, 시스템은 각각의 개별자료를 전송할 때마다, 그 프로그램을 시작시킬려고 한다. 이러한 방식으로 실행할 프로그램을 등록(register)하려면, transaction SM59에서 RFC destination(TCP/IP)를 선택한 다음, [Registration] 버튼을 누르고, 필요한 정보를 입력한다. R/3 gateway에서 “saprfc.ini”에 원하는 프로그램 이름을 입력해 놓으면, gateway server가 가동될 때, 그 프로그램이 자동적으로 R/3에 등록될 것이다. 병렬처리(parallel processing)를 활용하기 위해서 한 프로그램을 여러 번 등록할 수도 있지만, 이러한 방식은 외부 프로그램이 multi-tasking과 record-level locking을 지원할 수 있을 때만 제대로 작동한다. 이러한 형태의 병렬처리를 하고자 하면, IDOC serialization 기능을 더 이상 사용할 수 없게 된다.  외부시스템에서 R/3 시스템으로의 inbound 통신에 대해서는, 이렇게 프로그램을 등록하는(register) 방법을 적용할 수 없다. 만약 자료 전송이 빈번하다면, logon 후에 연결(connection)을 계속적으로 활성상태로 유지하고, 자료가 도착할 때마다 R/3로 자료를 전송하도록 하는 것이 도움이 될 것이다.  SAP gateway server는 외부시스템에 대해 자주 ping을 해보고, 가능하다면 그 연결(connection)을 개방된 상태로 유지할 것이다. 또한 외부시스템은 IDOC을 하나씩 전송하지 않고, IDOC packet의 형태로 전송하는 것이 바람직한 방식으로 제시되고 있다. 또한 R/3와 R/3 간의 연결에서는 프로그램을 등록(register)하여 사용할 수 없다. 이 말은 각각의 tRFC call을 호출할 때마다 매번 새로이 logon해야 한다는 것을 의미한다.

 

수신시스템에서 application이 IDOC을 처리하는 방법에는 두 가지 방식이 있다. 첫 번째  방식은 가장 많이 사용되는 방식인데, 특정 표준 function module을 호출하여 자료를 application database에 곧바로 반영하는 방식이다. 이 방식은 다른 방식에  비하여 application 측면에서의 자료 점검이 많지 않다. 이 방식을 이용하면, 한번의 호출로 여러 개의 IDOC을 처리할 수 있는 ‘mass update’ 기술을 사용할 수 있는데, 이것은 전반적인 처리시간을 상당히 줄여 줄 수 있는 기술이다. 하지만 이 mass update는 몇몇 message type에 대해서만 사용할 수 있다. 이것을 확인하기 위해서는 transaction BD51을 실행하거나, SAP 시작메뉴 [Tools] à [ALE] à [ALE Development] à [Idocs] à [Inbound Processing] à [Function Module] à [Define Attributes]를 사용하라. [그림 10-4]을 참조하라. 여기서 [Input Type] 필드에는 inbound function module에 대하여 세 가지 값을 지정할 수  있는데, “O”은  mass update 처리를 의미하고, “1”과 “2”는 개별 입력을 의미한다. 만약 수신시스템에서 packet 형태의 IDOC 이 생성되어 있고, inbound function module이 mass update 처리를 지원하지 않는다면, packet 속에 있는 IDOC들은 한 work process에서 순차적으로 하나씩 처리될 것이다. inbound 처리에서 사용할 수 있는 또 다른 방법은 전통적인 batch input기법인데, 여기서는 IDOC 자료를 application에 반영하기 위해서  function 속에서 “Call Transaction using <transaction code>”를 호출한다. 이 방식은 속도가 늦지만, 처리과정에서 자료에 대한 모든 일관성 점검이 이루어 진다.  이 접근방식은 일부 inbound IDOC function module에서만 이용되고 있다.

 

inbound function module을 실행한 work process 내에서 ABAP/4 문장 “SET UPDATE TASK LOCAL”을 사용하여 자료가 갱신된다는 것을 반드시 명심해야 한다. 이 말은 이 작업을 하는데는 update work process가 사용되지 않는다는 것을 의미한다.


그림 10‑4 Inbound IDOC에 대한 Mass Processing과 개별 입력

 

 


 

이제 우리는 R/3에서 사용되는 세 가지 형태의 RFC 간의 차이점을  구분해 보도록 하자. 먼저 동기식 RFC(Synchronous RFC)는 원격지 시스템에 있는 function을 호출하고 응답을 기다린다. 이 방식은 ALE에서 설정항목에 대한 통합성을 점검하기 위해서만 사용된다. 호출 프로그램은 원격지 시스템에서 호출된 function의 처리결과를 알고 있다.  반면에 비동기식 RFC(Asynchronous RFC-aRFC) 는 호출 프로세서가 원격지 시스템에 있는 function을 호출하기는 하지만, 응답을 기다리지 않는 remote call이다. 이러한 aRFC는, master data를 병렬로 직접 전송하고자 하는 경우에 송신시스템에서 사용되고, 수신시스템에서는 병렬로 inbound 처리를 하고자 하는 경우에 사용된다. 비동기식 RFC(Asynchronous RFC)는 ABAP/4 문장 “CALL FUNCTION ……. STARTING NEW TASK”를 사용하여 호출된다. 송신시스템에서의 transactional RFC는 한 logical unit of work(LUW) 안에 remote function call의 그룹을 호출한다. 만약 하나의 function call만  실패해도, 전체 LUW가 roll back처리된다. transactional RFC는 ALE가 한 시스템에서 다른 시스템으로 IDOC을 전송하기 위해서 사용하고, 수신시스템에서는 단 하나의 function “INBOUND_IDOC_PROCESS”가 호출된다. 모든 tRFC는 ABAP/4 문장 “CALL FUNCTION….. IN BACKGROUND TASK”로 호출된다.