SAP ALE IDOC EDI-Kor_02.4.8 Interface 작동

출판된 한글판 도서


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


Original Book Contents


2.4.8    Interface 작동

 

지금까지 우리는 R/3 R/3 간을 interface하기 위해서 필요한 시스템 설정을 완료했으므로, 이제는 이 interface를 실제로 실행하고, 그 결과를 이해하는 방법에 대하여 공부해 보기로 하자. 또한 우리는 통신상태를 monitoring해 볼 수 있는 기술을 배울 것이며, 나중에는 R/3 R/3 간에 ALE 통신을 할 때의 performance문제에 대해서도 토론할 것이다.

 

  자료의 송신:

 

SAP IDOC을 송신해 주고, 처리해 주는 표준 프로그램을 기본적으로 제공해 준다. 우리가 수신시스템으로 자료를 보낼 때 사용할 프로그램은 Characteristics Master를 송신하는 프로그램 RBDSECHR Class Master를 송신하는 프로그램 RBDSECLS이다. 여기서 한 가지 유념해야 할 것은, characteristics class에 포함되어 있기 때문에, class characteristics를 포장한 것과 같기 때문에, Class Master보다 Characteristics Master자료가 먼저 송신되어야 한다는 것이다. 먼저 첫 번째 단계로, 송신시스템에서 characteristics  IDOC을 생성해 보기로 하겠다.

 

n  시작메뉴 [Tools] à [ALE] à [Master Data Distribution] à [Logistics] à [Classification System] à [Characteristics] à [Send]를 실행한다. 이것은 프로그램 RBDSECHR을 실행하거나, transaction BD91을 실행하는 것과 동일하다.

n  [Characteristic] 필드에 송신하고자 하는 characteristics 이름이나 범위를 입력한다.

n  [Logical system] 필드에 CHRCLSR301을 입력한다.

n  프로그램을 실행시킨다.

 

만약 characteristics의 수가 많으면, 사전에 적절한 variant를 정의한 다음에프로그램 RBDSECHR background job으로 스케줄링하여 실행해야 한다. 생성된 IDOC을 확인하기 위해서는 transaction WE05를 사용한다. 생성된 IDOC들은 status 30(IDOC ready for dispatch(ALE service))으로 되어 있을 것이다. IDOC 자료의 내용을 이해하고, 자료를 검증하기 위해서 IDOC을 조회해 보라.

 

Class Master에 대한 IDOC을 생성하기 위해서는 다음 작업을 수행한다.

 

n  SAP의 시작메뉴 [Tools] à [ALE] à [Master Data Distribution] à [Logistics] à [Classification System] à [Class] à [Send]를 실행한다. 이것은 프로그램 RBDSECLS을 실행하거나 transaction BD92을 실행하는 것과 동일하다.

n  [Class Type] 필드를 입력하는데, 여기서는 material에 대해서는 001, customer에 대해서는 011을 입력한다. 다음으로 [Class] 필드에 여러분이 분배하고자 하는  class의 이름을 입력한다또한 [Logical system] 필드에 logical system이름을 입력하는데, 이번 경우는 CHRCLSR301이다.

n  프로그램을 실행시킨다.

 

만약 class의 수가 많으면, 사전에 적절한 variant를 정의한 다음에, 프로그램 RBDSECLS  background job으로 스케줄링하여 실행해야 한다.. IDOC 자료의 내용을 이해하고, 자료를 검증하기 위해서 IDOC을 조회해 보라.

 

  수신시스템으로의 IDOC 전송

 

여러분은 일단 communication IDOC을 생성했는데, 다음 단계는 그들을 수신시스템으로 전송하는 것이다. 지금시점이 원격지 시스템과 연결하여 통신하기 위해서 transactional RFC call을 호출해야 하는 시점이다. 통신 경로가 개방되어 있고 실제로 작동하고 있는지를 확인하려면, transaction SM59을 이용하여 RFC destination CHRCLSR301에 대해서 연결 테스트를 실시해 보라.  IDOC을 수신시스템으로 전송하기 위해서는 다음 작업을 수행한다.

 

n  transaction WEDI à [Test] à [Outbound Processing from Idoc]을 실행한다. 이것은 프로그램 RSEOUT00을 실행하거나 transaction WE14을 실행하는 것과 동일하다.

n  message type(CHRMAS, CLSMAS), 수신자의 partner number, 마지막 생성일자와 같은 parameter들를 입력한다.

n  프로그램을 실행한다.

 

만약 IDOC 숫자가 많으면, 사전에 적절한 variant를 정의한 다음에, 프로그램 RSEOUT00  background job으로 스케줄링하여 실행해야 한다. 이 작업이 완료된 후, 모든IDOC status 03(Data passed to port OK)으로 되어 있는 것을 확인해야 한다. status 03이라는 것은 transactional RFC통신이 성공적이었다는 것을 항상 의미하지는 않는다는 사실을 반드시 유념해야 한다. 우리는 IDOC status가 최종 처리상태를 반영할 수 있도록 status를 갱신하는 방법에 대하여 나중에 공부할 것이다.

 

  Transactional RFC에 대한 Monitoring

 

여러분이 tRFC를 사용하여 한 R/3에서 다른 R/3 IDOC을 전송하는 동안에, 통신상태를 점검해 보고, 자료 송신이 성공적으로 끝날 수 있도록 적절한 조치를 취할 수 있다. 이러한 작업을 하기 위한 기본적인 도구가 tRFC monitor인데,  transaction WEDI à [Idoc] à [Display Status] à [Transactional RFC]를 통하여 해당 프로그램을 실행할 수 있다. 이것은 transaction SM58을 실행하거나, 프로그램 RSARFCRD을 실행하는 것과 동일한 것이다. 이 프로그램에서 RFC에 대한 유효기간과 RFC를 시동시킨 user ID를 입력한다. 프로그램을 실행하면 RFC에 대한 log목록이 나타나는데, 여기서 보여주는 log는 오류가 발생한 RFC만 보여준다는 것에 주의해야 한다. [그림 2-32]를 참조하라. 만약 log에 나타난 항목이 있으면, transaction SM21 transaction SM22을 사용하여 그 기간동안에 발생한 system log dump를 분석하여 문제를 분석할 수 있을 것이다. 이러한 오류들을  조심스럽게 분석하여 적절한 조치를 취해야 한다. 많은 경우에 R/3 연결이 정상적이지 않을 수도 있고, 또는 user가 수신시스템에서 새로운 항목을 생성할 수 있는 충분한 권한을 가지고 있지 않을 수도 있다만약 오류가 발생한 경우에 자동적으로 재처리하게끔 설정되어 있으면, 문제의 원인이 필수적인 설정사항이 아닌 다른 것 인 경우는, 대부분의 RFC transaction은 재처리 과정을 통하여 짧은 시간 안에 모두 처리될 것이다통신 오류가 발생한 경우에는, Job Overview(transaction SM37)를 조회해 보면, 이름이 ARFC로 시작하는 여러 개의 job을 발견할 수 있을 것이다. R/3 시스템이 RFC transaction을 다시 처리하기 위해서 이러한 job을 자동으로 scheduling하기 때문에, 이것은 아주 정상적인 현상이다. 하지만, 그런 job의 수가 너무 많으면, 모든 batch process의 수용능력을 초과하게 되고, 이것은 다시 새로운 job을 생성하게 하는, 반복적인 악순환으로 연결될 수도 있기 때문에, 전체 시스템을 Down시킬 수도 있다참고적으로, 송신시스템에서의 RFC call에 대한 상태정보는 table ARFCSSTATE에 저장되어 있는 반면, 수신시스템에서의 RFC call에 대한 상태정보는 table ARFCRSTATE에 저장되어 있다. 우리는 다음 절에서 IDOC 전송 결과에 대한 status 정보를 갱신하는 방법에 대하여 공부하겠다.


그림 2‑32 tRFC Monitoring

 

 

 


 

  수신시스템에서의 IDOC 처리

 

송신시스템에서 보낸 IDOC이 수신시스템에 도착하면, 그들은 status 64(IDOC ready to be passed to application)의 상태로 생성된다. 이것은, 우리가 수신시스템에서 그것들을 받는 즉시 처리하기 보다는, background 방식으로 처리하도록 설정해 놓았기 때문이다. 따라서 이러한 IDOC을 처리하여 application  자료를 반영하기 위해서는 별도 프로그램을 실행시켜야 한다. 이러한 작업을 위해서는 다음 작업들을 수행한다. [그림 2-33]를 참조하라.

 

n  transaction BD20 실행하거나 프로그램 RBDAPP01을 실행한다.

n  이 화면에서 message type(이번에는 CHRMAS, CLSMAS), 생성일자, IDOC 번호와 같은 parameter를 입력하고, 프로그램을 실행시킨다.

n  처리결과에 대한 상태정보를 보여주는 목록들이 나타날 것이다.

n  transaction WE02WE05을 사용하여 IDOC의 처리상태를 점검해 본다. 모든 IDOC status 53(application document posted)의 상태에 있어야 한다.

 

만약 workflow가 작동되도록 설정되어 있다면, 오류가 발생할 경우에는 지정된 user ID inbox work item이 수신되어 있을 것이다. 만약 오류의 원인이 IDOC 자료에 있다면, 여기서 IDOC 자료를 수정하여 재처리할 수 있다. 하지만 application 상의 문제라고 하면, log를 점검하여, 이러한 오류를 발생시킨 원인을 파악하고, 적절한 수정조치를 취해야 한다. 이렇게 하기 위해서는 다음 작업을 실행한다. [그림 2-34]를 참조하라.

 

n  transaction SLG1을 실행한다.

n  [Object] 필드에 대하여 CAPI(classification system), [Sub-Object] 필드에 대하여 CAPI_LOG(Cl./Conf. APIs message log)을 입력한다. 필요하다면, 원하는 시간과 사용자 정보, 기타 필요한 사항들을 입력하고, 프로그램을 실행시킨다.

n  여러분은 다음 화면에서 characteristics class에 대한 오류를 조회할 수 있을 것이다. 또한 여러분은 모든 성공한 class(message type CLSMAS) transaction에 대한 log message도 확인해 볼 수 있다는 사실에 주의하기 바란다.

 

시스템의 가동상태나, deadlock, 또는 일시적인 자료 문제로 인하여 오류가 발생한 경우에는, 프로그램 RBDMAIN background job으로 scheduling하여 status 51(application Document not posted)의 상태에 있는 IDOC을 재처리할 수 있다.

 

송신시스템은 원격지 시스템 상에서 tRFC call이 성공적으로 처리되었다는 것을 어떻게 확인할 수 있을까? 여러분은 원격지 시스템 상에서 tRFC call의 처리결과에 대한 정보를 수집하고, 그 결과를 송신 client에게 보고해 주는 프로그램을 사용할 수 있다. 이렇게 하기  위해서는 다음 작업들을 수행한다. [그림 2-35]를 참조하라.

 

n  transaction BD75를 실행하거나 프로그램 RBDMOIND를 실행한다.

n  IDOC 생성일자와 IDOC의 개수로 지정된 Commit단위를, 예를 들면 100과 같이 입력한다. 이것은 프로그램이 100 개의 IDOC에 대한 status 점검을 완료할 때마다 IDOC status 정보를 갱신한다는 것을 의미한다.

 

tRFC call이 성공적이라면, 앞에서 언급한 절차들을 통하여 수신시스템으로 전송된 IDOC은 모두 status 12(Dispatch OK)로 변경되어 있을 것이다.


그림 2‑33 수신시스템에서의 Inbound IDOC처리

 

 

 

 

 


 


그림 2‑34 IDOC처리 Log 확인


그림 2‑35 IDOC에 대한 tRFC 처리 Status 갱신