EXPORT / IMPORT TO/FROM SHARED BUFFER

[Former Member]

Hello all,

I am facing a problem with the EXPORT/IMPORT to SHARED BUFFER statements.

In my report program , I export data to the shared memory.

I then call a transaction to park an accouting document.

The BTE 2218 gets triggered in the process. Here the IMPORT works fine.

Later, there is a standard function module which is called IN UPDATE TASK.

Within this, the IMPORT statement fails.

It works on one server but not on another.

Notes :

The IMPORT works in debugging mode but fails if I simply run.

Another point is that the ID used for identifying the shared memory uses sy-uname.

Can the visiblity of sy-uname in UPDATE TASK be controlled by settings ?

Any ideas on this ?

Please don't copy paste the help on SHARED BUFFER etc.

Thanks in advance.

[Former Member]

Hi

The SHARED BUFFER uses the cross-transaction application buffer.

This is common for all transactions on a single application server.

If multiple application servers exist on your landscape, the IMPORT will not work.

Maybe you could investigate on these lines ?

Hope this helps.

[Former Member]

Hi,

I just wanted to add something how I solved a similar problem in a different way, transferring data from the current session into the update task:

- Right, using memory-ID's are of no use when you want to pick up some data within the update task module

- Right, using the application buffer is somewhat restricted to the current application server

When possible, I have called another function module IN UPDATE TASK, exporting the data that I would like to have in the update task for later usage.

That function module then performs the EXPORT TO MEMORY.

As this is executed within the update task, the memory will be available later for the exits or Badis.

Prerequesite is, that the call to the export-to-memory-FM is registered before the function modules for the update task, so it may vary from the application you're implementing.

Best wishes,

Florin

[Former Member]

Ho you solved this problem.We are also facing the same . Please let me know

Thanks in advance

[Former Member]

Hi,

I have the same problem

I create a FM UPDATE TASK to export the data

I need to import an internal table from memory in FM UPDATE TASk

thats start delayed

The import works in DEBUGGING but fails in simply run

How can I solve this problem?

Thanks,

Mariano.

[vigneshyeram]

Hi Mariano,

the issue is to due to multiple servers present where SHARED MEMORY is specific for each application server.

So we export data into shared memory in program A, we have to be sure, that program B or FM which is called in background or update task by program A runs on the same application server

Here, the problem is when program A calls the program B or FM in background or update it’s a dynamic scheduling to all application server with have batch work processes and not the same application server that of calling program A always, so program B runs on another application server which has different shared  memory.

Solution will be:-

1. To Force program B to run on same application server as of calling program A by
   passing sy-host of calling program A to Function module “JOB_CLOSE” parameter
   name “TARGETSERVER”. OR
2. Instead of using SHARED MEMORY we will use DATABASE.

        EXPORT itab FROM itab  TO DATABASE indx(ar) CLIENT sy-mandt ID job_number in programA where job number is unique.

        Then IMPORT itab TO itab FROM database indx(ar) CLIENT sy-mandt ID job_number  in program B Where job number is passed from program A to B.

        Then DELETE FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number.

Regards,

Vignesh Yeram

.

[Abhijeet-K]

The first solution has a small correction: Instead of sy-host, the full name of the server needs to be specified. This is because the FM BP_MAP_SERVER_TO_HOST refers to the name and not the host field.

For the benefit of others here is the code:

CALL FUNCTION 'TH_SERVER_LIST'
         TABLES
           list           = lt_servers
         EXCEPTIONS
           no_server_list = 1
           OTHERS         = 2.
       IF sy-subrc <> 0.
         MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
            WITH sy-msgv1  sy-msgv2  sy-msgv3  sy-msgv4
            RAISING job_falied.
       ENDIF.

       READ TABLE lt_servers INTO ls_server
            WITH KEY host = sy-host.

       v_server = ls_server-name.
       CALL FUNCTION 'JOB_CLOSE'
         EXPORTING
           jobcount             = v_jbnum
           jobname              = v_jbnam
           strtimmed            = 'X'
           targetserver         = v_server
         EXCEPTIONS
           cant_start_immediate = 1
           invalid_startdate    = 2
           jobname_missing      = 3
           job_close_failed     = 4
           job_nosteps          = 5
           job_notex            = 6
           lock_failed          = 7
           OTHERS               = 8.
       IF sy-subrc <> 0.
         MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
            WITH sy-msgv1  sy-msgv2  sy-msgv3  sy-msgv4
            RAISING job_falied.
       ENDIF.

This needs toe be called after the SUBMIT ... AND RETURN statement.

[sandeep_katoch]

Guys,

This post is solved but I want to add a little for the solution which is quiet simple.

Instead of exporting to shared buffer which uses the application server instances specific memory we can used INDX table for export and import.

Its very smple we just need to export to indx and then import from indx .

Please remember to delete INDX entry once data is imported.

Thanks

Sandeep Katoch