SAP ALE IDOC EDI-Kor_07.4 기타의 ALE 프로그램

출판된 한글판 도서


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


Original Book Contents


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 처리상태를 보고받을 수 있고, 그 내용을  확인할 수 있다는 것을 인식하는 것이 중요하다.

 

프로그램 RBDMOIND, 그 시스템에서 RFC를 사용하여 송신된 IDOC status를 그 IDOC이 성공적으로 전송되었는지를 확인해주는 status로 변환하기 위해서 사용된다. [그림 7-14]를 참조하라. 다시 말하면, status 03(data passed to port OK) 상태의 IDOC이 다른 시스템으로 성공적으로 전송되었는지를 점검하고, 만약 그렇다면 status 12(dispatch OK)로 변경한다. 만약 성공적으로 전송되지 않았다면, status 03은 변경되지 않는다. [그림 7-15] [그림 7-16]에서 이전과 이후의 status를 확인해 보라. 이 프로그램에는 두 개의 parameter가 있는데, [Changed on] [IDocs/Commit Work]가 그것이다. 이 프로그램에서는 status 03인 자료 중에서 지정일자 이후에 변경된 모든 IDOC이 처리를 위해서 선택된다. 두 번째 parameter에는 그러한 모든 IDOC에 대한 status 정보가 몇 개마다 갱신되는지를(database commit되는지를) 나타내는 숫자를 지정한다. 이 프로그램은 scheduling job으로 만들어 주기적으로 실행할 수 있으며, 그 실행빈도는 ALE 처리의 빈도와 그것을 monitor하는데 활용할 수 있는 자원과 같은 여러가지 고려사항에 따라 결정될 수 있다. transaction BD75를 통해서도 이 프로그램을 곧바로 실행할 수 있다.

 

 


 


그림 7‑14 RBDMOIND IDOC 전송 Status 변환을 위한 선택


그림 7‑15 RBDMOIND Status 변환이전의 IDOC

 


그림 7‑16 RBDMOIND Status 변환이후의 IDOC

 

 


 

프로그램 RSARFCEX는 아직 실행되지 않은 RFC call을 실행하기 위해서 사용된다. 이렇게 호출이 지연되는 것은, 연결오류가 발생하거나, 대상 시스템에 대한 gateway가 활성화되어 있지 않거나, 통신이 끊어지거나, 처리를 위해서 필요한 자원이 사용 가능해질 때까지 대기행렬에서 기다려야 하는 것등의 이유로 인해서다정상적인 상황에서는, RFC call이 성공적으로 처리되지 못하면, 이러한 RFC call을 다시 처리하기 위한 새로운 scheduling job이 자동적으로 생성된다: 이렇게 하는 이유는 대상 시스템으로 자료를 확실히 성공적으로 전달하려고 하기 때문이다. 재시도의 숫자와 빈도는 RFC destination 상에 있는 특정 parameter를 조정하여 통제할 수 있다(이것에 대한 보다 상세한 사항에 대해서는, 10ALE 최적화을 보라). 또한 RFC call이 이러한 방식으로 자동적으로 재처리되지 않도록 설정할 수도 있는데, 이것은 그렇게 하는 다른 충분한 이유가 있기 때문이다. 앞에서 언급한 것처럼, RFC call이 성공적으로 처리되지 않으면, batch job이 반복적으로 scheduling되어 실행되게 되는데, 이는 RFC call이 성공적으로 처리되거나 또는 사전에 지정한 최대 재시도 숫자를 초과할 때까지 반복된다. 예를 들어, 만약에 gateway server가 반응하지 않는 것과 같은 몇 개의 통신 오류가 있다면, 그 결과로 수백 개의 batch job이 생성되고, 시스템 상의 batch processor의 용량을 초과하게 될 것이다. 이렇게 되면, 더욱 가속도가 붙어서 더 많은 aRFC job들이 생성될 수도 있다. 이러한 불안정한 상황을 피하기 위해서, RFC call에 대하여 자동 재처리를 지정하지 않고, 대신에 프로그램 RSARFCEX scheduling job으로 만들어 수작업으로 실행할 수 있다. 이렇게 되면, 이 프로그램은 정기적으로 실행되면서, 아직까지 처리되지 않고 있는 RFC를 재처리할 수 있게 되는 것이다. 이 프로그램에서 사용할 수 있는 선택조건은 일자, RFC destination, user ID 등이다. 또한 여러분은 communication error, recorded, being executed, 그리고 terminated because of overload와 같은 RFC status를 선택할 수 있다. transaction BDA1 통해서도 이 프로그램을 곧바로 실행할 수 있다. [그림 7-17]을 참조하라.

 

 

 


 


그림 7‑17 RSARFCEX RFC Call의 재실행

 

 

 

 


 

프로그램 RBDSTATE는 두 개의 R/3 시스템 간에 ALE transaction에 대한 audit confirmation을 위해서 사용된다. Audit Confirmation이라 함은, 수신시스템에서 ALE transaction이 성공적으로 처리되었는지 아니면 실패했는지를 나타내는 표시를 의미한다. 이 프로그램을 사용하면, 수신시스템 상에서의 ALE transaction에 대한 상태정보를 송신시스템으로 보고해 준다. 이 과정은, 그 자체로는 수신시스템에서 송신시스템으로 가는 interface로서 message type ALEAUD, IDOC type ALEAUD01이 사용된다. 우리는 이 절에서 ALEAUD 설정을 하고, 프로그램 RBDSTATE를 실행하는데 필요한 여러 단계들에 대해서 배울 것이다.

 

base logical system FSTCLNT100(송신시스템) logical system FSTCNLT065(수신시스템)으로 정의되어 있는, 두 개의 다른 R/3 시스템에 대해서 생각해 보자. 우리는 message type CHRMAS를 이용하여, FSTCLNT100에서 FSTCNLT065 Characteristics Master를 분배한다고 가정하자. 우리가 IDOC CHRMAS03 FSTCLNT100에서 송신할 때, 그들이 송신시스템에서 성공적으로 외부로 전달되었다면, 그들의 status03(data passed to port OK)의 상태가 된다. 만약 그 IDOC이 수신시스템 FSTCNLT065에서 접수되어 성공적으로 처리되었다면, 수신시스템에 있는 그들 IDOC status53(application data posted)이 될 것이다. 우리는 수신시스템 FSTCNLT065에서 CHRMAS message type을 수신하기 위해서 partner profile FSTCLNT100을 생성했음을 기억하라. 수신시스템 상에 있는 partner profile FSTCLNT100내의 inbound parameter에서 message type CHRMAS, process code CHRM이 지정되어 있다. 이제 우리는 ALEAUD message를 송신시스템인 FSTCLNT100으로 송신하기 위해서, 수신시스템 FSTCNLT065에서 필요한 설정을 해야 할 필요가 있고, 또한 송신시스템인 FSTCLNT100이 이러한 message를 받아, 수신시스템으로 송신된 IDOC CHRMAS03에 대한 status를 갱신할 수 있도록 하기 위해서, 송신시스템에서 필요한 설정을 할 필요가 있다. 다음에 제시된 절차를 실행한다.

 

n  수신시스템 FSTCNLT065에 있는 customer distribution model에서 message type ALEAUD logical system FSTCLNT100으로 분배되는 message flow에 대하여 설정을 하라.

n  filter object type MESTYP을 사용하여, 여러분이 audit confirmation처리를 하고자 하는 message type (예를 들면 CHRMAS)을 입력하여 filter object를 생성한다. 여기서 사용되는 message type은 송신시스템인 FSTCLNT100에서 수신시스템인 FSTCNLT065로 전송되는 것이어야 한다. 우리의 예제에서는, filter object type MESTYP에 대한 값은 Characteristics Master에 대한 message type CHRMAS가 될 것이다.  customer distribution model을 저장한다. 이 작업을 하려면, transaction BD64를 사용하라.

n  수신시스템 FSTCNLT065에서 이름이 FSTCLNT100 RFC destination을 생성한다. 관련되는 connection type을 선택하고, client FSTCLNT100이 있는 R/3 시스템에서 사용되는 logon parameter password를 입력한다. 이 작업은 transaction SM59를 사용한다.

n  수신시스템 FSTCNLT065에서 transaction SALE à [Modelling and Implementing Business Processes] à [Partner Profiles and Time of Processing] à [Generate Partner Profiles]을 실행한다. 화면에서 앞에서 정의한 customer distribution model을 지정하고, 프로그램을 실행한다. 이렇게 하여 partner profile을 생성하고, port를 정의한다. partner profile을 점검하여 outbound parameter message type ALEAUD message type SYNCH에 대한 입력항목이 있는지를 확인한다.

n  송신시스템인 FSTCLNT100에서 FSTCNLT065에 대하여 logical system을 생성한다. logical system FSTCNLT065에 대한 partner profile을 생성하고, inbound parameter에서 [Message type] 필드에 ALEAUD를 입력하고, [Process code] 필드에 AUD1을 입력한다.

n  FSTCNLT065 상에서 FSTCLNT100으로 customer distribution model은 분배할 필요는 없다.

 

이제 우리는 ALE audit confirmation 프로세서를 테스트할 준비가 되었다. 송신시스템  FSTCLNT100에서, 먼저 몇 개의 IDOC CHRMAS03(Characteristics Master)을 수신시스템 FSTCNLT065로 전송한다. IDOC status03(data passed to port OK)인지를 확인하라. 수신시스템 FSTCNLT065에서 이런 IDOC들이 수신되었는지를 점검하라. 그리고 이 IDOC들의 status53(application data posted)인지를 점검하라. 수신시스템에서 적절한 parameter를 지정하여 프로그램 RBDSTATE를 실행하라. [Confirmations to system] 필드에 FSTCLNT100, [Message type] 필드에 CHRMAS를 입력하고, 그리고 필요하다면 일자를 지정하라. 프로그램이 성공적으로 실행되면, 생성된 IDOC의 숫자와 ALEAUD IDOC status를 보여주는 안내 메시지가 나타날 것이다(하나의 ALEAUD audit IDOC은 여러 개의 application IDOC에 대한 audit message를 포함할 수 있다. 이러한 기능을 이용하여, 두 시스템 간에 오가는 IDOC 숫자를 감소시키고, audit confirmation으로 인한 부담을 최소한으로 유지해 준다). 송신시스템 FSTCLNT100에서 ALEAUD message를 수신했는지를 점검한다. 우리가 처음에 수신시스템으로 전송했던 IDOC CHRMAS03 status41(application document created in target system)로 변경되어 있어야 한다. 이것으로 ALE audit confirmation에 대한 테스트를 모두 완료하게 된다. [그림 7-18]을 참조하라. 수신시스템과 송신시스템에서의 IDOC 조회는  [그림 7-19] [그림 7-20]을 참조하라.

 

ALE audit confirmation은 실제의 운영환경에서 운영상태를 보고하고, monitor하는데 있어서 매우 중요한 역할을 차지하고 있다. 여러분은 수신시스템에서 프로그램 RBDSTATE scheduling job으로 만들어 주기적으로 실행하여, 송신시스템으로 처리상태를 보고하게끔 할 수 있다. 수신시스템에서 IDOC application 문서에 반영되는데 시간이 필요하기 때문에, 여러분은 수신시스템으로 application IDOC을 송신하는 시점과 이 프로그램을 실행하는 시점 사이에는 충분한 시간간격을 유지해야 한다는 것을 꼭 기억하기 바란다. transaction BDM8 통해서도 이 프로그램을 곧바로 실행할 수 있다.

 

 


 


그림 7‑18 RBDSTATE ALEAUD IDOC의 생성

 

 

 

 


 


그림 7‑19 수신시스템에서의 Application IDOC Audit IDOC


그림 7‑20 송신시스템에서의 Application IDOC Audit IDOC

 

프로그램 RBDAUD01은 프로그램 RBDSTATE에 의해서 처리된 ALE audit에 대한 통계적인 분석자료를 얻고자 할 때 사용된다. 이 프로그램은 message type ALEAUD에 근거하여 보고된 IDOC status에 대한 정보를 수집한다. 이 보고 프로그램이 작동하려면, 앞에서 설명한대로 ALEAUD에 대한 모든 사항들이 설정되어 있어야 한다. 보고서에 나타나는 항목들은 다음과 같다. receiving system은 수신자의 logical system을 의미한다. message type message flow의 유형을 나타내고, [Created on IDOC]은 생성일자를 보여준다. [Last IDOC]은 지정일자에 그 시스템에서 마지막 IDOC이 전송된 시간을 보여준다.  [Total IDOC]은 전송된 IDOC의 총 개수를 보여주고, [Outbound queue] [Inbound Queue] 항목은 그 해당 queue에서 처리되기를 기다리는 IDOC의 숫자를 의미한다. 특히 [Outbound queue]는 우리 자체의 시스템 상에서 전송되기를 기다리는 IDOC의 숫자를 의미하고, [Inbound queue]는 수신시스템이 수신했지만 아직 처리되지 않은 IDOC 숫자를 의미한다. 자료가 있는 행을 double-click하면, 송신시스템에서 처리된 IDOC의 숫자와 status, 그리고 수신시스템에서 처리된 IDOC의 숫자와 status를 보여주는 또 다른 목록이 나타난다. 이 프로그램의 선택화면에는 logical receiver system, message type, 기타의 parameter/선택조건이 있다또한 [Incomplete statistics only]에 대한 flag도 있다. 이 프로그램은 이것으로   audit 통계 미 완료 IDOC만 포함할 것인지, 아니면 모든 IDOC을 포함할 것인지를 결정한다. audit 통계 미 완료, inbound queue outbound queue에 아직 처리되지 않은 IDOC이 있는 경우나, 특정일자의 IDOC의 일부 또는 전부가 아직 audit 통계에 잡히지 않은 경우를 의미한다. 후자는 보고서에서 있는 [Last IDOCs] 항목에 시간이 24:00:00 이전인 자료가 있다는 사실에 의해서 파악할 수 있는데, 이는 단지 그때가지의 IDOC들만이 통계에 포함되었다는 것을 의미한다. 이 보고서는 그 interface의 처리속도를 monitor하는데 아주 유용하다. 프로그램 RBDAUD01 scheduling job으로 만들어 주기적으로 실행함으로써, ALE audit에 대한 통계자료를 수집할 수 있다. 이러한 기능은 transaction BDM7 통해서도 실행할 수  있다. [그림 7-21] [그림 7-22]를 참조하라.

 

 


 


그림 7‑21 RBDAUD01 ALEAUD에 대한 통계 분석을 위한 선택조건


그림 7‑22 RBDAUD01 -- ALEAUD에 대한 통계 분석


 

프로그램 RBDAUD02 audit database table을 정리(reorganize)하는데 사용된다. 이 프로그램은 database table에서 audit 자료를 삭제한다. [Test No physical deletion] checkbox check하여 테스트 mode에서 실행해하게 되면, 삭제될 자료에 대한 보고자료를 제공해 주기는 하지만, 실제로 그들을 삭제하지는 않는다. 또 다른 flag [Delete only if complete]는 그 IDOC이 그 시스템에서 완전히 송신된 경우에만 자료를 삭제할 수 있는 기능을 여러분에게 제공해 준다. audit 통계의 일자도 선택조건으로 사용할 수 있다. 이 프로그램은 audit database를 관리하는데 유용하게 사용할 수 있는데, 특히 audit statistics의 량이 매우 많은 경우에 특히 유용하다. 이 프로그램은 transaction BDM9를 사용하거나, transaction BALE à [Services] à [Audit] à [Reorganize Audit Database]를 통해서도 접근이 가능하다.  [그림 7-23]을 참조하라.


그림 7‑23 RBDAUD02 ALEAUD Database에 대한 정리(reorganization)

 


 

프로그램 RBDCPCLR change pointer database를 정리(reorganize)하는데 사용된다. 앞에서 언급한 것처럼, change pointer table BDCP에 저장되어 있고, 그에 대한 status 자료는 table BDCPS에 저장되어 있다. 시간이 경과함에 따라, 이미 쓸모가 없어졌거나 이미 처리된 change pointer의 개수가 점차 증가할 것이며, change pointer 체계를 이용하고 있는  master data ALE interface의 성능이 떨어지기 시작할 것이다. 그 이유는 이러한 환경에서 master data ALE function module이 실행될 때마다, module들은 이 두 개의 table을 읽고, 처리가 완료되면 table BDCPS를 갱신하기 때문이다. 처리성능을 향상시키고, 쓸모없거나 이미 처리된 change pointer를 제거하기 위해서, 여러분은 프로그램 RBDCPCLR을 사용할 수 있다. 이 프로그램은 [Obsolete change pointer] [Processed change pointer]에 대하여 여러가지 checkbox parameter/선택조건을 가지고 있다. [Obsolete change pointer]  change pointer가 처리된 것인지 또는 아닌지에 상관없이 지정된 일자와 시간까지의 모든 IDOC을 의미한다. [Processed change pointer]는 실제로 처리된 것으로, table BDCPS PROCESS flagX로 표시되어 있는 것을 의미한다. 여러분은 일자와 시간을 일정범위로 지정할 수 있다. 또한 테스트 mode에서 프로그램을 실행할 수 있는 flag도 있다. flag를 사용하면, 프로그램은 처리할 change pointer를 선택하기만 하고, 실제로 database에서 삭제하지는 않는다. 이것은 여러분이 삭제하고자 하는 자료를 확인하는데 아주 유용한 선택사항이다. 실행이 완료될 때 나타나는 안내 메시지는 실행시에 선택된, 쓸모없거나 처리된 change pointer의 숫자를 보여준다. 쓸모없는 change pointer는 그것의 처리상태와는 상관없이 삭제된다는 것을 다시 한번 유념하기 바란다. 이 프로그램은 기술적인 필요나 업무적인 필요성에 따라서 scheduling job으로 만들어 주기적으로 실행할 수 있다. [그림 7-24]를 참조하라. transaction BD22 통해서도 이 프로그램을 곧바로 실행할 수 있다.

 

 

 


 


그림 7‑24 RBDCPCLR - Change Pointer Database 정리


 

프로그램 RBDMOIN8 cross-system IDOC에 대해서 파악하고자 하는 경우에 사용된다. 이 프로그램은 관련되는 R/3 시스템들 간에 걸친 IDOC flow와 시점에 대한 추적자료를 생성해 낸다. 이것은 IDOC 전송에 대한 처리성능의 정도를 추적하는데 사용할 수 있을 뿐만  아니라, IDOC 자체의 이동상황을 추적하는데도 유용하게 사용할 수 있는 보고서이다. 여기서는 IDOC의 마지막 status03(Data passed to port OK) 또는 12(Dispatch OK) IDOC만 처리 대상이 된다. 이 프로그램은 우리에게 송신시스템의 IDOC 번호와 수신시스템의 IDOC 번호 간에 상호 참조 정보를 제공해 준다. 이 프로그램에서 사용할 수 있는 parameter와 선택조건에는 message type, partner type partner number(필수사항)와 같은 수신자에 대한 상세정보, 시작 생성일자와 시간, 종료 생성일자와 시간 등이 포함되어 있다. 첫 번째 화면의 보고서는 우리에게 수신시스템에서의 IDOC status IDOC의 숫자를 보여준다. 여러분이 원하는 행에 커서를 놓고 [Display linked IDOC] 버튼을 누르거나, double-click하여 drill-down해 보면, 송신시스템과 수신시스템의 IDOC 번호, 일자와 시간, 그리고 두 시점 간의 차이에 대한 정보를 보여주는 목록을 볼 수 있을 것이다. [그림 7-25] [그림 7-26]을 참조하라. transaction BDM2 통해서도 이 프로그램을 곧바로 실행할 수 있다.

 


 


그림 7‑25 RBDMOIN8 - IDOC trance 보고서 개요


그림 7‑26 RBDMOIN8 - Cross-system IDOC 보고서

 

프로그램 RSARFCRD는 시스템 내에서 RFC 활동상황을 monitor하기 위해서 사용된다. 이 프로그램은 RFC transaction에서 발생한 오류에 대한 기록을 확인하기 위해서 활용할 수 있다. 이 프로그램은 단지 현재 처리중인 RFC call이나 오류가 발생한 RFC call만을 고려한다. RFC call을 실행한 후에 오류가 발생한 경우는, 오류의 내용이 log에 기록된다. log RFC call ID와 함께 오류의 유형과 임시적인 통계자료를 보여주는 간단한 메시지를 포함하고 있다. transaction SM58을 실행하거나, transaction BALE à [Idoc] à [Display Status] à  [Transactional RFC]를 통해서도 이 프로그램을 실행할 수 있다. 우리는 RFC와 이러한 monitoring에 대하여 제 10ALE 최적화에서 더욱 상세히 논의할 것이다. [그림 7-27]을 참조하라.

 

우리가 이미 본 것처럼, SAP ALE/IDOC interface에 대한 실행, 처리결과 추적, 처리상황 보고, monitoring 등을 용이하게 해주는 여러 가지 프로그램을 우리에게 제공해 준다. 이러한 도구들은 interface를 개발하고 실제로 운영할 때, interface를 유연하게 운영하고, 문제를 해결하는데 매우 중요한 역할을 한다.


그림 7‑27 RSARFCRD RFC 실행 상황 Monitoring