Functional Description 

The SAP Data Provider is based on the push model. This means that, before a control can reference a data object, the data is always passed from the server to the client as an internal table (by RFC).

Each data object has a unique name, which usually has the syntax

sapr3://<GUID>

and is known as the URL. To reference a data object, you specify its URL.

Data on the client side is often represented as internal tables, but there are also typical interfaces for mass data. These forms of representation are known as media. When accessing data, you specify the desired medium. The data is then represented accordingly, and converted if necessary.

Each data object on the client side is described by the attributes Type and SubType, which are closely related to the MIME types used in the Internet and are known as the format. Conversions between different media depend on the format of the data object, since different conversions are available for different formats. You can also convert data objects between different formats, depending on the source and target formats.

When transporting data from the client to the server, the same principle applies. You can place data in the Data Provider object using any medium you like. If there is no URL, you must assign one to the data object via the SAP Data Provider. You can then specify this URL in order to pass the data object as an internal table to the application server.

To enable access to non-SAP data sources, the SAP Data Provider can also process URLs in the http:, ftp:, and file: namespaces. The procedure for these is identical to that described above, except that the data is not passed from the application server to the client via a push model, but loaded in a pull model from the relevant server.

Use of MIME Types

To describe Binary Large Object (BLOB) data, MIME types are used. This allows you to manage the conversion of different types of BLOB data, and permits access to the data objects themselves.

By specifying a MIME type or part of a MIME type before accessing a server, you can ensure that a data transfer is triggered only if data of the relevant type exists.

If data exists in several different formats, specifying MIME types also allows you to specify which format is to be used. The rules governing this are listed in the table below:

 

MIME type specification	Processing
Type and sub-type specified	Only this MIME type is processed.
Either type or sub-type specified	Only data corresponding to the specified part is processed. The other part is ignored or interpreted as a wildcard.
Neither type nor sub-type specified	All data is processed. This can result in unnecessary server accesses and consequently worse performance.

 

You must specify a MIME type for BLOB data, otherwise the data is not accepted and an error occurs.

·        If no suitable standard MIME type exists for a data object, you can use any name:

¡        The main type should always be called application

¡        The sub-type should always begin with x- (for example, application/x-myspecialtype).

·        If the MIME type is irrelevant, use application/x-unknown.

·        If you want to transport your own non-standard MIME type from/to an http: server, do one of the following:

¡        Use the standard MIME type application/octet-stream

¡        Register your own MIME type on the http: server.

When transporting BLOB data as an internal table to the client, you should specify the size of the BLOB data. If you fail to do this, the assumed size is the number of lines multiplied by the width of the table.

Typed Tables

When transporting typed tables, you need to know the structure in the client.

You always use application/x-r3table as MIME type. Also passed in this case is a table of the type RFC_FIELDS, which describes the actual data table. For this type of data object, there is a conversion object, which meets the requirements of typed tables.

To transport typed tables, there are function modules in the function group CNDP.

·         When transporting typed tables from the client to an ABAP program, you should first transport an empty table of the same type to the client. This way, the program/control in the client can fill the table, and you can transport it back to the server any time you like.

·         You cannot transport typed internal tables from or to http:, ftp: or file: servers, because this would require a known and secure protocol for serializing internal tables. It makes more sense to switch to OLE DB and Active Data Object (ADO). The required format conversion object is registered under the MIME type application/x-rowset.

·         There is no delta management in RFC between the SAP GUI and the application server. For this reason, you are not recommended to send tables to the client, modify them, and then request them again from the application server. You can try to store the modification in your own table, but this does not make sense for BLOB data, because modifying BLOB data in ABAP programs is not always reliable.

Data Transfer from ABAP Program to Client

...

       1.      The ABAP program calls CONTROL_CREATE, or another create module, to create a control to handle the BLOB data.

       2.      The ABAP program reads the BLOB data into an internal table.

       3.      The ABAP program calls a function module such as DP_SEND_STREAM, which provides parameters for the internal table that holds the data, the size of the BLOB data in bytes, and the MIME type of the BLOB data.

...

                            a.      The called function module gets some system information and calls DP_CREATE_URL.

                            b.      DP_CREATE_URL generates a unique name (sapr3://<GUID>) for the current data object.

                            c.      DP_PUT_CLIENT_TABLE is called in the SAP GUI (SAPAWRFC.DLL) and receives the internal table, the size and the MIME type of the data, the URL, and the system information.

                                                  i.       DP_PUT_CLIENT_TABLE attaches the internal table to an ISAPrfcITab interface.

                                                ii.       A reference to the ISAPrfcITab interface, the MIME type, the size of the BLOB data and other system information are stored in the global object LocalTables together with the URL and also an identifier for the current context.

                                               iii.       DP_CREATE_URL returns the name (URL), under which a reference to the internal table was stored in LocalTables.

       4.      The control generated in point 1 knows and generates a Data Provider object. If not, go to point 5.

...

                            a.      The URL of the data object is communicated to the control by CONTROL_SET_PROPERTY or CONTROL_CALL_METHOD.

                                                  i.       The control generates a Data Provider object.

                                                ii.       In the Data Provider object, the control calls (for example) the method SetDataFromUrl, using the URL as parameter.

The Data Provider object generates a reference to the global LocalTables object.

The URL is passed to the LocalTables object. This gives the Data Provider object a reference to the ISAPrfcITab interface.

                            b.      The control reads the data using a property of the Data Provider object.

                                                  i.       The Data Provider object returns the data according to the access medium required by the control. Access to data is not necessarily via the ISAPrfcITab interface, it can be via any standard COM interface (IStream, ILockBytes, IUnknown, VARIANT,…)[1]

                            c.      Go to point 8.

       5.      The ABAP program calls the function module DP_CREATE, which generates a Data Provider object in the client.

       6.      The ABAP program calls the method SetDataFromUrl of the Data Provider object and passes the URL as essential parameter.

...

                            a.      The Data Provider object generates a reference to the global LocalTables object.

                            b.      The URL is passed to the LocalTables object. This gives the Data Provider object a reference to the ISAPrfcITab interface and all additional information.

       7.      The control generated in point 1 does not know the SAP Data Provider.

...

                            a.      The ABAP program calls CONTROL_ASSIGN_PROPERTY2, which assigns a property of the Data Provider object to a property of the control.

Depending on the type of data, the MIME type and the property (medium) used, the data is passed to the control.

       8.      The transaction ends.

       9.      A new transaction starts.

...

                            a.      The SAP GUI recognizes that the last transaction has ended.

                            b.      The SAP GUI generates a reference to the global LocalTables object and informs the object that the last transaction has finished by passing the context identifier of the finished transaction.

                                                  i.       The LocalTables object deletes all references to tables that have the specified context identifier and releases these references (Garbage Collection)

Other Data Sources

If the data object does not originate from the ABAP program, but from an external source, you can use the same process, with the following exceptions:

·        Omit points 2 and 3 for transfer to the client

·        Get the reference to the data object via the URL.

At present, the ftp:, http:, and file: namespaces are supported.

Data Transfer from Client to ABAP Program

...

       1.      The ABAP program calls CONTROL_CREATE, or a similar module, to create a control.

       2.      The control generated in point 1 knows the Data Provider object. Otherwise, go to point 3.

...

                            a.      The control generates a Data Provider object.

                            b.      The control gives the Data Provider object a reference to its data in a suitable medium.

                            c.      The control calls the method SaveDataToUrl in the Data Provider object. Either the control specifies the URL, or the Data Provider object generates a URL with the syntax „sapr3://<GUID>“.

                                                  i.       The Data Provider object generates a reference to the global object LocalTables.

                                                ii.       Both the URL and a reference to the data object are passed to this global object.

                                               iii.       Go to point 4.

       3.      The control generated in point 1 does not know the Data Provider object.

...

                            a.      The ABAP program generates a Data Provider object with DP_CREATE.

                            b.      The ABAP program generates an appropriate format object.

                            c.      The ABAP program calls CONTROL_ASSIGN_PROPERTY2, which assigns a property of the control to a property of the format object. This control property contains the data or a reference to the data.

                            d.      The ABAP program calls the method SaveDataToUrl in the Data Provider object.

                            e.      Continue as under 2.c.

       4.      The data is transferred to the ABAP program.

...

                            a.      The ABAP program calls the function module DP_GET_STREAM, which contains an internal table as a parameter to store the data and the URL of the data object from 2.c.

                            b.      DP_GET_STREAM calls the function DP_GET_CLIENT_TABLE in the SAP GUI (SAPAWRFC.DLL) and passes the URL and the table.

                                                  i.       DP_GET_CLIENT_TABLE generates a reference to the global object LocalTables.

                                                ii.       The URL is passed to the LocalTables object and returns a reference to the data object.

                                               iii.       The data object is copied to the internal table passed to DP_GET_CLIENT_TABLE.

                                               iv.       The reference to the data object is deleted from the LocalTables object and released.

                            c.      As result, DP_GET_STREAM returns the data, the MIME type and the size of the BLOB data in bytes.

Other Data Storage Options

You can also store data on ftp:, http: or file: servers. To do this, all you have to do is assign the data and call the method SaveDataToUrl in the Data Provider object.

Since these or similar procedures for sending and receiving data are required again and again, the most important steps are encapsulated in ABAP function modules.