[번역] tRFC in ABAP

tRFC in ABAP – SAPCODES

tRFC in ABAP

 

tRFC (트랜잭션 RFC)

tRFC는 SAP 시스템 간에 데이터를 전송할 때 사용하는 통신 방식 중 하나입니다.

한 시스템에서 다른 시스템으로 함수 모듈을 호출할 때, 특히 대상 시스템이 즉시 사용 가능하지 않을 수 있는 상황에서 유용합니다.

---

사용 사례: 구매 오더 생성

한 시스템에서 구매 오더(PO)를 만들었는데, 이 PO를 다른 SAP 시스템에도 똑같이 생성해야 하는 상황을 가정해 보겠습니다.

• 문제점: 동기식 호출(Synchronous Call) 방식을 사용하면, 대상 시스템이 반드시 활성화되어 있어야 합니다. 하지만 이 경우, 대상 시스템이 꺼져 있거나 바쁠 수 있습니다.
• 해결책: tRFC가 바로 이 문제를 해결해 줍니다. 대상 시스템이 당장 활성화되어 있지 않더라도, 구매 오더가 결국 성공적으로 생성되도록 보장합니다.

---

작동 방식

1. 호출: 송신 시스템의 프로그램이 tRFC 함수 모듈을 호출하고, PO 관련 데이터(매개변수)를 넘깁니다. 이 데이터는 송신 시스템 내 임시 테이블에 저장됩니다. (tRFC는 Importing Parameter를 허용하지 않으므로, 데이터는 내부적으로 전달됩니다.)
2. 커밋: 호출 프로그램에서 COMMIT WORK 문이 실행되면, 송신 시스템의 아웃바운드 스케줄러가 작동을 시작합니다.
3. 실행:
   • 스케줄러는 임시 테이블에 저장된 tRFC 호출 정보를 읽고, 지정된 목적지 시스템으로 함수 모듈을 실행하려 합니다.
   • 만약 대상 시스템이 현재 활성화되어 있다면, 함수 모듈은 즉시 실행됩니다.
   • 만약 대상 시스템이 활성화되어 있지 않다면, 백그라운드 프로그램이 주기적으로 재실행을 시도합니다. 이 과정은 함수 모듈이 대상 시스템에서 성공적으로 실행될 때까지 계속됩니다.
   • 가장 중요한 점은, 이 모든 과정에서 프로그램이 함수 모듈이 정확히 한 번만 실행되도록 보장한다는 것입니다. 이로 인해 중복된 데이터가 생성되는 것을 막을 수 있습니다.

요약하자면, tRFC는 대상 시스템의 상태와 관계없이 데이터가 반드시 한 번은 전달되도록 보장하는 신뢰성 높은 통신 방식입니다.

---

Step1.타겟(수신) 시스템에서 RFC FM 만들기

Step2. 타겟(수신) 시스템에서 RFC FM 만들기 : Import Parameter 선언

 

Step3. scarr 테이블에 데이터 insert하는 프로그램 개발

Step4. 송신 시스템: 송신시스템과 타겟(수신) 시스템 간 RFC 연결 확인

Step5. 송신 시스템에서 연결 테스트 수행

Step6. 타겟(수신) 시스템에서 SCARR 테이블 확인

Step7. 송신 시스템에서 RFC를 tRFC로 호출하는 프로그램

 

전체 소스코드

DATA ls TYPE scarr.
CONSTANTS : rfc_det TYPE rfcdest VALUE ‘DEV_TO_TED’.
SELECTION-SCREEN : BEGIN OF BLOCK b1.
PARAMETERS : cr RADIOBUTTON GROUP g1,
                            up RADIOBUTTON GROUP g1,
                             dl RADIOBUTTON GROUP g1.
SELECTION-SCREEN : END OF BLOCK b1.

SELECTION-SCREEN : BEGIN OF BLOCK b2.
PARAMETERS : carrid TYPE scarr-carrid,
                             carrname TYPE scarr-carrname.
SELECTION-SCREEN : END OF BLOCK b2.

START-OF-SELECTION.
  IF carrid IS NOT INITIAL AND carrname IS NOT INITIAL.
    CASE ‘X’.
      WHEN cr.
        ls-carrid = carrid.
        ls-carrname = carrname.
        CALL FUNCTION ‘ZRFC_CREATE_AIRLINE_CODE’
          IN BACKGROUND TASK AS SEPARATE UNIT  ” calling a tRFC for create
          DESTINATION rfc_det                                              ” tRFC doesn’t have importing parameter
          EXPORTING
            ls = ls.
        IF sy-subrc = 0.
          COMMIT WORK.
        ELSE.
          ROLLBACK WORK.
        ENDIF.
      WHEN up.
        CALL FUNCTION ‘ZRFC_UPDATE_AIRLINE_CODE’
          IN BACKGROUND TASK AS SEPARATE UNIT   ” calling a tRFC for update
          DESTINATION rfc_det
          EXPORTING
            ls = ls.
        IF sy-subrc = 0.
          COMMIT WORK.
        ELSE.
          ROLLBACK WORK.
        ENDIF.
      WHEN dl.
        CALL FUNCTION ‘ZRFC_DELETE_AIRLINE_CODE’
          IN BACKGROUND TASK AS SEPARATE UNIT  ” calling a tRFC for delete
          DESTINATION rfc_det
          EXPORTING
            ls = ls.
        IF sy-subrc = 0.
          COMMIT WORK.
        ELSE.
          ROLLBACK WORK.
        ENDIF.
    ENDCASE.
    WRITE : /’Check Transaction SM58  for tRFC call’.
    WRITE : /’Check Transaction SMQS for Scheduler’.
    WRITE : /’Check table : ARFCSSTATE ‘.
  ELSE.
    WRITE :/’ please provide valid I/P  details’.
  ENDIF.

Step8. 발신 시스템에서 SM85 실행

Step9. 현재 SM58에서 전송대기중인 tRFC건 없음 확인

Step10. SMQS로 이동하여 Outbound Queue Scheduler 확인

Step11. 현재 송신 시스템 상태 확인

Step12. 송신시스템의 SE11->ARFCSSTATE 테이블에 Destination 검

Step13. 송신 시스템에 디버깅 설정(세션 디버깅)

Step14. 송신 시스템에서 정보 송신

Step15. 송신 시스템 디버깅1

15단계는 COMMIT WORK 문이 실행될 때의 중요한 순간을 설명합니다.

---

커밋 워크(COMMIT WORK)의 역할

디버거가 COMMIT WORK 문에 멈췄을 때, 이 문장은 tRFC(트랜잭션 RFC) 호출을 실제 실행하는 방아쇠 역할을 합니다.

• 실행 지연: tRFC 함수 모듈이 호출될 때, 사실 대상 시스템의 소스 코드가 바로 실행되는 것이 아닙니다. 대신, 호출 정보가 송신 시스템의 임시 테이블에 기록되어 대기합니다.
• 실행 시작: 이때 COMMIT WORK 문이 실행되면, 시스템은 이 기록된 tRFC 요청을 처리하기 위해 아웃바운드 스케줄러를 작동시킵니다.
• 결과: 디버거에서 F5를 다시 누르면, 이 명령이 실행되고 tRFC는 대기 상태에서 활성 상태로 전환됩니다. 이후, 시스템은 기록된 함수 모듈을 대상 시스템에서 실행하려고 시도합니다.

따라서 COMMIT WORK는 단순히 다음 코드로 넘어가는 것이 아니라, 이전에 대기 상태였던 tRFC를 실행시키는 결정적인 트리거라고 할 수 있습니다.

Step16. 송신 시스템 디버깅2

commit work 구문이 FC의 실행을 트리거했습니다. 여기서 멈추고 F8을 누르지 마세요

Step17. SM58에서 항목 확인1

Step18. SM58에서 항목 확인2

SM58은 SAP에서 tRFC 항목을 확인하고 관리하는 데 사용되는 트랜잭션 코드입니다. 이 트랜잭션 코드는 실제로 ARFCSSTATE 테이블의 내용을 사용자 친화적인 방식으로 보여주는 역할을 합니다.

작동 방식

1. 데이터 기록: tRFC 호출이 발생하면, 그 요청은 즉시 실행되지 않고 필요한 모든 정보와 함께 ARFCSSTATE 테이블에 하나의 항목으로 기록됩니다. 이 정보에는 다음이 포함됩니다.
   • RFC 목적지 이름: 함수 모듈을 실행해야 할 대상 시스템의 이름입니다.
   • 상태: tRFC 호출이 현재 어떤 상태에 있는지(예: 실행 대기 중, 성공적으로 처리됨, 오류 발생 등)를 나타냅니다.
2. SM58의 역할: COMMIT WORK 문이 성공적으로 실행되어 tRFC 요청이 ARFCSSTATE 테이블에 기록되면, SM58 트랜잭션을 통해 이 기록을 확인할 수 있습니다.

요약하자면, SM58은 ARFCSSTATE 테이블에 저장된, 처리 대기 중인 모든 트랜잭션 RFC 호출 목록을 보여주는 창구라고 할 수 있습니다.

Step19. 송신시스템 디버거에서 F7을 눌러 Commit work 실행 종료

Step20. 송신시스템 송신 완료1

COMMIT WORK 문이 완료되면,

tRFC 호출 항목은 더 이상 ARFCSSTATE 테이블이나 SM58 트랜잭션에서 바로 보이지 않게 됩니다.

이는 아웃바운드 스케줄러가 요청을 넘겨받아 처리하기 시작했기 때문입니다.

 

스케줄러는 tRFC 호출을 대기열(ARFCSSTATE)에서 실행 중인 대기열로 옮깁니다.

이 새로운 대기열은 다른 트랜잭션인 SMQS (Queued RFC의 트랜잭션 모니터)에서 모니터링됩니다.

SMQS로 이동하면, 여러분의 RFC 목적지 이름이 'waiting' 상태로 표시된 것을 볼 수 있습니다.

이 'waiting' 상태는 시스템이 대상 시스템에서 함수 모듈을 활발하게 실행하려고 시도하고 있으며, 아직 실행이 완료되지 않았음을 의미합니다. tRFC 호출은 성공적으로 완료되거나 오류가 발생할 때까지 SMQS에 남아있게 됩니다.

Step21. 송신시스템 송신 완료2

Step22. 수신시스템 디버거에서 펑션 호출여부 확

Step23. 수신 시스템 SMQ3 확인

대상 시스템의 디버거가 실행을 멈추고 있는 동안, 함수 모듈의 작업은 아직 완료되지 않았습니다. 송신 시스템의 관점에서 보면, 호출은 대상 시스템으로 넘어갔지만 최종적인 성공 확인 신호는 아직 받지 못한 상태입니다.

바로 이 때문에 송신 시스템의 트랜잭션 SMQS에서 상태가 여전히 'waiting'(대기 중)으로 표시되는 것입니다.

이 상태는 시스템이 호출을 활발하게 처리하려고 시도하고 있지만, 완료를 기다리고 있음을 의미합니다.

디버거에서 F8을 누르면 "실행을 완료하라"고 시스템에 지시하는 것과 같습니다.

이 명령을 통해 함수 모듈 코드가 끝까지 실행됩니다.

코드가 완료되고 결과가 다시 전송되면, 송신 시스템의 tRFC 항목 상태는 'waiting'에서 'executed'(실행 완료)와 같은 완료 상태로 업데이트됩니다.

Step24. 송신 시스템 새로고침 시 상태 inactive로 변경.

화면을 새로고침하면, 상태가 'inactive'(비활성)로 바뀝니다. 이는 스케줄러가 더 이상 처리할 호출이 없어졌음을 의미합니다.

즉, tRFC 호출이 대상 시스템에서 성공적으로 완료되었기 때문에, 스케줄러는 이제 다른 작업을 처리할 준비가 된 상태입니다.

Step25. 수신 시스템에서 레포트 확인

Step26. 수신 시스템에 항목 추가 확인

Step27. 송신 시스템 SM58 항목 삭제 확인

COMMIT WORK 문이 실행되면, tRFC 호출은 더 이상 SM58 트랜잭션에 표시되지 않습니다.

이는 해당 호출이 더 이상 대기 상태가 아니며, 이제 스케줄러가 이 요청을 넘겨받아 실제로 처리할 준비가 되었기 때문입니다.

Step28. 송신 시스템 임시 데이터 삭제 확인

동시에, tRFC 호출을 위해 임시로 저장되었던 데이터도 관련 테이블에서 삭제됩니다.

스케줄러가 호출을 넘겨받아 처리하는 순간, 임시로 저장된 정보는 더 이상 필요 없으므로 시스템은 이를 제거하여 자원을 확보합니다.

이 두 단계는 tRFC가 성공적으로 전달되었음을 나타내며, 이제 호출의 실행은 전적으로 스케줄러의 책임이 됩니다.