topic Re: RFC_READ_TABLE: Fields with type P in Application Development and Automation Discussions

RFC_READ_TABLE: Fields with type P

Former Member — Tue, 23 May 2006 09:01:00 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Former Member — Tue, 23 May 2006 09:05:52 GMT

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

Re: RFC_READ_TABLE: Fields with type P

athavanraja — Tue, 23 May 2006 09:50:36 GMT

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-b686a7b51492

Regards

Raja

Re: RFC_READ_TABLE: Fields with type P

Former Member — Tue, 23 May 2006 10:05:41 GMT

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

Re: RFC_READ_TABLE: Fields with type P

andreas_mann3 — Tue, 23 May 2006 11:49:12 GMT

try,

fm 'TABLE_ENTRIES_GET_VIA_RFC'

it's better . i think

Re: RFC_READ_TABLE: Fields with type P

former_member183804 — Tue, 23 May 2006 14:44:10 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Clemenss — Tue, 23 May 2006 16:28:56 GMT

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

Re: RFC_READ_TABLE: Fields with type P

former_member183804 — Tue, 23 May 2006 16:59:52 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Clemenss — Tue, 23 May 2006 17:10:42 GMT

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

Re: RFC_READ_TABLE: Fields with type P

former_member183804 — Tue, 23 May 2006 17:21:30 GMT

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.

Re: RFC_READ_TABLE: Fields with type P

Former Member — Wed, 24 May 2006 10:23:32 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Clemenss — Wed, 24 May 2006 12:11:55 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Former Member — Mon, 29 May 2006 12:52:45 GMT

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

Re: RFC_READ_TABLE: Fields with type P

former_member183804 — Mon, 29 May 2006 13:29:27 GMT

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

Re: RFC_READ_TABLE: Fields with type P

former_member183804 — Mon, 29 May 2006 13:33:11 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Clemenss — Mon, 29 May 2006 13:56:58 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Former Member — Mon, 29 May 2006 14:39:21 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Former Member — Mon, 29 May 2006 14:50:11 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Clemenss — Mon, 29 May 2006 15:22:27 GMT

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

Re: RFC_READ_TABLE: Fields with type P

Former Member — Tue, 30 May 2006 12:48:49 GMT

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