EWM是SAP较新的SCM下的产品，实际磨练比不上SAP ERP系列，仓库系统的实时性要求较高，这就要求EWM的性能要绝对的好，下面将研究如何提升EWM的运行和响应时间。
Note 1423066 - Optimization of the performance in EWM
1. 设置WT异步更新
TCODE：/SCWM/DLV_ASYN
2. 定义并行处理和性能的常规设置
定义并行波次，并发生成WT，并行发货处理等
、
3. 取消RF消息接收
TCODE：/SCWM/RSCMSG_DEACT
4. 设置仓库内操作是否记录日志
可在仓库编号级别、活动区域级别、WO产生级别设置
SAP 发布的性能相关的资料：
| Summary |
| Symptom You are using Extended Warehouse Management (EWM) and you notice that system performance is inadequate for your requirements with regard to the following aspects of performance: · Dialog response times are too long § in particular for "small" transactions, such as radio frequency (RF) transactions § In particular for "large" transactions, such as the release of a large wave pick with several thousand items. · High consumption of system resources (CPU and database size) Reason and Prerequisites Possible causes of the inadequate performance are · You use CPUs with inadequate single computing unit (SCU) performance (see SAP Note 1501701). According to recommendations of the SAP Quick Sizer, you should use CPUs with SCU performance class AAA for certain process steps in EWM. At least the application server used by the relevant system users should have this performance class. · Inadequate maintenance of the database and/or the NetWeaver components · Inadequate execution of the "periodic tasks" to be carried out regularly in the "Solution Operation Guide for SAP EWM 2007 (SAP EWM 2007)" or in the "Application Operations Guide for SAP EWM 7.0" · Available EWM notes of category "P" (performance) are not implemented in your system · Inadequate use of optimization options provided by the EWM application relating to optimized dialog response times and the optimization of datasets created by transactions (for example, application log and change documents). Solution This consulting note focuses on the documentation of all optimization options available in the EWM application. In addition, you should also ensure that you · Carry out all the "periodic tasks" named in the "Operations Guide"; these tasks are not explained again in this note. You can find the "Operations Guide" under https://service.sap.com/instguides -> SAP Business Suite Applications -> SAP SCM -> SAP EWM -> Using SAP EWM 7.0 · Have implemented all notes of the category "P" that are relevant for your processes. In particular, bear in mind that not only EWM application component notes are relevant; notes for other application components may also be relevant. The following list provides an overview: § SCM-EWM* § SCM-BAS-DF § AP-LIM* (for example, Note 1039436 and in particular the activation of the database index D of the table /lime/coll_w2im is required for EWM) § SCM-BAS-ODM § SCM-BAS-PAK* § SCM-BAS-INT-MD § SCM-BAS-MD-BM, SCM-BAS-MD-CAL, SCM-BAS-MD-LO, SCM-BAS-MD-PR, SCM-BAS-MD-RT, SCM-BAS-MD-SCU, SCM-BAS-MD-ZON § SCM-BAS-MDL § SCM-BAS-RG § SCM-BAS-EHS* The following list provides an overview of the optimization options that are available in the EWM application. Detailed documentation about the various points is available in the KW documentation, the IMG documentation, or in the long text of the relevant note: · Optimization of response times in RF transactions: § Update of the start dates of the loading or unloading process in the outbound delivery order or the inbound delivery: This update potentially includes a lot of deliveries or delivery items and, as a result, the response time may be greater than 1 second. The number of deliveries involved depends on the navigation in the RF because all deliveries belonging to the initial element (such as door or transportation unit, for example) are updated respectively. If this execution date is not required in the persistent data of the deliveries, this update should be deactivated via Customizing using the IMG activity that you can find in transaction SPRO under "Extended Warehouse Management -> Cross-Process Settings -> Shipping and Receiving -> General Settings -> General Settings for Shipping and Receiving". § Update of deliveries in RF transactions that update multiple delivery items: Warehouse tasks that reference multiple delivery items can be confirmed in some RF transactions and these delivery items must be updated during this confirmation. These are normally handling unit (HU) warehouse tasks where multiple HU items reference multiple delivery items. Examples include unloading, loading, and putting away a HU. Due to the potentially large number of involved delivery items, the dialog response time may be greater than 1 second. To ensure a guaranteed short dialog response time, a threshold value for the number of delivery items can be defined starting from when the delivery is updated asynchronously. In this case, the delivery update does not contribute to the dialog response time. For EWM 5.1, the configuration of the threshold value is provided by Note 1277950 (and other subsequent notes, see the Related Notes section); as of EWM 7.0 Support Package 03, the configuration is contained in the SAP application menu under "Extended Warehouse Management -> Settings -> Activate Asynchronous Delivery Update" (or transaction code). Bear in mind the restrictions mentioned in Note 1277950 (and subsequent notes) regarding the processes in which the system actually uses the asynchronous delivery update in accordance with the settings. Generally, this asynchronous delivery update should only be used in necessary cases because the price of short response times is increased system load and this has a negative effect on the required system sizing. § Update of the delivery during RF unloading with an implicit goods receipt: A restriction to the previously mentioned asynchronous delivery update refers to the confirmation of an unloading warehouse task where the system also carries out the goods receipt posting automatically because it is the warehouse task that was confirmed first. Using another configuration also makes it possible to activate the asynchronous delivery update in this case. For EWM 5.1, the configuration is provided with Note 1151892; as of EWM 7.0, the configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, the parameter "Act. ESL" can be set per warehouse number. § Check for different routes and date/time of departure: you have the option to run this check during warehouse order creation and confirmation and, therefore, you may also run it in RF confirmations, such as loading. You can deactivate these checks in transaction SPRO under the IMG activity "Extended Warehouse Management -> Cross-Process Settings -> Shipping and Receiving -> General Settings -> General Settings for Shipping and Receiving". This can improve the dialog response time of RF confirmations. § Transfer of the route from the outbound delivery order to the transportation units activity: If a delivery item that was not assigned previously is loaded to the transportation unit, the route is transferred from the delivery to the transportation unit. This transfer may increase the RF load confirmation response time. You can deactivate this transfer in transaction SPRO under the IMG activity "Extended Warehouse Management -> Cross-Process Settings -> Shipping and Receiving -> General Settings -> General Settings for Shipping and Receiving". This can improve the dialog response time of RF confirmations. § If you use HTTP-based or HTTPS-based RF user interfaces (UIs) (via Internet Transaction Server (ITS) or WebConsole), then take into account the recommendations from Note 1422086 about the adjustments necessary for the Internet Communication Manager (ICMAN) parameter. Otherwise, response times may increase by up to 750 milliseconds when the ICMAN default parameter values are used. § If you use products that are subject to batch management requirement, the system always creates a batch subitem in the delivery document by default, even if only a single batch is involved. Creating a batch subitem leads to increased response times in the picking confirmation during the synchronous delivery update; during the asynchronous delivery update, it leads to a negative effect on the system sizing and on the performance of the following "In Process" desktop transaction (for example, goods issue posting) which must then technically process the duplicate number of delivery items. The creation of the batch item can be suppressed in many cases; for more detailed information, see Note 1367078. As of EWM 7.0 Support Package 05, the configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here you can set the parameter "No Split" (Avoid Automatic Batch Split for (Picking) Confirmation) per warehouse number. § Optimizing or deactivating the display of messages that were send from the monitor (transaction /SCWM/MON) to the resource: by implementing Note 1417111, the display is optimized in such a way that the display function no longer runs between each individual (validation) field during the warehouse task confirmation but rather only runs when you switch to another screen. This has a positive effect on the response time of the validation of some fields and also has a very positive influence on the number of database commits, which are greatly reduced. With Note 1420970, a configuration is offered as of EWM 7.0 with which the message display in the RF dialog can be deactivated as standard per warehouse number. This optimizes the response times for switching screens in RF transactions. As of EWM 7.0 Support Package 06, this configuration is contained in the SAP application menu under "Extended Warehouse Management -> Master Data -> Resource Management -> Deactivate Messages to Resources" (or transaction code /SCWM/RSCMSG_DEACT). § Update of the delivery during the RF-based confirmation of a transportation unit movement to the door in the case of very large transportation units in relation to the number of assigned delivery items (more than 1,000 items): Note 1314848 enabled the parallel delivery update. As of EWM 7.0 Support Package 03, the configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, you can set the parameter "Parallel CI / YMove" per warehouse number. In addition, in the IMG under "Extended Warehouse Management -> Cross-Process settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery", parallel processing of the delivery must be activated for the "TU Check In and Yard Movement: Delivery Update" application. · Optimization of the response times of "large" desktop transactions and optimization of background processing: § Wave pick creation: In scenarios with high throughput numbers (in relation to the number of delivery items), it is recommended that you use automatic wave assignment for outbound delivery orders instead of manual wave creation. The Post Processing Framework (PPF) action definition /SCWM/PRD_OUT_WAVE_NEW of the action profile /SCDL/PRD_OUT of the application /SCDL/DELIVERY enables this. (See transaction SPPFCADM). The waves that are created automatically can demonstrate high performance with the monitor (transaction /SCWM/MON). This is especially suitable as the entry point for further processing steps for the wave (manual postprocessing in relation to delivery assignments as well as wave release and monitoring degrees of processing). If manual wave assignments are carried out for a large number of delivery items per wave (using transaction /SCWM/WAVE or by jumping from transaction /SCWM/MON), the response time may be very long (a number of minutes) when the changed wave is saved. It is recommended that you activate the parallel delivery update in this case. This is possible in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery". Activate parallel processing for the "Delivery Assignment to Wave" application. This enables the manual assignment or cancellation of the assignment for thousands of delivery items during a system runtime of just a few minutes. § Wave pick release: high-volume wave picks should be released using transaction /SCWM/MON because this monitor transaction offers the best response times for very large waves (for example, several thousand items). Furthermore, we recommend that you activate parallel processing using the IMG activity "Extended Warehouse Management -> Goods Issue Process -> Wave Management -> General Settings -> Edit Parallel Processing for Waves". § Warehouse order creation: Parallel processing can be used for the assignment of warehouse tasks to warehouse orders and, with it, warehouse order creation. This is always useful in the case of many warehouse tasks that are assigned to different activity areas or queues (warehouse tasks for the same queue or for the same activity area are always dealt with in the same parallel process). Warehouse order creation is also part of the wave release (for example) so that it represents another parallel process that can potentially minimize the runtime in the wave release. You can set parallel processing of warehouse order creation in the SAP menu under "Extended Warehouse Management -> Settings -> Warehouse Order -> Set Up Control Parameters for Warehouse Order Creation" (or transaction code /SCWM/WOLOG ) by setting the "Parallel" parameter for the warehouse number. § Desktop-based confirmation of large warehouse orders: the configuration options for the asynchronous delivery update as of a threshold value related to the number of delivery items, which were mentioned previously in the RF transactions area, are also taken into account by the system during desktop-based warehouse order confirmations. Consequently, this optimizes the response time when saving the confirmation of large warehouse orders. This affects picking and putaway as well as loading and unloading from transactions /SCWM/LOAD and /SCWM/UNLOAD. § Creation of outbound deliveries and goods issue posting for a transportation unit using transaction /SCWM/TU: When using very large transportation unit activities related to the number of outbound delivery items contained in them, we recommend activating parallel processing for the creation of outbound deliveries and the goods issue posting if more than one outbound delivery order is assigned to the transportation units activity. You should always consider this technical optimization when the system response times are significantly higher than the durations required from a business point of view. The typical threshold value from which this parallelization is most often useful is 1,000 delivery items. In EWM 5.1, this parallelization is made possible by Note 1164464 (and its related notes). As of EWM 7.0, the configuration is included in the IMG (also in higher Support Packages for EWM 5.1). You must carry out the following IMG activities: 1. Activity: "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, the parameter "ParGI" can be set per warehouse number. 2. Activity: "Extended Warehouse Management -> Cross-Process Settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery". Here, parallel processing is activated for the "Outbound Delivery Creation" and "Confirmations for Goods Issue" applications. § In transaction /SCWM/CICO, it is possible to use a dialog step for a transportation unit activity to carry out the "Arrival at Checkpoint" as well as the planned assignment to a door (with the creation of a warehouse task for the yard movement of the transportation unit from the checkpoint to the door). For very large transportation units (more than 1,000 assigned delivery items), we recommend using the parallel delivery update to optimize the system response time. Note 1277438 makes this optimization possible. As of EWM 7.0 Support Package 03, the configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, you can set the "ParCI/YM" parameter per warehouse number. In addition, in the IMG under "Extended Warehouse Management -> Cross-Process settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery", the parallel processing of the delivery must be activated for the "TU Check In and Yard Movement: Delivery Update" application. § Update of the delivery during the desktop-based confirmation of a transportation unit movement to the door (transaction /SCWM/YMOVE) in the case of very large transportation units related to the number of assigned delivery items (more than 1,000 items): Note 1311161 enabled the parallel delivery update. As of EWM 7.0 Support Package 03, the configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, you can set the "ParCI/YM" parameter per warehouse number. In addition, in the IMG under "Extended Warehouse Management -> Cross-Process settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery", the parallel processing of the delivery must be activated for the "TU Check In and Yard Movement: Delivery Update" application. § Creation of unloading warehouse tasks and/or creation of putaway warehouse tasks in transaction /SCWM/UNLOAD or /SCWM/TODLV: In these transactions, the creation of unloading warehouse tasks and/or putaway warehouse tasks may be requested for thousands of handling units and/or the inbound delivery items contained in them. Note 1135535 (EWM 5.1 Support Package 05) and Note 1229776 (EWM 5.1 Support Package 08) enable parallel processing. As of EWM 7.0, this is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, the parameter "Par.Ibd.WT" can be set per warehouse number. You can use parallel processing for all process steps in which you create putaway warehouse tasks together with unloading HU tasks or create only putaway warehouse tasks. § Quantity adjustment in the merchandise distribution flow-through (transaction /SCWM/MEDI_AQTY) as of EWM 7.0: With this transaction, the mass quantity adjustment of outbound delivery orders is possibly based on the quantities of the related inbound deliveries (in the flow-through scenario). The proposed quantity for distribution is calculated and displayed by the transaction and you can save the proposal as changed or unchanged. Parallel processing is provided to calculate the proposed quantity and save the changed outbound delivery orders. This can be set in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery". Activate parallel processing for the applications "Merchandise Distribution Adjustment: Quantity Calculation" and "Merchandise Distribution Adjustment: Delivery Update". § Suppressing the update of wave pick items with the transportation unit number: The assigned transportation unit of a wave pick item is often not important from a business point of view. Therefore, Note 1439613 can be used to suppress the often unnecessary update of wave items. As of EWM 7.0 Support Package 06, this configuration is included in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Define General Settings for Parallel Processing and Performance". Here, the parameter "NoWvUpd" can be set per warehouse number. § Deletion of the "Expected Goods Receipt" documents: In EWM, optional "Expected Goods Receipt" documents can be created based on the plan data of the SAP ERP purchase order. These documents can be deleted periodically and recreated based on potentially changed purchase order data. To reduce the runtime, these documents can be deleted in parallel processing. This can be set in the IMG under "Extended Warehouse Management -> Cross-Process Settings -> Delivery Processing -> General Settings -> Parallel Processing in the Delivery". Activate parallel processing for the "Deleting Expected Goods Receipts" application. · Generic optimizations that are possible within the EWM system for the optimization of response times and the consumption of system resources: § Deactivation of the application log: In the normal productive system, all EWM application logs should be deactivated in such a way that an application log is only generated in the case of errors. These configuration settings can be made in the productive system using the following menu transactions: 1) Transaction /SCWM/DLVPPFLOG: Log of PPF actions of the PPF application /SCDL/DELIVERY (delivery). These actions contain subsequent processing for the delivery (for example, wave pick assignment). 2) Transaction /SCWM/WOHULOG: Log of the PPF print actions of the PPF application /SCWM/WME (Warehouse Management Engine). 3) Transaction /SCWM/ACTLOG: Many different log subobjects, such as the warehouse task processing log (for example). Here, the logs should be configured in such a way that the "No Info." setting is activated. Also, only important messages (error messages) should be taken into account when the "Log Active" parameter value is set. 4) Transaction /SCWM/PSLOG: The determination analysis of the packaging specification determination should be activated only in test operation/test system. § Deactivation of change documents: In scenarios with high throughput, we advise deactivating the change document update of the delivery by using delivery document type Customizing provided this is permitted from a business point of view. In addition to the documents from the outbound delivery process and the inbound delivery process, this also affects documents of the warehouse-internal processes of posting changes and stock transfers. § Deactivation of PPF action definitions that are not used: All PPF action definitions that are not used should be deactivated using transaction SPPFCADM because otherwise the schedule conditions are evaluated for all active action definitions and this is unnecessary. § An important example for the deactivation of PPF action definitions is the deactivation of the action definition /SCWM/SR_SET_TU_SYNC_DLV of the action profile /SCWM/TU of the PPF application /SCWM/SHP_RCV. This contains a schedule condition that has hard-coded logic in the standard SAP system. The scheduling of this action is generally avoided by the deactivation in transaction SPPFCADM. This is possible with Note 1397685. Without the deactivation, the action is always scheduled in the standard SAP system when the assignments of deliveries or handling units for the transportation unit are changed. For example, this is the case when loading data to a transportation unit without the existence of a plan assignment beforehand. This can lead to a high number of executions of this PPF action and this also negatively affects the scaling of the system due to the reserved hardware resources and lock times on the transportation unit objects and delivery objects. An alternative to the scheduling and executing of this PPF action is the manual "check" of a transportation unit using transaction /SCWM/TU because this check also implicitly synchronizes the transportation unit. This synchronization also runs implicitly at the start of important functions such as the goods issue posting of the transportation unit (for example). § Process definition with minimized EWM system load: The number of documents (for example, the number of warehouse tasks for the outbound delivery process of a delivery item) should be critically scrutinized in the Business Blueprint phase in relation to the subsequent system sizing requirements. Complex warehouse processes that consist of many steps require much more hardware system resources. An analysis using the SAP EWM Quick Sizer is recommended. The SAP EWM Quick Sizer is contained in the general SAP Quick Sizer (https://service.sap.com/quicksizer) in the SCM area. Take into account the online help for the EWM Inbound and the EWM Outbound process. It contains Quick Sizer data for EWM sample delivery processes, among other things. § Process definition with minimized system communication load: EWM allows process definitions that can potentially generate a very high SAP EWM - SAP ERP system communication load. An example for this are the partial goods receipt postings (on the partial quantities of an inbound delivery item) that can be sent to the SAP ERP system as partial goods receipt postings. An advantage of these partial confirmations is the immediate availability of these partial quantities in the stock of the ERP system. However, a disadvantage is the increased system communication related to the necessary system sizing, especially on the SAP ERP system. In the IMG, EWM provides the option of using Customizing to influence the message structure that EWM sends to SAP ERP. This can be set in the IMG under "Extended Warehouse Management -> Interfaces -> ERP Integration -> General Settings -> Set Control Parameters for ERP Version Control". · Generic optimizations (within technology components) § If you use DB2 as a database, then take into account Note 1430621 and implement the optimizations included in it. Otherwise, the performance problems described in the note may occur in EWM systems with high data throughput due to waiting updates for the table VBDATA (update task interface data). § Take into account the recommendations mentioned in Note 1422086 for the required adjustments to the Internet Communication Manager (ICMAN) parameter. § General aspects related to asynchronous and parallel processing: In many different application areas, EWM provides the option of asynchronous updates (technically possible using qRFC) and parallel processing (technically possible via ABAP "call function in new task"). A logon/server group, which is entered respectively in Customizing, is technically used for these asynchronous updates and parallel processing. This can be different to the logon group of the dialog user. By using these separate server groups, the allocation of system resources between normal dialog user transactions, asynchronous background processing using qRFC, and specific parallel processing can be optimized (refer to Notes 726148 and 74141 for the configuration of resource management for transactional RFC (tRFC) and asynchronous RFC (aRFC)). In particular, it is possible in heterogeneous hardware system architectures to allocate the hardware with the best "single user response time" to the runtime-critical processes. Take this into account in relation to the logon group of the RF users and in relation to the server groups for runtime-critical parallel processing. § Material flow system (MFS) integration: This integration contains a special example of background processing in relation to the possible configuration of the allocation of system resources using server groups. The server groups used for MFS can be defined using transaction /SCWM/MFS_APPSRV in the productive system. § qRFC processing: This is a specific example of background processing with reference to the possible configuration for the allocation of system resources using server groups. qRFC is used in the EWM system both for system interfaces (for example, the distribution of deliveries from the ERP system to the EWM system) and for internal process flows (for example, process-oriented storage control). The qRFC inbound processing, which causes the workload when you use inbound queuing, can be assigned to a separate logon group or server group for each queue name. You do this by using the QIN Scheduler (for example, you can access this by calling transaction SMQ2 and chooseing Goto->QIN Scheduler in the menu). It is then possible to assign, for example, a specific server group to the processing of delivery receipts from the ERP system in the EWM system. § PPF action processing: This is a specific example of background processing in relation to the possible configuration of the allocation of system resources using server groups. In the EWM system the standard EWM PPF actions whose processing time is set to "when saving the document" are processed directly asynchronously without queuing using qRFC. If this background processing is to be directed to special server groups, you can do this by implementing Note 1599301. If you implement the BadI implementation described in the note, a qRFC is interconnected that then allows you to assign a server group to the qRFC processing (if you are working with a constant prefix in the queue name). This may be particularly relevant for the EWM system performance if large numbers of PPF actions are created at the same time due to mass transactions. If you do not ues qRFC, these PPF actions are all processed at the same time and they create a peak system load. An EWM example for this is the simultaneous goods issue of many delivery documents, for example the goods issue of a transportation unit with many delivery documents. § Size definition of the size of the enqueue lock table: If the EWM system is operated with many simultaneous users or transactions that deal with a lot of objects are executed, it is often necessary to increase the profile parameter enqueue/table_size as described in Note 552289. Transactions with a lot of delivery items are particularly relevant here because the lock often occurs on the level of the individual delivery items (and not on the delivery document header level). An example of this is the wave pick release of a wave with tens of thousands of items. |
