Wednesday, 16 July 2014
Export and import in shared memory
EXPORT WA_VAR1 TO SHARED MEMORY INDX(mu) ID 'MEMORYNAME'
Same for import
IMPORT WA_VAR1 FROM SHARED MEMORY INDX(mu) ID 'MEMORYNAME'
Wednesday, 11 June 2014
HANA Views
Attribute View: Select one master table and one text table and join and display
Analytical: create a view by joining two table with numeric fields and with some calculation added.
Calculated view:
Analytical: create a view by joining two table with numeric fields and with some calculation added.
Calculated view:
HANA analytic Privilege
To provide the access for a view or table to a specific user - Right clock on the package and select Analytical Privilege
Stored Procedures(like function module): we can define the procedure(with native sql) and we can call in out program by required input and output parameters
to call any procedure we haveto start with _SYS_BIC( all the abap objects will be saved here) .
We can create the Interface for the stored procedure and we can use that as a in ABAP program and we can directly call the procedure in the program without any Native sql, but here the database should be HANA database.
Go to ABAP stack and go to package
right click on package
Select other ABAP repository object
search with PROXY
click on database procedure proxy
click a name for your proxy and select the proxy required and complete it
It will generate an interface for this which we can use in program
DATA: lt_cust_early TYPE TABLE OF if_ha400_early_and_late=>et_early,
lt_cust_late TYPE TABLE OF if_ha400_early_and_late=>et_late.
CALL DATABASE PROCEDURE ha400_early_and_late
EXPORTING
iv_number = pv_number
IMPORTING
et_early = lt_cust_early
et_late = lt_cust_late.
ct_cust_early = lt_cust_early.
ct_cust_late = lt_cust_late.
Stored Procedures(like function module): we can define the procedure(with native sql) and we can call in out program by required input and output parameters
to call any procedure we haveto start with _SYS_BIC( all the abap objects will be saved here) .
We can create the Interface for the stored procedure and we can use that as a in ABAP program and we can directly call the procedure in the program without any Native sql, but here the database should be HANA database.
Go to ABAP stack and go to package
right click on package
Select other ABAP repository object
search with PROXY
click on database procedure proxy
click a name for your proxy and select the proxy required and complete it
It will generate an interface for this which we can use in program
DATA: lt_cust_early TYPE TABLE OF if_ha400_early_and_late=>et_early,
lt_cust_late TYPE TABLE OF if_ha400_early_and_late=>et_late.
CALL DATABASE PROCEDURE ha400_early_and_late
EXPORTING
iv_number = pv_number
IMPORTING
et_early = lt_cust_early
et_late = lt_cust_late.
ct_cust_early = lt_cust_early.
ct_cust_late = lt_cust_late.
Tuesday, 10 June 2014
HANA Certification
the below link shows about HANA certification
https://training.sap.com/de/en/courses-and-curricula/hana
https://training.sap.com/de/en/courses-and-curricula/hana
To access HANA data from the excel report
1) we have to instal HANA CLIENT in system
2) Then go to excel -> data - > from other sources -> From data connection wizard -> other/ advanced and then press next -> SAP HANA MDX provider and press next
3) Enter the HOST details and connect to HANA STUDIO
2) Then go to excel -> data - > from other sources -> From data connection wizard -> other/ advanced and then press next -> SAP HANA MDX provider and press next
3) Enter the HOST details and connect to HANA STUDIO
Transport management in HANA
1) we haveto create the delivery unit
2) assign package to delivery unit
3) select the raquired transport or create new or select the new object
But, wheneverr we do some changes we have to transport(create new delivery unit) again. it will create another version.
2) assign package to delivery unit
3) select the raquired transport or create new or select the new object
But, wheneverr we do some changes we have to transport(create new delivery unit) again. it will create another version.
Performance in SAP HANA ABAP
1) By using database specifc native SQL statements
2) Inner joins instead of nested loops
3) It will do all the calculations at the database level, and ther wont be much load on application layer.
2) Inner joins instead of nested loops
3) It will do all the calculations at the database level, and ther wont be much load on application layer.
Monday, 9 June 2014
OPEN SQL and NATIVE SQL IN HANA ABAP
OPEN SQL:
SELECT bp~bp_id AS bp_id
bp~company_name AS bp_name
inv~created_at AS created_at
FROM snwd_so_inv_head AS inv JOIN snwd_bpa AS bp ON inv~buyer_guid = bp~node_key
CONNECTION (pv_dbcon)
INTO TABLE lt_customer_invoice
WHERE inv~payment_status <> 'P'
ORDER BY bp~bp_id.
NATIVE SQL:
* Use a native SQL call with ADBC here to retrieve the joined
* Step 1: Construct the native SQL string into local variable lv_sql.
* Make sure to order by business partner ID
* Step 2: Instantiate the SQL connection and the SQL statement objects
* Step 3: Execute the native SQL query
* Step 4: Read the result into the internal table lt_partner
* Step 5: close resources, i.e. the SQL statement and connection
* ADBC Objects and variables
DATA: lo_sql_stmt TYPE REF TO cl_sql_statement,
lo_conn TYPE REF TO cl_sql_connection,
lo_result TYPE REF TO cl_sql_result_set,
lv_sql TYPE string,
lr_data TYPE REF TO data.
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* analyze, then improve code here
* Declarations
****************
TYPES: BEGIN OF lts_partner,
bp_id TYPE snwd_bpa-bp_id,
company_name TYPE snwd_bpa-company_name,
created_at TYPE snwd_so_inv_head-created_at,
END OF lts_partner.
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE lts_partner,
lt_partner TYPE STANDARD TABLE OF lts_partner.
* ADBC Objects and variables
DATA: lo_sql_stmt TYPE REF TO cl_sql_statement,
lo_conn TYPE REF TO cl_sql_connection,
lo_result TYPE REF TO cl_sql_result_set,
lv_sql TYPE string,
lr_data TYPE REF TO data.
* Eception handling
DATA: lx_sql_exc TYPE REF TO cx_sql_exception,
lv_text TYPE string.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
TRY.
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
* Step 1: Construct the native SQL string into local variable lv_sql.
* Make sure to order by business partner ID
CONCATENATE 'SELECT BP.BP_ID, BP.COMPANY_NAME, INV.CREATED_AT'
' FROM SNWD_BPA AS BP INNER JOIN SNWD_SO_INV_HEAD AS INV'
' ON BP.NODE_KEY = INV.BUYER_GUID'
' WHERE INV.CLIENT = '''
sy-mandt
''' AND PAYMENT_STATUS <> ''P'''
' ORDER BY BP.BP_ID'
INTO lv_sql.
** Alternative using String templates and expressions:
* lv_sql = | SELECT BP.BP_ID, BP.COMPANY_NAME, INV.CREATED_AT |
* && | FROM SNWD_BPA AS BP INNER JOIN SNWD_SO_INV_HEAD AS INV |
* && | ON BP.NODE_KEY = INV.BUYER_GUID |
* && | WHERE iNV.CLIENT = '{ SY-MANDT }' AND PAYMENT_STATUS <> 'P' |
* && | ORDER BY BP.BP_ID |.
* Step 2: Instantiate the SQL connection and the SQL statement objects
* Get a secondary DB connection
lo_conn = cl_sql_connection=>get_connection( pv_dbcon ).
* Create an SQL statement to be executed via the connection
lo_sql_stmt = lo_conn->create_statement( ).
** ALTERNATIVE: Do both in one step.
* CREATE OBJECT lo_sql_stmt EXPORTING con_ref = cl_sql_connection=>get_connection( pv_dbcon ).
** ALTERNATIVE: Don't even pass a secondary connection if the "default" connection is used anyway
* CREATE OBJECT lo_sql_stmt.
* use method set_table_name_for_trace( ... ) to tell SQL Trace which table is accessed
lo_sql_stmt->set_table_name_for_trace( 'SNWD_SO join SNWD_BPA' ).
* Step 3: Execute the native SQL query
lo_result = lo_sql_stmt->execute_query( lv_sql ).
* Step 4: Read the result into the internal table lt_partner
GET REFERENCE OF lt_partner INTO lr_data.
lo_result->set_param_table( lr_data ).
lo_result->next_package( ).
* Step 5: close resources, i.e. the SQL statement and connection
lo_result->close( ).
lo_conn->close( ).
* Loop over result as in Open SQL version, to calculate the average sales order ages
LOOP AT lt_partner INTO ls_partner.
IF sy-tabix = 1. " First customer, first order
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
CLEAR: ls_customer-avg_days_open.
ELSEIF ls_customer-id <> ls_partner-bp_id. "First order of next customer
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
CLEAR: ls_customer-avg_days_open,
lv_count.
ENDIF.
lv_count = lv_count + 1.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_partner-created_at ) / 86400.
ENDLOOP.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers. " Don't forget last customer
CATCH cx_sql_exception INTO lx_sql_exc.
lv_text = lx_sql_exc->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM. "
and display the data:
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
1) referance for SQL ststements
2) Referance for the connection
3) Referance for the instantiation
4) read the data withh standard methos
5) close the connection
SELECT bp~bp_id AS bp_id
bp~company_name AS bp_name
inv~created_at AS created_at
FROM snwd_so_inv_head AS inv JOIN snwd_bpa AS bp ON inv~buyer_guid = bp~node_key
CONNECTION (pv_dbcon)
INTO TABLE lt_customer_invoice
WHERE inv~payment_status <> 'P'
ORDER BY bp~bp_id.
NATIVE SQL:
* Use a native SQL call with ADBC here to retrieve the joined
* Step 1: Construct the native SQL string into local variable lv_sql.
* Make sure to order by business partner ID
* Step 2: Instantiate the SQL connection and the SQL statement objects
* Step 3: Execute the native SQL query
* Step 4: Read the result into the internal table lt_partner
* Step 5: close resources, i.e. the SQL statement and connection
* ADBC Objects and variables
DATA: lo_sql_stmt TYPE REF TO cl_sql_statement,
lo_conn TYPE REF TO cl_sql_connection,
lo_result TYPE REF TO cl_sql_result_set,
lv_sql TYPE string,
lr_data TYPE REF TO data.
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* analyze, then improve code here
* Declarations
****************
TYPES: BEGIN OF lts_partner,
bp_id TYPE snwd_bpa-bp_id,
company_name TYPE snwd_bpa-company_name,
created_at TYPE snwd_so_inv_head-created_at,
END OF lts_partner.
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE lts_partner,
lt_partner TYPE STANDARD TABLE OF lts_partner.
* ADBC Objects and variables
DATA: lo_sql_stmt TYPE REF TO cl_sql_statement,
lo_conn TYPE REF TO cl_sql_connection,
lo_result TYPE REF TO cl_sql_result_set,
lv_sql TYPE string,
lr_data TYPE REF TO data.
* Eception handling
DATA: lx_sql_exc TYPE REF TO cx_sql_exception,
lv_text TYPE string.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
TRY.
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
* Step 1: Construct the native SQL string into local variable lv_sql.
* Make sure to order by business partner ID
CONCATENATE 'SELECT BP.BP_ID, BP.COMPANY_NAME, INV.CREATED_AT'
' FROM SNWD_BPA AS BP INNER JOIN SNWD_SO_INV_HEAD AS INV'
' ON BP.NODE_KEY = INV.BUYER_GUID'
' WHERE INV.CLIENT = '''
sy-mandt
''' AND PAYMENT_STATUS <> ''P'''
' ORDER BY BP.BP_ID'
INTO lv_sql.
** Alternative using String templates and expressions:
* lv_sql = | SELECT BP.BP_ID, BP.COMPANY_NAME, INV.CREATED_AT |
* && | FROM SNWD_BPA AS BP INNER JOIN SNWD_SO_INV_HEAD AS INV |
* && | ON BP.NODE_KEY = INV.BUYER_GUID |
* && | WHERE iNV.CLIENT = '{ SY-MANDT }' AND PAYMENT_STATUS <> 'P' |
* && | ORDER BY BP.BP_ID |.
* Step 2: Instantiate the SQL connection and the SQL statement objects
* Get a secondary DB connection
lo_conn = cl_sql_connection=>get_connection( pv_dbcon ).
* Create an SQL statement to be executed via the connection
lo_sql_stmt = lo_conn->create_statement( ).
** ALTERNATIVE: Do both in one step.
* CREATE OBJECT lo_sql_stmt EXPORTING con_ref = cl_sql_connection=>get_connection( pv_dbcon ).
** ALTERNATIVE: Don't even pass a secondary connection if the "default" connection is used anyway
* CREATE OBJECT lo_sql_stmt.
* use method set_table_name_for_trace( ... ) to tell SQL Trace which table is accessed
lo_sql_stmt->set_table_name_for_trace( 'SNWD_SO join SNWD_BPA' ).
* Step 3: Execute the native SQL query
lo_result = lo_sql_stmt->execute_query( lv_sql ).
* Step 4: Read the result into the internal table lt_partner
GET REFERENCE OF lt_partner INTO lr_data.
lo_result->set_param_table( lr_data ).
lo_result->next_package( ).
* Step 5: close resources, i.e. the SQL statement and connection
lo_result->close( ).
lo_conn->close( ).
* Loop over result as in Open SQL version, to calculate the average sales order ages
LOOP AT lt_partner INTO ls_partner.
IF sy-tabix = 1. " First customer, first order
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
CLEAR: ls_customer-avg_days_open.
ELSEIF ls_customer-id <> ls_partner-bp_id. "First order of next customer
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
CLEAR: ls_customer-avg_days_open,
lv_count.
ENDIF.
lv_count = lv_count + 1.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_partner-created_at ) / 86400.
ENDLOOP.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers. " Don't forget last customer
CATCH cx_sql_exception INTO lx_sql_exc.
lv_text = lx_sql_exc->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM. "
and display the data:
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
1) referance for SQL ststements
2) Referance for the connection
3) Referance for the instantiation
4) read the data withh standard methos
5) close the connection
SQL trace in HANA ABAP
1) SET we can execute
2) ST05 :
select activate trace with filter
give the parameters with you id
then execute the transaction
come to ST05 and deactivate thetrace
click on display trace
go to trace and select structure identical statements
3) SCI
4) ATC: ABAP TEST COCKPIT : to get this right click on the program and select ATC.
5) SQLM: SQL
2) ST05 :
select activate trace with filter
give the parameters with you id
then execute the transaction
come to ST05 and deactivate thetrace
click on display trace
go to trace and select structure identical statements
3) SCI
4) ATC: ABAP TEST COCKPIT : to get this right click on the program and select ATC.
5) SQLM: SQL
Program: ZHA400_OPT_OSQL_T1
*&---------------------------------------------------------------------*
*& Report HA400_OPTIMIZE_OSQL_S1
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT zha400_opt_osql_t1 MESSAGE-ID ha400.
* Structure for Result: list of customers with age of their sales orders
TYPES: BEGIN OF ts_customer,
id TYPE snwd_bpa-bp_id,
name TYPE snwd_bpa-company_name,
avg_days_open TYPE i,
END OF ts_customer.
TYPES: tt_customer TYPE STANDARD TABLE OF ts_customer
WITH NON-UNIQUE KEY id, company_name.
* Data objects
DATA: gt_customers TYPE tt_customer,
gt_customers_t TYPE tt_customer.
* Database connection
DATA gv_dbcon TYPE dbcon-con_name.
CONSTANTS:
c_primdb TYPE dbcon-con_name VALUE 'DEFAULT',
c_secdb TYPE dbcon-con_name VALUE 'HANADB'.
* selection screen
SELECTION-SCREEN BEGIN OF BLOCK exe WITH FRAME TITLE text-exe.
PARAMETERS:
pa_temp TYPE xfeld RADIOBUTTON GROUP exe DEFAULT 'X',
pa_solu TYPE xfeld RADIOBUTTON GROUP exe,
pa_both TYPE xfeld RADIOBUTTON GROUP exe.
SELECTION-SCREEN END OF BLOCK exe.
SELECTION-SCREEN BEGIN OF BLOCK dbc WITH FRAME TITLE text-dbc.
PARAMETERS:
pa_prim TYPE xfeld RADIOBUTTON GROUP dbc,
pa_sec TYPE xfeld RADIOBUTTON GROUP dbc DEFAULT 'X'.
SELECTION-SCREEN END OF BLOCK dbc.
START-OF-SELECTION.
CASE 'X'.
WHEN pa_prim.
gv_dbcon = c_primdb.
WHEN pa_sec.
gv_dbcon = c_secdb.
ENDCASE.
CASE 'X'.
WHEN pa_temp. " template only
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
PERFORM display USING gt_customers_t.
WHEN pa_solu. " solution only
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM display USING gt_customers.
WHEN pa_both. " both subroutines
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
IF gt_customers <> gt_customers_t.
MESSAGE i010.
ELSE.
MESSAGE s011.
ENDIF.
ENDCASE.
*&---------------------------------------------------------------------*
*& Form get_data_template
*&---------------------------------------------------------------------*
FORM get_data_template USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa
CONNECTION (pv_dbcon)
INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head
CONNECTION (pv_dbcon)
INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form output
*&---------------------------------------------------------------------*
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
*& Report HA400_OPTIMIZE_OSQL_S1
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT zha400_opt_osql_t1 MESSAGE-ID ha400.
* Structure for Result: list of customers with age of their sales orders
TYPES: BEGIN OF ts_customer,
id TYPE snwd_bpa-bp_id,
name TYPE snwd_bpa-company_name,
avg_days_open TYPE i,
END OF ts_customer.
TYPES: tt_customer TYPE STANDARD TABLE OF ts_customer
WITH NON-UNIQUE KEY id, company_name.
* Data objects
DATA: gt_customers TYPE tt_customer,
gt_customers_t TYPE tt_customer.
* Database connection
DATA gv_dbcon TYPE dbcon-con_name.
CONSTANTS:
c_primdb TYPE dbcon-con_name VALUE 'DEFAULT',
c_secdb TYPE dbcon-con_name VALUE 'HANADB'.
* selection screen
SELECTION-SCREEN BEGIN OF BLOCK exe WITH FRAME TITLE text-exe.
PARAMETERS:
pa_temp TYPE xfeld RADIOBUTTON GROUP exe DEFAULT 'X',
pa_solu TYPE xfeld RADIOBUTTON GROUP exe,
pa_both TYPE xfeld RADIOBUTTON GROUP exe.
SELECTION-SCREEN END OF BLOCK exe.
SELECTION-SCREEN BEGIN OF BLOCK dbc WITH FRAME TITLE text-dbc.
PARAMETERS:
pa_prim TYPE xfeld RADIOBUTTON GROUP dbc,
pa_sec TYPE xfeld RADIOBUTTON GROUP dbc DEFAULT 'X'.
SELECTION-SCREEN END OF BLOCK dbc.
START-OF-SELECTION.
CASE 'X'.
WHEN pa_prim.
gv_dbcon = c_primdb.
WHEN pa_sec.
gv_dbcon = c_secdb.
ENDCASE.
CASE 'X'.
WHEN pa_temp. " template only
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
PERFORM display USING gt_customers_t.
WHEN pa_solu. " solution only
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM display USING gt_customers.
WHEN pa_both. " both subroutines
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
IF gt_customers <> gt_customers_t.
MESSAGE i010.
ELSE.
MESSAGE s011.
ENDIF.
ENDCASE.
*&---------------------------------------------------------------------*
*& Form get_data_template
*&---------------------------------------------------------------------*
FORM get_data_template USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa
CONNECTION (pv_dbcon)
INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head
CONNECTION (pv_dbcon)
INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form output
*&---------------------------------------------------------------------*
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
SAP HANA - DATABASE CONFIG
We haveto config in DBCO transaction with the server and instance number and it will take as secondary database for system.
To config connection name to database in HANA system will be done in the transaction DBACOCKPIT.
here we will maintain the database(HDB) to connection name(HANADB).
we will use the connectname in abap programs to read the data from hana database.
To config connection name to database in HANA system will be done in the transaction DBACOCKPIT.
here we will maintain the database(HDB) to connection name(HANADB).
we will use the connectname in abap programs to read the data from hana database.
SAP HANA PROGRAM - HA400_SEC_DB_CON_S1
*&---------------------------------------------------------------------*
*& Report HA400_OPTIMIZE_OSQL_S1
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT ha400_sec_db_con_s1 MESSAGE-ID ha400.
* Structure for Result: list of customers with age of their sales orders
TYPES: BEGIN OF ts_customer,
id TYPE snwd_bpa-bp_id,
name TYPE snwd_bpa-company_name,
avg_days_open TYPE i,
END OF ts_customer.
TYPES: tt_customer TYPE STANDARD TABLE OF ts_customer
WITH NON-UNIQUE KEY id.
* Data objects
DATA: gt_customers TYPE tt_customer,
gt_customers_t TYPE tt_customer.
DATA: lv_start TYPE timestampl,
lv_end TYPE timestampl,
lv_message TYPE string.
* Database connection
DATA gv_dbcon TYPE dbcon-con_name.
CONSTANTS:
c_primdb TYPE dbcon-con_name VALUE 'DEFAULT',
c_secdb TYPE dbcon-con_name VALUE 'HANADB'.
* selection screen
SELECTION-SCREEN BEGIN OF BLOCK exe WITH FRAME TITLE text-exe.
PARAMETERS:
pa_temp TYPE xfeld RADIOBUTTON GROUP exe DEFAULT 'X',
pa_solu TYPE xfeld RADIOBUTTON GROUP exe,
pa_both TYPE xfeld RADIOBUTTON GROUP exe.
SELECTION-SCREEN END OF BLOCK exe.
SELECTION-SCREEN BEGIN OF BLOCK dbc WITH FRAME TITLE text-dbc.
PARAMETERS:
pa_prim TYPE xfeld RADIOBUTTON GROUP dbc,
pa_sec TYPE xfeld RADIOBUTTON GROUP dbc DEFAULT 'X'.
SELECTION-SCREEN END OF BLOCK dbc.
START-OF-SELECTION.
CASE 'X'.
WHEN pa_prim.
gv_dbcon = c_primdb.
WHEN pa_sec.
gv_dbcon = c_secdb.
ENDCASE.
CASE 'X'.
WHEN pa_temp. " template only
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
PERFORM display USING gt_customers_t.
WHEN pa_solu. " solution only
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM display USING gt_customers.
WHEN pa_both. " both subroutines
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
IF gt_customers <> gt_customers_t.
MESSAGE i010.
ELSE.
MESSAGE s011.
ENDIF.
ENDCASE.
*&---------------------------------------------------------------------*
*& Form get_data_template
*&---------------------------------------------------------------------*
FORM get_data_template USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa
CONNECTION (pv_dbcon)
INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head
CONNECTION (pv_dbcon)
INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form output
*&---------------------------------------------------------------------*
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
*& Report HA400_OPTIMIZE_OSQL_S1
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT ha400_sec_db_con_s1 MESSAGE-ID ha400.
* Structure for Result: list of customers with age of their sales orders
TYPES: BEGIN OF ts_customer,
id TYPE snwd_bpa-bp_id,
name TYPE snwd_bpa-company_name,
avg_days_open TYPE i,
END OF ts_customer.
TYPES: tt_customer TYPE STANDARD TABLE OF ts_customer
WITH NON-UNIQUE KEY id.
* Data objects
DATA: gt_customers TYPE tt_customer,
gt_customers_t TYPE tt_customer.
DATA: lv_start TYPE timestampl,
lv_end TYPE timestampl,
lv_message TYPE string.
* Database connection
DATA gv_dbcon TYPE dbcon-con_name.
CONSTANTS:
c_primdb TYPE dbcon-con_name VALUE 'DEFAULT',
c_secdb TYPE dbcon-con_name VALUE 'HANADB'.
* selection screen
SELECTION-SCREEN BEGIN OF BLOCK exe WITH FRAME TITLE text-exe.
PARAMETERS:
pa_temp TYPE xfeld RADIOBUTTON GROUP exe DEFAULT 'X',
pa_solu TYPE xfeld RADIOBUTTON GROUP exe,
pa_both TYPE xfeld RADIOBUTTON GROUP exe.
SELECTION-SCREEN END OF BLOCK exe.
SELECTION-SCREEN BEGIN OF BLOCK dbc WITH FRAME TITLE text-dbc.
PARAMETERS:
pa_prim TYPE xfeld RADIOBUTTON GROUP dbc,
pa_sec TYPE xfeld RADIOBUTTON GROUP dbc DEFAULT 'X'.
SELECTION-SCREEN END OF BLOCK dbc.
START-OF-SELECTION.
CASE 'X'.
WHEN pa_prim.
gv_dbcon = c_primdb.
WHEN pa_sec.
gv_dbcon = c_secdb.
ENDCASE.
CASE 'X'.
WHEN pa_temp. " template only
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
PERFORM display USING gt_customers_t.
WHEN pa_solu. " solution only
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM display USING gt_customers.
WHEN pa_both. " both subroutines
PERFORM get_data_solution USING gv_dbcon
CHANGING gt_customers.
PERFORM get_data_template USING gv_dbcon
CHANGING gt_customers_t.
IF gt_customers <> gt_customers_t.
MESSAGE i010.
ELSE.
MESSAGE s011.
ENDIF.
ENDCASE.
*&---------------------------------------------------------------------*
*& Form get_data_template
*&---------------------------------------------------------------------*
FORM get_data_template USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form get_data_solution
*&---------------------------------------------------------------------*
FORM get_data_solution USING pv_dbcon TYPE dbcon-con_name
CHANGING ct_customers TYPE tt_customer.
* Declarations
****************
* Work Area for Result
DATA ls_customer LIKE LINE OF ct_customers.
* Targets for Select
DATA: ls_partner TYPE snwd_bpa,
ls_invoice TYPE snwd_so_inv_head.
* help variables
DATA: lv_current_date TYPE timestampl,
lv_count TYPE i.
* processing
****************
CLEAR ct_customers.
CLEAR lv_count.
" get current date (UTC)
GET TIME STAMP FIELD lv_current_date.
SELECT * FROM snwd_bpa
CONNECTION (pv_dbcon)
INTO ls_partner.
ls_customer-id = ls_partner-bp_id.
ls_customer-name = ls_partner-company_name.
*
CLEAR: ls_customer-avg_days_open,
lv_count.
SELECT * FROM snwd_so_inv_head
CONNECTION (pv_dbcon)
INTO ls_invoice
WHERE buyer_guid = ls_partner-node_key
AND payment_status <> 'P'.
ls_customer-avg_days_open = ls_customer-avg_days_open
+ cl_abap_tstmp=>subtract( tstmp1 = lv_current_date
tstmp2 = ls_invoice-created_at ) / 86400.
lv_count = lv_count + 1.
ENDSELECT.
IF ls_customer-avg_days_open <> 0.
ls_customer-avg_days_open = ls_customer-avg_days_open / lv_count.
INSERT ls_customer INTO TABLE ct_customers.
ENDIF.
ENDSELECT.
SORT ct_customers BY id.
ENDFORM. "
*&---------------------------------------------------------------------*
*& Form output
*&---------------------------------------------------------------------*
FORM display USING it_customers TYPE tt_customer.
DATA: lo_alv TYPE REF TO cl_salv_table,
lx_msg TYPE REF TO cx_salv_msg,
lv_text TYPE string.
* display
TRY.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = it_customers ).
lo_alv->display( ).
CATCH cx_salv_msg INTO lx_msg.
lv_text = lx_msg->get_text( ).
MESSAGE lv_text TYPE 'E'.
ENDTRY.
ENDFORM.
Saturday, 10 August 2013
sample code To capture the Lead selection values in webdynpro abap
DATA lo_nd_it_mara TYPE REF TO
DATA lt_it_mara TYPE wd_
DATA ls_it_mara TYPE wd_
DATA it_mara_new TYPE wd_
DATA ls_mara_new TYPE wd_
* navigate from <CONTEXT>
lo_nd_it_mara = wd_context->
lo_nd_it_mara->get_static_
DATA: ld_element TYPE RE
it_rows TYPE wdr_
wa_rows LIKE LINE OF
DATA: ld_index TYPE i.
*** to get the lead selected values
ld_element = lo_nd_it_
it_rows = lo_nd_it_mara->
LOOP AT it_rows INTO wa_
CALL METHOD wa_rows->get_
IMPORTING
static_attributes =
READ TABLE lt_it_mara INTO
ld_index = sy-tabix. "
APPEND ls_it_mara TO it_
ENDLOOP.
IF it_mara_new IS NOT INITIA
DATA lo_nd_it_mara_new TYP
DATA lt_it_mara_new TYPE
* navigate from <CONTEXT> to <
lo_nd_it_mara_new = wd_
SORT it_mara_new BY matnr.
lo_nd_it_mara_new->bind_
ENDIF.
DATA lt_it_mara TYPE wd_
DATA ls_it_mara TYPE wd_
DATA it_mara_new TYPE wd_
DATA ls_mara_new TYPE wd_
* navigate from <CONTEXT>
lo_nd_it_mara = wd_context->
lo_nd_it_mara->get_static_
DATA: ld_element TYPE RE
it_rows TYPE wdr_
wa_rows LIKE LINE OF
DATA: ld_index TYPE i.
*** to get the lead selected values
ld_element = lo_nd_it_
it_rows = lo_nd_it_mara->
LOOP AT it_rows INTO wa_
CALL METHOD wa_rows->get_
IMPORTING
static_attributes =
READ TABLE lt_it_mara INTO
ld_index = sy-tabix. "
APPEND ls_it_mara TO it_
ENDLOOP.
IF it_mara_new IS NOT INITIA
DATA lo_nd_it_mara_new TYP
DATA lt_it_mara_new TYPE
* navigate from <CONTEXT> to <
lo_nd_it_mara_new = wd_
SORT it_mara_new BY matnr.
lo_nd_it_mara_new->bind_
ENDIF.
Monday, 1 July 2013
Table buffering in SAP - important
Pls refer the belo link:
http://www.sap-perf.ca/sap-table-buffering/
Which Tables should be Buffered?
Only transparent tables and pooled tables can be buffered. Cluster tables cannot be buffered.
Character data types must be assigned to all key fields of buffered tables, that is the data type of the field must be mapped to one of the ABAP types C, N, D or T (see
Mapping to ABAP Data Types).The following two points speak against table buffering:
The table data is frequently modified. In this case the cost of synchronization could be greater than the gain in performance resulting from buffering. Roughly speaking, it does not make sense to buffer a table if more than one percent of the accesses to the table are modifying accesses.
The table containing currency exchange rates is updated only once a day, but it is read frequently. Buffering is recommended in this case.
The contents of buffered tables are not always up-to-date in a distributed system. You can bypass the buffer and read the data directly from the database table with the ABAP command "SELECT SINGLE ... BYPASSING BUFFER". If a buffered table is accessed frequently with this command, you should consider whether it is really necessary for the table to be buffered or whether it is essential to have the current state of the database.
You must define whether and how a table is buffered in its technical settings (see
Technical Settings).
***********************************************
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f244446011d189700000e8322d00/content.htm
Buffering Database Tables
Buffering a table improves the performance when accessing the data records contained in the table.
The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.
Buffering is particularly important in client/server environments, as it takes considerably longer to access a table with the network than it does to access a table that is buffered locally. Depending on the network load, this factor can lie between 10 and 100.
The difference in performance is somewhat less marked in central systems (systems with only one application server) than in local ones (systems with several application servers). However, even in central systems, a reduction in process changes and increased sophistication of the buffering over that provided by the database system have a noticeable effect on performance.How are the Buffers Filled?If a program accesses the data of a buffered table, the database interface determines whether this data is in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The next access to this data can then use the buffer.
The buffering type determines which records are loaded into the buffer during an access.
How are the Local Buffers Synchronized?A buffered table is generally read on all application servers and held in the buffer there. If a program changes the data contained in the table on an application server, this is noted in the log table by the database interface. The buffers still have the old status on all the other application servers, so that the programs might read obsolete data.
A synchronization mechanism runs at a fixed time interval, usually every 1-2 minutes. The log table is read and the buffer contents that were changed by other servers are invalidated. In the next access, the data of invalidated tables is read directly from the database and updated in the buffer.DisplacementIf more space is required in the buffer due to new data, the data that has not been accessed for the longest time is displaced. The data is displaced asynchronously at certain times that are defined dynamically by the buffer accesses. The data is only displaced if at this time the free space in the buffer is less than a given value or if the access quality is not good enough.Resetting the Table BuffersYou can reset the table buffers on the corresponding application servers by entering $TAB in the command field. All the data in the buffer is invalidated.
Only use this command if inconsistencies occurred in the buffer! It can take several hours to fill the buffers in large systems. Performance is considerably reduced during this time.See also:Local Buffer SynchronizationWhich Tables Should be Buffered?
How are Table Buffers Implemented Technically?
Which Accesses Proceed Directly to the Database?How can you Analyze the Buffer Quality?
http://www.sap-perf.ca/sap-table-buffering/
Which Tables should be Buffered?
Only transparent tables and pooled tables can be buffered. Cluster tables cannot be buffered.
Character data types must be assigned to all key fields of buffered tables, that is the data type of the field must be mapped to one of the ABAP types C, N, D or T (see
Mapping to ABAP Data Types).The following two points speak against table buffering:- The data read by the application must always be up-to-date. Delays caused by the synchronization mechanism (see
The table containing currency exchange rates is updated only once a day, but it is read frequently. Buffering is recommended in this case.
The contents of buffered tables are not always up-to-date in a distributed system. You can bypass the buffer and read the data directly from the database table with the ABAP command "SELECT SINGLE ... BYPASSING BUFFER". If a buffered table is accessed frequently with this command, you should consider whether it is really necessary for the table to be buffered or whether it is essential to have the current state of the database.
You must define whether and how a table is buffered in its technical settings (see
Technical Settings).
***********************************************
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f244446011d189700000e8322d00/content.htm
Buffering Database Tables Buffering a table improves the performance when accessing the data records contained in the table.
The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.
Buffering is particularly important in client/server environments, as it takes considerably longer to access a table with the network than it does to access a table that is buffered locally. Depending on the network load, this factor can lie between 10 and 100.
The difference in performance is somewhat less marked in central systems (systems with only one application server) than in local ones (systems with several application servers). However, even in central systems, a reduction in process changes and increased sophistication of the buffering over that provided by the database system have a noticeable effect on performance.How are the Buffers Filled?If a program accesses the data of a buffered table, the database interface determines whether this data is in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The next access to this data can then use the buffer.
The buffering type determines which records are loaded into the buffer during an access.
How are the Local Buffers Synchronized?A buffered table is generally read on all application servers and held in the buffer there. If a program changes the data contained in the table on an application server, this is noted in the log table by the database interface. The buffers still have the old status on all the other application servers, so that the programs might read obsolete data.
A synchronization mechanism runs at a fixed time interval, usually every 1-2 minutes. The log table is read and the buffer contents that were changed by other servers are invalidated. In the next access, the data of invalidated tables is read directly from the database and updated in the buffer.DisplacementIf more space is required in the buffer due to new data, the data that has not been accessed for the longest time is displaced. The data is displaced asynchronously at certain times that are defined dynamically by the buffer accesses. The data is only displaced if at this time the free space in the buffer is less than a given value or if the access quality is not good enough.Resetting the Table BuffersYou can reset the table buffers on the corresponding application servers by entering $TAB in the command field. All the data in the buffer is invalidated.
Only use this command if inconsistencies occurred in the buffer! It can take several hours to fill the buffers in large systems. Performance is considerably reduced during this time.See also:Local Buffer SynchronizationWhich Tables Should be Buffered?
How are Table Buffers Implemented Technically?
Which Accesses Proceed Directly to the Database?How can you Analyze the Buffer Quality?
Work Processes in SAP
http://help.sap.com/saphelp_wp/helpdata/en/fc/eb2e7d358411d1829f0000e829fbfe/content.htm
Work Processes
Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.Structure of a Work ProcessWork processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:
Each work process contains two software processors and a database interface.Screen ProcessorIn R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.ABAP-ProzessorThe actual processing logic of an application program is written in ABAP - SAP’s own programing language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
Database InterfaceThe database interface provides the following services:- Establishing and terminating connections between the work process and the database.
- Access to database tables
- Access to R/3 Repository objects (ABAP programs, screens and so on)
- Access to catalog information (ABAP Dictionary)
- Controlling transactions (commit and rollback handling)
- Table buffer administration on the application server.
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the Basis system. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.Types of Work ProcessAlthough all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.
Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.
The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:
The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail. Dialog Work ProcessDialog work processes deal with requests from an active user to execute dialog steps.Update Work ProcessUpdate work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.Background Work ProcessBackground work processes process programs that can be executed without user interaction (background jobs).Enqueue Work ProcessThe enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.Spool Work ProcessThe spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process.
The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
Subscribe to:
Posts (Atom)