************************************************************************
* Performance tuning using GROUPBY
*
* Extracts from program ZFAL2002
************************************************************************
************************************************************************
* START-OF-SELECTION
SELECT KALNR KALKA BWVAR MEEHT SUM( MENGE )
INTO TABLE I_CKIS FROM CKIS
WHERE KADKY <= SY-DATUM
AND TVERS = '01'
AND KALKA IN ('01','Z1','Z2')
AND BWVAR IN ('Z01','Z02','Z03','Z04','Z07')
* and kkzst = ' '
AND KKZMA = ' '
AND TYPPS = 'E'
AND ( KSTAR <> 800040 OR KSTAR <> 800050 )
AND ( MEEHT = 'MIN' OR MEEHT = 'H' )
GROUP BY KALNR KALKA BWVAR MEEHT.
* Perform actual processing
Perform get_associated_labour_hours.
*----------------------------------------------------------------------*
FORM GET_ASSOCIATED_LABOUR_HOURS.
* Determine start position and then process single record for given key
* i_ckis is sorted on kalnr kalka bwvar meeht with menge summated.
READ TABLE I_CKIS WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
MEEHT = 'H' BINARY SEARCH.
IF SY-SUBRC = 0.
D_LAB_HRS = I_CKIS-MENGE * 60.
ENDIF.
READ TABLE I_CKIS WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
MEEHT = 'MINS' BINARY SEARCH.
IF SY-SUBRC = 0.
D_LAB_HRS = D_LAB_HRS + I_CKIS-MENGE.
ENDIF.
D_LAB_HRS = D_LAB_HRS / W_KEKO-LOSGR.
D_LAB_HRS = D_LAB_HRS / 60. "Convert from mins into hours
ENDFORM. " GET_LABOUR_HOURS_ASSOCIATED
Sunday, May 13, 2007
Performance Tuning using Parallel cursor
************************************************************************
* Performance Tuning using parallel cursor
*
* Extracts from program ZFAL2002
************************************************************************
************************************************************************
* START-OF-SELECTION
SELECT *
INTO TABLE I_KEPH FROM KEPH
WHERE KADKY <= SY-DATUM
AND TVERS = '01'
AND KALKA IN ('01','Z1','Z2')
AND BWVAR IN ('Z01','Z02','Z03','Z04','Z07')
AND KKZST = ' '
AND KKZMA = ' '
AND KKZMM = ' '
AND KEART = 'H'
AND PATNR = 0.
* Table must be sorted to ensure all required records are together
SORT I_KEPH BY KALNR KALKA BWVAR KADKY.
* Perform actual processing
Perform get_cost_values.
*----------------------------------------------------------------------*
FORM GET_COST_VALUES.
* Determine start position and then process all records for given key
* from that starting point
* i_keph is sorted on kalnr kalka bwvar kadky.
READ TABLE I_KEPH WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
KADKY = W_KEKO-KADKY BINARY SEARCH.
IF SY-SUBRC = 0.
* Loop at itab from first record found (sy-tabix) until record
* no-longer matches your criteria.
LOOP AT I_KEPH FROM SY-TABIX.
IF I_KEPH-KALNR = W_KEKO-KALNR AND I_KEPH-KALKA = W_KEKO-KALKA
AND I_KEPH-BWVAR = W_KEKO-BWVAR AND I_KEPH-KADKY = W_KEKO-KADKY.
* Key match
D_MAT_COST = D_MAT_COST + I_KEPH-KST001.
D_LAB_COST = D_LAB_COST + I_KEPH-KST004.
D_OVER_HEAD = D_OVER_HEAD + I_KEPH-KST010.
D_EXT_PURCH = D_EXT_PURCH + I_KEPH-KST014.
D_MISC_COST = D_MISC_COST + I_KEPH-KST002 + I_KEPH-KST003
+ I_KEPH-KST005 + I_KEPH-KST006 + I_KEPH-KST007
+ I_KEPH-KST008 + I_KEPH-KST009 + I_KEPH-KST011
+ I_KEPH-KST012 + I_KEPH-KST013 + I_KEPH-KST015
+ I_KEPH-KST016 + I_KEPH-KST017 + I_KEPH-KST018
+ I_KEPH-KST019 + I_KEPH-KST020 + I_KEPH-KST021
+ I_KEPH-KST022 + I_KEPH-KST023 + I_KEPH-KST024
+ I_KEPH-KST025 + I_KEPH-KST026 + I_KEPH-KST027
+ I_KEPH-KST028 + I_KEPH-KST029 + I_KEPH-KST030
+ I_KEPH-KST031 + I_KEPH-KST032 + I_KEPH-KST033
+ I_KEPH-KST034 + I_KEPH-KST035 + I_KEPH-KST036
+ I_KEPH-KST037 + I_KEPH-KST038 + I_KEPH-KST039
+ I_KEPH-KST040.
ELSE.
* Key greater - can't be less
EXIT. " Exit loop
ENDIF.
ENDLOOP.
ENDIF.
D_MAT_COST = D_MAT_COST / W_KEKO-LOSGR.
D_LAB_COST = D_LAB_COST / W_KEKO-LOSGR.
D_OVER_HEAD = D_OVER_HEAD / W_KEKO-LOSGR.
D_EXT_PURCH = D_EXT_PURCH / W_KEKO-LOSGR.
D_MISC_COST = D_MISC_COST / W_KEKO-LOSGR.
ENDFORM. " GET_COST_VALUES
* Performance Tuning using parallel cursor
*
* Extracts from program ZFAL2002
************************************************************************
************************************************************************
* START-OF-SELECTION
SELECT *
INTO TABLE I_KEPH FROM KEPH
WHERE KADKY <= SY-DATUM
AND TVERS = '01'
AND KALKA IN ('01','Z1','Z2')
AND BWVAR IN ('Z01','Z02','Z03','Z04','Z07')
AND KKZST = ' '
AND KKZMA = ' '
AND KKZMM = ' '
AND KEART = 'H'
AND PATNR = 0.
* Table must be sorted to ensure all required records are together
SORT I_KEPH BY KALNR KALKA BWVAR KADKY.
* Perform actual processing
Perform get_cost_values.
*----------------------------------------------------------------------*
FORM GET_COST_VALUES.
* Determine start position and then process all records for given key
* from that starting point
* i_keph is sorted on kalnr kalka bwvar kadky.
READ TABLE I_KEPH WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
KADKY = W_KEKO-KADKY BINARY SEARCH.
IF SY-SUBRC = 0.
* Loop at itab from first record found (sy-tabix) until record
* no-longer matches your criteria.
LOOP AT I_KEPH FROM SY-TABIX.
IF I_KEPH-KALNR = W_KEKO-KALNR AND I_KEPH-KALKA = W_KEKO-KALKA
AND I_KEPH-BWVAR = W_KEKO-BWVAR AND I_KEPH-KADKY = W_KEKO-KADKY.
* Key match
D_MAT_COST = D_MAT_COST + I_KEPH-KST001.
D_LAB_COST = D_LAB_COST + I_KEPH-KST004.
D_OVER_HEAD = D_OVER_HEAD + I_KEPH-KST010.
D_EXT_PURCH = D_EXT_PURCH + I_KEPH-KST014.
D_MISC_COST = D_MISC_COST + I_KEPH-KST002 + I_KEPH-KST003
+ I_KEPH-KST005 + I_KEPH-KST006 + I_KEPH-KST007
+ I_KEPH-KST008 + I_KEPH-KST009 + I_KEPH-KST011
+ I_KEPH-KST012 + I_KEPH-KST013 + I_KEPH-KST015
+ I_KEPH-KST016 + I_KEPH-KST017 + I_KEPH-KST018
+ I_KEPH-KST019 + I_KEPH-KST020 + I_KEPH-KST021
+ I_KEPH-KST022 + I_KEPH-KST023 + I_KEPH-KST024
+ I_KEPH-KST025 + I_KEPH-KST026 + I_KEPH-KST027
+ I_KEPH-KST028 + I_KEPH-KST029 + I_KEPH-KST030
+ I_KEPH-KST031 + I_KEPH-KST032 + I_KEPH-KST033
+ I_KEPH-KST034 + I_KEPH-KST035 + I_KEPH-KST036
+ I_KEPH-KST037 + I_KEPH-KST038 + I_KEPH-KST039
+ I_KEPH-KST040.
ELSE.
* Key greater - can't be less
EXIT. " Exit loop
ENDIF.
ENDLOOP.
ENDIF.
D_MAT_COST = D_MAT_COST / W_KEKO-LOSGR.
D_LAB_COST = D_LAB_COST / W_KEKO-LOSGR.
D_OVER_HEAD = D_OVER_HEAD / W_KEKO-LOSGR.
D_EXT_PURCH = D_EXT_PURCH / W_KEKO-LOSGR.
D_MISC_COST = D_MISC_COST / W_KEKO-LOSGR.
ENDFORM. " GET_COST_VALUES
SQL Trace
SQL Trace
SQL trace(ST05) provides the developer with the ability to analyse database select statements. Simply execute ST05
to turn on SQL trace, then execute the statement/program you want to analyse. Now turn off SQL trace using ST05
and click on list trace to view the details.
You can also perform traces on other items such as authorisation objects. Dont trade blindly in Stock market with global market future live track http://liveworldmarket.blogspot.in/
SQL trace(ST05) provides the developer with the ability to analyse database select statements. Simply execute ST05
to turn on SQL trace, then execute the statement/program you want to analyse. Now turn off SQL trace using ST05
and click on list trace to view the details.
You can also perform traces on other items such as authorisation objects. Dont trade blindly in Stock market with global market future live track http://liveworldmarket.blogspot.in/
Runtime Analysis
*To turn runtim analysis on within ABAP code insert the following code
SET RUN TIME ANALYZER ON.
*To turn runtim analysis off within ABAP code insert the following code
SET RUN TIME ANALYZER OFF.
SET RUN TIME ANALYZER ON.
*To turn runtim analysis off within ABAP code insert the following code
SET RUN TIME ANALYZER OFF.
IDOC
IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.
BASIC
ABAP (Advanced Business Application Programming) is a programming language for developing applications for the SAP R/3 system, a widely-installed business application subsystem. The latest version, ABAP Objects, is object-oriented programming. SAP will run applications written using ABAP/4, the earlier ABAP version, as well as applications using ABAP Objects.
SAP's original business model for R/3 was developed before the idea of an object-oriented model was widespread. The transition to the object-oriented model reflects an increased customer demand for it. ABAP Objects uses a single inheritance model and full support for object features such as encapsulation, polymorphism, and persistence.
SAP's original business model for R/3 was developed before the idea of an object-oriented model was widespread. The transition to the object-oriented model reflects an increased customer demand for it. ABAP Objects uses a single inheritance model and full support for object features such as encapsulation, polymorphism, and persistence.
Subscribe to:
Posts (Atom)