2006 Oct 17 7:51 AM
Hi,
I have many RFCs called in my VC application. They all belong to the same Function Group. Will it be the same session for each call. I set certain global data(Function Group) in the first RFC call and use that data in the subsequent calls. But this does not seem to work properly.
Any idea how I can achieve this or is it not possible?
Thanks.
Srinivas.
Hi,
I have many RFCs called in my VC application. They all belong to the same Function Group. Will it be the same session for each call. I set certain global data(Function Group) in the first RFC call and use that data in the subsequent calls. But this does not seem to work properly.
Any idea how I can achieve this or is it not possible?
Thanks.
Srinivas.
2006 Oct 18 8:41 AM
Hi,
as nobody answered this question in the VC forum, I move it to an ABAP forum, hoping for more success.
Mario
2006 Oct 18 9:25 AM
HI Srinivas
I think each and every call to SAP is treated as an independent request or separate logons, irrespective of the Function group.
It might work in the case whereby the call is made and another FM within the same group is used internally.
Am not sure, but maybe you can try with the below method.
<b>EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.
Extras:
1. ... = f (for each field to be exported)
2. ... FROM f (for each field to be exported)
3. ... CLIENT g (before ID key )
4. ... USING form
5. ... FROM wa (after ID key or dbtab(ar))
6. ... COMPRESSION ON/OFF (as the last addition)
7. ... CODE PAGE HINT g (for internal use only) )
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters and Cannot Use Table Work Areas.
Effect
Exports a data cluster to the database table dbtab. The objects specified, obj1 ... objn (fields, structures, or tables) are stored as a cluster in the database table dbtab.
The database table dbtab specified must have a standardized structure.
The database table dbtab is divided into different logically related areas (ar, 2-character name).
You can export collections of data objects (known as data clusters) under a freely definable key (field key) to an area of this database.
IMPORT allows you to import individual data objects from this cluster.
Notes
You must enter an explicit name for the exported data objects in classes - that is, either addition 1 or addition 2 is mandatory.
You must also enter the work area explicitly in classes - that is, addition 5 is mandatory.
The table dbtab specified after DATABASE must be declared under TABLES (except in addition 5).
The header lines of internal tables cannot be exported because specifying the name of an internal table with a header line always exports the actual table data.
Data is stored in the database. The operation is only irrevocable after a database commit (see LUW). Prior to this, any database update can be reversed by a database rollback (see Programming Transactions).
The key must be a character-type data object (but not a string).
Example
Export two fields and an internal table to the database table INDX:
TYPES: BEGIN OF ITAB3_TYPE,
CONT(4),
END OF ITAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH NON-UNIQUE
DEFAULT KEY INITIAL SIZE 2,
WA_INDX TYPE INDX.
Before the export, fill the data
fields before CLUSTR.
WA_INDX-AEDAT = SY-DATUM.
WA_INDX-USERA = SY-UNAME.
Export data.
EXPORT F1 FROM F1
F2 FROM F2
ITAB3 FROM ITAB3
TO DATABASE INDX(ST) FROM WA_INDX ID INDXKEY.
DATABASE INDX(ST) ID INDXKEY.
Addition 1
... = f (for each object to be exported)
Effect
Exports the contents of the field f and stores them under the specified name in the database.
Addition 2
... FROM f (for each object to be exported)
Effect
Exports the contents of the field f and stores them under the specified name in the database.
Addition 3
... CLIENT g (after dbtab(ar))
Effect
Stores the data objects in the client g (if the import/export database table dbtab is client-specific). The client g must be a character-type data object (but not a string).
Addition 4
... USING form
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Effect
Does not export the data to the database table. Instead, calls the FORM routine form for every record written to the database without this addition. The name of the routine has the format <name of database table>_<name of form>. The routine can take the data from the work area of the database table; it has a parameter, which describes the operation mode (READ, UPDATE or INSERT). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.
Addition 5
... FROM wa (as last addition, or after dbtab(ar))
Effect
You must use this addition to save user data fields in a cluster database. The work area entered, wa, is used instead of a table work area. The work area entered must have the same structure as the named table dbtab.
Example
DATA WA LIKE INDX.
DATA F1.
WA-AEDAT = SY-DATUM.
WA-USERA = SY-UNAME.
WA-PGMID = SY-REPID.
EXPORT F1 = F1 TO DATABASE INDX(AR)
CLIENT '002' ID 'TEST'
FROM WA.
Addition 6
... COMPRESSION ON/OFF (as the last addition)
Effect
Specifies whether the data stored in the database table is to be compressed or not. The default value is "not compressed".
Addition 7
... CODE PAGE HINT g (for internal use only)
Effect
For non-unique code pages (such as 6200), you can use this addition to specify which code page g should be used to interpret the data during import (such as 8000 (Japanese)). g must be a character-type field.
Note
You must only use this addition for non-unique system code pages. The code page specified must be a subarea of the non-unique code page.
Exceptions
Errors in the structure of the EXPORT/IMPORT database table can cause runtime errors.</b>
Kind Regards
Eswar
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |