Aaron H. Kim Fearless Integration Maniac

SAP로부터 idoc 수신에 실패할 경우 - 2

2008-05-23
Aaron Kim

BizTalk 서버의 역할 중 하나는 Legacy System과의 연동이고 이 중에 가장 빈번하게 연동해야 할 대상 ERP 시스템은 SAP가 되겠습니다. Interface 서버의 특성상.. A 와 B라는 서로 다른 시스템을 연동한다면.. I/F에 어떤 문제가 발생했을 때, 실제 원인은 A나 B 시스템에 있다해도 I/F 실패의 원인을 찾아내고 문제를 해결하는 역할은 BizTalk 서버 담당자의 몫입니다. 이 때 문제의 정확한 원인을 찾기 위해서는 연동 대상이 되는 시스템들에 대한 제반 지식을 학습할 필요가 있습니다.

얼마전에 제가 운영하는 BizTalk 시스템에서 SAP로부터 idoc을 못내려받는 현상이 발생했습니다. 이전에도 이와 비슷한 경우가 있었기 때문에 먼저 체크해보았지만..

불행히도 같은 원인이 아니었습니다. 해당 SAP는 Non-Unicode 시스템 설정을 유지하고 있더군요.
사용자 삽입 이미지

MSFT에서 제공하는 TroubleShooting Guide에 따르면 idoc 수신을 못받는 경우 다음과 같이 해결책을 제시하고 있습니다. 정확히 말해 해결책은 아니지만.. 문제의 원인을 찾아내는 방법은 될 수 있습니다.

BizTalk service is not receiving IDOCs from the SAP system
Problem
The BizTalk service is not receiving IDOCs.

Cause

  • There are a few possible causes:
  • The SAP system is trying and failing to send the IDOCs.
  • BizTalk Server is not logged on to SAP.
  • The RPC connection is failing, or the mechanism for submitting IDOCs is failing.

Resolution

  • Try the following to resolve the problem:
  • Examine the list of sent IDOCs. Execute the we05 transaction to bring up a search page that you can use to query for IDOCs submitted within a certain time period.
  • View the sm58 transaction output. Execute the sm58 transaction. If there are IDOC attempts listed here, then the SAP system is attempting and failing to send the IDOCs.
  • Verify the BizTalk Server connection. Verify active connections to SAP by running the smgw transaction and then using the Goto menu to navigate to Logged on clients.
  • Test the RPC connection. Use the sm59 transaction to list current RPC ports, and then test a port by clicking the Test Connection button on an individual port’s details screen.</BLOCKQUOTE>

보시면.. we05, sm58, sm59 등의 트랜잭션을 실행하라고 하는데.. 이건 SAP에서의 명령 단위라고 생각하시면 됩니다. SAP 관리자들은 자주 쓰는 트랜잭션 번호 정도는 암기해두어야겠지요? BizTalk 관리자분들도 교양삼아 알아두시면 좋겠습니다.

sm58을 실행하니 위 Resolution에 적힌대로 idoc 문서들을 보내려고 시도한 흔적들이 남아 있습니다. 보내고 실패하기를 반복했다는 뜻이지요.

에러 발생한 인스턴스의 Function module은

IDOC_INBOUND_ASYNCHRONOUS</BLOCKQUOTE>이며 Status_text에 남아있는 에러 메시지를 확인하면 다음과 같습니다.

program TTTAS_TTPAS not registered / CPI-C error CM_ALLOCATE_FAILURE_RETRY</BLOCKQUOTE>여기서 IDOC_INBOUND_ASYNCHRONOUS 모듈은 SAP R/3 시스템에서 Non-SAP System(BizTalk과 같은)으로 idoc을 전송시 호출되는데

다음과 같은 구조를 가지고 있습니다.

사용자 삽입 이미지

CALL FUNCTION ‘IDOC_INBOUND_ASYNCHRONOUS’
IN BACKGROUND TASK
DESTINATION «FONT color=#ff0000>RFC-destination</FONT>>
TABLES
IDOC_CONTROL_REC_40 = <table of control records>
IDOC_DATA_REC_40 = <table of data records>

따라서 에러 메시지[footnote]program TTTAS_TTPAS not registered[/footnote]가 의미하는 바는 해당 SAP시스템에 TTTAS_TTPAS라고 하는 Program id가 등록이 되어 있지 않다는 뜻이 되겠지요.

하지만 sm59에서 확인한 결과 해당 Program id는 제대로 등록이 되어 있었고, Connection Test도 정상적으로 실행이 되었습니다. SAP쪽에 Program id가 등록이 되어 있는데 Connection에 문제가 있을 수 있는 경우는 BizTalk 서버의 수신 위치가 실행 상태가 아닌 경우도 해당되기 때문에 BizTalk 수신 위치를 다시 확인하니..

수신 위치들은 모두 실행 상태였지만 해당 Program id를 바라보는 수신 위치가 4개더군요. SAP 관리자에게 송신 서버의 개수를 확인하니 5개였습니다. 결국 해당 다섯번째 서버를 바로보는 BizTalk 수신 위치가 없어서 생긴 문제였습니다. 원래 4개에서 보내기로 했는데 5개에서 보내고 있더군요.

문제 해결은 수신 위치를 하나 더 만드는 대신 다음과 같은 방법을 사용했습니다.

  1. SAP – sm59 실행
  2. SAP – 문제가 되는 Program id 선택
  3. SAP – Gateway 선택
  4. SAP – Gateway host와 Gateway Service를 첫번째 SAP 서버로 설정.
  5. BizTalk – 첫번째 SAP 서버를 Gateway Host로 바라보는 수신 위치 하나만 제외하고 나머지 전부 삭제.</BLOCKQUOTE>이런 방법을 사용할 수 있는 이유는, 여러 대의 SAP 서버가 있을 때 하나를 Message Server 로 지정해서 나머지 SAP에서 보낸 메시지들이 전부 해당 서버를 통하게끔 할 수 있기 때문입니다. SAP에서 이렇게 설정해두면, BizTalk에서도 해당 SAP 서버를 바라보는 수신 위치 하나만 생성하면 되기 때문에 모두가 행복해지지요. :)

Similar Posts

Comments