ABAP-Fallen: RFC ja, Konvertierung nein

Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht.

Vor einigen Wochen musste ich eine scheinbar einfache Aufgabe programmieren: Von einem SAP Business Workflow, der in System ABC ausgeführt wird, musste ein Sub-Workflow mit mehreren Schritten in einem anderen System oder sogar in mehreren anderen Systemen gestartet werden. Da keine BPM-Engine verfügbar war, entschied ich mich, einfache RFC-fähige Funktionsbausteine zu verwenden, um Workflow-Ereignisse im Zielsystem auszulösen. Die Sub-Workflows können dann über einfache Objekttyp-Verknüpfungseinträge gestartet werden. Dieser Ansatz funktioniert zwar für mein einfaches Szenario recht gut, aber ich bin auf ein völlig unerwartetes Problem gestoßen, dessen Lösung mich eine ganze Weile gekostet hat.

Es gibt zwei Funktionsbausteine, um die Workflow-Ereignisse auszulösen: SAP_WAPI_CREATE_EVENT und SAP_WAPI_CREATE_EVENT_EXTENDED. In meinem Fall habe ich den erweiterten Funktionsbaustein verwendet, weil ich mit klassenbasierten Ereignissen gearbeitet habe. Der Aufruf lautete also im Grunde

  CALL FUNCTION 'SAP_WAPI_CREATE_EVENT_EXTENDED' DESTINATION l_rfcdest
    EXPORTING
      catid             = 'CL'
      typeid            = 'ZCL_MY_CLASS'
      instid            = l_instid
      event             = 'MY_EVENT'
    ...

Zu meiner Überraschung funktionierte es nicht – das System meldete immer wieder, dass das Ereignis M nicht existiert. Nachdem ich viel Zeit mit der Fehlersuche verbracht und mir den Kopf zerbrochen hatte, konnte ich das Problem schließlich identifizieren. Da es schwierig sein kann, dieses spezielle Problem zu reproduzieren, ist hier ein sehr einfacher Funktionsbaustein, um das eigentliche Problem zu veranschaulichen:

FUNCTION ztest_rfc_echo.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(I_INPUT_VALUE) TYPE  STRING
*"  EXPORTING
*"     VALUE(E_OUTPUT_VALUE) TYPE  STRING
*"----------------------------------------------------------------------

  e_output_value = i_input_value.

ENDFUNCTION.

(Wenn Sie dies selbst ausprobieren möchten, stellen Sie sicher, dass der Funktionsbaustein RFC-fähig ist.)

Dies ist nicht mehr als eine einfache Wertzuweisung – Text geht rein, Text kommt raus, oder? Schauen wir mal. Hier ist ein Demoprogramm, um es auszuprobieren:

REPORT ztest_rfc_conversion.

DATA: g_value TYPE string.

START-OF-SELECTION.

  CALL FUNCTION 'ZTEST_RFC_ECHO'
    EXPORTING
      i_input_value  = 'This is a C literal'
    IMPORTING
      e_output_value = g_value.
  WRITE: / '1:', g_value.

  CALL FUNCTION 'ZTEST_RFC_ECHO'
    EXPORTING
      i_input_value  = `This is a STRING literal`
    IMPORTING
      e_output_value = g_value.
  WRITE: / '2:', g_value.

  CALL FUNCTION 'ZTEST_RFC_ECHO' DESTINATION 'NONE'
    EXPORTING
      i_input_value  = 'This is a C literal'
    IMPORTING
      e_output_value = g_value.
  WRITE: / '3:', g_value.

  CALL FUNCTION 'ZTEST_RFC_ECHO' DESTINATION 'NONE'
    EXPORTING
      i_input_value  = `This is a STRING literal`
    IMPORTING
      e_output_value = g_value.
  WRITE: / '4:', g_value.

In diesem Programm wird der Funktionsbaustein zweimal innerhalb derselben Sitzung und zweimal zu Beginn einer neuen Sitzung aufgerufen, wobei sowohl ein Zeichenliteral als auch ein Stringliteral verwendet wird (beachten Sie den Unterschied zwischen 'X' und `X`!). Und die Ausgabe lautet:

Wie Sie leicht erkennen können, wird das Zeichen literal nach dem ersten Zeichen abgeschnitten, aber nur, wenn der Funktionsbaustein über RFC aufgerufen wird. Dasselbe ist in meinem ursprünglichen Programm passiert, da der Parameter EVENT des Funktionsbausteins SAP_WAPI_CREATE_EVENT_EXTENDED vom Typ STRING ist.

Ich hielt dies für einen Fehler, zumal weder SLIN noch der Code-Inspektor vor diesem Problem gewarnt haben. Als guter SAP-Bürger erstellte ich ein SAPnet-Ticket. Nach einer langen Diskussion wurde mir mitgeteilt:

There is no “implicit conversion” in RFC, therefore application need to adjust (or choose) a proper data types for calling/receiving RFMs.

Letztendlich ähnelt dieses Problem sehr dem, das Jerry Wang in seinem Blog vor einigen Wochen beschrieben hat – eine weitere Falltür in der Entwicklungsumgebung, die man bei der RFC-Programmierung ständig im Auge behalten muss, wenn man vermeiden möchte, dass man mit viel Mühe auf ein einzelnes Zeichen reduziert wird…