Very useful tool to excute by RFC a SAP program and then get its spool.
To use it, you have to install the RFC function module YY_RFC_ABAP_RUN
Télécharger l’outil Excel RFC_ABAP_RUN.xls
Usage is very simple, just enter the program and variant name.
The tool provides also the possibility to enter a list of selection parameters.
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.
Get SAP table structure directly into Excel bypassing SAPGUi and SE11.
You need RFC autorisations to call function module RFC_READ_TABLE.
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
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.
Go to transaction OY19.
Put the table you want to compare on the remote system
Choose the remote SAP system
Go to transaction search_sap_menu and enter a keyword.
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
There is no SAP standard tool to change the status of an IDoc.
The ABAP program YTREXPA700 changes the status of IDocs to “Archived”.
Status is changed to 38 or 73 depending on the direction of the IDoc.
Optimum ALE processing is synonymous with an optimum throughtput of IDocs
IDocs are processed during the ALE processing flow in the following places :
Processing in these places can be optimized by one or more of the following measures :
Creating and transferring IDocs to the communication layer in two separate steps improves the overall performance of the ALE process.
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.
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.
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.
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 :
Two groups of functions modules are used to post IDocs :
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
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:
In more detail, the parameters for identifying the SAP system are as follows: