mapping SAP table to a web page

[Former Member]

hi there,

I'm wondering which is the fastest way to retrieve a table from a SAP system handling web table paging (displaying n records along with Next and Prev buttons).

is there a .Net Connector function or a BAPI to map to that accepts a tablename and delivers its content? second step should be to accept page size and page number as parameters, delivering the requested page:

sapProxy.GETTable("ZDETAILS", 50, 4)

which returns records from 151 to 200 of table ZDETAILS.

any hint about that?

ps. using XML for handling dynamic table structure could be an option...

[Former Member]

I finally reply to myself in case some other has got same question: there are a couple of pre-built rfc bapi in SAP: RFC_READ_TABLE and GET_TABLE_RFC.

a good approach for the usage of the first is clearly described here: http://www.codeproject.com/dotnet/SapDBReader.asp

basically, by using the provided wrapped class DBReader.TableReader (but you can implement your own), you can specify the query, the rows to skip and the amount of rows to read from the SAP table.

[reiner_hille-doering]

Paging is notmally done by the control (e.g. by DataGrid or our Table control in the PDK), not by the proxy. Of cause you would keep the table or the whole proxy that contains the table in Session state.

[Former Member]

hi Reiner,

thank you for your interest.

suppose you have a large table: usually, the data layer is bound to a db server-side cursor, so you don't have to load it entirely in memory.

for example, we have a 'products' page on a web app; the underlying object is bound to a SQL Server view that joins some SAP tables directly, taking advantage of server-side cursors. now, I wish to get the same without direct accessing the db, using RFC instead.

as far as I can suppose, in order to use high-level integration (RFC calls trhough .Net Connector) a SAP function should pass table pages handling server-side cursors with the underlying db. however, I'm not an ABAP expert (I think you already understood that so I might have taken the wrong direction.

[reiner_hille-doering]

You should consider that SAP server is NOT a database, but an application server. You would also not query a table, but execute some business functions (BAPI). Those functions might return so called "internal tables", which are more like arrays in other programming languages. They are anyway stored or created in memory of the Application Server, depending on the business logic it executes. Of cause in many cases the result of a function depends on it's input parameters, but you cannot compare it to a database cursor.

[Former Member]

the BAPI could handle a server-side cursor with the underlying db, taking a table page (n records starting from record y) and passing it to the calling RFC:

SAP DB>BAPI>RFC>.Net Connector>WEB APP

instead of the actual:

SAP DB>ADO.Net>WEB APP

[which could seem better but it relies on physical SAP Tables whose method is discouraged]

so, which is the best method to display the Products in a web page?

if there is no way to let a BAPI handle a server-side cursor with the underlying db used by SAP, then it's not the case to use BAPI and get all the Products, unless we implement a Products mirror table on the web application side refreshing it, say, every night.

if it's the case, I'd prefer the "actual method" above (direct View to the SQL Server which holds the SAP db).

[Former Member]

From the looks of your code it looks like you are hitting a custom RFC function. You can also put paging logic in the function call on the ABAP side.

If your data is not going to change much I would look at using a globally cached dataset object (I've used these successfully), or writing to an XML file.

I would focus on keeping the SAP function operational. If your SAP function is well designed it is much easier to make changes in the data and it is invisible to your application(as long as you are not changing the output/input structure). You always want to design your data pulls from SAP to where you can look at a screen in SAP and get the same results. It makes it so much easier from a user support standpoint. This is much harder to do with direct SQL calls.

You can also bind the full dataset and make the grid scroll, if you just want to manage the size of the screen.

I don't know if any of these will work for you but I thought I would throw them out as scenerios for you to review.

[Former Member]

Hi,

If you have EP 5.0/6.0, try building an iview using the com.sap.pct.srv.portaldataviewer.JCoTableTemplate component.

Easy and standard.