cancel
Showing results for 
Search instead for 
Did you mean: 

Performance Issues using JCo Server to extract tables using RFC_STREAM_READ_TABLE

atemsah-incorta
Explorer
0 Kudos
319

Hi

We've been developing some Function Modules to extract data and it behaves in a way like RFC_STREAM_READ_TABLE where we process data then send to another system (The calling system) using remote RFCs (Callbacks) defined on that server.

Here's a sample of how we call that remote function from our SAP System

CALL FUNCTION callback_fm1                            "#EC *
        DESTINATION 'ZINC_JCO_SERVER' "'BACK'
        KEEPING LOGICAL UNIT OF WORK
        EXPORTING
          e_no_more_data        = abap_false
        IMPORTING
          eop                   = ieop
        TABLES
          e_table               = <target_table>
        EXCEPTIONS
          read_error            = 1
          system_failure        = 2  MESSAGE error_message
          communication_failure = 3  MESSAGE error_message
          OTHERS                = 4.

However I've had a couple of issues with this starting with errors of `This method is not defined on the server`, since the function module is only available on the SAP JCo Server I had to statically create it's template

JCoCustomRepository temsahServRepo = JCo.createCustomRepository("TemsahServRepo");

JCoListMetaData tables = JCo.createListMetaData("TABLES");

JCoRecordMetaData record = JCo.createRecordMetaData("e_table");
record.add("ROW", JCoRecordMetaData.TYPE_CHAR, 4096, 0, 8192, 0);
record.setRecordLength(4096, 8192);
tables.add("e_table", JCoMetaData.TYPE_TABLE, 0, 0, 0, null, null, 0, record, null);

tables.lock();

JCoListMetaData importing = JCo.createListMetaData("IMPORTING");
importing.add("e_no_more_data", JCoMetaData.TYPE_CHAR, 1, 2, 0, null, null, JCoListMetaData.IMPORT_PARAMETER, null, null);
importing.lock();

JCoFunctionTemplate pingTemoTemplate = JCo.createFunctionTemplate("Z_PING_TEMO", importing, null, null, tables, null);
temsahServRepo.addFunctionTemplateToCache(pingTemoTemplate);

My problem with this is that I have to define the table record as a char array and then deserialize that manually.

1. Is there a way to dynamically get the table's structure so I don't have to map it as a char array?

Another thing is that when processing any of the function calls I don't need to return the table's data back but turns out if I didn't clean it it will send it in the response and slow the response time since it's sending the table records back so I have to manually clean it up with each call like so

function.getImportParameterList().clear();
        
function.getTableParameterList().clear();
function.getTableParameterList().setActive("e_table", false);

Even after doing that the response seems slow taking something like 9 seconds.


2. What could be causing this slowness?

In general what would be the best way to extract data with JCo in general? Any tips? documentations?

Accepted Solutions (0)

Answers (1)

Answers (1)

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos

Not really a complete answer, but perhaps two tips that could help:

If the "target table" exists in the ABAP DDIC (and your Java program is not only a server, but also has user credentials for opening a client connection), you could use

JCoRepository.getRecordMetaData(String recordName)

and then add that object to the "tables" list instead of the one created via JCo.createRecordMetaData("e_table");

For the performance problems you could activate the JCo and/or RFC trace and then check the timestamps in the trace to find out, where exactly these 9s are lost. Depending on where it turns out, one could then think about the next steps on how to improve that performance.

BTW: is the clear() really necessary? I would expect that the setActive(false) would already suffice.