{"id":2604,"date":"2017-05-23T12:27:14","date_gmt":"2017-05-23T06:27:14","guid":{"rendered":"http:\/\/sdn.kz\/?p=2604"},"modified":"2017-05-23T12:27:14","modified_gmt":"2017-05-23T06:27:14","slug":"error-handling-when-calling-other-system-using-rfc","status":"publish","type":"post","link":"https:\/\/entropii.net\/2017\/05\/23\/error-handling-when-calling-other-system-using-rfc\/","title":{"rendered":"Error handling when calling other system using RFC"},"content":{"rendered":"

Preparation<\/strong><\/p>\n

You have configured outbound connection and started to write code.<\/p>\n

Iteration 1<\/strong><\/p>\n

\n

CALL FUNCTION ‘RFC_PING’ DESTINATION ‘DUMMY’.<\/font><\/p>\n<\/blockquote>\n

Looks fine enough. But if you make mistake or connection is temporarily down or happens something else, you will get short dumps CALL_FUNCTION_REMOTE_ERROR,  CALL_FUNCTION_NO_DEST or CALL_FUNCTION_OPEN_ERROR etc.<\/p>\n

You should always avoid short dumps in common environment.<\/p>\n

<\/p>\n

 <\/p>\n

Iteration 2<\/strong><\/p>\n

When you use CALL FUNCTION \u2026 DESTINATION \u2026<\/strong> statement you should always add EXCEPTIONS section.<\/p>\n

\n

CALL FUNCTION ‘RFC_PING’ DESTINATION ‘NONE’
  EXCEPTIONS
    communication_failure = 1
    system_failure        = 2.<\/font><\/p>\n<\/blockquote>\n

These system exceptions are part of RFC concept and do not exist in FM implementation.<\/p>\n

Looks better.<\/p>\n

In most cases dev-team just checks sy-subrc<\/strong> and displays error with common message:<\/p>\n

\n

IF sy-subrc NE 0.
  MESSAGE e001(zzz). "Connection error. Try again later
ENDIF.<\/font><\/p>\n<\/blockquote>\n

You should get details. Why? Because it saves team\u2019s time.<\/p>\n

When user or support team member faces the indefinite message he will spent more time or\/and involve more people to identify the root cause. <\/p>\n

Also definite message error is very useful for bug reporting.<\/p>\n

Iteration 3<\/strong><\/p>\n

To get text of error message you should add MESSAGE<\/strong> key word.<\/p>\n

\n

DATA:  lv_msg TYPE char200.
CLEAR lv_msg.
CALL FUNCTION ‘RFC_PING’ DESTINATION ‘NONE’
  EXCEPTIONS
    communication_failure = 1 MESSAGE lv_msg
    system_failure        = 2 MESSAGE lv_msg.
IF sy-subrc NE 0.
  WRITE: \/ sy-subrc, lv_msg.
  MESSAGE e001(zzz) with lv_msg. "Connection error: &1
ENDIF.<\/font><\/p>\n<\/blockquote>\n

Is it best solution?<\/p>\n

No, if you use message-based error handling and logging, sometimes you will receive cropped message:<\/p>\n

\n

Error when opening an RFC connection (CPIC-CALL: ‘<\/p>\n<\/blockquote>\n

Iteration 4<\/strong><\/p>\n

For an easy solution just add substring manipulation:<\/p>\n

\n

MESSAGE i000(zzz) 
  WITH lv_msg(50) 
       lv_msg+50(50) 
       lv_msg+100(50) 
       lv_msg+150(50). "System error: &1&2&3&4<\/font><\/p>\n<\/blockquote>\n

Here is new error message:<\/p>\n

\n

Error when opening an RFC connection (CPIC-CALL: ‘ThSAPOCMINIT’, communication rc: CM_RESOURCE_FAILURE_RETRY (cmRc=27).<\/p>\n<\/blockquote>\n

Some developers find this snippet ugly, but I have no problem with that.<\/p>\n

Iteration 5<\/strong><\/p>\n

You can use structures instead:<\/p>\n

\n

DATA: BEGIN OF ls_msg,
        msgv1 TYPE char50,
        msgv2 TYPE char50,
        msgv3 TYPE char50,
        msgv4 TYPE char50,
      END OF ls_msg.
CLEAR ls_msg.
CALL FUNCTION ‘RFC_PING’ DESTINATION ‘DUMMY’
  EXCEPTIONS
    communication_failure = 1 MESSAGE ls_msg
    system_failure        = 2 MESSAGE ls_msg.
IF sy-subrc NE 0.
  MESSAGE i000(zzz)
    WITH ls_msg-msgv1
         ls_msg-msgv2
         ls_msg-msgv3
         ls_msg-msgv4. "System error: &1&2&3&4
ENDIF.<\/font><\/p>\n<\/blockquote>\n

Verbose code or not?<\/p>\n

 <\/p>\n

Thank you for reading.<\/p>\n","protected":false},"excerpt":{"rendered":"

Preparation You have configured outbound connection and started to write code. Iteration 1 CALL FUNCTION ‘RFC_PING’ DESTINATION ‘DUMMY’. Looks fine enough. But if you make mistake or connection is temporarily down or happens something else, you will get short dumps …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[],"class_list":["post-2604","post","type-post","status-publish","format-standard","hentry","category-abap"],"_links":{"self":[{"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/posts\/2604","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/comments?post=2604"}],"version-history":[{"count":0,"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/posts\/2604\/revisions"}],"wp:attachment":[{"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/media?parent=2604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/categories?post=2604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/entropii.net\/wp-json\/wp\/v2\/tags?post=2604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}