RFC_READ_TABLE: Fields with type P

[Former Member]

Hi All,

I use RFC_READ_TABLE in order to read some table values from another SAP system. This works fine in principle - it returns data converted to characters, which I can access via wa+offset(length). However, I haven't found a way to access fields, which are of type P, e.g. T006-ADDKO. So far I managed to get various short dumps. Any ideas?

(I know the function module is not released to customers. Maybe this is a "feature" ...)

Best regards

Lars

[Former Member]

Hv u checked 'FIELDS' tables in 'RFC_READ_TABLE'. We can specify type FIELDS-TYPE = 'P' while calling the FM

[Former Member]

Hi Vijay,

I think the attributes like TYPE within FIELDS are returned by the function module - any value I specify there when calling the function module seems to be ignored. I got always the same data back, which I failed so far to convert to a variable of type P.

Lars

[andreas_mann3]

try,

fm 'TABLE_ENTRIES_GET_VIA_RFC'

it's better . i think

A.

[tobias_sawitzki]

Hi,

I know the post is a Little older, but I want to share my solution with you. It solves the Problem with X and P fields, but required a Little develompent: (ca. line 105)

* compute the place for contents of next field in DATA rows

*{   REPLACE        OHTK903959                                        1

*\  LINE_CURSOR = LINE_CURSOR + TABLE_STRUCTURE-LENG.

* Correct fields length for decimals an signed numbers

  IF FIELDS_INT-TYPE EQ 'X'.

*    Double length for output

    MULTIPLY FIELDS_INT-LENGTH_DST BY 2.

  ELSE.

    IF FIELDS_INT-TYPE EQ 'P'.

      IF FIELDS_INT-DECIMALS GT 0.

*        Additional space for decimal dot

        ADD 1 TO FIELDS_INT-LENGTH_DST.

      ENDIF.

    ENDIF.
    IF TABLE_STRUCTURE-SIGN EQ 'X'.
*      Additional space for sign
      ADD 1 TO FIELDS_INT-LENGTH_DST.
    ENDIF.

  ENDIF.
  LINE_CURSOR = LINE_CURSOR + FIELDS_INT-LENGTH_DST.

*}   REPLACE

There has to be +1 additionol length für P with decimals and +1 for the sign (if negative).

For X fields the length has to be doubled, because the Output length of a hex value is double its length.

TABLE_ENTRIES_GET_VIA_RFC did not work for me. I was e.g. reading the table PA0007. It has numeric fields, witch dupm, when requested with this fm.

Hint for reading tables longer than 512 signs:

Make a first call with

NO_DATA = 'X'

Then you get the list of all fields. Then request the data in blocks of max 512 length. E.g. by Looping the table FIELDS, adding the FIELDS-LENGTH until 512 is reached. Then request the data and do another round, until all fields are read. Meybe you have to check no data was modified in this period. But the sorting of results will stay the same.

Regards

Tobias

[Sandra_Rossi]

A 10 years post, wow! For which release did you make it work? Thx

[tobias_sawitzki]

The Release is

SAP ECC 6.0 - 700

But I think the FM might not have been chaned by SAP, since it is not released for customers yet

This Post was the first I found when searching for a solution, so I postet my own solution here, even the thread is old. Maybe someone else will find the solution here, too.

Regards

Tobias

[matt]

Generally speaking, it's not a good idea to answer old questions. In this case though, I think it was appropriate. However, if you wish to continue the discussion, please start a new one - and link to this one.

Thanks

[athavanraja]

Welcome to SDN

check this oss note (382318) about using RFC_READ_TABLE

you may be interested in this code sample.

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f50dcd4e-0501-0010-3596-b68...

Regards

Raja

[former_member183804]

Just one more feature that does not require developer access at the destination. The select statement has the option to define a RFC target ( keyword Connection ). This of course requires an authorization one should not have.

Best Regards

Klaus

see /nabaphelp select source connection

[former_member183804]

Hello Lars,

the RFC_READ_TABLE fubas are only sample stuff and lack also in some other respect than only p Fields. As already mentioned a Fuba with xString-Table and Serialization can solve your requirements. But different to the mentioned PDF the use of export/import from/to data buffer is superior to call transformation in this case. It is much faster and offers better compression. The only reason for XML might be if you cross relase boundaries.

Additionally it is to mention that such a RFC might introduce a security leak. Please use AUTHORITY-CHECK to ensure a proper permission.

Best Regards

klaus

[Clemenss]

OK fellows,

I put a similar question here some time ago and did not get really helpful answers - but I am successful with any kind of tables and fields now (after having had dump after dump and try after try):

1. I use a structure of veri_raw (uninterpreted sequence of 2048 bytes) for the transfer table.

2. Numerical fields are 'aligned' in ABAP: You can get the actual offset and length (x031l-dblength) using FUNCTION 'DD_RTOBJ_GET'

3. Put the determined part of the record into a temporary field of raw type.

lv_tabrec = <ft>+<x031l>-offset(<x031l>-dblength).

assign the appropriate part of this to an untyped field-symbol (type any) casting the desired type:

ASSIGN lv_tabrec(<x031l>-dblength) TO <fs>

CASTING TYPE (<x031l>-rollname).

The field-symbol <fs> carries whatever field you assigned. No dumps except for fields without <x031l>-rollname.

I'm not sure why I need the temporary field between, but I had dumps when assigning directly with given offset.

I used this in 640 unicode for a RFC table compare program - tens of thousands of tables checked successfully.

Hope this really helps,

Clemens

[former_member183804]

Hello Clemens,

a table of type Xstring will also do, and be a little more comfortable. Bt regarding field-symbols and casting I have strong concerns. This might cause lots of problems when crossing system boundaries (little/big endian, (non) unicode). What was your reason not to use export/import or call transformation ?

Regards,

Klaus

[Clemenss]

Hi Klaus,

XSTRING does not work at all because you can't assign offsets with length in xstrings. So not much more comfort. I don't even know if you can select into xstrings, but I didn't try.

You may be right with your conversion concerns. Our situation is a typical 3-system-landscape with technical idetical systems - so ther is nothing to bother.

My solution allows to get data of any table in any type from any system reached by RFC.

And it works without implementing anything in any system except the calling one - this makes the difference and is the reason not to use any method recommended by you.

There may be so many better solutions not running yet.

regards,

Clemens

Message was edited by: Clemens Li

[former_member183804]

Hello Clemens,

the xString is only to carry the data between both systems. Of course you have to deserialize it at the end.

Regards

Klaus

Report Kzi_test_01.
  data: cur_Info type xstring, all_Infos type standard table of xstring.
  data: cur_Line type Tadir,   all_Lines type standard table of tadir.

" get data / serialize at rfc target "
  select * from Tadir up to 20 rows into table all_Lines.
  loop at all_Lines into cur_Line.
    export data = cur_Line to data buffer cur_Info.
    append cur_Info to all_Infos.
  endloop.

" deserialize in local system "
  loop at all_Infos into cur_Info.
    import data = cur_Line from data buffer cur_Info.
    write: / cur_Line-Obj_Name.
  endloop.

[Former Member]

Hi All,

thanks for all the answers!

Unfortunately I cannot use TABLE_ENTRIES_GET_VIA_RFC due to Unicode and not having the possibility to restrict the SELECT to a list of fields.

I thought there may be a possibility with RFC_READ_TABLE, also on fields of type P. Then I have either to live without P fields or to write something my self.

Best regards

Lars

[Clemenss]

Hi Lars,

I'm quite sure it works with my approach posted earlier. Do you have a table name for trying?

I tried with T001K with type P field BDIFP and it works perfect. We are on SAP ERP Central Component 5.0, BASIS 640, Unicode.

Regards

Clemens

[Former Member]

Hi Clemens,

you wrote your own function module, right?

I would like to use an existing one like RFC_READ_TABLE, since I do not have development access to some of the systems I would like to call.

Best regards

Lars

[former_member183804]

Hello Lars,

one other feature that does not require developer access is to use a RFC target in the select statement:

select * From {db-table} connection {rfc-dest} ....

This of course requires an authorization one should not have :(=.

Best Regards,

Klaus

[Clemenss]

Hi Lars,

no I did not write my own function module. I wrote a report as temporary object on development system and I can read tables from all systems including productive system.

Did you try the way I suggested earlier?

Regards,

Clemens

[Former Member]

Hi Klaus,

our Basis team was clever enough not to define the destinations in table DBCON. ==> I get short dumps.

Was a nice try anyway ...

Best regards

Lars

[Former Member]

Hi Clemens,

hm, I tried to call RFC_READ_TABLE using a table for the data based on veri_raw. I already get a short dump when I call the FM (CX_SY_DYN_CALL_ILLEGAL_TYPE). The reason may be that we are on Unicode. I also tried to define a new data element and domain for RAW 512 (since the data table in the FM interface has got a record length of 512 characters) and failed again.

Best ragards

Lars

[Clemenss]

Hi Lars,

our system is SAP ERP Central Component 5.0, SAP_BASIS 640, SAP_ABA 640, ORACLE 9.2.0.7.0, Unicode.

I won't post the whole program here (too much and too specific), just the most 'critical' pieces:

PARAMETERS:

p_rfc1 TYPE rfcdes-rfcdest.

TYPES:

tabrec TYPE veri_raw,

ty_t_tabrec TYPE STANDARD TABLE OF tabrec.

...

DATA:

lt_tabrec_1 TYPE ty_t_tabrec,

lv_dbcnt1 TYPE sy-dbcnt.

FIELD-SYMBOLS:

<tabname> TYPE tabname.

• get table entries from 1st destination

PERFORM rfc_tab_get

USING p_rfc1 <tabname>

CHANGING lt_tabrec_1 lv_dbcnt1.

...

&----

---

*& Form rfc_tab_get

&----

---

FORM rfc_tab_get USING pv_rfc1 TYPE rfcdest

pt_tabname TYPE tabname

CHANGING pt_tab TYPE table

pv_dbcnt TYPE sydbcnt.

CALL FUNCTION 'RFC_GET_TABLE_ENTRIES' DESTINATION pv_rfc1

EXPORTING

table_name = pt_tabname

max_entries = p_maxrec

IMPORTING

number_of_entries = pv_dbcnt

TABLES

entries = pt_tab

EXCEPTIONS

OTHERS = 0.

ENDFORM. "rfc_tab_get

Note: <tabname> is used with loop ... assigning and an internal table for all tables to be read.

Check if your table type is wrong or you are on a system^I don't know what kind of. And one more hint: If you want to test it, use DESTINATION NONE. May be you got the dump because you tried to execute without DESTINATION.

Keep on steady,

Clemens

[Former Member]

Hi Clemens,

thanks for the hint regarding DESTINATION 'NONE' - no short dump anymore!

I got it working with RFC_GET_TABLE_ENTRIES, but failed on RFC_READ_TABLE (data looks shifted somehow). By the way, I didn't need the temporary raw variable before the ASSIGN.

RFC_GET_TABLE_ENTRIES does not have the possibility to specify the field values - how do you read tables with a wide record structure like VBAP (exceeded 512 characters)?

Secondly, RFC_GET_TABLE_ENTRIES does not have a parameter for the WHERE clause. But there is a generic key, which I didn't get working.

Thanks again for all your help!

Best regards

Lars

[Former Member]

Hi lars,

1. Secondly, RFC_GET_TABLE_ENTRIES does not have a parameter for the WHERE clause. But there is a generic key, which I didn't get working

Eg. If we give table name T001

and give Generic key as 1000

then it fetches the record for that

company code 1000.

regards,

amit m.

[Clemenss]

Hi Lars and Amit,

nice thread, learned a lot!

I used RFC_GET_TABLE_ENTRIES to compare sets of customizing tables between systems. So I did not need any restrictions, just fetched the whole table using RFC_GET_TABLE_ENTRIES. So similar that I did not realize we are talking about RFC_READ_TABLE all the time. - But it worked fine...

Anyway. I just tried VBAP and it finally dies at field PS_PSP_PNR. The assign casting is faulty in this case, it shows '########' for '00000000'. When I use a 'write to' for this value, it goes through conversion exit ABPSP and dumps because '########' can not be interpreted as a number.

I don't know yet how to overcome this situation.

Anyway, I think RFC_GET_TABLE_ENTRIES could work with VBAP because the buffer size in the function is 4100 characters (8200 bytes unicode) and the unicode length of VBAP is 2328.

If you have any idea regardig the above casting: Let me know!

Regards,

Clemens