When linking to another system through webservices, it's not uncommon to create a service answering a request. Many types of request are possible here, from "get the name of a customer" to "give me the customer open orders" to "place an order". If the third party access is trusted, there's a way to make SAP database read access very easy. Consider creating a webservice for RFC function module RFC_READ_TABLE.

Beware: this article describes how a web service for reading tables from SAP's database from a remote location, which could pose a hazardous security risk. There's some hints an tips on limiting access at the end of tis article.

If your systems are sharing the same network and a direct RFC call is an option, a short explanation of how the RFC_READ_TABLE operates is enough. Let's assume the link is SAP to SAP, as a basis for any link. The module will be called with an instruction to read a table (passed as parameter) with a selection for that table (passed as parameter). Thus if I want to get the description of an article, this is the approach:

• Specify which table should be selected (parameter QUERY_TABLE), in this case the MAKT Material descriptions table
• Specify the selection to be used (parameter OPTIONS), in this case MATNR = somearticle AND SPRAS = language

  The way the options should be composed is vey much like it is coded in ABAP or SQL. This example looks up the description of materials in Dutch (N) for all materials starting with '0':

  APPEND 'MATNR LIKE ''''0%'''' AND SPRAS = ''''N''''' TO LT_OPTIONS. 

  (Don't worry about the enormous amount of '-characters here, this is an Abap matter. Effectively the above coding will put the following line into the options parameter:

  MATNR LIKE '0%' AND SPRAS = 'N'

• Specify the fields that should be returned (parameter FIELDS). This (table) parameter is returned with the DATA table. It holds the list of fields with offset, type and description for the fields selected. Note that this is a changing parameter, specifiy the field names that you want to receive or don't specify any fields - which will make the module return all available fields.
• Speficy no data should be selected (parameter NO_DATA), this can be used to populate the field list for the table of your choice. Normally a preperation step as part of development. 
• Speficy the number of rows that should be skipped (parameter ROWSKIPS), which can be important when large selections are processed. When a selection yields more than e.g. 100 results, you may want to process these results with 100 lines at a time. The RFC call can be done "processing the next 100 lines" and the caller has the controls.
• Specify the maximum number of rows to be selected (parameter ROWCOUNT), which is always a good idea. If the selection is too large, performance will become an issue, both for the actual function module processing as for data-passing in the RFC. Think about this parameter value and set it to a limit.
• The call to the RFC function module is made (in this example from Abap coding, but alternate languages can mimic the same setup).

  CALL FUNCTION 'RFC_READ_TABLE'
    EXPORTING
      query_table = 'MARA'
      delimiter = ';'
      no_data = SPACE
      rowskips = 0
      rowcount = 10
    TABLES
      options = lt_options
      fields = lt_fields
      data = lt_data
    EXCEPTIONS
      OTHERS = 4.
  

• The function module will return a table parameter DATA which holds all selected fields separated by the separator character. It also returns the FIELDS parameter, which lists the fields (columns) on DATA, with description.

  Example output - FIELDS

  FIELDNAME                      OFFSET LENGTH T FIELDTEXT
  MANDT                          000000 000003 C Mandant
  MATNR                          000004 000018 C Artikelnummer
  SPRAS                          000023 000001 C Taalcode
  MAKTX                          000025 000040 C Artikelomschrijving
  MAKTG                          000066 000040 C Artikelomschrijving in hoofdletters voor matchcodes

  Example output - DATA

  WA
  400;0                 ;N;ALTERNATIEF 0.02                        ;ALTERNATIEF 0.02
  400;0 130 101 60DEC   ;N;ELEKTROMOTOR                            ;ELEKTROMOTOR
  400;0 204 114 60DEC   ;N;REMMENSET                               ;REMMENSET
  400;0 204 125 26DEC   ;N;REMBEKRACHTIGER                         ;REMBEKRACHTIGER
  400;0 221 505 42DEC   ;N;BOBINE                                  ;BOBINE
  400;0 242 229 57DEC   ;N;BOUGIE                                  ;BOUGIE
  400;0 242 229 77DEC   ;N;0242229775  BOUGIES                     ;0242229775  BOUGIES
  400;0 242 240 55DEC   ;N;0 242 240 555 BOSCH BOUGIE              ;0 242 240 555 BOSCH BOUGIE

... as webservice

All nice and well - when direct RFC access is available, but what if the third party required access as a web service ? The solution simple and straightforward: a Webservice in SAP is backed by an RFC-enabled function module, and the RFC_READ_TABLE module is such module. All that would need to be done is create the webservice (SE80), enable the parameters and the functionality described in the previous paragraph becomes available through a web service.

What about security

If security is no concern, you're missing an important point. Security IS a concern.

Even though this setup is very flexible, it allows selection from any table in the system. Limit this selection with a bit of custom coding: create an RFC module with the same parameters as the RFC_READ_TABLE which calls the RFC_READ_TABLE. The only additional check is on the QUERY_TABLE name, if it's not in the list of agreed names, simply refuse output. There: best of both worlds. Minimal effort.

• Prev
• Next