2

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#.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Namit
  • 331
  • 3
  • 7
  • 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](http://theobald-software.com/en/erpconnect-productinfo.html) to call this from C#/.net. – Random Dev Apr 15 '15 at 13:39
  • you probably won't find anything that flexible. Most connectors use modified versions of RFC_READ_TABLE to bulk load data. I'm not aware of one that supports joins, that would need quite a bit of work on the SAP side of things. And your data buffer problem won't go away just because you use some other BAPI. If you want to load too much data for a single call, your call won't succeed. If you have a limited number of queries, you could create database views for them in the SAP system and load those with a customized RFC_READ_TABLE. – Dirk Trilsbeek Apr 15 '15 at 13:57
  • 1
    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 Apr 15 '15 at 14:33
  • Thanks Carsten / Dirk - icbytes5 : My contact in ABAP Side says that it is very difficult to create a BAPI / RFC that can take sql statement as string and process. I have to provide query upfront and his code will execute that query . Is my knowledge accurate ? – Namit Apr 15 '15 at 19:50
  • 2
    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 Apr 16 '15 at 07:17
  • 1
    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 Apr 16 '15 at 07:23
  • Dirk - I checked with my ABAP contact and he said that they can build view only if they knows query upfront. For every new query they will need to create a new view and which means admin need to evolve. In our case we want to enable our non sap BA with adhoc queries .. and hence the requirements – Namit Apr 16 '15 at 16:04
  • 1
    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 Apr 17 '15 at 10:16
  • I found solution for buffer related issue. Table join is still an issue: http://rfcconnector.com/documentation/kb/0007/ – Namit Apr 17 '15 at 17:18

4 Answers4

4

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

Ogo
  • 41
  • 2
  • Thanks Ogo I have some more followup questions : 1. Thanks . It make sense. 2. My colleague in ABAP side say that he can build in FM / RFC that has predefine query . It is very difficult to have FM that let caller to define query - Do you have any advise on that. 3. You point is valid - i dont see many scenario where our BA need all fields , but problem is 512 KB may be limiting and there was not way to through warning to user that he exceeding. I found some solution to this issues in URL rfcconnector.com/documentation/kb/0007. – Namit Apr 20 '15 at 17:27
  • Hello Namit, 2) is not so difficult, but it is a very VERY bad idea. That was my question at the end of point 3 above. Are you building some completely generic BI tool? You have no information about the queries you can use for hardcoding - limits, filters etc. First of all no sane SAP admin side would let you run such queries against his system (for the record there are products that do it, but...). Regarding 3) It is 512 bytes per line. You can solve your problem by limiting the columns you are interested in. If your answer is "I need all of them", you have a bigger problem. Please tell more. – Ogo Apr 21 '15 at 17:50
3

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

Suncatcher
  • 10,355
  • 10
  • 52
  • 90
Mattias Johansson
  • 723
  • 2
  • 6
  • 22
  • Thanks for reply. Is it possible to have function module in SAP that takes string : perameter - containt sql statement on runtime , we check on ABAP side and process. Idea it to define query at runtime / not compile time. I am open for any solution. – Namit Apr 20 '15 at 17:18
  • It is certainly possible, please see http://scn.sap.com/thread/25114 for an example. But you need to make sure to clean the input data to avoid security holes. – Mattias Johansson Apr 21 '15 at 20:49
-1

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

-1

Alternative table is DDIF_FIELDINFO_GET FM. Please use this for details

maddy7781
  • 157
  • 1
  • 3
  • 8