Kontakt

Ansicht
Dokumentation

LOY_PROC_SET - Processing Settings

LOY_PROC_SET - Processing Settings

Addresses (Business Address Services)   General Material Data  
This documentation is copyright by SAP AG.
SAP E-Book

Processing parameters are used to set up the following in loyalty management:

Loyalty engine:

  • You make the settings in Customizing for Customer Relationship Management under Loyalty Management - Execution -> Processing Settings -> Define Loyalty Engine Parameters.
  • These parameters are loyalty engine specific.

Batch processing:

  • You make the settings in Customizing for Customer Relationship Management under Loyalty Management - Execution -> Processing Settings -> Define Batch Processing Parameters.
  • The batch processing parameter settings are used by all parallel processing in loyalty execution, except for the loyalty engine.

Parameter Description
BATCH_CURSOR_SIZE Parameter determines number of records read from the data base in a single read.
BATCH_RECORDS_PER_WP Number of records to be processed in a single dialog work process.
BATCH_MAX_NO_WP Maximum number of work processes to be used in parallel processing
SERVER_GROUP_BATCH Defines the group of instances (application servers) on which the parallel processes can run.

The parameters are not automatically the same in batch processing and loyalty engine Customizing for the following reasons:

  1. The loyalty engine is a CPU-intensive process. That means it demands a high CPU time (90% CPU and 10% DB) during processing.
  2. Other parallel processes should (ideally) not be run on the same instance during processing. You have to make this decision based on the following:
  • Number of records that the loyalty engine has to process

  • Whether most of the activity processing happens in the background (batch processing) or online

SERVER_GROUP_BATCH
  • SERVER_GROUP_BATCH
  • Define a server group using transaction RFC Server Group Maintenance and assign the group name. You can assign a set of instances to a group (name) and you can also decide what percentage of work processes should be used from each instance.

  • If the loyalty engine only runs during the end of the day and no other parallel processes run during that period, the same server group can be used in both Customizing activities Define Batch Processing Parameters and Define Loyalty Engine Parameters. Otherwise, we recommend to have different server groups for performance reasons.

  • BATCH_RECORDS_PER_WP
  • This parameter is data base dependent and has to be evaluated separately for each data base and each scenario. The central dispatcher (see BATCH_CURSOR_SIZE) sends a specified number of records to each work process, and each work process has to re-query the data base to process the records passed to it using a query like SELECT * FROM X WHERE GUID IN (list). This size of the list is data base dependent. Above 500 records, the performance degrades as more data has to be passed between a central and processing work processes.

  • We recommend the value on MaxDB between 200 -500; 100-200.

  • BATCH_CURSOR_SIZE
  • Typically, for each of the parallel processes, a central dispatcher work process runs in background mode. The dispatcher reads-in a specified number of records into an internal table, sequences the records according to the scenario, and dispatches the records for processing into different parallel work processes. One way to calculate the size is using a formula (Number of Dialog WP's available) x (Value of BATCH_RECORDS_PER_WP).

  • You have to provide a higher value if the calculated value is too small.

  • You read-in a set of records into an internal table to:

  1. Limit the amount of memory you use
  2. Keep data base hits to a minimum
  • BATCH_MAX_NO_WP
  • This parameter is used during parallel processing to determine the maximum number of dialog work processes to be used from the pool of available work processes. We do not recommend a standard setting because it depends on various parameters, such as the type and model of central processing unit (CPU), the number of available CPUs in a system, the load on the system, and so on.

  • On a system with no load, start with a value equal to number of CPUs in the system and record the processing time. Increasing the value in steps of one, notice the change in processing time. Also, obtain STAD traces and compare the results. An ideal value is obtained when the processing time is minimum and STAD traces show "Processing Time" approximately equal to "CPU Time" plus 30%.

  • Note: A suboptimal value will result in reduced throughput.






TXBHW - Original Tax Base Amount in Local Currency   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

Length: 6836 Date: 20240523 Time: 195110     sap01-206 ( 110 ms )