Bypass RFC_READ_TABLE limitations

2
votes

For my C# application I need to access some data from SAP Tables based on use selections. In this context I made use of .net connector + RFC_READ_TABLE to read the data from single table and it works. After further review I found 3 issues with this approach.

  1. RFC_READ_TABLE is not supported RFC from SAP , so most expert agree that it should not use in production

  2. RFC_READ_TABLE does not support table join.

  3. Select * query does not work for most cases as data_buffer_exceed error is thrown

I did some research on ABAP side and I did not find any alternative API / RFC / BAPI that can accept SQL statement as input argument on runtime.

I need something like DataTable in C#.

4
abapsaprfc
I know it is not exactly an answer but maybe you are interested in it anyway: our workflow between .net and SAP is usually this: the ABAP programmer creates a BAPI and I use a software called ERPConnect to call this from C#/.net. - Random Dev
Create or tell Your collegues, to create a Z-function module. Especially one for each data-query. Seperation of concerns and no sql-statement needed as argument, Some parameters could be number of maximum results to reduce overhead, or some range tables with the proper fieldnames and options to specify a nicer where clause on the client-side. Then call it, as already told, via ERPConnect or as You are doing, via .net connector. It is not hat hard to write an mutexed .net method, which calls the sap-rfc module. - icbytes
That is one way. If you have several queries and you really only need queries, no business logic, you could, as mentioned, use database views instead. Your DB Admin would create those views in the SAP system and you could query the view with RFC_READ_TABLE (or a modified version of that, the original function module has some limitations). The advantage would be that your SAP guys don't have to maintain several BAPIs and you work with the same BAPI all the time, just changing the parameters for the different queries. - Dirk Trilsbeek
regarding RFC_READ_TABLE, ask your ABAP guys to have a look at SAP Note #758278. It should contain more information about modifications to the function module to get around some of its limitations. - Dirk Trilsbeek
as mentioned before, dynamic queries will be quite difficult. Both Z-BAPIs and Views will need you to define the queries in advance. - Dirk Trilsbeek

4 Answers

4
votes

1) RFC_READ_TABLE is not supported RFC from SAP ==>> This is used by millions of customers and within SAP's own development all over the place. This IS the official API for generic table access. Use it and worry not.

2) RFC_READ_TABLE does not support table join ==>> You can always join in your own application. If you don't want to do it or cannot do it (like performance reasons) then ask your ABAP contact to prepare a RFC-enabled function module for you. That has nothing to do with a thing being a BAPI. BAPI means something completely different. BAPIs can be very difficult, that is correct, but RFC enabled query function is not a BAPI. BAPIs happen to be RFC-enabled quite often, but there is no link between those things.

3) Select * query does not work for most cases as data_buffer_exceed error is thrown ==>> With all due respect you are not supposed to be reading everything anyway, you need to do your research first and request only those fields you really need. Unless this is some sort of a BI generic tool, you don't need all fields. I can tell from the experience.

cheers Otto

3
votes

To allow .NET client app to send an unchecked SQL statement is a bad idea both security- and performance-wise.

The standard way would be to either create remote enabled function modules or use Gateway to expose data as ODATA.

http://scn.sap.com/community/gateway

-1
votes

Alternative table is DDIF_FIELDINFO_GET FM. Please use this for details

-1
votes

As of now there is no join in RFC_READ_TABLE. However the steps that you could incorporate (which is a lengthy one) is:

  1. Create a batch file to pass your input SAP tables as parameters to your code.

  2. Extract relevant data by putting filters (which is possible) in RFC_READ_TABLE or RFC_GET_TABLE_ENTRIES to get the structure & data separately; since RFC_READ_TABLE has 512 byte limitation - which can be bypassed by using RFC_GET_TABLE_ENTRIES FM.

    Note: But data in the 2nd FM is in one string, which you need to filter based

    on the structure that you have extracted.

  3. Now you should have 2 outputs of both the tables.

  4. Upload them to MS Access via a simple batch job, which should be fully automated.

  5. Once uploaded to MS Access, please write your join to connect both.

Check out my video - where I have bypassed the 512 byte.

I have 2 more videos up in youtube.

Hope this helps.

Thanks

Ram.S