Field becomes blank when update statement is executed

[Former Member]

Hi experts,

I am working in SAP Netweaver PI (Process Integration). I am facing an issue while writing a function module in ECC.

The function module updates a database table in ECC system (not PI system).

TABLE:

FUNCTION MODULE:

Import parameters of function module:

IF_NAME               TYPE     CHAR_02 (Character of length 2)

SENDER_DATE     TYPE     CHAR_08   (Character of length 😎

Export parameter:

V_OUTPUT     TYPE     INT

CODE:

FUNCTION ZFILE_COUNTER.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IF_NAME) TYPE  CHAR_02
*"     VALUE(SENDER_DATE) TYPE  CHAR0008
*"  EXPORTING
*"     VALUE(V_OUTPUT) TYPE  INT1
*"----------------------------------------------------------------------
   TABLES zfile_counter.
TYPES:  BEGIN OF ty_zfile_counter,
           mandt TYPE zfile_counter-mandt,
           if_name TYPE zfile_counter-if_name,
           cntr_value TYPE zfile_counter-cntr_value,
           curr_date TYPE zfile_counter-curr_date,
END OF  ty_zfile_counter.

DATA: wa_zfile_counter  TYPE ty_zfile_counter.

CLEAR: wa_zfile_counter.

SELECT SINGLE mandt if_name cntr_value curr_date
   FROM zfile_counter
   INTO wa_zfile_counter
   WHERE if_name = if_name.

IF sy-subrc = 0.

   IF sender_date <> wa_zfile_counter-curr_date.

       wa_zfile_counter-cntr_value = '0'.
       wa_zfile_counter-curr_date = sender_date.

       UPDATE ZFILE_COUNTER from wa_zfile_counter.
      
        COMMIT WORK.

   ELSE.

     v_output = wa_zfile_counter-cntr_value + 1.

       UPDATE zfile_counter SET cntr_value = v_output
       WHERE if_name = if_name.

       IF sy-subrc = 0.
         commit WORK.
       endif.

ENDIF.
ENDIF.
ENDFUNCTION.

*********************************************************************************************************

PI will call the above function module whenever it receives a message from system, say system-A.

The import parameters of FM, will be sent from PI, when the function module is called in PI using RFC lookup feature.

IF_NAME is always a constant = "PI" (There is only going to be one record in the DB)

SENDER_DATE is the current date (i.e) date when PI calls the function module. This is sent as an 8 char number (eg: "20121026" for 26-Oct-2012)

So, the SENDER_DATE is just considered as a character string here and not as data-type: date.

AIM OF FN.MODULE:

The aim of the function module is to return a counter value, incremented by 1 each time the fn. module is called, which will be used in PI to maintain count of files coming in, during a single day. BUT, when a message comes on the next day, the counter value should be reset to 0 and start again.

LOGIC:

PI sends the current date when the first file comes into PI. This will be updated in field "CURR_DATE" of table in the ECC system by the function module. When next message comes into PI, again the fn. module is called and PI sends current date. This is checked with the value already there in CURR_DATE. If, there is a match, (it means the second file was also received on same date), the counter value is increased by 1 and returned. Like this the process continues.  So, during any given time of the day, the total number of files received by PI will be stored in the table.

HOWEVER

When a message comes to PI on the next day, the date sent by PI for the function call (SENDER_DATE) will not be equal to CURR_DATE of the DB table. (Because, CURR_DATE will have previous day's date) So, the counter value will be reset to "0" and the field CURR_DATE of the table will be updated with the value of SENDER_DATE.

ISSUE:

I filled the table like this before first execution of function module: (random values to prevent the first SELECT query from failing)

(CURR_DATE = 25-Oct-2012)

When I called the function module from PI, the first time, the table got updated as below:

(SENDER_DATE = 20121026) **refer to PI trace below**

The counter value was correctly reset to "0" (since CURR_DATE does not match with SENDER_DATE), but the date string did not get updated in CURR_DATE.

When the second file came in to PI and function module was called second time, the table was updated like this:

So, obviously, there is some issue with CURR_DATE field but I cant find it. The data types are all the same.

The value passed by PI is STRING, the type of the import parameter, SENDER_DATE is CHAR and the type of the field CURR_DATE of DB table is also CHAR.

EXTRACT FROM PI TRACE:

PI also seems to be sending the correct value while calling the RFC. Any suggestions to remedy this are most welcome !!

thanks & regards,

Manoj

[Former Member]

Hello,

You can refer to SAP Note 730870 - FAQ XI 3.0/7.0/7.1/7.11/7.2/7.3 RFC Adapter see Question 24 below:

Q 24:  It seems that the RFC-Adapter does not convert every parameter of the function module between native RFC and RFC-XML. It looks like some parameter is lost or empty. Why does this happen? 
              A: The conversion between native RFC and RFC-XML is done by using the metadata provided by the metadata repository, which is an SAP-system. Before the first call to one function module it's metadata is retrived from the SAP-system and stored in a local RFC-Adapter cache memory. Each successive call to the same function module uses this cache which is much faster. 
              If the signature of the function module is changed in the SAP-system  this change also has to be done in the RFC-Adapter's cache memory. The possible solutions do accomplish this are described in Q5. 
              In case of an RFC receiver channel, the called function module in the  SAP system can be debuged with the ABAP debugger. This way the actual  used parameter values of the request and the response can be viewed in  the ABAP debugger. Note 668256 describes the procedures for ABAP remote debugging. 
              See also Q 18 which is related to this one.  

Hope this helps,

Mark

[Former Member]

Hi,

Use MODIFY statement instead of UPDATE ZFILE_COUNTER from wa_zfile_counter.

The statement MODIFY updates an existing database entry and inserts a new one if there is no existing such entry. No need to manually maintain data in the table as you are doing in case of UPDATE.

Thanks,

Anubhav

[Former Member]

hello,

The field curr_date should be a key of the table.

best regards,

swanand

[Former Member]

Hi Anubhav,

     The requirement is to have only one record in the table. The same record should be overwritten each time the FM is called.

But the field CURR_DATE alone becomes blank instead of getting updated with the value of SENDER_DATE.

Reg,

Manoj

[Former Member]

Hi,

First of all, thanks for having descibed your issue so clearly!! It is not so often that issues are so well presented in here

You code is ok to me... nothing to change here! If you test the function from ECC directly, this will work like a charm...

So I guess the problem relies in the PI declaration type... Have you tried changing it to a char type instead of string? or the other way around use a type string in your table and function?

Cheers,

Manu.

[Former Member]

Hi Manu,

Thanks !!

After checking with the help of external debugger, I found that though in PI log (pasted in my post) it shows that the date value (SENDER_DATE) is being sent by PI with some value, when the RFC is actually called, this value goes missing.

I am checking why this data loss occurs. Will update soon.

Regards,

Manoj

[markangelo_dihiansan]

Hello,

You can refer to SAP Note 730870 - FAQ XI 3.0/7.0/7.1/7.11/7.2/7.3 RFC Adapter see Question 24 below:

Q 24:  It seems that the RFC-Adapter does not convert every parameter of the function module between native RFC and RFC-XML. It looks like some parameter is lost or empty. Why does this happen? 
              A: The conversion between native RFC and RFC-XML is done by using the metadata provided by the metadata repository, which is an SAP-system. Before the first call to one function module it's metadata is retrived from the SAP-system and stored in a local RFC-Adapter cache memory. Each successive call to the same function module uses this cache which is much faster. 
              If the signature of the function module is changed in the SAP-system  this change also has to be done in the RFC-Adapter's cache memory. The possible solutions do accomplish this are described in Q5. 
              In case of an RFC receiver channel, the called function module in the  SAP system can be debuged with the ABAP debugger. This way the actual  used parameter values of the request and the response can be viewed in  the ABAP debugger. Note 668256 describes the procedures for ABAP remote debugging. 
              See also Q 18 which is related to this one.  

Hope this helps,

Mark

[Former Member]

Hi Mark,

Thank you very much! I referred to the above note. The solution was quite simple:

Earlier, I had changed the data-type of SENDER_DATE several times while debugging.

I also had re-imported  the function module into PI's Integration Repository, every time I changed it in ECC. However, this would have updated only the RFC definition in the metadata repository and the cache would have still been containing the old definition.

As suggested in the note, I changed the communication channel involved as well and re-activated it. This cleared the metadata cache. After this, when the FM was called from PI, the value of SENDER_DATE was propagated to ECC correctly, since the newer definition of the FM would have been loaded into the cache !!

Thanks again Mark!

Manoj