SAP XI 2.0 to 3.0 / 7.0 delta
Hi XI Gurus
I wanted to know the delta between SAP XI 3.0 and 2.0
and delta between SAP XI 7.0 and 3.0.
Regards
Madhan Doraikannan
Hi Madhan,
You can refer to to the release notes for all the updates in any SAP Products at following URL.
http://help.sap.com/saphelp_nw04/helpdata/en/57/a21f407b402402e10000000a1550b0/frameset.htm
Thanks,
Prateek
Similar Messages
-
Dear Experts..
Will any expert will tell how to stop the v3 jobs for 2lis_!3_vdkon......
Thank
RadhaSorry How to stop the V3 jobs in sap r/3..... since my delta load was failed,,, due to change my standarad strucutre....
so i need to stop the jobs in sap r/3 side
Thanks
Radha -
/usr/sap/trans/actlog - Increase log detail
Hi everyone,
I'm after away of logging when objects are added to deleted from a modifiable change request (eg I want to see the object details, who, and date/time. I'm aware that when you create a new transport request/task that a log is created in /usr/sap/trans/actlog, however I was wondering if there was away to increase the detail level of what is written to the log file, or if someone knows of another way of tracking this information.
Cheers
ShaunOperating system level files in the transport process:
The SAP C program TP, requires a special file structure for the transport process. The file system is operating system dependent. TP uses a transport directory or file system, which is called /usr/sap/trans.
The /usr/sap/trans file system is generally NFS mounted form the development system to other systems unless a system is defined as a single system in the CTS pipeline. All the sub directories should have <SID>adm as the owner and sapsys as the group; and proper read, write and execute access should be given to owner and the group. The TP imports are always performed by <SID>adm.
The following are the subdirectories in /usr/sap/trans:
/data
/cofiles
/bin
/log
/actlog
/buffer
/sapnames
/tmp
/usr/sap/trans/data: holds the data of transport objects after they are released . This subdirectory contains files named R9<5 digits >. containing the exported objects. The example of a data file is R904073.DEV. The extension DEV means the data file was released from the DEV or development system.
/usr/sap/trans/cofiles: The cofiles directory holds the command files for all change requests. This subdirectory contains command files named K9<5 digits>.. They contain, for example, import steps to be performed. files are like a command or control files used to import the data files. The common directory for CTS system is /usr/sap/trans. After a change request is released from the source system , the data is exported immediately to the file system of the operating system. The SAP transport utility TP uses the cofile to transport a data file. The example of a file in cofiles directory is K904073.DEV.
/usr/sap/trans/bin: holds the most important file TPPARAM in the CTS system. TPPARAM file has all the information about the CTS systems in the CTS pipeline. TPPARAM file is the parameter file for the transport program TP and it is the common file for all the systems in the CTS pipeline. As you know already that /usr/sap/trans should be NFS mounted to all the systems in a CTS pipeline, TP program has access to the TPPARAM file from all the systems. The following is an example of typical TPPARAM file for five SAP systems in the CTS pipeline:
#@(#) TPPARAM.sap 20.6 SAP 95/03/28
# Template of TPPARAM for UNIX #
# First we specify global values for some parameters, #
# later the system specific incarnation of special parameters #
# global Parameters #
transdir = /usr/sap/trans/
dbname = $(system)
alllog = ALOG$(syear)$(yweek)
syslog = SLOG$(syear)$(yweek).$(system)
# System spezific Parameters #
# Beispiel T11 #
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
QAS/dbname = QAS
QAS/dbhost = sap8f
QAS/r3transpath = /usr/sap/QAS/SYS/exe/run/R3trans
TRN/dbname = TRN
TRN/dbhost = sap17
TRN/r3transpath = /usr/sap/TRN/SYS/exe/run/R3trans
PRE/dbname = PRE
PRE/dbhost = sap19f
PRE/r3transpath = /usr/sap/PRE/SYS/exe/run/R3trans
PRD/dbname = PRD
PRD/dbhost = sap18f
PRD/r3transpath = /usr/sap/PRD/SYS/exe/run/R3trans
/usr/sap/trans/log: holds the entire log files, trace files and statistics for the CTS system. This subdirectory contains all log files, such as ULOGs, ALOGs, SLOGs, log files named 9<5 digits>. for each executed step, and log files named . for steps that are collectively executed, for example, step N (structure conversion) and step P (move nametabs). When the user goes to SE09 (workbench organizer) or SE10 (customizing organizer) transaction and opens the log for a transport, the log file for that transport will be read from /usr/sap/trans/log directory. Each change request should have a log file. Examples of log files are DEVG904073.QAS, DEVI904073.QAS and DEVV904073.QAS. The name of a log file consists of the names of the change request, the executed step, and the system in which the step was executed:
<source system><action><6 digits>.<target system>
Now we can analyze the above example DEVG904073. QAS. The <source system> = DEV, <action> = G or report and screen generation, <6 digits> = 904073 (these six digits numbers are exactly the same number as the six digits of the transport) and the <target system> = QAS
Possible values for <action> are:
A: Dictionary activation
D: Import of application-defined objects
E: R3trans export
G: Report and screen generation
H: R3trans dictionary import
I: R3trans main import
L: R3trans import of the command files
M: Activation of the enqueue modules
P: Test import
R: Execution of reports after put (XPRA)
T: R3trans import of table entries
V: Set version flag
X: Export of application-defined objects.
/usr/sap/trans/actlog: This subdirectory contains files named Z<6 digits> recording each action on a request or task, for example, creation, release, or change of ownership. The example of an action file is DEVZ902690.DEV. The following are the contents of the file:
1 ETK220 “==================================================” “=================
=============================
1 ETK191 “04/30/1998″ Action log for request/task: “DEVK902690″
1 ETK220 “==================================================” “=================
=============================
1 ETK185 “04/30/1998 18:02:32″ “MOHASX01″ has reincluded the request/task
4 EPU120 Time… “18:02:32″ Run time… “00:00:00″
1 ETK193 “04/30/1998 18:02:33″ “MOHASX01″ owner, linked by “MOHASX01″ to “DEVK902691″
4 EPU120 Time… “18:02:33″ Run time… “00:00:00″
1 ETK190 “05/04/1998 11:02:40″ “MOHASX01″ has locked and released the request/task
1 ETK194 “05/04/1998 11:02:40″ **************** End of log *******************
4 EPU120 Time… “11:02:40″ Run time… “00:00:09″
~
~”DEVZ902690.DEV” 10 lines, 783 characters
/usr/sap/trans/buffer: This subdirectory contains an import buffer for each SAP System named after the SID. When a change request is released, the import buffer of the target systems is updated. Contains control information on which requests are to be imported into which systems and in what order the imports must occur. The /usr/sap/trans/buffer will have a directory for each system in the CTS pipeline. For example the buffer file for DEV system is /usr/sap/trans/buffer/DEV.
/usr/sap/trans/sapnames: holds information pertaining to transport requests for each system user. This subdirectory contains files named after the user's logon name. A file is created for each SAP System user, who performs transport actions, and updated when the user releases a request. There are files for each user who released change requests from the system.
/usr/sap/trans/tmp: holds information about temporary data and log files. While the transport is occurring the Basis administrator can find a file that is related to the transport in the tmp directory; that file shows the exact status if the transport (What objects are being imported at that time).
Important SAP delivery class and table types and tables in the CTS process:
Delivery class
The delivery class defines who (i.e. the SAP system itself or the customer) is responsible for maintaining the table contents. In addition the delivery class controls how the table behaves in a client copy and an upgrade. For example when you select a SAP defined profiles to perform a client copy, certain tables are selected according to their delivery class. DD02L table can show what delevery class a table belongs to.
The following delivery classes exist:
A: Application table.
C: Customizing table, maintenance by customer only.
L: Table for storing temporary data.
G: Customizing table, entries protected against overwriting.
E: Control table.
S: System table, maintenance only by SAP.
W: System table, contents can be transported via own TR objects.
Table type
The table type defines whether a physical table exists for the logical table description defined in the ABAP/4 Dictionary and how the table is stored on the database.
The following are different table types in SAP:
Transparent Tables
There is a physical table on the database for each transparent table. The names of the physical table and the logical table definition in the ABAP/4 Dictionary are same. For every transparent table in SAP, there is a table in database. The business and application data are stored in transparent tables.
Structure
No data records exist on the database for a structure. Structures are used for the interface definition between programs or between screens and programs.
Append Structure
An Append structure defines a subset of fields which belong to another table or structure but which are treated as a separate object in the correction management. Append structures are used to support modifications.
The following table types are used for internal purposes, for example to store control data or for continuous texts:
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated-pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Tables in CTS process:
TRBAT and TRJOB:
TRJOB and TRBAT are the major tables in the CTS process. After TP program has sent the event to the r3 system, RDDIMPDP checks table TRBAT in the target system to find out if there is an action to be performed. Mass activation, distribution, or table conversions are the examples of actions. If there is action to be performed, RDDIMPDP starts the appropriate program in the background task. RDDIMPDP then reschedules itself.
By checking table TRJOB, RDDIMPDP automatically recognizes if a previous step was aborted, and restarts this step. For each transport request , TP program inserts an entry into table TRBAT. If the return code 9999 in this table then the step is waiting to be performed. Return code 8888 indicates that the step is active and currently being processed. A return code of 12 or less indicates that the step is finished. In addition, TP inserts a header entry to let the RDDIMPDP program know to start processing. The column return code will therefore contain a B for begin. When RDDIMPDP is started, it sets the header entry to R(un), and starts the required program. When all the necessary actions are performed for all the transport requests, the column return code contains all the return codes received, and the column TIMESTAMP contains the finishing time. The header entry is set to F(inished). TP monitors the entries in TRBAT and TRJOB tables. When the header entry in TRBAT is set to finished. The entry in TRJOB is deleted.
Transport Tables SE06
TDEVC – Development classes
TASYS – Details of the delivery. Systems in the group that should automatically receive requests, have to be specified in table TASYS.
TSYST – The transport layers will be assigned to the integration systems. ( Define all systems)
TWSYS – Consolidation routes ( define consolidation path)
DEVL – Transport layers are defined here
In “Configuring the CTS system” section, We will learn more about the transport tables in SE06 transaction
Programs in the CTS process:
In the CTS table section we learned about the RDDIMPDP program. RDDIMPDP program needs to be scheduled in all the clients in an instance. It is recommended to schedule the RDDIMPDP as event driven.
RDDPUTPP and RDDNEWPP programs can be used to schedule RDDIMPDP program in the background.
The ABAP/4 programs that RDDIMPDP starts are determined by the transport step to be executed that is entered in the function field of table TRBAT.
Function Job Name Description of transport Steps
J RDDMASGL Activation of ABAP/4 dictionary objects
M RDDMASGL Activation of match codes and lock objects
S RDDDISOL Analysis of database objects to be converted
N RDDGENOL Conversion of database objects
Y RDDGENOL Conversion of matchcode tables
X RDDDICOL Export of AD0 objects
D RDDDIC1L Import of AD0 objects
E RDDVERSE Version management update during export
V RDDVERSL Version management update during import
R RDDEXECL Execution of programs for post – import processing
G RDDDIC3L Generation of ABAP/4 programs and screens
Version Management:
One of the important features of Workbench Organizer is Version Management. This feature works for all the development objects. Using the version management feature the users can compare and retrieve previous versions of objects.
Version management provides for comparisons, restore of previous versions, documentation of changes and assistance in the adjustment of data after upgrading to a new release. With the release of a change request, version maintenance is automatically recorded for each object. If an object in the system has been changed N times, it will have N delta versions and one active version. To display version management, for ABAPs use transaction SE38 and for tables, domains and data elements use SE11. The path to follow is Utilities -> Display version. Using version management the users can view existing version for previously created ABAP code, make changes to the code, compare code versions and restore original version of the code. Now the users will be restore previous versions without cut and paste steps of the past.
TP and R3trans program:
The basis administrator uses TP program to transport SAP objects from one system to another. TP is a C program delivered by SAP that runs independently of the R/3 system. TP program uses the appropriate files located in a common transport directory /usr/sap/trans. TP starts C programs, ABAP/4 programs and special operating system commands to its job. R3trans is one of the most important utility program called by TP. Before using the TP program, the basis administrator needs to make sure that the CTS system is setup properly and the right version of TP is running in the system. The TP program is located in the run time directory /usr/sap/<SID>/SYS/exe/run directory. It is automatically copied in the install process. A global parameter file TPPARAM that contains the databases of the different target systems and other information for the transport process controls TP. The global parameter file determines which R3trans is used for each system. If the parameter r3transpath is not defined properly then no export and import can be done. The basis administrator should make sure that the default value “r3transpath” is properly defined. Later in this chapter we will learn more about TP and R3trans; also we are going to see how they are used.
Configuring the TPPARAM file:
Each time TP is started, it must know the location of the global parameter file. As we have seen before TPPARAM file should be in directory /usr/sap/trans/bin. The parameters in TPPARAM can either global (valid for each and every system in the cts pipeline) or local to one system. Th parameters are either operating system dependant (these parameters preceded by a keyword corresponding to the specific operating system) or database dependant (contain a keyword corresponding to a specific database system).
The global parameter file provides variables that can be used for defining parameters. The variables can be defined in format: $(xyz). The brackets can be substituted with the “\”-character if required.
The following pre-defined variables are available for the global parameter file:
$(cpu1): The CPU name can be sun or as4 for example. In heterogeneous networks this variable is very important.
$(cpu2): Acronym for the name of the operating system. The example for this variable can be
hp-ux, or sunos . This is an operating system specific variable.
$(dname): Used for the day of the week (SUN,MON,….).
$(mday): Used for the day of the current month (01-31).
$(mname): Used for the name of the month (JAN…DEC).
$(mon): Used for the Month (01-12).
$(system): R/3 System name.
$(wday): Day of the week (00-06, Sunday=00, Monday=01, Tuesday=02 and so on).
$(yday): Day of the current year (001-366). Using the number any day of the year can be chosen.
$(year): Year (Example:1998 or 1999).
$(syear): Short form of the year (two positions).
$(yweek): Calendar week (00-53). The first week begins with the first Sunday of the year.
For the database connection:
The transport environment also needs parameters to connect to the R/3 System database. As we know already the every instance in the R/3 CTS pipeline has its own database, therefore specific parameters should be defined for each database system. From dbtype parameter of RSPARAM file, TP program identifies the database system.
The two parameters “dbname” and “dbhost” are required for ORACLE databases.
DBHOST: is the name of the computer on which the database processes execute. TCP/IP name of the host if NT is being used.
DBNAME: is the name of the database instance.
As of Release 3.0E, two new parameters have been introduced.
DBLOGICALNAME: The default value is $(system). The logical name that was used to install the database.
DBCONFPATH: The default value is $(transdir).
The parameters “dbname” and “dbhost” are also used for INFORMIX databases in an installation:
DBHOST: Same as Oracle.
DBNAME: Name of the database instance, uppercase and lowercase are distinguished here.
INFORMIXDIR : “/informix/<SAPSID>” is the default value. Defines the directory namewhere the database software can be found.
INFORMIXSQLHOSTS: “$(informixdir)/etc/sqlhosts[.tli|.soc]“is default value under Unix. The name of the SQLhosts file with its complete path is defined with this parameter.
INFORMIX_SERVER: “$(dbhost)$(dbname)shm” is the default value. The name of the database server may be specified for a local connect.
INFORMIX_SERVERALIAS: “$(dbhost)$(dbname)tcp”is the default vlue. The name of the database server can be specified for a remote connect.
For Microsoft SQL Server database the two parameters “dbname” and “dbhost” are also required. DBHOST: The TCP/IP name of the host on which the database is running.
DBNAME: The database instance name.
For DB2 in AS/400 only “dbhost” is required.
DBHOST: System name of the host on which the database is running.
If the”OptiConnect” is used, the following line should be specified:
OPTICONNECT 1
For DB2/ AIX
The two parameters “dbname” and “dbhost” are required
DBHOST: The host on which the database processes are running. It is the TCP/IP name of the host for Windows NT (As we have seen in the earlier examples).
DBNAME: Database instance name.
The DB2 for AIX Client Application Enabler Software must also be installed on the host on which tp is running.
ALLLOG: “ALOG” $(syear) $(yweek)”is the default value. This variable can be used in TPPARAM file to specify the name of a file in which tp stores information about every transport step carried out for a change request anywhere in the transport process. The file always resides in the log directory.
SYSLOG: “SLOG $(syear) $(yweek).$(system)” is the default value. This variable can be used to name a file in which tp stores information about the progress of import actions in a certain R/3 System. The file does not store information for any particular change request. The file always resides in the log directory.
tp_VERSION: Zero is the default value. If this parameter is set to not equal to zero, a lower version of tp may not work with this TPPARAM file. If the default value (zero) is set, the parameter has no affect.
STOPONERROR: (Numeric value) The default value is 9. When STOPONERROR is set to zero, tp is never stopped in the middle of an “import” or “put” call. When STOPONERROR is set to a value greater than zero, tp stops as soon as a change request generates a return code that is equal to or greater than this value (The numeric value of the STOPONERROR parameter is stored in the variable BADRC). Change requests, which still have to be processed for the current step, are first completed. A “SYNCMARK” in the buffer of the R/3 System involved, sets a limit here. tp divides the value of this parameter between two internal variables. STOPONERROR itself is treated as a boolean variable that determines whether tp should be stopped, if the return code is too high.
REPEATONERROR (Numeric value too): The default value is 9. The REPEATONERROR parameter is similar to STOPONERROR. The difference is, REPEATONERROR specifies the return code up to which a change request is considered to be successfully processed. Return codes less than REPEATONERROR are accepted as “in Order”. Change requests that were not processed successfully stay in the buffer.
NEW_SAPNAMES: Default value is “FALSE”. A file is created for each user of the R/3 System group in the “sapnames” subdirectory of the transport directory. Except some of the operating system,the name of the user is the name of the file. It is very important to remember hat the special characters or length of the file name could cause problems. If all the R/3 Systems in the transport group have at least Release level 3.0.; TP program is efficient to handle this problem. The user names are modified to create file names that are valid in all operating systems and the real user names are stored in a corresponding file.
Though we have seen so many parameters, for the minimum configuration the following two parameters are very important.
TRANSDIR: specifies the name of the common transport directory. The following is a typical example from TPPARAM of Unix as we have seen before.
transdir = /usr/sap/trans/
DBHOST: contains the name of the database host. In Windows NT environment, this is the TCP/IP host name. The following is an example in Unix:
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
For TP, to control ‘Start and Stop’ command files and database in R/3 the following important parameters are specified in TPPARAM:
Parameters for the tp Function “PUT”: LOCK_EU (boolean) default value is “TRUE”. Though from version 3.1 onward the tp put command is used seldom in cts process still it is important to know how this parameter works. When “tp put” is used, it changes the system change option . If the parameter is set to “FALSE” nothing gets changed. If the parameter is set to “TRUE”, the system change option is set to “Objects cannot be changed” at the beginning of the call, and gets changed back to its previous value at the end of the call. The “tp put” command will give the exact status of the locking mechanism.
LOCKUSER (used as boolean value): Default value is “TRUE”. This parameter is about the user login while tp put call is executed. If this parameter is set to “FALSE”, no locking mechanism for the users takes affect. If this parameter is defined as “TRUE” then a character is set in the database level; so only DDIC and SAP* can log on to the system. Users that have already logged on are not affected (this is a reason for activating the parameters STARTSAP and STOPSAP). The charactertor is removed at the end of the call, and all the users can log on to the SAP R/3 System again.
STARTSAP: Default value is ” “.or “PROMPT” for Windows NT . This parameter is used by TP to start an R/3 System. It is not necessary for the clients to make tp start and stop R/3 system..
STOPSAP: Default value is ” “or “PROMPT” for Windows NT. TP uses this parameter to stop an R/3 System.
STARTDB: Default value is ” “. TP uses the value of this parameter to start the database of an R/3 System.
The parameter is not active under Windows NT.
STOPDB: Default value is ” “. TP uses the value of this parameter to stop the database of an R/3 System.
This parameter is not active under Windows NT.
The above parameters in UNIX can be used as following:
STARTSAP = startsap R3
STOPSAP = stopsap R3
STARTDB = startsap db
STOPDB = stopsap db
In Windows NT:
STARTSAP = \\$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\startsap.exe
R3 <SID> <HOST NAME> <START PROFILE>
STOPSAP = \\$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\stopsap.exe
R3 <SID> <HOST NAME> <INSTANCE> <PROFILE PATH + Instance profile>
The parameters STARTDB and STOPDB are not active under Windows NT.
Parameters for the tp function “CLEAROLD”
DATALIFETIME (Numeric): Default value is “200″. When the data file has reached a minimum age, it is moved to the subdirectory old data with tp check. tp clearold all. The life span of the data files in the data sub directory can be set in days with this all, parameter.
OLDDATALIFETIME (Numeric): Default value is “365″. When a file located in the olddata subdirectory is no longer needed for further actions of the transport system and has reached a minimum age, it is removed with tp check.all, tp clearold all. The minimum age in days can be set with this parameter.
COFILELIFETIME (Numeric): Default value is “365″. This parameter is used just like DATALIFETIME parameter.
LOGLIFETIME (Numeric): Default value is “200″. This parameter applies to the life span of the log files. When the log files in log subdirectory is no longer needed for the transport system and has reached a minimum age, it is deleted with the calls tp check.all, tp clearold all. The minimum age in days can be defined with this parameter.
The Three Key Utilities of the CTS system (TP, R3trans and R3chop):
TP: Earlier in this chapter we have seen the objectives of TP. The TP transport control program is a utility program that helps the user to transport objects from one system to another. TP program is the front-end for the utility R3trans. TP stands for “Transports and Puts”. To make the TP work successfully the CTS system needs to be correctly configured. The following steps are very important for TP to run properly.
The transport directory /usr/sap/trans must be installed and NFS mounted to all the systems in the CTS pipe line.
RDDIMPDP program must be running (event driven is recommended) in each client. RDDIMPDP can be scheduled in the background by executing RDDNEWPP or RDDPUTPP. Use the tp checkimpdp <sap sid> command in /usr/sap/trans/bin directory as <sid>adm user to check RDDIMPDP program.
Use the tp connect <sap sid> command in /usr/sap/trans/bin directory to see whether the tp program is connecting to the database successfully or not. To run TP command the user has to logon as <sid>adm in source or target system.
The R/3 Systems in the CTS pipeline must have different names.
The Global CTS Parameter File TPPARAM must be correctly configured.
The source system (for the export) and target system ( for the import) must have at least two background work processes. TP always schedules the C class job, so if all the background jobs are defined as A class job then there will be problems in transport steps.
Important Tips :.It is always better to have the up to date TP version installed in your system. A user can ftp a current version of TP from SAPSERV4 of SAP. Though R3trans and other utility programs can be used to do the transport, it is recommended to use TP whenever possible for the following reasons..
The exports and imports are done separately using TP program. For example: when a transport is released from the system, the objects are exported from the source database to the operating system and then the import phase starts to transport those objects to the target system.
TP takes care of the order of the objects. The order, that was followed to export the objects; the same order will be followed to import them to the target database.
The TP command processes all change requests or transports in the SAP system buffer that have not yet been imported successfully. All the import steps are executed automatically after TP calls R3trans program to execute the following necessary steps:
Dictionary Import: ABAP/4 dictionary objects will be imported in this step.
Dictionary Activation: Name tabs or runtime descriptions will be written inactively. The R/3 system keeps running until the activation phase is complete. The enqueue modules are the exceptions in the running phase. After the activation of new dictionary structure the new actions are decided to get the runtime objects to the target system.
Structure conversion: If necessary the table structure is changed in this phase.
Move Nametabs: The new ABAP/4 Dictionary runtime objects which were inactive up to now are moved into the active runtime environment in this process. The database structures are adjusted accordingly. From the first step to the Main import step inconsistencies can occur to the R/3 system. After the main import phase all the inconsistency ca be solved.
Main import with R3trans: All the data are imported completely and the system comes to a consistent state.
Activation of enqueue-objects: The enqueue-objects cannot be activated in the same way as the objects of the ABAP/4 Dictionary, so they have to be activated after the main import in this step. They are then used directly in the running system.
Structure Conversion of match codes, Import application defined objects, versioning and execution of user defined activities are some of the steps after activation of enqueue-objects. The next step is generation of ABAP/4 programs and screens, where all the programs and screens associated with the change request are generated. When all the import steps are completed successfully, the transport request is removed from the import buffer.
It is recommended by SAP to schedule regular periods for imports into the target system (e.g. daily, weekly or monthly). Shorter periods between imports are not advisable. The transport to production should not be done in the off hours when the users are not working
TP can be started with different parameters. The “tp help” command can help user to generate a short description about the use of the command.
The following are the some important commands of TP:
For export:
tp export <change request>: The complete objects in the request from the source system will be transported. This command also used by SAP System when it releases a request.
tp r3e <change request>: R3trans export of one transport request.
tp sde <change request>: Application defined objects in one transport request can be exported.
tp tst <change request> <SAP system >: The test import for transport request can be done using this command.
tp createinfo <change request>: This command creates a information file that is automatically done during the export.
tp verse <request>: This command creates version creates versions of the objects in the specified request.
To Check the transport buffer, global parameter file and change requests:
tp showbuffer <sid>: Shows all the change requests ready to be imported to the target system.
tp count <sid>: Using this command users can find out the number of requests in the buffer waiting for import.
tp go <sid>: This command shows the environment variables needed for the connection to the database of the <sid> or target system.
tp showparams <sid>: All the values of modifiable tp parameters in the global parameter file. The default value is shown for parameters that have not been set explicitly.
To import the change requests or transports:
tp addtobuffer <request>.<sid>: If a change request is not in the buffer then this command is used to add it to the buffer, before the import step starts.
tp import all <sid>: This command imports all the change requests from the buffer to the target system.
tp put <sid>: The objective of this command is same as “tp import all <sid>”, but this command locks the system. This command also starts and stops the SAP system, if the parameters startsap and stopsap parameters are not set to ” “.
tp import <change request> <sid>: To import a single request from the source system to target system.
tp r3h <change request>| all <sid>: Using this command user can import the dictionary structures of one transport or all the transport from the buffer.
tp act <change request>|all <sid>: This command activates all the dictionary objects in the change request.
tp r3i <change request> | all <sid>: This command imports everything but dictionary structures of one.
tp sdi <change request>|all <sid>: Import application-defined objects.
tp gen <change request>|all <sid>: Screen and reports are generated using this command.
tp mvntabs <sid>: All inactive nametabs will be activated with this command.
tp mea <change request>|all <sid>: This command will activate the enqueue modules in the change request.
When you call this command, note the resulting changes to the import sequence.
Additional tp utility options:
tp check <sid>|all (data|cofiles|log|sapnames|verbose): User uses this command to find all the files in the transport directory that are not waiting for imports and they have exceeded the minimum time specified using the COFILELIFETIME, LOGFILELIFETIME, OLDDATALIFETIME and DATALIFETIME parameters of TPPARAM file.
tp delfrombuffer <request>.<sid>: This command removes a single change request from the buffer. In case of TMS, the request will be deleted from the import queue.
tp setstopmark <sid>: A flag is set to the list of requests ready for import into the target system. When the user uses the command tp import all <sapsid> and tp put <sapsid>, the requests in front of this mark are only processed. After all the requests in front of the mark have been imported successfully, the mark is deleted.
tp delstopmark <sid>: This command deletes the stop mark from the buffer if it exists.
tp cleanbuffer <sapsid>: Removes all the change requests from the buffer that are ready for the import into the target system.
tp locksys <sid>: This command locks the system for all the users except SAP* and DDIC. The users that have already logged on are not affected by the call.
tp unlocksys <sid>: This command unlocks the system for all the users.
tp lock_eu <sid>: This command sets the system change option to “system can not be changed” tmporarily.
tp unlock_eu <sid>: This command unlocks the system for all the changes.
tp backupall <sid>: This command starts a complete backup using R3trans command. It uses /usr/sap/trans/backup directory for the backup.
tp backup delta <sid>: Uses R3trans for a delta backup into /usr/sap/trans/backup directory.
tp sapstart <sid>: To start the R/3 system.
tp stopsap <sid>: To stop the R/3 system.
tp dbstart <sid>: To start the database.
tp dbstop <sid>: To stop the database.
Unconditional modes for TP: Unconditional modes are used with the TP program and these modes are intended for the special actions needed in the transport steps. Using unconditional mode user can manipulate the rules defined by the workbench organizer. The unconditional mode should be used when needed, otherwise it might create problems for the R/3 system database. Unconditional mode is used after the letter “U” in the TP command. Unconditional mode can be a digit between 0 to 9 and each has a meaning to it. The following is a example of a import having unconditional mode.
tp import devk903456 qas client100 U12468
0: Called a overtaker; change request can be imported from buffer without deleting it and then uncoditional mode 1 is used to allow another import in the correct location.
1: If U1 is used with the export then it ignores the correct status of the command file; and if it is used with import then it lets the user import the same change request again.
2: When used with tp export, it dictates the program to not to expand the selection with TRDIR brackets. If used in tp import phase, it overwrites the originals.
3: When used with tp import, it overwrites the system-dependant objects.
5: During the import to the consolidation system it permits the source systems other than the integration system.
6: When used in import phase, it helps to overwrite objects in unconfirmed repairs.
8: During import phase it ignores the limitations caused by the table classification.
9: During import it ignores that the system is locked for this kind of transport.
R3trans: TP uses R3trans program to transport data from one system to another in the CTS pipeline. efficient basis administrator can use R3trans directly to export and import data from and into any SAP systems. Using this utility transport between different database and operating system can e done without any problems. Different versions of R3trans are fully compatible with each other and can be used for export and import. The basis administrator has to be careful using R3trans for different release levels of R/3 software; logical inconsistency might occur if the up to date R3trans is not used for the current version of R/3 system.
The syntax for using the control file is following:
R3trans [<options>] <control file> (several options used at the same time; at least one option must be there)
For example: R3trans –u 1 –w test.log test
In the above example a unconditional mode is used, a log file “test.log” file is used to get the log result and a control file “test”, where the instructions are given for the R3trans to follow. The user needs to logon as <sid>adm to execute R3trans.
The following options are available for the R3trans program:
R3trans -d : This command is used to check the database connection .
R3trans -u <int>: Unconditional mode can be used as we have seen in the above example.
R3trans -v : This is used for verbose mode. It writes additional details to the log file
R3trans -i <file>: This command directly imports data from data file without a control file.
R3trans -l <file>: This provides output of a table of contents to the log file.
R3trans -n : This option provides a brief information about new features of R3trans.
R3trans –t: This option is used for the test mode. All modifications in the database are rolled back.
R3trans -c <f1> [<f2>]: This command is used for conversion. The <f1> file will be copied to <f2> file after executing a character set conversion to the local character set.
Important tips: Do not confuse the backup taken using R3trans with database backup. The backups taken using R3trans are logical backups of objects. In case something happens to the SAP system these backups can not be used for recovery. R3trans backups can be only used to restore a copy of a particular object that has been damaged or lost by the user.
R3trans -w <file>: As we have seen in the above example this option can be used to write to a log file. If no file is mentioned then trans.log is default directory for the log.
R3trans also can be used for the database backup.
R3trans –ba: This command is used for a complete backup. we will see in the next paragraph how to use
the control file for the backup.
R3trans –bd: This command is used for a delta backup if the user does not want a complete backup.
R3trans –bi: This option -
Hi,
Here are some BW interview questions. Make sure you have prepared for all the q's before going for an interview.
1) Please describe your experience with BEx (Business Explorer)
A) Rate your level of experience with BEx and the rationale for youre self-rating
B) How many queries have you developed? :
C) How many reports have you written?
D) How many workbooks have you developed?
E) Experience with jump targets (OLTP, use jump target)
F) Describe experience with BW-compatible ETL tools (e.g. Ascential)
2) Describe your experience with 3rd party report tools (Crystal Decisions, Business Objects a plus)
3) Describe your experience with the design and implementation of standard & custom InfoCubes.
1. How many InfoCubes have you implemented from start to end by yourself (not with a team)?
2. Of these Cubes, how many characteristics (including attributes) did the largest one have.
3. How much customization was done on the InfoCubes have you implemented?
4) Describe your experience with requirements definition/gathering.
5) What experience have you had creating Functional and Technical specifications?
6) Describe any testing experience you have:
7) Describe your experience with BW extractors
1. How many standard BW extractors have you implemented?
2. How many custom BW extractors have you implemented?
8) Describe how you have used Excel as a compliment to BEx
A) Describe your level of expertise and the rationale for your self-rating (experience with macros, pivot tables and formatting)
B)
9) Describe experience with ABAP
10) Describe any hands on experience with ASAP Methodology.
11) Identify SAP functional areas (SEM, CRM, etc.) you have experience in. Describe that experience.
12) What is partitioning and what are the benefits of partitioning in an InfoCube?
A) Partitioning is the method of dividing a table (either column wise or row wise) based on the fields available which would enable a quick reference for the intended values of the fields in the table. By partitioning an infocube, the reporting performance is enhanced because it is easier to search in smaller tables. Also table maintenance becomes easier.
13) What does Rollup do?
A) Rollup creates aggregates in an infocube whenever new data is loaded.
14) What are the inputs for an infoset?
A) The inputs for an infoset are ODS objects and InfoObjects (with master data or text).
15) What internally happens when BW objects like Info Object, Info Cube or ODS are created and activated?
A) When an InfoObject, InfoCube or ODS object is created, BW maintains a saved version of that object but does not make it available for use. Once the object is activated, BW creates an active version that is available for use.
16) What is the maximum number of key fields that you can have in an ODS object?
A) 16.
17) What is the specific advantage of LO extraction over LIS extraction?
A) The load performance of LO extraction is better than that of LIS. In LIS two tables are used for delta management that is cumbersome. In LO only one delta queue is used for delta management.
18) What is the importance of 0REQUID?
A) It is the InfoObject for Request id. OREQUID enables BW to distinguish between different data records.
19) Can you add programs in the scheduler?
A) Yes. Through event handling.
20) What is the importance of the table ROIDOCPRMS?
A) It is an IDOC parameter source system. This table contains the details of the data transfer like the source system of the data, data packet size, maximum number of lines in a data packet, etc. The data packet size can be changed through the control parameters option on SBIW i.e., the contents of this table can be changed.
21) What is the importance of 'start routine' in update rules?
A) A Start routine is a user exit that can be executed before the update rule starts to allow more complex computations for a key figure or a characteristic. The start routine has no return value. Its purpose is to execute preliminary calculations and to store them in a global data structure. You can access this structure or table in the other routines.
22) When is IDOC data transfer used?
A) IDOCs are used for communication between logical systems like SAP R/3, R/2 and non-SAP systems using ALE and for communication between an SAP R/3 system and a non-SAP system. In BW, an IDOC is a data container for data exchange between SAP systems or between SAP systems and external systems based on an EDI interface. IDOCs support limited file size of 1000 bytes. So IDOCs are not used when loading data into PSA since data there is more detailed. It is used when the file size is lesser than 1000 bytes.
23) What is partitioning characteristic in CO-PA used for?
A) For easier parallel search and load of data.
24) What is the advantage of BW reporting on CO-PA data compared with directly running the queries on CO-PA?
A) BW has a better performance advantage over reporting in R/3. For a huge amount of data, the R/3 reporting tool is at a serious disadvantage because R/3 is modeled as an OLTP system and is good for transaction processing rather than analytical processing.
25) What is the function of BW statistics cube?
A) BW statistics cube contains the data related to the reporting performance and the data loads of all the InfoCubes in the BW system.
26) When an ODS is in 'overwrite' mode, does uploading the same data again and again create new entries in the change log each time data is uploaded?
A) No.
27) What is the function of 'selective deletion' tab in the manage->contents of an infocube?
A) It allows us to select a particular value of a particular field and delete its contents.
28) When we collapse an infocube, is the consolidated data stored in the same infocubeinfocube? or is it stored in the new
A) Data is stored in the same cube.
29) What is the effect of aggregation on the performance? Are there any negative effects on the performance?
A) Aggregation improves the performance in reporting.
30) What happens when you load transaction data without loading master data?
A) The transaction data gets loaded and the master data fields remain blank.
31) When given a choice between a single infocube and multiple InfoCubes with a multiprovider, what factors does one need to consider before making a decision?
A) One would have to see if the InfoCubes are used individually. If these cubes are often used individually, then it is better to go for a multiprovider with many cubes since the reporting would be faster for an individual cube query rather than for a big cube with lot of data.
32) How many hierarchy levels can be created for a characteristic info object?
A) Maximum of 98 levels.
33) What is open hub service?
A) The open hub service enables you to distribute data from an SAP BW system into external data marts, analytical applications, and other applications. With this, you can ensure controlled distribution using several systems. The central object for the export of data is the Infospoke. Using this, you can define the object from which the data comes and into which target it is transferred. Through the open hub service, SAP BW becomes a hub of an enterprise data warehouse. The distribution of data becomes clear through central monitoring from the distribution status in the BW system.
34) What is the function of 'reconstruction' tab in an infocube?
A) It reconstructs the deleted requests from the infocube. If a request has been deleted and later someone wants the data records of that request to be added to the infocube, one can use the reconstruction tab to add those records. It goes to the PSA and brings the data to the infocube.
35) What are secondary indexes with respect to InfoCubes?
A) Index created in addition to the primary index of the infocube. When you activate a table in the ABAP Dictionary, an index is created on the primary key fields of the table. Further indexes created for the table are called secondary indexes.
36) What is DB connect and where is it used?
A) DB connect is database connecting piece of program. It is used in connecting third party tools with BW for reporting purpose.
37) Can we extract hierarchies from R/3 for CO-PA?
A) No We cannot, NO hierarchies in CO/PA�?.
38) Explain field name for partitioning in CO-PA
A) The CO/PA partitioning is used to decrease package size (eg: company code)
39) What is V3 update method ?
A) It is a program in R/3 source system that schedules batch jobs to update extract structure to data source collectively.
40) Differences between serialized and non-serialized V3 updates
41) What is the common method of finding the tables used in any R/3 extraction
A) By using the transaction LISTSCHEMA we can navigate the tables.
42) Differences between table view and infoset query
A) An InfoSet Query is a query using flat tables.
43) How to load data from one InfoCube to another InfoCube ?
A) Thro DataMarts data can be loaded from one InfoCube to another InfoCube.
44) What is the significance of setup tables in LO extractions ?
A) It adds the Selection Criteria to the LO extraction.
45) Difference between extract structure and datasource
A) In Datasource we define the data from diff source sys,where as in extract struct it contains the replicated data of datasource n where in we can define extract rules, n transfer rules
B) Extract Structure is a record layout of InfoObjects.
C) Extract Structure is created on SAP BW system.
46) What happens internally when Delta is Initialized
47) What is referential integrity mechanism ?
A) Referential integrity is the property that guarantees that values from one column depend on values from another column.This property is enforced through integrity constraints.
48) What is activation of extract structure in LO ?
49) What is the difference between Info IDoc and data IDoc ?
50) What is D-Management in LO ?
A) It is a method used in delta update methods, which is based on change log in LO.
Plz experts.. provide the answers for the questions..
Thanx in advance.
SunilHi,
In my case i dont have an experience in BW. I went straight to academy.It is like i am starting a new career.Are the questions also apply to me . -
Upgrade HR component after EHP4 upgrade
Hello,
Recently we did a upgrade from R/3 4.7x110 to ECC 6.0 EHP4 using CUUC method. For EHP4 in the MOPZ we selected some 5 usage types where HCM self services or Self services (XSS) was not selected. Now after the upgrade we hav SAP_HR in release 600 and level 045 and EA_HR is also in same level.
Right now we are trying to configure MSS and found business functions related to HCM are
missing in the backend system also when we tried to customize the Report launch pad we did not get the tab in SPRO. Can we solve this problem by upgrading SAP_HR and EA_HR to 604 release or we should add all the HCM related Technical usage types into the system to get them activated.
Because as per the link below we are not having the correct version for
SAP_HR and EA_HR.
http://wiki.sdn.sap.com/wiki/display/ERPHCM/HOWTOGETRIDOFSPSTACKMISMATCHISSUES
Please find the ERP EHP stack and SPS levels we are in at present:
ERP Stack:16
EHP:04
EHP Stack:05
We have PORTAL on NW 700 EHP1 SPS05.
Regards,
Yoganand.VHi,
> We will proceed and upgrade SAP_HR to 604, but the addon EA-HR also needs to be upgraded to EA-HR 604 and for this we >have to upgrade to EA-HR 601 and then go to 604, please share your thoughts on this.
As per EHP terminology, EHP packages are cumulative so when you will donwload all the packages from MOPZ, it will take care of all dependencies and download the file accordingly. Please check below extract from Technical FAQ guide:
We would like to clarify this without using the term "cumulative", as this term could
potentially be ambiguous:
u2013 You can install EHP4 for SAP ERP 6.0 in one step on 64-bit platforms without having
installed EHP3 before.
u2013 Every EHP version includes the content of any previous EHP versions. For example,
you cannot install EHP4 without getting the content of EHP3 and EHP2 as well.
u2013 Technically, SAP has started to deliver EHP software packages as delta packages with
EHP4 for SAP ERP 6.0. Thus, your EHP4 installation queue will contain EHP4 and
EHP3 packages if you have not already installed EHP3. However, all these packages
should be installed in one step on 64-bit platforms.
> Also before upgrading SAP_HR do we need to take backup of any tables related to HR, but right now in our system we >are not using HR.
Its not required as you are not using HR module earlier.
Thanks
Sunny -
How to make an Iview of an Internal Request for show an Adobe Form(from R3)
Hi forum
I need to show an Adobe Form (building in R3), in the role of Employee Self-Service of SAP EP. I read that this is possible building an Scenario, but i don´t have very clear the steps.
This are te steps that i made:
1) I create a scenario with de ISR Wizard, and i tested it and works ok.
2) I made an iview of the Web Dynpro Application sap.com/pcui_gp~isr with de application parameters
SCENARIO=ZZZZ&MODE=DISPLAY&sap.wdarfc.useSys=WD_EMPLOYEE_MODELDATA_DEST:PL7&sap.wdarfc.useSys=WD_EMPLOYEE_RFC_METADATA_DEST:PL7
3) I made a Delta Link of this Iview to the role of ESS.
I test, and i don´t show anything.
Is there something bad ?
Thnks
Josué CruzHi Narasimha
In what transaction can i change this property, by de SFP ?
Thnks
Josué Cruz -
Transport classes and programs to another server
Except for transport routing and charm copy function, do we have other ways to do so?
for example copy or so forth.
best regards,
Blake LeHi Blake
SAP R/3 Correction and Transport System
Operating system level files in the transport process:
The SAP C program TP, requires a special file structure for the transport process. The file system is operating system dependent. TP uses a transport directory or file system, which is called /usr/sap/trans.
The /usr/sap/trans file system is generally NFS mounted form the development system to other systems unless a system is defined as a single system in the CTS pipeline. All the sub directories should have <SID>adm as the owner and sapsys as the group; and proper read, write and execute access should be given to owner and the group. The TP imports are always performed by <SID>adm.
The following are the subdirectories in /usr/sap/trans:
/data
/cofiles
/bin
/log
/actlog
/buffer
/sapnames
/tmp
/usr/sap/trans/data: holds the data of transport objects after they are released . The example of a data file is R904073.DEV. The extension DEV means the data file was released from the DEV or development system.
/usr/sap/trans/cofiles: The cofiles directory holds the command files for all change requests. These files are like a command or control files used to import the data files. The common directory for CTS system is /usr/sap/trans. After a change request is released from the source system , the data is exported immediately to the file system of the operating system. The SAP transport utility TP uses the cofile to transport a data file. The example of a file in cofiles directory is K904073.DEV.
/usr/sap/trans/bin: holds the most important file TPPARAM in the CTS system. TPPARAM file has all the information about the CTS systems in the CTS pipeline. TPPARAM file is the parameter file for the transport program TP and it is the common file for all the systems in the CTS pipeline. As you know already that /usr/sap/trans should be NFS mounted to all the systems in a CTS pipeline, TP program has access to the TPPARAM file from all the systems. The following is an example of typical TPPARAM file for five SAP systems in the CTS pipeline:
#@(#) TPPARAM.sap 20.6 SAP 95/03/28
Template of TPPARAM for UNIX #
First we specify global values for some parameters, #
later the system specific incarnation of special parameters #
global Parameters #
transdir = /usr/sap/trans/
dbname = $(system)
alllog = ALOG$(syear)$(yweek)
syslog = SLOG$(syear)$(yweek).$(system)
System spezific Parameters #
Beispiel T11 #
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
QAS/dbname = QAS
QAS/dbhost = sap8f
QAS/r3transpath = /usr/sap/QAS/SYS/exe/run/R3trans
TRN/dbname = TRN
TRN/dbhost = sap17
TRN/r3transpath = /usr/sap/TRN/SYS/exe/run/R3trans
PRE/dbname = PRE
PRE/dbhost = sap19f
PRE/r3transpath = /usr/sap/PRE/SYS/exe/run/R3trans
PRD/dbname = PRD
PRD/dbhost = sap18f
PRD/r3transpath = /usr/sap/PRD/SYS/exe/run/R3trans
/usr/sap/trans/log: holds the entire log files, trace files and statistics for the CTS system. When the user goes to SE09 (workbench organizer) or SE10 (customizing organizer) transaction and opens the log for a transport, the log file for that transport will be read from /usr/sap/trans/log directory. Each change request should have a log file. Examples of log files are DEVG904073.QAS, DEVI904073.QAS and DEVV904073.QAS. The name of a log file consists of the names of the change request, the executed step, and the system in which the step was executed:
<source system><action><6 digits>.<target system>
Now we can analyze the above example DEVG904073. QAS. The <source system> = DEV, <action> = G or report and screen generation, <6 digits> = 904073 (these six digits numbers are exactly the same number as the six digits of the transport) and the <target system> = QAS
Possible values for <action> are:
A: Dictionary activation
D: Import of application-defined objects
E: R3trans export
G: Report and screen generation
H: R3trans dictionary import
I: R3trans main import
L: R3trans import of the command files
M: Activation of the enqueue modules
P: Test import
R: Execution of reports after put (XPRA)
T: R3trans import of table entries
V: Set version flag
X: Export of application-defined objects.
/usr/sap/trans/actlog: holds action log files. The example of an action file is DEVZ902690.DEV. The following are the contents of the file:
1 ETK220 u201C==================================================u201D u201C=================
=============================
1 ETK191 u201C04/30/1998u2033 Action log for request/task: u201CDEVK902690u2033
1 ETK220 u201C==================================================u201D u201C=================
=============================
1 ETK185 u201C04/30/1998 18:02:32u2033 u201CMOHASX01u2033 has reincluded the request/task
4 EPU120 Timeu2026 u201C18:02:32u2033 Run timeu2026 u201C00:00:00u2033
1 ETK193 u201C04/30/1998 18:02:33u2033 u201CMOHASX01u2033 owner, linked by u201CMOHASX01u2033 to u201CDEVK902691u2033
4 EPU120 Timeu2026 u201C18:02:33u2033 Run timeu2026 u201C00:00:00u2033
1 ETK190 u201C05/04/1998 11:02:40u2033 u201CMOHASX01u2033 has locked and released the request/task
1 ETK194 u201C05/04/1998 11:02:40u2033 **************** End of log *******************
4 EPU120 Timeu2026 u201C11:02:40u2033 Run timeu2026 u201C00:00:09u2033
~
~u201DDEVZ902690.DEVu201D 10 lines, 783 characters
/usr/sap/trans/buffer: transport buffer of the target systems; contains control information on which requests are to be imported into which systems and in what order the imports must occur. The /usr/sap/trans/buffer will have a directory for each system in the CTS pipeline. For example the buffer file for DEV system is /usr/sap/trans/buffer/DEV.
/usr/sap/trans/sapnames: holds information pertaining to transport requests for each system user. There are files for each user who released change requests from the system.
/usr/sap/trans/tmp: holds information about temporary data and log files. While the transport is occurring the Basis administrator can find a file that is related to the transport in the tmp directory; that file shows the exact status if the transport (What objects are being imported at that time).
Important SAP delivery class and table types and tables in the CTS process:
Delivery class
The delivery class defines who (i.e. the SAP system itself or the customer) is responsible for maintaining the table contents. In addition the delivery class controls how the table behaves in a client copy and an upgrade. For example when you select a SAP defined profiles to perform a client copy, certain tables are selected according to their delivery class. DD02L table can show what delevery class a table belongs to.
The following delivery classes exist:
A: Application table.
C: Customizing table, maintenance by customer only.
L: Table for storing temporary data.
G: Customizing table, entries protected against overwriting.
E: Control table.
S: System table, maintenance only by SAP.
W: System table, contents can be transported via own TR objects.
Table type
The table type defines whether a physical table exists for the logical table description defined in the ABAP/4 Dictionary and how the table is stored on the database.
The following are different table types in SAP:
Transparent Tables
There is a physical table on the database for each transparent table. The names of the physical table and the logical table definition in the ABAP/4 Dictionary are same. For every transparent table in SAP, there is a table in database. The business and application data are stored in transparent tables.
Structure
No data records exist on the database for a structure. Structures are used for the interface definition between programs or between screens and programs.
Append Structure
An Append structure defines a subset of fields which belong to another table or structure but which are treated as a separate object in the correction management. Append structures are used to support modifications.
The following table types are used for internal purposes, for example to store control data or for continuous texts:
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated-pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Tables in CTS process:
TRBAT and TRJOB:
TRJOB and TRBAT are the major tables in the CTS process. After TP program has sent the event to the r3 system, RDDIMPDP checks table TRBAT in the target system to find out if there is an action to be performed. Mass activation, distribution, or table conversions are the examples of actions. If there is action to be performed, RDDIMPDP starts the appropriate program in the background task. RDDIMPDP then reschedules itself.
By checking table TRJOB, RDDIMPDP automatically recognizes if a previous step was aborted, and restarts this step. For each transport request , TP program inserts an entry into table TRBAT. If the return code 9999 in this table then the step is waiting to be performed. Return code 8888 indicates that the step is active and currently being processed. A return code of 12 or less indicates that the step is finished. In addition, TP inserts a header entry to let the RDDIMPDP program know to start processing. The column return code will therefore contain a B for begin. When RDDIMPDP is started, it sets the header entry to R(un), and starts the required program. When all the necessary actions are performed for all the transport requests, the column return code contains all the return codes received, and the column TIMESTAMP contains the finishing time. The header entry is set to F(inished). TP monitors the entries in TRBAT and TRJOB tables. When the header entry in TRBAT is set to finished. The entry in TRJOB is deleted.
Transport Tables SE06
TDEVC - Development classes
TASYS - Details of the delivery. Systems in the group that should automatically receive requests, have to be specified in table TASYS.
TSYST - The transport layers will be assigned to the integration systems. ( Define all systems)
TWSYS - Consolidation routes ( define consolidation path)
DEVL - Transport layers are defined here
In u201CConfiguring the CTS systemu201D section, We will learn more about the transport tables in SE06 transaction
Programs in the CTS process:
In the CTS table section we learned about the RDDIMPDP program. RDDIMPDP program needs to be scheduled in all the clients in an instance. It is recommended to schedule the RDDIMPDP as event driven.
RDDPUTPP and RDDNEWPP programs can be used to schedule RDDIMPDP program in the background.
The ABAP/4 programs that RDDIMPDP starts are determined by the transport step to be executed that is entered in the function field of table TRBAT.
Function Job Name Description of transport Steps
J RDDMASGL Activation of ABAP/4 dictionary objects
M RDDMASGL Activation of match codes and lock objects
S RDDDISOL Analysis of database objects to be converted
N RDDGENOL Conversion of database objects
Y RDDGENOL Conversion of matchcode tables
X RDDDICOL Export of AD0 objects
D RDDDIC1L Import of AD0 objects
E RDDVERSE Version management update during export
V RDDVERSL Version management update during import
R RDDEXECL Execution of programs for post - import processing
G RDDDIC3L Generation of ABAP/4 programs and screens
Version Management:
One of the important features of Workbench Organizer is Version Management. This feature works for all the development objects. Using the version management feature the users can compare and retrieve previous versions of objects.
Version management provides for comparisons, restore of previous versions, documentation of changes and assistance in the adjustment of data after upgrading to a new release. With the release of a change request, version maintenance is automatically recorded for each object. If an object in the system has been changed N times, it will have N delta versions and one active version. To display version management, for ABAPs use transaction SE38 and for tables, domains and data elements use SE11. The path to follow is Utilities -> Display version. Using version management the users can view existing version for previously created ABAP code, make changes to the code, compare code versions and restore original version of the code. Now the users will be restore previous versions without cut and paste steps of the past.
TP and R3trans program:
The basis administrator uses TP program to transport SAP objects from one system to another. TP is a C program delivered by SAP that runs independently of the R/3 system. TP program uses the appropriate files located in a common transport directory /usr/sap/trans. TP starts C programs, ABAP/4 programs and special operating system commands to its job. R3trans is one of the most important utility program called by TP. Before using the TP program, the basis administrator needs to make sure that the CTS system is setup properly and the right version of TP is running in the system. The TP program is located in the run time directory /usr/sap/<SID>/SYS/exe/run directory. It is automatically copied in the install process. A global parameter file TPPARAM that contains the databases of the different target systems and other information for the transport process controls TP. The global parameter file determines which R3trans is used for each system. If the parameter r3transpath is not defined properly then no export and import can be done. The basis administrator should make sure that the default value u201Cr3transpathu201D is properly defined. Later in this chapter we will learn more about TP and R3trans; also we are going to see how they are used.
Configuring the TPPARAM file:
Each time TP is started, it must know the location of the global parameter file. As we have seen before TPPARAM file should be in directory /usr/sap/trans/bin. The parameters in TPPARAM can either global (valid for each and every system in the cts pipeline) or local to one system. Th parameters are either operating system dependant (these parameters preceded by a keyword corresponding to the specific operating system) or database dependant (contain a keyword corresponding to a specific database system).
The global parameter file provides variables that can be used for defining parameters. The variables can be defined in format: $(xyz). The brackets can be substituted with the u201C\u201D-character if required.
The following pre-defined variables are available for the global parameter file:
$(cpu1): The CPU name can be sun or as4 for example. In heterogeneous networks this variable is very important.
$(cpu2): Acronym for the name of the operating system. The example for this variable can be
hp-ux, or sunos . This is an operating system specific variable.
$(dname): Used for the day of the week (SUN,MON,u2026.).
$(mday): Used for the day of the current month (01-31).
$(mname): Used for the name of the month (JANu2026DEC).
$(mon): Used for the Month (01-12).
$(system): R/3 System name.
$(wday): Day of the week (00-06, Sunday=00, Monday=01, Tuesday=02 and so on).
$(yday): Day of the current year (001-366). Using the number any day of the year can be chosen.
$(year): Year (Example:1998 or 1999).
$(syear): Short form of the year (two positions).
$(yweek): Calendar week (00-53). The first week begins with the first Sunday of the year.
For the database connection:
The transport environment also needs parameters to connect to the R/3 System database. As we know already the every instance in the R/3 CTS pipeline has its own database, therefore specific parameters should be defined for each database system. From dbtype parameter of RSPARAM file, TP program identifies the database system.
The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required for ORACLE databases.
DBHOST: is the name of the computer on which the database processes execute. TCP/IP name of the host if NT is being used.
DBNAME: is the name of the database instance.
As of Release 3.0E, two new parameters have been introduced.
DBLOGICALNAME: The default value is $(system). The logical name that was used to install the database.
DBCONFPATH: The default value is $(transdir).
The parameters u201Cdbnameu201D and u201Cdbhostu201D are also used for INFORMIX databases in an installation:
DBHOST: Same as Oracle.
DBNAME: Name of the database instance, uppercase and lowercase are distinguished here.
INFORMIXDIR : u201C/informix/<SAPSID>u201D is the default value. Defines the directory namewhere the database software can be found.
INFORMIXSQLHOSTS: u201C$(informixdir)/etc/sqlhosts[.tli|.soc]u201Cis default value under Unix. The name of the SQLhosts file with its complete path is defined with this parameter.
INFORMIX_SERVER: u201C$(dbhost)$(dbname)shmu201D is the default value. The name of the database server may be specified for a local connect.
INFORMIX_SERVERALIAS: u201C$(dbhost)$(dbname)tcpu201Dis the default vlue. The name of the database server can be specified for a remote connect.
For Microsoft SQL Server database the two parameters u201Cdbnameu201D and u201Cdbhostu201D are also required. DBHOST: The TCP/IP name of the host on which the database is running.
DBNAME: The database instance name.
For DB2 in AS/400 only u201Cdbhostu201D is required.
DBHOST: System name of the host on which the database is running.
If theu201DOptiConnectu201D is used, the following line should be specified:
OPTICONNECT 1
For DB2/ AIX
The two parameters u201Cdbnameu201D and u201Cdbhostu201D are required
DBHOST: The host on which the database processes are running. It is the TCP/IP name of the host for Windows NT (As we have seen in the earlier examples).
DBNAME: Database instance name.
The DB2 for AIX Client Application Enabler Software must also be installed on the host on which tp is running.
ALLLOG: u201CALOGu201D $(syear) $(yweek)u201Dis the default value. This variable can be used in TPPARAM file to specify the name of a file in which tp stores information about every transport step carried out for a change request anywhere in the transport process. The file always resides in the log directory.
SYSLOG: u201CSLOG $(syear) $(yweek).$(system)u201D is the default value. This variable can be used to name a file in which tp stores information about the progress of import actions in a certain R/3 System. The file does not store information for any particular change request. The file always resides in the log directory.
tp_VERSION: Zero is the default value. If this parameter is set to not equal to zero, a lower version of tp may not work with this TPPARAM file. If the default value (zero) is set, the parameter has no affect.
STOPONERROR: (Numeric value) The default value is 9. When STOPONERROR is set to zero, tp is never stopped in the middle of an u201Cimportu201D or u201Cputu201D call. When STOPONERROR is set to a value greater than zero, tp stops as soon as a change request generates a return code that is equal to or greater than this value (The numeric value of the STOPONERROR parameter is stored in the variable BADRC). Change requests, which still have to be processed for the current step, are first completed. A u201CSYNCMARKu201D in the buffer of the R/3 System involved, sets a limit here. tp divides the value of this parameter between two internal variables. STOPONERROR itself is treated as a boolean variable that determines whether tp should be stopped, if the return code is too high.
REPEATONERROR (Numeric value too): The default value is 9. The REPEATONERROR parameter is similar to STOPONERROR. The difference is, REPEATONERROR specifies the return code up to which a change request is considered to be successfully processed. Return codes less than REPEATONERROR are accepted as u201Cin Orderu201D. Change requests that were not processed successfully stay in the buffer.
NEW_SAPNAMES: Default value is u201CFALSEu201D. A file is created for each user of the R/3 System group in the u201Csapnamesu201D subdirectory of the transport directory. Except some of the operating system,the name of the user is the name of the file. It is very important to remember hat the special characters or length of the file name could cause problems. If all the R/3 Systems in the transport group have at least Release level 3.0.; TP program is efficient to handle this problem. The user names are modified to create file names that are valid in all operating systems and the real user names are stored in a corresponding file.
Though we have seen so many parameters, for the minimum configuration the following two parameters are very important.
TRANSDIR: specifies the name of the common transport directory. The following is a typical example from TPPARAM of Unix as we have seen before.
transdir = /usr/sap/trans/
DBHOST: contains the name of the database host. In Windows NT environment, this is the TCP/IP host name. The following is an example in Unix:
DEV/dbname = DEV
DEV/dbhost = sap9f
DEV/r3transpath = /usr/sap/DEV/SYS/exe/run/R3trans
For TP, to control u2018Start and Stopu2019 command files and database in R/3 the following important parameters are specified in TPPARAM:
Parameters for the tp Function u201CPUTu201D: LOCK_EU (boolean) default value is u201CTRUEu201D. Though from version 3.1 onward the tp put command is used seldom in cts process still it is important to know how this parameter works. When u201Ctp putu201D is used, it changes the system change option . If the parameter is set to u201CFALSEu201D nothing gets changed. If the parameter is set to u201CTRUEu201D, the system change option is set to u201CObjects cannot be changedu201D at the beginning of the call, and gets changed back to its previous value at the end of the call. The u201Ctp putu201D command will give the exact status of the locking mechanism.
LOCKUSER (used as boolean value): Default value is u201CTRUEu201D. This parameter is about the user login while tp put call is executed. If this parameter is set to u201CFALSEu201D, no locking mechanism for the users takes affect. If this parameter is defined as u201CTRUEu201D then a character is set in the database level; so only DDIC and SAP* can log on to the system. Users that have already logged on are not affected (this is a reason for activating the parameters STARTSAP and STOPSAP). The charactertor is removed at the end of the call, and all the users can log on to the SAP R/3 System again.
STARTSAP: Default value is u201D u201C.or u201CPROMPTu201D for Windows NT . This parameter is used by TP to start an R/3 System. It is not necessary for the clients to make tp start and stop R/3 system..
STOPSAP: Default value is u201D u201Cor u201CPROMPTu201D for Windows NT. TP uses this parameter to stop an R/3 System.
STARTDB: Default value is u201D u201C. TP uses the value of this parameter to start the database of an R/3 System.
The parameter is not active under Windows NT.
STOPDB: Default value is u201D u201C. TP uses the value of this parameter to stop the database of an R/3 System.
This parameter is not active under Windows NT.
The above parameters in UNIX can be used as following:
STARTSAP = startsap R3
STOPSAP = stopsap R3
STARTDB = startsap db
STOPDB = stopsap db
In Windows NT:
STARTSAP =
$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\startsap.exe
R3 <SID> <HOST NAME> <START PROFILE>
STOPSAP =
$(SAPGLOBALHOST)\sapmnt\$(system)\sys\exe\run\stopsap.exe
R3 <SID> <HOST NAME> <INSTANCE> <PROFILE PATH + Instance profile>
The parameters STARTDB and STOPDB are not active under Windows NT.
Parameters for the tp function u201CCLEAROLDu201D
DATALIFETIME (Numeric): Default value is u201C200u2033. When the data file has reached a minimum age, it is moved to the subdirectory old data with tp check. tp clearold all. The life span of the data files in the data sub directory can be set in days with this all, parameter.
OLDDATALIFETIME (Numeric): Default value is u201C365u2033. When a file located in the olddata subdirectory is no longer needed for further actions of the transport system and has reached a minimum age, it is removed with tp check.all, tp clearold all. The minimum age in days can be set with this parameter.
COFILELIFETIME (Numeric): Default value is u201C365u2033. This parameter is used just like DATALIFETIME parameter.
LOGLIFETIME (Numeric): Default value is u201C200u2033. This parameter applies to the life span of the log files. When the log files in log subdirectory is no longer needed for the transport system and has reached a minimum age, it is deleted with the calls tp check.all, tp clearold all. The minimum age in days can be defined with this parameter.
The Three Key Utilities of the CTS system (TP, R3trans and R3chop):
TP: Earlier in this chapter we have seen the objectives of TP. The TP transport control program is a utility program that helps the user to transport objects from one system to another. TP program is the front-end for the utility R3trans. TP stands for u201CTransports and Putsu201D. To make the TP work successfully the CTS system needs to be correctly configured. The following steps are very important for TP to run properly.
The transport directory /usr/sap/trans must be installed and NFS mounted to all the systems in the CTS pipe line.
RDDIMPDP program must be running (event driven is recommended) in each client. RDDIMPDP can be scheduled in the background by executing RDDNEWPP or RDDPUTPP. Use the tp checkimpdp <sap sid> command in /usr/sap/trans/bin directory as <sid>adm user to check RDDIMPDP program.
Use the tp connect <sap sid> command in /usr/sap/trans/bin directory to see whether the tp program is connecting to the database successfully or not. To run TP command the user has to logon as <sid>adm in source or target system.
The R/3 Systems in the CTS pipeline must have different names.
The Global CTS Parameter File TPPARAM must be correctly configured.
The source system (for the export) and target system ( for the import) must have at least two background work processes. TP always schedules the C class job, so if all the background jobs are defined as A class job then there will be problems in transport steps.
Important Tips :.It is always better to have the up to date TP version installed in your system. A user can ftp a current version of TP from SAPSERV4 of SAP. Though R3trans and other utility programs can be used to do the transport, it is recommended to use TP whenever possible for the following reasons..
The exports and imports are done separately using TP program. For example: when a transport is released from the system, the objects are exported from the source database to the operating system and then the import phase starts to transport those objects to the target system.
TP takes care of the order of the objects. The order, that was followed to export the objects; the same order will be followed to import them to the target database.
The TP command processes all change requests or transports in the SAP system buffer that have not yet been imported successfully. All the import steps are executed automatically after TP calls R3trans program to execute the following necessary steps:
Dictionary Import: ABAP/4 dictionary objects will be imported in this step.
Dictionary Activation: Name tabs or runtime descriptions will be written inactively. The R/3 system keeps running until the activation phase is complete. The enqueue modules are the exceptions in the running phase. After the activation of new dictionary structure the new actions are decided to get the runtime objects to the target system.
Structure conversion: If necessary the table structure is changed in this phase.
Move Nametabs: The new ABAP/4 Dictionary runtime objects which were inactive up to now are moved into the active runtime environment in this process. The database structures are adjusted accordingly. From the first step to the Main import step inconsistencies can occur to the R/3 system. After the main import phase all the inconsistency ca be solved.
Main import with R3trans: All the data are imported completely and the system comes to a consistent state.
Activation of enqueue-objects: The enqueue-objects cannot be activated in the same way as the objects of the ABAP/4 Dictionary, so they have to be activated after the main import in this step. They are then used directly in the running system.
Structure Conversion of match codes, Import application defined objects, versioning and execution of user defined activities are some of the steps after activation of enqueue-objects. The next step is generation of ABAP/4 programs and screens, where all the programs and screens associated with the change request are generated. When all the import steps are completed successfully, the transport request is removed from the import buffer.
It is recommended by SAP to schedule regular periods for imports into the target system (e.g. daily, weekly or monthly). Shorter periods between imports are not advisable. The transport to production should not be done in the off hours when the users are not working
TP can be started with different parameters. The u201Ctp helpu201D command can help user to generate a short description about the use of the command.
The following are the some important commands of TP:
For export:
tp export <change request>: The complete objects in the request from the source system will be transported. This command also used by SAP System when it releases a request.
tp r3e <change request>: R3trans export of one transport request.
tp sde <change request>: Application defined objects in one transport request can be exported.
tp tst <change request> <SAP system >: The test import for transport request can be done using this command.
tp createinfo <change request>: This command creates a information file that is automatically done during the export.
tp verse <request>: This command creates version creates versions of the objects in the specified request.
To Check the transport buffer, global parameter file and change requests:
tp showbuffer <sid>: Shows all the change requests ready to be imported to the target system.
tp count <sid>: Using this command users can find out the number of requests in the buffer waiting for import.
tp go <sid>: This command shows the environment variables needed for the connection to the database of the <sid> or target system.
tp showparams <sid>: All the values of modifiable tp parameters in the global parameter file. The default value is shown for parameters that have not been set explicitly.
To import the change requests or transports:
tp addtobuffer <request>.<sid>: If a change request is not in the buffer then this command is used to add it to the buffer, before the import step starts.
tp import all <sid>: This command imports all the change requests from the buffer to the target system.
tp put <sid>: The objective of this command is same as u201Ctp import all <sid>u201D, but this command locks the system. This command also starts and stops the SAP system, if the parameters startsap and stopsap parameters are not set to u201D u201C.
tp import <change request> <sid>: To import a single request from the source system to target system.
tp r3h <change request>| all <sid>: Using this command user can import the dictionary structures of one transport or all the transport from the buffer.
tp act <change request>|all <sid>: This command activates all the dictionary objects in the change request.
tp r3i <change request> | all <sid>: This command imports everything but dictionary structures of one.
tp sdi <change request>|all <sid>: Import application-defined objects.
tp gen <change request>|all <sid>: Screen and reports are generated using this command.
tp mvntabs <sid>: All inactive nametabs will be activated with this command.
tp mea <change request>|all <sid>: This command will activate the enqueue modules in the change request.
When you call this command, note the resulting changes to the import sequence.
Additional tp utility options:
tp check <sid>|all (data|cofiles|log|sapnames|verbose): User uses this command to find all the files in the transport directory that are not waiting for imports and they have exceeded the minimum time specified using the COFILELIFETIME, LOGFILELIFETIME, OLDDATALIFETIME and DATALIFETIME parameters of TPPARAM file.
tp delfrombuffer <request>.<sid>: This command removes a single change request from the buffer. In case of TMS, the request will be deleted from the import queue.
tp setstopmark <sid>: A flag is set to the list of requests ready for import into the target system. When the user uses the command tp import all <sapsid> and tp put <sapsid>, the requests in front of this mark are only processed. After all the requests in front of the mark have been imported successfully, the mark is deleted.
tp delstopmark <sid>: This command deletes the stop mark from the buffer if it exists.
tp cleanbuffer <sapsid>: Removes all the change requests from the buffer that are ready for the import into the target system.
tp locksys <sid>: This command locks the system for all the users except SAP* and DDIC. The users that have already logged on are not affected by the call.
tp unlocksys <sid>: This command unlocks the system for all the users.
tp lock_eu <sid>: This command sets the system change option to u201Csystem can not be changedu201D tmporarily.
tp unlock_eu <sid>: This command unlocks the system for all the changes.
tp backupall <sid>: This command starts a complete backup using R3trans command. It uses /usr/sap/trans/backup directory for the backup.
tp backup delta <sid>: Uses R3trans for a delta backup into /usr/sap/trans/backup directory.
tp sapstart <sid>: To start the R/3 system.
tp stopsap <sid>: To stop the R/3 system.
tp dbstart <sid>: To start the database.
tp dbstop <sid>: To stop the database.
Unconditional modes for TP: Unconditional modes are used with the TP program and these modes are intended for the special actions needed in the transport steps. Using unconditional mode user can manipulate the rules defined by the workbench organizer. The unconditional mode should be used when needed, otherwise it might create problems for the R/3 system database. Unconditional mode is used after the letter u201CUu201D in the TP command. Unconditional mode can be a digit between 0 to 9 and each has a meaning to it. The following is a example of a import having unconditional mode.
tp import devk903456 qas client100 U12468
0: Called a overtaker; change request can be imported from buffer without deleting it and then uncoditional mode 1 is used to allow another import in the correct location.
1: If U1 is used with the export then it ignores the correct status of the command file; and if it is used with import then it lets the user import the same change request again.
2: When used with tp export, it dictates the program to not to expand the selection with TRDIR brackets. If used in tp import phase, it overwrites the originals.
3: When used with tp import, it overwrites the system-dependant objects.
5: During the import to the consolidation system it permits the source systems other than the integration system.
6: When used in import phase, it helps to overwrite objects in unconfirmed repairs.
8: During import phase it ignores the limitations caused by the table classification.
9: During import it ignores that the system is locked for this kind of transport.
R3trans: TP uses R3trans program to transport data from one system to another in the CTS pipeline. efficient basis administrator can use R3trans directly to export and import data from and into any SAP systems. Using this utility transport between different database and operating system can e done without any problems. Different versions of R3trans are fully compatible with each other and can be used for export and import. The basis administrator has to be careful using R3trans for different release levels of R/3 software; logical inconsistency might occur if the up to date R3trans is not used for the current version of R/3 system.
The syntax for using the control file is following:
R3trans [<options>] <control file> (several options used at the same time; at least one option must be there)
For example: R3trans u2013u 1 u2013w test.log test
In the above example a unconditional mode is used, a log file u201Ctest.logu201D file is used to get the log result and a control file u201Ctestu201D, where the instructions are given for the R3trans to follow. The user needs to logon as <sid>adm to execute R3trans.
The following options are available for the R3trans program:
R3trans -d : This command is used to check the database connection .
R3trans -u <int>: Unconditional mode can be used as we have seen in the above example.
R3trans -v : This is used for verbose mode. It writes additional details to the log file
R3trans -i <file>: This command directly imports data from data file without a control file.
R3trans -l <file>: This provides output of a table of contents to the log file.
R3trans -n : This option provides a brief information about new features of R3trans.
R3trans u2013t: This option is used for the test mode. All modifications in the database are rolled back.
R3trans -c <f1> [<f2>]: This command is used for conversion. The <f1> file will be copied to <f2> file after executing a character set conversion to the local character set.
Important tips: Do not confuse the backup taken using R3trans with database backup. The backups taken using R3trans are logical backups of objects. In case something happens to the SAP system these backups can not be used for recovery. R3trans backups can be only used to restore a copy of a particular object that has been damaged or lost by the user.
R3trans -w <file>: As we have seen in the above example this option can be used to write to a log file. If no file is mentioned then trans.log is default directory for the log.
R3trans also can be used for the database backup.
R3trans u2013ba: This command is used for a complete backup. we will see in the next paragraph how to use
the control file for the backup.
R3trans u2013bd: This command is used for a delta backup if the user does not want a complete backup.
R3trans u2013bi: This option will display backup information.
The following are some of the examples of control files:
We have already learned how to use a command for the logical backup of the objects in the database. To get a complete backup the following example control file can be used.
backup all
file = /usr/sap/trans/backall
The option u201Cfile = u2026u201D is the name of the directory into which the data files are to be written. If you are taking a complete backup of DEV system then the backup file is going to look like u201CDEV.A000.bcku201D the next complete
Reward if useful
Regards
divya -
Hi Friends,
I run t-code FF7A - Cash position report with the display option 'Delta display'. The report shows the balances with balances on day 1 (for today). Subsequent days it shows without balance correctly as I need.
Anybody faced similar problem? Appreciate your responses.
Kalyan.I had posted a OSS note for the above question and SAP says that the FF7A report with the option 'Delta display' will (that is SAP's intention) display 'with balance' in the first and last column and 'without balance' in the other columns.
So when we run the report today we should use 'Current day minus 1' in the 'display as of ' field. so that in the second column we can see today's transactions without balance. That works for me.
Thanks to all who replied to my posting.
Kalyan. -
Cash Position - Entry for accounts with balance zero
Hello Guru,
is there a possibility to see in my cash position one entry for each account, which is included in the structure, even if the balance of the corresponding account is zero. At the moment I get no entry for accounts whose balances are zero.
Best regards
PhillipI had posted a OSS note for the above question and SAP says that the FF7A report with the option 'Delta display' will (that is SAP's intention) display 'with balance' in the first and last column and 'without balance' in the other columns.
So when we run the report today we should use 'Current day minus 1' in the 'display as of ' field. so that in the second column we can see today's transactions without balance. That works for me.
Thanks to all who replied to my posting.
Kalyan. -
Filter Delta Upload from CRM into R3
Hi SAP gurus,
How can i set the filter for delta upload from CRM into R3? As far as i know, the filter settings in R3AC1 is only applicable for data exchange from the source system R3. What if i would like to filter the data where the source is CRM instead? Did i miss out anything in the configuration? I have been able to filter data coming from R3, but NOT data from CRM going into R3.
Would appreciate your help on this.
Thanks. Points will be rewarded.Do you set all req.customizing in tr smoeac?
-
ALE Delta using Change Document
Hi Experts,
Im having a problem here..
We need to create R3 Delta Extractor for SAP Standard tables but these tables doesnt have the delta-specific field that can be used as delta.
So we tried to use ALE Delta for some of the sap standard tables and it worked and thats because the ALE Delta config already maintained in SCDO by SAP. But there are some of the SAP tables are not set in the tcode SCDO so I need to create a new entries in SCDO and generates the update program. But the thing is these tables are maintaned by user in SAP Standard tcode and the user do not want to have a customized program to maintain the tables. So how should I do this? Where should I park the generated update program? I already checked he tcodes doesnt have any user exits.
These are the tables that i want to create the ALE Delta:
T8J1A
T8J1B
and they are maintaned in standard sap tcode GJ25 and GJ26 respectively.Hi Sudheer,
I have the same business requirement. If you get an answer to this, I would be interested in hearing the resutls. Thanks! -
Uploading data from Legacy system
Hi
i am shorthly going to work on data migration project. I have never worked on a data migration project and want to know the answers for the following questions.
1] which technique i must first consider in data upload ( both master data and transaction data )
2] What steps are involved?
3] I know we can use LSMW, BAPI's , BDC , Direct Input , IDOC etc but want to know which one choose and when?
4] What care must be taken in each data migration
5] is there is std list of programs or a good document on when to choose what?
~SRHi,
Data migration can be done by the follwoing methods:
LSMW : for master data migartion or small data migartion
BAPI : its just like a FM , thru which u can create master aswell as Transactional data.
u have to import some paremetre as well as tables if required, and Bapi will RETURN the message saying so and so material/delievry had cretaed.
BDC : in BDC we got 2 methods.
CAll transaction and session.
CAll transacton : using this u can uplaod transcational data as well as master data.
the updation can be synchronus or asynchronus updates.
Session: using this u can uplaod transcational data as well as master data.
The updation in session is synchronus, so its time taking process.
Most of the time we go for Call transcation In real situations.
Dircet input method: its out dated.no longer it is being used.
in all the above cases, data is alraedy existing in flat file and u r going to migrate the data in one shot but IDOC is used where the dynamical data migration is necessary.
suppose say ones the material is craeted in legacy sytem , that particulat matreial shud be migarted to R/3.this can be handled thru IDOC.
Idoc: master data as well as Trnascational data is migarted thru IDOC( matmas, orders).
Idoc uses ALE technology in migartion of idoc.
Revert back if any issues.
Check these links.
SAP Data Migration with LSMW
http://www.sap-img.com/sap-data-migration.htm
For BDC:
http://myweb.dal.ca/hchinni/sap/bdc_home.htm
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/bdc&
http://www.sap-img.com/abap/learning-bdc-programming.htm
http://www.sapdevelopment.co.uk/bdc/bdchome.htm
http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm
http://help.sap.com/saphelp_47x200/helpdata/en/69/c250684ba111d189750000e8322d00/frameset.htm
http://www.sapbrain.com/TUTORIALS/TECHNICAL/BDC_tutorial.html
LSMW
No ABAP effort are required for the SAP data migration. However, effort are required to map the data into the structure according to the pre-determined format as specified by the pre-written ABAP upload program of the LSMW.
The Legacy System Migration Workbench (LSMW) is a tool recommended by SAP that you can use to transfer data once only or periodically from legacy systems into an R/3 System.
More and more medium-sized firms are implementing SAP solutions, and many of them have their legacy data in desktop programs. In this case, the data is exported in a format that can be read by PC spreadsheet systems. As a result, the data transfer is mere child's play: Simply enter the field names in the first line of the table, and the LSM Workbench's import routine automatically generates the input file for your conversion program.
The LSM Workbench lets you check the data for migration against the current settings of your customizing. The check is performed after the data migration, but before the update in your database.
So although it was designed for uploading of legacy data it is not restricted to this use.
We use it for mass changes, i.e. uploading new/replacement data and it is great, but there are limits on its functionality, depending on the complexity of the transaction you are trying to replicate.
The SAP transaction code is 'LSMW' for SAP version 4.6x.
For those with the older SAP version (4.7 and below), the data migration programs might not have been pre-loaded.
You can download the LSMW at no cost from SAPNet under Services, SAP Methodology and Tools, category Tools.
If you are an existing SAP customer with an OSS ID, you can access the SAP Service Marketplace to download the LSWM for your Basis teams to install to your SAP system: http://service.sap.com/lsmw
The LSM Workbench carries out the following tasks:
Reads the transfer data from one or more files (for example, spreadsheets, sequential files etc.)
Converts the data from the source format into the target format
Note that with background processing, the input file must not be located in the presentation server. Access to presentation server files is only possible when you are working onlineUpload Condition Pricing
LSMW STEPS
Data Cleansing
Data cleansing allows you to compare, include and merge redundant business partner master records (potential duplicates) in data cleansing cases. Following the data cleansing process you can remove data records from the system using archiving.
Integration
Before you can carry out data cleansing, you must determine the redundant data in your system and include it in data cleansing cases.
You have the following options for duplicate recognition and creation of data cleansing cases.
The Business Address Services (BAS) provide interfaces for integrating the relevant external software (search machines).
User-defined programs
Services of data providers, who check their data for possible duplicates.
In the options described above, the data cleansing cases are created via the system and put into the data cleansing worklist for further processing.
In individual cases you can find potential business partner duplicates in the hitlist of the business partner search and create a separate data cleansing case.
After connecting the non-SAP software (search engines), the system starts duplicate recognition (Delta Scan) with every change to or new entry of a business partner for this specific individual record. You should do a full scan through the complete dataset at the beginning of the consolidation process using the non-SAP software, this registers all potential duplicates in data cleansing cases and makes them available or further processing.
Within the application basis, the referencing objects, which are taken into account by the data cleansing, are limited to the sub-objects of the business partner. You have the possibility to make modification-free enhancements to the referencing objects.
Prerequisites
You must have determined the redundant data records in your system.
To use the interface of the Business Address Services, make the following Customizing settings: SAP Implementation Guide -> Basis -> Basis Services -> Address Management -> Activate Duplicate Check Index Pool
Make the following system settings in the IMG of the SAP Business Partner: Basic Settings -> Data Cleansing -> Maintain Number Range / Define Priorities / Activate Data Cleansing.
Activities
Register data cleansing cases via BAPIs or create them in the dialog for business partner maintenance from the worklist or the business partner search.
Process the created data cleansing cases in a separate process step afterwards.
BATCH DATA COMMUNICATION
About Data Transfer In R/3 System
When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes into replace or complement existing application.
In the process of replacing current applications and transferring application data, two situations might occur:
The first is when application data to be replaced is transferred at once, and only once.
The second situation is to transfer data periodically from external systems to SAP and vice versa.
There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive.
The SAP system offers two primary methods for transferring data into SAP systems. From non-SAP systems or legacy system. These two methods are collectively called batch input or batch data communication.
1. SESSION METHOD
2. CALL TRANSACTION
3. DIRECT INPUT
Advantages offered by BATCH INPUT method:
1. Can process large data volumes in batch.
2. Can be planned and submitted in the background.
3. No manual interaction is required when data is transferred.
4. Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.
To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP system. This program, known as a data transfer program must map the data from the external system into the data structure required by the SAP batch input program.
The batch input program must build all of the input to execute the SAP transaction.
Two main steps are required:
To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.
To pass the table to SAP for processing.
Prerequisite for Data Transfer Program
Writing a Data Transfer Program involves following prerequisites:
Analyzing data from local file
Analyzing transaction
Analyzing transaction involves following steps:
The transaction code, if you do not already know it.
Which fields require input i.e., mandatory.
Which fields can you allow to default to standard values.
The names, types, and lengths of the fields that are used by a transaction.
Screen number and Name of module pool program behind a particular transaction.
To analyze a transaction::
Start the transaction by menu or by entering the transaction code in the command box.
(You can determine the transaction name by choosing System Status.)
Step through the transaction, entering the data will be required for processing your batch input data.
On each screen, note the program name and screen (dynpro) number.
(dynpro = dyn + pro. Dyn = screen, pro = number)
Display these by choosing System Status. The relevant fields are Program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen.
The technical info pop-up shows not only the field information but also the program and screen.
For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical Info.
Note the following information:
- The field name for batch input, which youll find in its own box.
The length and data type of the field. You can display this information by double clicking on the Data Element field.
Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen).
Place the cursor on the button or menu entry while holding down the left mouse button. Then press F1.
In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.
You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.
Once you have program name, screen number, field name (screen field name), you can start writing.
DATA TRANSFER program.
Declaring internal table
First Integral Table similar to structure like local file.
Declaring internal table like BDCDATA
The data from internal table is not transferred directly to database table, it has to go through transaction. You need to pass data to particular screen and to particular screen-field. Data is passed to transaction in particular format, hence there is a need for batch input structure.
The batch input structure stores the data that is to be entered into SAP system and the actions that are necessary to process the data. The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION.
This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is as follows:
Create a BDCDATA structure
Write the structure out to a session or process it with CALL TRANSACTION USING; and then
Create a BDCDATA structure for the next transaction that is to be processed.
Within a BDCDATA structure, organize the data of screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.
The screen identifier record is followed by a separate BDCDATA record for each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:
Data that is entered into screen fields.
Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.
The BDCDATA structure contains the following fields:
PROGRAM: Name of module pool program associated with the screen. Set this field only for the first record for the screen.
DYNPRO: Screen Number. Set this field only in the first record for the screen.
DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to (blank) for all other records.)
FNAM: Field Name. The FNAM field is not case-sensitive.
FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format.
Transferring data from local file to internal table
Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.
Population of BDCDATA
For each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure.
All these five initial steps are necessary for any type of BDC interface.
DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same.
First step for both the methods is to upload the data to internal table. From Internal Table, the data is transferred to database table by two ways i.e., Session method and Call transaction.
SESSION METHOD
About Session method
In this method you transfer data from internal table to database table through sessions.
In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.
When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system.
Unless session is processed, the data is not transferred to database table.
BDC_OPEN_GROUP
You create the session through program by BDC_OPEN_GROUP function.
Parameters to this function are:
User Name: User name
Group: Name of the session
Lock Date: The date on which you want to process the session.
Keep: This parameter is passed as X when you want to retain session after
processing it or to delete it after processing.
BDC_INSERT
This function creates the session & data is transferred to Session.
Parameters to this function are:
Tcode: Transaction Name
Dynprotab: BDC Data
BDC_CLOSE_GROUP
This function closes the BDC Group. No Parameters.
Some additional information for session processing
When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not.
However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.
CALL TRANSACTION
About CALL TRANSACTION
A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>
Messages into <MSGTAB>.
Parameter 1 is transaction code.
Parameter 2 is name of BDCTAB table.
Parameter 3 here you are specifying mode in which you execute transaction
A is all screen mode. All the screen of transaction are displayed.
N is no screen mode. No screen is displayed when you execute the transaction.
E is error screen. Only those screens are displayed wherein you have error record.
Parameter 4 here you are specifying update type by which database table is updated.
S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.
A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).
Parameter 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:
1. Tcode: Transaction code
2. Dyname: Batch point module name
3. Dynumb: Batch input Dyn number
4. Msgtyp: Batch input message type (A/E/W/I/S)
5. Msgspra: Batch input Lang, id of message
6. Msgid: Message id
7. MsgvN: Message variables (N = 1 - 4)
For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).
Steps for CALL TRANSACTION method
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)
4. Loop at itab.
Populate BDCTAB table.
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>.
Refresh BDCTAB.
Endloop.
(To populate BDCTAB, You need to transfer each and every field)
The major differences between Session method and Call transaction are as follows:
SESSION METHOD CALL TRANSACTION
1. Data is not updated in database table unless Session is processed. Immediate updation in database table.
2. No sy-subrc is returned. Sy-subrc is returned.
3. Error log is created for error records. Errors need to be handled explicitly
4. Updation in database table is always synchronous Updation in database table can be synchronous Or Asynchronous.
Error Handling in CALL TRANSACTION
When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:
Steps for the error handling in CALL TRANSACTION
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL
4. Internal table similar to Ist internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction <tr.code> using <Bdctab>
Mode <A/N/E>
Update <S/A>
Messages <BDCMSG>.
Perform check.
Refresh BDCTAB.
Endloop.
7 Form check.
IF sy-subrc 0. (Call transaction returns the sy-subrc if updating is not successful).
Call function Format_message.
(This function is called to store the message given by system and to display it along with record)
Append itab2.
Display the record and message.
DIRECT INPUT
About Direct Input
In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly.
You can start a Direct Input program in two ways;
Start the program directly
This is the quickest way to see if the program works with your flat file. This option is possible with all direct input programs. If the program ends abnormally, you will not have any logs telling you what has or has not been posted. To minimize the chance of this happening, always use the check file option for the first run with your flat file. This allows you to detect format errors before transfer.
Starting the program via the DI administration transaction
This transaction restarts the processing, if the data transfer program aborts. Since DI document are immediately posted into the SAP D/B, the restart option prevents the duplicate document posting that occurs during a program restart (i.e., without adjusting your flat file).
Direct input is usually done for standard data like material master, FI accounting document, SD sales order and Classification for which SAP has provided standard programs.
First time you work with the Direct Input administration program, you will need to do some preparation before you can transfer data:
- Create variant
Define job
Start job
Restart job
Common batch input errors
- The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen.
The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.
On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this.
The BDCDATA structure contains fields, which are longer than the actual definition.
Authorization problems.
RECORDING A BATCH INPUT
A B recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format.
You can either use SHDB transaction for recording or
EDIT BATCH INPUT  SERVICES SYSTEM
And from here click recording.
Enter name for the recording.
(Dates are optional)
Click recording.
Enter transaction code.
Enter.
Click Save button.
You finally come to a screen where, you have all the information for each screen including BDC_OKCODE.
Click Get Transaction.
Return to BI.
Click overview.
Position the cursor on the just recorded entry and click generate program.
Enter program name.
Click enter
The program is generated for the particular transaction.
BACKGROUND PROCESSING
Need for Background processing
When a large volume of data is involved, usually all batch inputs are done in background.
The R/3 system includes functions that allow users to work non-interactively or offline. The background processing systems handle these functions.
Non-interactively means that instead of executing the ABAP/4 programs and waiting for an answer, user can submit those programs for execution at a more convenient planned time.
There are several reasons to submit programs for background execution.
The maximum time allowed for online execution should not exceed 300 seconds. User gets TIMEOUT error and an aborted transaction, if time for execution exceeds 300 seconds. To avoid these types of error, you can submit jobs for background processing.
You can use the system while your program is executing.
This does not mean that interactive or online work is not useful. Both type of processing have their own purposes. Online work is the most common one entering business data, displaying information, printing small reports, managing the system and so on. Background jobs are mainly used for the following tasks; to process large amount of data, to execute periodic jobs without human intervention, to run program at a more convenient, planned time other than during normal working hours i.e., Nights or weekends.
The transaction for background processing is SM36.
Or
Define jobs Jobs  Administration Tools
Or
System Jobsservices
Components of the background jobs
A job in Background processing is a series of steps that can be scheduled and step is a program for background processing.
Job name. Define the name of assigned to the job. It identifies the job. You can specify up to 32 characters for the name.
Job class. Indicates the type of background processing priority assigned to the job.
The job class determines the priority of a job. The background system admits three types of job classes: A B & C, which correspond to job priority.
Job steps. Parameters to be passed for this screen are as follows:
Program name.
Variant if it is report program
Start criteria for the job: Option available for this are as follows:
Immediate - allows you to start a job immediately.
Date/Time - allows you to start a job at a specific name.
After job - you can start a job after a particular job.
After event - allows you to start a job after a particular event.
At operation mode - allows you to start a job when the system switches to a particular operation mode.
Defining Background jobs
It is two step process: Firstly, you define the job and then release it.
When users define a job and save it, they are actually scheduling the report i.e., specifying the job components, the steps, the start time.
When users schedule program for background processing, they are instructing the system to execute an ABAP/4 report or an external program in the background. Scheduled jobs are not executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time. Both scheduling and releasing of jobs require authorizations.
HANDLING OF POP UP SCREEN IN BDC
Many times in transaction pop up screen appears and for this screen you dont pass any record but some indication to system telling it to proceed further. For example: The following screen
To handle such screen, system has provided a variable called BDC_CURSOR. You pass this variable to BDCDATA and process the screen.
Usually such screen appears in many transactions, in this case you are just passing information, that YES you want to save the information, that means YES should be clicked. So you are transferring this information to BDCDATA i.e., field name of YES which is usually SPOT_OPTION. Instead of BDC_OKCODE, you are passing BDC_CURSOR.
BDC_CURSOR is also used to place cursor on particular field.
AN EXAMPLE WITH SESSION METHOD
Following program demonstrates how data is passed from flat file to SAP transaction and further to database table by using SESSION method.
The transaction is TFBA (to change customer).
A simple transaction where you are entering customer number on first screen and on next screen data is displayed for the particular customer number. Field, which we are changing here, are name and city. When you click on save, the changed record gets saved.
Prerequisite to write this BDC interface as indicated earlier is:
1. To find screen number
2. To find screen field names, type of the field and length of the field.
3. To find BDC_OKCODE for each screen
4. Create flat file.
Flat file can be created in your hard disk as follows:
1 Vinod Krishna Hyderabad
2 Kavitha Secunderabad
3 Kishore Hyderabad
(Where 1st character field is Customer number, 2nd field is Customer name and 3rd field is City.)
To transfer this data to database table SCUSTOM following interface can be used.
REPORT DEMO1.
Following internal table is to upload flat file.
DATA: BEGIN OF ITAB OCCURS 0,
ID(10),
NAME(25),
CITY(25),
END OF ITAB.
*Following internal table BDCDATA is to pass date from internal table to session.
DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE.
Variables
DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. This is for Hold Date
To upload flat file to internal table.
CALL FUNCTION UPLOAD
EXPORTING
FILE NAME = C:FF.TXT
FILE TYPE = ASC
TABLES
DATA_TAB = ITAB
EXCEPTIONS
CONVERSION_ERROR = 1
INVALID_TABLE_WIDTH = 2
INVALID_TYPE = 3
NO_BATCH = 4
UNKNOWN_ERROR = 5
OTHERS = 6.
If sy-subrc = 0.
Calling Function to Create a Session
CALL FUNCTION BDC_OPEN_GROUP
EXPORTING
CLIENT = SY-MANDT
GROUP = POTHURI
HOLDDATE = DATE1
KEEP = X
USER = SY-UNAME
EXCEPTIONS
CLIENT_INVALID = 1
DESTINATION_INVALID = 2
GROUP_INVALID = 3
GROUP_IS_LOCKED = 4
HOLDDATE_INVALID = 5
INTERNAL_ERROR = 6
QUEUE_ERROR = 7
RUNNING = 8
SYSTEM_LOCK_ERROR = 9
USER_INVALID = 10
OTHERS = 11.
If sy-subrc = 0.
*-- MAIN Logic--
LOOP AT ITAB
PERFORM GENERATE_DATA. Populating BDCDATA Table
CALL FUNCTION BDC_INSERT
EXPORTING
TCODE = TFBA
TABLES
DYNPROTAB = BDCTAB
EXCEPTIONS
INTERNAL_ERROR = 1
NOT_OPEN = 2
QUEUE_ERROR = 3
TCODE_INVALID = 4
PRINTING_INVALID = 5
POSTING_INVALID = 6
OTHERS = 7.
REFRESH BDCTAB
ENDLOOP.
Calling function to close the session
CALL FUNCTION BDC_CLOSE_GROUP
EXCEPTIONS
NOT_OPEN = 1
QUEUE_ERROR = 2
OTHERS = 3.
Endif.
Endif.
*& Form GENERATE_DATA
Create BDC Data
FORM GENERATE_DATA
Passing information for 1st screen on BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAX-DYNPRO = 100.
BDCTAP-DYNBEGIN = X.
APPEND BCDTAB.CLEAR BDCTAB.
Passing field information to BDCDATA
BDCTAB-FNAM = SCUSTOM-ID
BDCTAB-FVAL = ITAB-ID.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = /5.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information for next screen to BDCDATA
BDCTAB-PROGRAM = SAPMTFBA.
BDCTAB-DYNPRO = 200.
BDCTAB-DYNBEGIN = X.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-NAME.
BDCTAB-FVAL = ITAB-NAME.
APPEND BDCTAB.CLEAR BDCTAB.
Passing screen information to BDCDATA
BDCTAB-FNAM = SCUSTOM-CITY.
BDCTAB-FVAL = ITAB-CITY.
APPEND BDCTAB.CLEAR BDCTAB.
Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = BDC_OKCODE.
BDCTAB-FVAL = SAVE.
APPEND BDCTAB.CLEAR BDCTAB.
ENDFORM. GENERATE_DATA
AN EXAMPLE WITH CALL TRANSACTION
Same steps to be repeated for CALL TRANSACTION
The only difference between the two types of interface is in Session method, you create session and store information about screen and data into session. When session is processed the data is transferred to database. While in CALL TRANSACTION, data is transferred directly to database table.
REPORT DEMO1.
Follow above Code till MAIN Logic. Even the Subroutine should be copied
LOOP AT ITAB
PERFORM GENERATE_DATA, Populating BDCDATA Table
Call transaction TFBA using BCDDATA Mode A Update S.
REFRESH BDCTAB
ENDLOOP.
check this link:
http://www.sap-img.com/abap/learning-bdc-programming.htm
http://www.sap-img.com/bdc.htm
www.sappoint.com/abap/bdcconcept.pdf
www.sap-img.com/abap/learning-bdc-programming.htm
www.sap-img.com/abap/question-about-bdc-program.htm
www.sapdevelopment.co.uk/bdc/bdchome.htm
www.planetsap.com/bdc_main_page.htm
Re: bdc mm01
http://www.sapbrain.com/TUTORIALS/TECHNICAL/BDC_tutorial.html
http://www.sap-img.com/abap/bdc-example-using-table-control-in-bdc.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/fa/097119543b11d1898e0000e8322d00/frameset.htm
http://myweb.dal.ca/hchinni/sap/bdc_home.htm
IDOC
What is IDOC ?
IDoc
Standard SAP format for electronic data interchange between systems (Intermediate Document). Different message types (such as delivery confirmations or purchase orders) normally represent different specific formats, the IDoc types. However, multiple message types with related content can be assigned to one IDoc type: For example, the IDoc type ORDERS01 transfers the logical message types ORDERS (purchase order) and ORDRSP (order confirmation).
Also check these link it will help you.
idoc information
http://help.sap.com/saphelp_nw2004s/helpdata/en/78/21785851ce11d189570000e829fbbd/frameset.htm
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/xi/sapR3%28Idocs%29ToXI--Steps+Summarized&
/people/prateek.shah/blog/2005/06/08/introduction-to-idoc-xi-file-scenario-and-complete-walk-through-for-starters
ALE/ IDOC/ XML
Troubleshooting of ALE Process - /people/raja.thangamani/blog/2007/07/19/troubleshooting-of-ale-process
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
IDOC Convertion
/people/kevin.wilson2/blog/2005/12/07/changing-fields-in-an-idoc-segment
Please check this online document for ALE and IDoc.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEIO/BCMIDALEIO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf
Also check this links for additional information.
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
serialization /people/alessandro.guarneri/blog/2006/11/26/content-based-serialization-dynamic-queue-name-in-xi
/people/prateek.shah/blog/2005/06/08/introduction-to-idoc-xi-file-scenario-and-complete-walk-through-for-starters - IDoc to File
IDOc testing - /people/suraj.sr/blog/2005/12/29/generate-test-case-for-an-idoc-scenario
/people/ravikumar.allampallam/blog/2005/06/24/convert-any-flat-file-to-any-idoc-java-mapping - Any flat file to any Idoc
/people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm - Collection of IDoc to Single File
/people/stefan.grube/blog/2006/09/18/collecting-idocs-without-using-bpm - collecting IDocs without BPM
/people/prateek.shah/blog/2005/06/08/introduction-to-idoc-xi-file-scenario-and-complete-walk-through-for-starters - IDoc to File
Hope it will be useful to u....plz don't forget to reward points...!!!!
Regards
Vasu -
Hi,
We have recently activated PM, MM & QM related Business contents and started taking the data in BW. We have following questions / doubts on RSA7 screen.
1. After executing the delta job in R/3, we can see the records in RSA7. There is one column 'Total' against each datasource.
--->Our question is when this column gets updated. Because we are unable to find the count what it is showing.
2. After uploading the delta succesfully in BW, when we return back to RSA7 screen, delta queue becomes empty. i.e when we select a datasource and click on 'Display data entries' button, we gets a message 'List contains no data'.
---> Our assumption is that delta queue becomes empty immediately after loading the delta into BW. But whatif the delta fails at BW side by some reasons ?
Please give your valuable inputs.
Thanks
Ramesh GanjiHi,
1. this number is reflecting the number of LUWs (logical units of work) in your delta queue. if you go to SMQ1 you'll see for instance InboundQueue MCEX03 (MM) with a number. These are the numbers of LUW successfully (could be number of documents or not since a LUW may commit several docs) recorded for your datasource.
When the update is fired, the InBoundQueue is passed to the Delta queue enabling you to see it in RSA7, for instance BW<CLIENT>2LIS_03_BF/UM.
2. yes, when you load your delta in BW the delta queue is empty. However we shall be more precise: it is the NEXT delta which doesn't have any data. Indeed you are always able to REPEAT the last delta.
In RSA7, you'll still see a number of LUWs <> 0 because there is still data in the repeat which you can display in RSA7. If you fire a second delta form BW right after the previous and there has been no update in between you shall get 0 records and the number is 0 in RSA7.
A delta gets repeated when you set your delta request status to RED in the monitor in SAP BW. When you'll request the next delta, the system will prompt you if you want to repeat it. If you gave this situation while executing a process chain the system will do it in silent mode if the request is NOT posted in ANY target; if a target still has the request, it won't request it since the system needs clarification from the user.
This is the plugin mechanism used in order to ensure integrity and system communications and I have to admit that's quite clever and reliable...
hope this helps
Olivier -
Hi,
I read many threads, but cudnt find any final answer. Can you please let me know how to extract CRM (6.0) to BW/BI systems!
What are the useful tcodes and how to enhance the Data Sources!
Thnx.There is no interval settings required, like there are for FI. Here's the technical description of the CRM extraction process for both Full and Delta extraction.
1) SAP BW calls the BW Adapter using the Service API.
2) BW Adapter reads the data from the source table for the DataSource.
3) Selected data is converted into the extract structure as a BDoc.
4) The BDoc type determine the BAdI that is called by the BW Adapte.
5) Data Package is transferred to SAP BW using the Service API.
Some considerations for Delta are:
1) Net changes in CRM are communicated via BDoc.
2) The flow controller for BDocs calls the BW Adapter.
3) BW Adapter checks if net change is in BDoc that's BW relevantci.
4) Non-relevant net changes are not sent to SAP BW.
5) Relevant net changes are transferred to SAP BW.
6) CRM standard DataSources use AIMD delta method. -
Long running init -- impact on delta
Hello experts,
I know that this is something of a basic question, but I'd still like someone to clarify.
The question that I have is regarding the time stamp that is set for the delta records. I have an initialization job that runs for a long time (let's say 4 hours). My question is if the timestamp for the delta is set at the start of the init job or at the end of it? If there are any transactions that occur during the time the init job is running, are they captured in the delta queue (RSA7) or do they form a part of the init job and the delta marker/timestamp is set at the end of the init job such that the new/changed records get picked up in the queue later on.
I know that the other alternative is to run an init without data transfer and get the rest of the records in full repair requests. I'd like to know the impact of the long running init job before I choose which way to go.
Thanks in advance for the responses.Hi,
For the timestamp data sources like FI,Co you cannot maintain the safelty interval delta as this is maintained by SAP.
The table names are BWOM2_TIMEST for controlling and for FI data sources in BWOM_SETTINGS tables.
The note 416265 tells you how to change it for CO and 1012874 for FI... but SAP strongly reccomends not to change these settings.
In case of FI-CO data sources you will not be able to see the data into the delta queue as there delta records are not pushed into delta queue by SAP but are pulled by BW system when the delta is scheduled.
So even if the delta is created you cannot see it in the delta queue.
For CO data source as I told you the records which got changed 2 hours before the initialization of the data sources only will come into delta queue and will get picked into delta.
The same is maintained for FI datasources.
Thanks
Ajeet
Maybe you are looking for
-
X64 Oracle 11g R2 Install On i7 3770 Windows 7 x64 Enterprise System Fails
x64 Oracle 11gR2 installation on my new Windows 7 x64 Enterprise system fails after the "Desktop/Server Class" screen. I click Next, and then nothing happens. The install app closes and no installation logs are available. I checked the Windows logs a
-
hi i have adifficult to acess itune. the avfoundationCF.dll is missing on my laptop error 7( windows error 126).how to reinstal it,thanks for your help
-
Scanning characters in a text file
Hello, firstly I am trying to get the program to work, then I will use different methods (program description shown in code). I have not done Java for a while therefore I do not know if i am on the right track or not - please say. Basicly I have the
-
Exception occured when I create owb repository owner on AIX box
Does Anyone excounter the issue? bash-2.04$ uname -a AIX sdcb80a061 3 5 00046F0F4C00 bash-2.04$ oslevel -r 5300-08 bash-2.04$ main.TaskScheduler timer[5]20090428@23:56:09.009: 00> oracle.wh.service.impl.assistant.ProcessEngine.display(ProcessEngine.j
-
CS4 Swap Image Disppears in IE
Hello Thank you for your time I've built a page using DWCS4 - that contains an image rollover built using DWCS4 - each rollover also displays a hidden layer built using DWCS4 behaviors - i pasted a code snippet below The problem is: The page displays