我写了一个自定义RFC,它从BKPF读取特定数据并返回它。
当我在SAP Gui中测试它时,功能模块工作得非常好,但是当我通过.Net Connector 3.0驱动程序从.Net应用程序使用它时,我在BUKRS而不是'IP01'中得到'I'值(有3个空格)。
我在连接参数中尝试了几个代码页但没有改变。
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.
它是函数体,如前所述它返回表BKPF中的一些行,并且在SAP Gui中测试时工作正常,但是当通过.Net Connector调用时,BUKRS的值返回'I'而不是'IP01'
在看了BKPF的结构之后,我发现SAP(MANDT,BUKRS)中的结构与我在.Net中查看table.Metadata.LineType
时得到的结构之间存在差异。
{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}}
您正在使用表BKPF
作为输出结构。该表具有关键字段MANDT
,用于第一个位置的客户端处理。您没有向我们展示您用于访问功能模块的代码,但我怀疑您以某种方式“忘记”有一个客户端字段。您的功能模块将客户端字段留空(三个空格),因此问题似乎是这样的:
what you want to get
|
/--\
MMMBBBB
AAAUUUU
NNNKKKK
DDDRRRR
TTTSSSS
\--/
|
what you really get
作为第一步,在Level4激活NCo跟踪并查看数据在线路上的样子。
确保在测试调用中FM只返回少量几行,否则数据将被压缩,然后你看不到任何东西...... :)
同样有趣的是看到你的连接参数。这看起来确实像Unicode-Non-Unicode不匹配。 (如果数据被意外解释为1字节的非unicode char,则2字节unicode char的后半部分被“误解”为终止零...)
通常你不需要弄乱CODEPAGE参数,因为NCo自动正确...(你只能在没有真正知道你做什么的情况下明确设置CODEPAGE时造成伤害。)
我刚尝试了另一个依赖于客户端的表,它存在于我的基础系统中:HRH1222。在这种情况下,DDIF_FIELDINFO_GET返回所有11个字段,包括位置0001的MANDT字段。所以一切都可以。而NCo 3.0正在使用DDIF_FIELDINFO_GET的输出来构造其结构信息。
可能的解释可能是您的案例中的问题:我听说某个咨询公司(Tata Consulting?)在一些客户项目中修改了标准SAP功能模块DDIF_FIELDINFO_GET以抑制“不需要的”字段。在这些领域中有可以携带密码的字段 - 以及MANDT字段!
如果你的后端有这样的修改,那就解释了我们在这里看到的行为......