SAP .Net Connector 3.0 RfC return incorrect values

Question

I wrote a custom RFC that reads specific data from BKPF and returns it.

The function module works very well when I test it in SAP Gui, but when I used it from a .Net application via the .Net Connector 3.0 driver I got ' I' value (with 3 spaces) in BUKRS instead of 'IP01'.

I tried several codepage in the connection parameters but nothing changed.

    FUNCTION ZONW_IMPORT_ECRM.
    *"----------------------------------------------------------------------
    *"*"Interface locale :
    *"  IMPORTING
    *"     VALUE(MAX_ROWS) TYPE  I DEFAULT 0
    *"     VALUE(WHERE_TAB) TYPE  WHERECONDS OPTIONAL
    *"     VALUE(COMPANYCODE) TYPE  BKPF-BUKRS DEFAULT 'IP01'
    *"     VALUE(CURRY) TYPE  BSEG-GJAHR DEFAULT SY-DATUM
    *"  EXPORTING
    *"     VALUE(RETURN_CODE) TYPE  I
    *"  TABLES
    *"      RETURN_TABLE STRUCTURE  BKPF
    *"----------------------------------------------------------------------

     CLEAR RETURN_TABLE.    REFRESH RETURN_TABLE.

    ****** Creation du type de la table ECRM

      TYPES: TT_ECRM TYPE STANDARD TABLE OF BKPF.

    ****** Creation d'une table interne

      DATA: IT_ECRM TYPE  TT_ECRM,
            CURRM   TYPE  BKPF-MONAT,
            PREVM   TYPE  BKPF-MONAT,
            PREVY   TYPE  BKPF-GJAHR.

    ****** Initialisation des variables

      IF CURRY IS INITIAL.
        CALL FUNCTION 'GET_CURRENT_YEAR'
        EXPORTING
          BUKRS = COMPANYCODE
        IMPORTING
           CURRM         = currm    " Current Fiscal Month
           CURRY         = curry    " Current Fiscal Year
           PREVM         = prevm    " Previous Fiscal Month
           PREVY         = prevy.   " Previous Fiscal Year
      ENDIF.


    ****** Récupération des données


      " La requete de sélection
          SELECT  BUKRS
                  BELNR
                  GJAHR
                  BLART
                  BLDAT
                  BUDAT
                  CPUDT
                  CPUTM
                  AEDAT
                  USNAM
                  XBLNR
                  DBBLG
                  STBLG
                  BKTXT
                  HWAER
                  BSTAT
            UP TO MAX_ROWS ROWS
          INTO CORRESPONDING FIELDS OF TABLE IT_ECRM
          FROM  BKPF
          WHERE BUKRS = COMPANYCODE
          AND   GJAHR = CURRY
          AND   (WHERE_TAB).



    RETURN_TABLE[] = IT_ECRM[].
    ENDFUNCTION.

It's the function body, as mentioned earlier it return some lines from the table BKPF and it works fine when tested in SAP Gui, but when invoked through the .Net Connector the value of BUKRS return ' I' instead of 'IP01'

After a look at the structure of BKPF it seems that there is a difference between the structure I found in SAP (MANDT, BUKRS, ) and the one I get when I look at the table.Metadata.LineType in .Net

{STRUCTURE BKPF{BUKRS:CHAR4, MANDT:CHAR3, BELNR:CHAR10, GJAHR:NUM(4), BLART:CHAR2, BLDAT:DATE, BUDAT:DATE, MONAT:NUM(2), CPUDT:DATE, CPUTM:TIME, AEDAT:DATE, UPDDT:DATE, WWERT:DATE, USNAM:CHAR12, TCODE:CHAR20, BVORG:CHAR16, XBLNR:CHAR16, DBBLG:CHAR10, STBLG:CHAR10, STJAH:NUM(4), BKTXT:CHAR25, WAERS:CHAR5, KURSF:BCD[5:5], KZWRS:CHAR5, KZKRS:BCD[5:5], BSTAT:CHAR1, XNETB:CHAR1, FRATH:BCD[7:2], XRUEB:CHAR1, GLVOR:CHAR4, GRPID:CHAR12, DOKID:CHAR40, ARCID:CHAR10, IBLAR:CHAR2, AWTYP:CHAR5, AWKEY:CHAR20, FIKRS:CHAR4, HWAER:CHAR5, HWAE2:CHAR5, HWAE3:CHAR5, KURS2:BCD[5:5], KURS3:BCD[5:5], BASW2:CHAR1, BASW3:CHAR1, UMRD2:CHAR1, UMRD3:CHAR1, XSTOV:CHAR1, STODT:DATE, XMWST:CHAR1, CURT2:CHAR2, CURT3:CHAR2, KUTY2:CHAR4, KUTY3:CHAR4, XSNET:CHAR1, AUSBK:CHAR4, XUSVR:CHAR1, DUEFL:CHAR1, AWSYS:CHAR10, TXKRS:BCD[5:5], LOTKZ:CHAR10, XWVOF:CHAR1, STGRD:CHAR2, PPNAM:CHAR12, BRNCH:CHAR4, NUMPG:NUM(3), ADISC:CHAR1, XREF1_HD:CHAR20, XREF2_HD:CHAR20, XREVERSAL:CHAR1, REINDAT:DATE, RLDNR:CHAR2, LDGRP:CHAR4, PROPMANO:CHAR13, XBLNR_ALT:CHAR26, VATDATE:DATE, XSPLIT:CHAR1, PSOTY:CHAR2, PSOAK:CHAR10, PSOKS:CHAR10, PSOSG:CHAR1, PSOFN:CHAR30, INTFORM:CHAR4, INTDATE:DATE, PSOBT:DATE, PSOZL:CHAR1, PSODT:DATE, PSOTM:TIME, FM_UMART:CHAR1, CCINS:CHAR4, CCNUM:CHAR25, SSBLK:CHAR1, BATCH:CHAR10, SNAME:CHAR12, SAMPLED:CHAR1, EXCLUDE_FLAG:CHAR1, BLIND:CHAR1, OFFSET_STATUS:CHAR2, OFFSET_REFER_DAT:DATE, PENRC:CHAR2, KNUMV:CHAR10}}

Answer 1

I just tried with another client-dependent table that exists in my basis system: HRH1222. In this case DDIF_FIELDINFO_GET returns all 11 fields including the MANDT field at position 0001. So everything ok here. And NCo 3.0 is using the output of DDIF_FIELDINFO_GET for constructing its structure information.

A possible explanation what might be the problem in your case: I heard that a certain consulting company (Tata Consulting?) has in a few customer projects modified the standard SAP function module DDIF_FIELDINFO_GET to suppress "unwanted" fields. Among these fields were fields that could carry passwords -- and the MANDT field!

If you have such a modification in your backend, that would explain the behavior we see here...

Answer 2

You are using the table BKPF as an output structure. That table has the key field MANDT for client handling in the first position. You have not shown us the code you use to access the function module, but I would suspect that you somehow "forgot" that there's a client field. Your function module leaves the client field empty (three spaces), so the problem appears to be this:

   what you want to get
    |
   /--\
MMMBBBB
AAAUUUU
NNNKKKK
DDDRRRR
TTTSSSS
\--/
 |
what you really get

Answer 3

As a first step, activate NCo trace at Level4 and take a look, how the data looks like when it comes over the wire.

Make sure that in your test call the FM returns only a handful of lines, because otherwise the data will be compressed, and then you can't see anything... :)

Also interesting would be to see your connection parameters. This looks indeed like a Unicode-Non-Unicode mismatch. (The second half of a 2-byte unicode char being "mis-interpreted" as a terminating zero, if data is accidentally interpreted as 1-byte non-unicode char...)

Normally you should not need to mess with the CODEPAGE parameter, because NCo automatically gets it right... (You can only cause damage, if you explicitly set a CODEPAGE without really knowing what you do.)