Extract SAP table Data from Excel

Cet outil permet d’extraire le contenu d’une table SAP directement à partir d’Excel. Il utilise pour cela le module fonction RFC de SAP RFC_READ_TABLE.

Il permet également de filtrer les champs à récupérer et de renseigner des critères de sélection complexes.

Télécharger l’outil

RFC_READ_TABLE.xls

Extract SAP Table structure from Excel

Get SAP table structure directly into Excel bypassing SAPGUi and SE11.
You need RFC autorisations to call function module RFC_READ_TABLE.

RFC_READ_TABLE_FIELDS.xls

Get SAP variant content from Excel

This tool allows to extract variant attributes and values from SAP to Excel.

Install first a new RFC enabled function module in your SAP system

YY_ASI_RS_VARIANT_CONTENTS.txt

YY_ASI_RS_VARIANT_CONTENTS

Download RS_VARIANT_CONTENTS.xls

To use the tool, simply enter a list of programs and their associated variants in variants tab and click on the Go button.

Variant attributes and content will be extracted respectively in tabs Attributes and Values.

SAPGUI Shortcut with password

By default, and for evident security reason, the login password is not saved when the user creates a SAPGUI shortcut.

Procceed as follow to create a password enabled shortcut :

First, register SAPGui shortcut keys and values in windows registry by running command sapshcut.exe -register
Sapshcut.exe is located in the installation directory of the SAPGUI (C:\Program Files\SAP\FrontEnd\SAPgui)

Then via regedit, enter the value 1 in the key :
HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security\EnablePassword

The sapshcut.exe can be executed in a cmd file  :
sapshcut.exe start -user = MYUSER -pw = MYPWD -language = EN -system-guiparm = SID = "xxx.xxx.xxx.xxx 00" -client = 100 maxgui

Caution: when using the -pw option, it is imperative to put the shortcut in a safe place as it contains password in clear text.

Sapgui Shortcut parameters, Version 620 Build 36

startup parameters:
-version display version information
-edit edit the shortcut via dialog
-register register the shortcut class to integrate into windows
-maxgui let GUI to be displayed in maximized window

logon parameters:
user identification
-user=userid to identify the user. (default is the windows user)
-pw=password to authorize the user
-language=E to set the prefered language

system identification
-system=DEV to identify the sap system
-client=032 to identify the client
-sysname=”DEV [PUBLIC]” to identify the sap system using load balancing
-guiparm=”sapserver 10″ to identify the sap system without load balancing

function identification
-command=”se38″ to set the function to start
-type=Transaction to set the function type
-title=”ABAP/4 Editor” to set the title to be displayed

SAP ALE performance optimization

Optimum ALE processing is synonymous with an optimum throughtput of IDocs

IDocs are processed during the ALE processing flow in the following places :

  • A: In the sending SAP system when IDocs are created
  • B: In the sending SAP system whe the IDocs are transferred to the communication layer
  • C: For communication between the sending system and receiving system
  • D: In the receiving system when IDocs are posted

Where can processing be optimized ?

Processing in these places can be optimized by one or more of the following measures :

  • Controlling IDoc events
  • Processing IDocs in parallel
  • Bundling of IDocs into packets (packet processing)
  • Administration of the IDoc communication

Creating and transferring IDocs to the communication layer in two separate steps improves the overall performance of the ALE process.


Creating IDocs in parallel

IDocs are created in parallel by several dialog processes that are used at once.

It can only be used if master datat is sent directly. In constrast, the program RBDMIDOC for analysing change pointers uses only one dialog process.

There are no benefits of creating IDocs in parallel for distributing transaction data in ALE, because this mainly involves single events which cannot be accelerated by running dialog processes at the same time.

You must specify a server group for creating IDocs in parallel (RZ12).

The server group is a list of the application servers, whose available dialog processes are used to create IDocs. Two dialog processes remain unused on every application server in a server group.

To create IDocs in parallel on a particular application server, a server group must be created with this application server as the only entry.


Parallel transfert to the communication Layer

In collected mode, RSEOUT00 groups together IDocs for communication with the same logical receiving system, in accordance with specifications in the partner profiles. The packet size parameter determines how many IDocs are transferred with one tRFC call.

The selection screen for RSEOUT00 contains a field “Maximum number of IDocs”. Here you can specify the maximum number of IDocs that are to be transferred before a COMMIT WORK is transmitted and the IDocs are unlocked. For many selected IDocs, a value that is too large can lead to runtime errors (timeout, memory overflow). In this situation, choose a smaller value.

As a guide, the packet size should be between 10 and 200 IDocs. The smaller the IDocs are, the larger the packet size can be. For message types which contain large volumes of data, for example, GLROLL or ALEAUD, the packet size should be between 1 and 10 IDocs.

If the IDocs are not going to be posted immediately in the receiving R/3 System, an IDoc packet can contain up to about 10000 data records. For example, if each IDoc contains 10 data records, a packet can contain up to 1000 IDocs.

IDoc communication uses all available dialog processses of the application server that transfers the IDocs to the communication layer.
With IDoc parallel communication, it does not matter whether IDocs are first collected or transferred immediately.

Make sure you specify a sufficient number of dialog processes on the application server of the receiving system. The number of dialog processes should not be less than the number of sending application server.

Each individual dialog process creates a tRFC connection to the receiving system.


Processing IDocs in parallel

Immediate processing :

When IDoc packets are processed immediately, all dialog processes on the receiving application server are used.

The immediate mode could block the application server. You cannot distribute inbound IDoc packets among one server group

If the IDoc packet consists of several IDocs and if the posting function module is not capable of mass processing, the ALE layer calls up the function module several times within the same dialog process and transfers a single IDoc for posting each time.

When setting table TEDEF is filled, (entry TRFC-IDOC, BATCHJOB), receiving system could use batch processes to integrate IDocs if all dialog work processes are already used. In this case, program RBDAPP01 is scheduled in background for each IDoc. This could also use all aailable batch processses. (Note 555229)

Background processing:

Inbound IDoc packets are split into individual IDocs and stored in the database.

All application servers in a server group can be used in parallel for posting IDocs in the background.

If you do not specify a server group, all dialog processes in the local server are used in parallel. This could block the application server.

If one server group is used for parallel processing, two dialog processes remain unused on every application server in a server group. This prevents the application server becoming blocked.

Two groups of function modules are used to post IDocs :
– Function modules which process IDocs in mass. Thesse transfers packets of IDocs whose individual IDocs are posted in the same Logical Unit of Work (LUW).
– Function modules which process one IDoc per call.

If you post the IDocs immediately, the R/3 sending system determines the IDoc packet size. ALE inbound processing can recognize if the posting function module allows packet processing and if so, passes the IDoc packet to it. If not, the IDoc packet is split into individual IDocs.

If you use function modules that can process IDocs in mass, the database load is reduced.

Packet Processing :

If you group IDocs into packets, this may also be practical for function modules that post inbound IDocs one at a time, because the ALE layer calls the function module several times in the same dialog process, thereby reducing the administrative load on the R/3 System.

If program RBDAPP01 carries out the background processing, as a guide, you should use a packet size of between 20 and 100 IDocs.

You can use packet processing in ALE for creating, transferring and posting IDocs.

Creation :

Cf § Creation of IDocs in the sending system.

Transfert :

Several IDocs can be grouped into a packet and sent in one transactional Remote Function Calll.

This has the following benefits :

  • The fewer administrative tasks reduce the load of the system.
  • tRFC uses less dialog processses in the sending system.
  • tRFC uses less dialog processses in the receiving system

IDoc posting :

Two groups of functions modules are used to post IDocs :

  • Function modules which process IDoc in mass.These transfert packets of IDocs whose individual IDocs are are posted on the same Logical Unit of Work (LuW).
  • Function modules which process one IDoc per call.

If you post IDoc immediately, the sending system determines the package size.
If IDocs are posted in the background, you can specify the size of packets to be generated by program RBDAPP01.

ALE inbound processing can recognize if the posting function module allows packet processing and if so, passes the IDoc packet to it. If not, the IDoc packet is split into individual IDocs.

If you use function modules that can process IDocs in mass, the database load is reduced.

If program RBDAPP01 carries out the background processing, as a guide, you should use a packet size of between 20 and 100 IDocs.

Source : BC619- ALE Technology

Triggering SAP Events from External Programs

Use the SAP program SAPEVT to trigger an event from a program running outside the SAP system.

The syntax for SAPEVT is as follows:

sapevt <EVENTID> [-p <EVENTPARM>] [-t]
pf=<Profile Name>|name=<SAP system name> nr=<SAP system mumber>

Example: sapevt END_OF_FI_DATATRANS name=C11 nr=11 triggers the event END_OF_FI_DATATRANS without a parameter. The event is triggered in SAP system C11, instance number 11. Any jobs that are waiting for this event are started.

The SAPEVT parameters are as follows:

  • <EVENTID>: The name of the event as defined in the SAP system with transaction SM64.
  • -p <EVENTPARM>: An optional argument for the EVENTID which qualifies the event. The EVENTPARM is not defined in the SAP system.
  • -t: Causes SAPEVT to log its actions in a short trace file. You can find the trace file in the current directory of the user who called SAPEVT.
  • pf=<Profile Name> or name=<SAP system name> nr=<SAP system mumber>: Either pf or name and nr identify the SAP system in which the event is to be triggered. At least one instance of the SAP system must be active when SAPEVT runs. Otherwise, the system will not know that the event has occurred. The instance must have the number specified in the SAPEVT call.

In more detail, the parameters for identifying the SAP system are as follows:

  • pf <Profile Name>: Enter the name of the profile with which the SAP background processing instance(s) are started. SAPEVT identifies the SAP system from the specifications in the profile.
  • You can find SAP system profiles in the globally shared SAP directory SYS\profile (Windows NT), or SYS/profile (UNIX).
  • name=<SAP system name> nr=<SAP system number>: The name of the SAP system (SID) and the SAP system number.