Monday, July 20, 2009
Sunday, July 19, 2009
R3 System Overview
Introduction of R3 system
The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. It is written in C and C++ and some ABAP.
Database: The applications do not communicate directly with the database. Instead, they use Basis services.
Communication: R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component.
ABAP workbench is written in ABAP.
The message server is responsible for communication between the application
servers. It passes requests from one application server to another within the system.
Software layer distribution:
A common configuration is to run the database system and a single application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.
Dialog step between presentation layer and application layer:
Application Server
Work Processes
An application server contains work processes, which are components that can run an
application. Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step.
Dispatcher
Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.
Gateway
Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The fact that the individual work processes work independently makes them suitable for a multi-procecssor architecuture
A mapping process projects the required context for a dialog step from shared
memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably.
Database Connection
When you start up an R/3 System, each application server registers its work proceses with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the
programming model explained below.
A dialog step from a program is assigned to a single work process for execution.
The individual dialog steps of a program can be executed on different work processes, and
the program context must be addressed for each new work process.
A work process can execute dialog steps of different programs from different users.
The SAP programming model contains a seies of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Work Processes
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.
Different types of Work Process:
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.
Update Work Process
Update 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 Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The 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 Process
The 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.
The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. It is written in C and C++ and some ABAP.
Database: The applications do not communicate directly with the database. Instead, they use Basis services.
Communication: R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component.
ABAP workbench is written in ABAP.
The message server is responsible for communication between the application
servers. It passes requests from one application server to another within the system.
Software layer distribution:
A common configuration is to run the database system and a single application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.
Dialog step between presentation layer and application layer:
Application Server
Work Processes
An application server contains work processes, which are components that can run an
application. Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step.
Dispatcher
Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.
Gateway
Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The fact that the individual work processes work independently makes them suitable for a multi-procecssor architecuture
A mapping process projects the required context for a dialog step from shared
memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably.
Database Connection
When you start up an R/3 System, each application server registers its work proceses with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the
programming model explained below.
A dialog step from a program is assigned to a single work process for execution.
The individual dialog steps of a program can be executed on different work processes, and
the program context must be addressed for each new work process.
A work process can execute dialog steps of different programs from different users.
The SAP programming model contains a seies of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Work Processes
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.
Different types of Work Process:
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.
Update Work Process
Update 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 Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The 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 Process
The 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.
Wednesday, July 15, 2009
Checks Using Checking Horizon
The checking horizon defines a time interval (check date + period) in which a product availability check can be carried out. If the requirements date lies within this time interval, the check is carried out. Requirements that lie after the end of the checking horizon are not checked, which means they are confirmed in full. The checking horizon can be used to model the replenishment lead time, for example.
The following prerequisites must be met for using the checking horizon:
The checking horizon and the checking horizon calendar must be entered in the location-specific product master data.
The checking horizon must be activated in Customizing for the check control.
Tuesday, June 30, 2009
Note 358330 - Delete old temp. qty assignments with pers. ind.
Symptom
You want to delete temporary quantity assignments, which exceeded a predetermined date and which have a determined persistence indicator.Additional key words
Delta records, /SAPAPO/OM_DELTA_REMOVE_OLDERCause and prerequisites
You can use report /SAPAPO/OM_DELTA_REMOVE_OLDER to delete old temporary quantity assignments (refer to Note 315507). However, up to now this report was able to delete old quantity assignments only according to user and type (product availability, product allocation, planning, network).Solution
This correction extends report /SAPAPO/OM_DELTA_REMOVE_OLDER so that you can also include persistence indicators (not persistent, pre persistent, persistent) The system will then only delete temp. quantity assignments, which correspond to one of the transferred persistence indicators.For this correction, you first have to import a new COM object (SAPAPO COM build 24 or higher) for the liveCache. The procedure is described in Note 359074. You do not need to re-initialize the liveCache.In addition to the attached source code corrections, the following measures are required:
1. Call Transaction SE11. Select Data type and enter /SAPAPO/PERSIND_LIST. Choose the Create button. Select Structure. As Short text, enter 'List of Boolean values, determines the persistence indicator'. Enter the following components with component type:
2. NORMAL XFELDPREPERS XFELDPERSIST XFELDChoose the Activate button. Enter /SAPAPO/ATP as Development class.
3. Call Transaction SE37. Enter /SAPAPO/OM_DELTA_REMOVE_DATE and choose the Change button. Choose tab title Import. Enter new parameter:IS_PERSINDLST TYPE /SAPAPO/PERSIND_LIST X
4. Choose the Activate button.
5. By using Transaction SE38, start the Editor and enter /SAPAPO/OM_DELTA_REMOVE_OLDER. Choose Change. In the menu, choose Goto->Text elements->Text symbols. In the table, make the following entry: 007 Persistence indicator. Choose the Activate button.In the menu, now choose Goto->Text elements->Selection texts. If the attached source code corrections are already made, three table entries appear, having the names PI1, PI2 and PI3 at which the text is missing. Enter the following:
6. PI1 not persistentPI2 pre persistentPI3 persistentThen choose the Activate button.
Implement the attached program corrections.Source code corrections
You want to delete temporary quantity assignments, which exceeded a predetermined date and which have a determined persistence indicator.Additional key words
Delta records, /SAPAPO/OM_DELTA_REMOVE_OLDERCause and prerequisites
You can use report /SAPAPO/OM_DELTA_REMOVE_OLDER to delete old temporary quantity assignments (refer to Note 315507). However, up to now this report was able to delete old quantity assignments only according to user and type (product availability, product allocation, planning, network).Solution
This correction extends report /SAPAPO/OM_DELTA_REMOVE_OLDER so that you can also include persistence indicators (not persistent, pre persistent, persistent) The system will then only delete temp. quantity assignments, which correspond to one of the transferred persistence indicators.For this correction, you first have to import a new COM object (SAPAPO COM build 24 or higher) for the liveCache. The procedure is described in Note 359074. You do not need to re-initialize the liveCache.In addition to the attached source code corrections, the following measures are required:
1. Call Transaction SE11. Select Data type and enter /SAPAPO/PERSIND_LIST. Choose the Create button. Select Structure. As Short text, enter 'List of Boolean values, determines the persistence indicator'. Enter the following components with component type:
2. NORMAL XFELDPREPERS XFELDPERSIST XFELDChoose the Activate button. Enter /SAPAPO/ATP as Development class.
3. Call Transaction SE37. Enter /SAPAPO/OM_DELTA_REMOVE_DATE and choose the Change button. Choose tab title Import. Enter new parameter:IS_PERSINDLST TYPE /SAPAPO/PERSIND_LIST X
4. Choose the Activate button.
5. By using Transaction SE38, start the Editor and enter /SAPAPO/OM_DELTA_REMOVE_OLDER. Choose Change. In the menu, choose Goto->Text elements->Text symbols. In the table, make the following entry: 007 Persistence indicator. Choose the Activate button.In the menu, now choose Goto->Text elements->Selection texts. If the attached source code corrections are already made, three table entries appear, having the names PI1, PI2 and PI3 at which the text is missing. Enter the following:
6. PI1 not persistentPI2 pre persistentPI3 persistentThen choose the Activate button.
Implement the attached program corrections.Source code corrections
Friday, June 19, 2009
Note 506393 - Conversion exits when creating characteristics combinations
Summary
Symptom
You would like to create or generate characteristics combinations for a planning object structure. The planning object structure contains one or more characteristics that have been assigned a conversion exit in the information object definition. This note describes how to deal with this situation.Solution
When characteristics combinations are created manually using transaction '/SAPAPO/MC62', the InfoObject conversion routines run. This means that you enter the external display of the characteristic value on the screen. However, only the internal display of the characteristic value that is determined by the conversion routine is stored.During the generation of characteristics combinations from an InfoCube using transaction '/SAPAPO/MC 62' no conversion routines are executed. This means that the characteristic values must be saved in the internal format in the InfoCube. You can display the InfoCube data in the 'LIST CUBE' using the option 'Do not use any conversion' in the internal display.If the data in the InfoCube is not saved in the internal format and the characteristics combinations are generated from this, different problems may occur in demand planning. One typical problem is that you cannot select your products in Interactive Planning. If you have generated your characteristics combinations with an incorrect internal display, you must delete the characteristics combinations and generate the characteristics combinations again with correct InfoCube data.
Related Notes
1025196 - Navigation attribute values are not loaded with CVC creation
540926 - Collective consulting note on planning object structures
Symptom
You would like to create or generate characteristics combinations for a planning object structure. The planning object structure contains one or more characteristics that have been assigned a conversion exit in the information object definition. This note describes how to deal with this situation.Solution
When characteristics combinations are created manually using transaction '/SAPAPO/MC62', the InfoObject conversion routines run. This means that you enter the external display of the characteristic value on the screen. However, only the internal display of the characteristic value that is determined by the conversion routine is stored.During the generation of characteristics combinations from an InfoCube using transaction '/SAPAPO/MC 62' no conversion routines are executed. This means that the characteristic values must be saved in the internal format in the InfoCube. You can display the InfoCube data in the 'LIST CUBE' using the option 'Do not use any conversion' in the internal display.If the data in the InfoCube is not saved in the internal format and the characteristics combinations are generated from this, different problems may occur in demand planning. One typical problem is that you cannot select your products in Interactive Planning. If you have generated your characteristics combinations with an incorrect internal display, you must delete the characteristics combinations and generate the characteristics combinations again with correct InfoCube data.
Related Notes
1025196 - Navigation attribute values are not loaded with CVC creation
540926 - Collective consulting note on planning object structures
Monday, June 8, 2009
Consistency Check between SCM and R3
Checks for Internal Consistency:
/SAPAPO/DMOPR_REORG_CTP - Backorder Elimination in Capable-to-Promise, Note: 426563,
Process:
You can plan report /SAPAPO/DMOPR_REORG_CTP to run regularly (for example, weekly) in the background. You cannot and must not define variants. There does not need to be parallel processing because the runtime is not critical.
Result:
The program run deletes the reservations of components and capacities. A results list is not created — there is no need to process or work through the results.
/SAPAPO/OM17 - Internal Consistency Check for Setup Matrixes
/SAPAPO/MATRIX_TO_LC_SEND - generate the inconsistent setup matrices in liveCache
Prerequisites
As well as the case described above (connection error to liveCache), we also recommend running the report before each consistency check for resources
Process
Report /SAPAPO/MATRIX_TO_LC_SEND must not be run in parallel. This is not necessary because the runtime is not critical. You can run other activities in the system.
Result
You can view the results list in the application log (transaction SLG1). Note that this log is not stored under the user name. You can find it under the object APO and sub-object PPDS.
/SAPAPO/REST02 - Internal Consistency Check for Resources
/SAPAPO/OM11 - Livecache Application log
/SAPAPO/ATPQ_CHKUSG - Internal Consistency Check for Product Allocations.
/SAPAPO/DMOPR_REORG_CTP - Backorder Elimination in Capable-to-Promise, Note: 426563,
Process:
You can plan report /SAPAPO/DMOPR_REORG_CTP to run regularly (for example, weekly) in the background. You cannot and must not define variants. There does not need to be parallel processing because the runtime is not critical.
Result:
The program run deletes the reservations of components and capacities. A results list is not created — there is no need to process or work through the results.
/SAPAPO/OM17 - Internal Consistency Check for Setup Matrixes
/SAPAPO/MATRIX_TO_LC_SEND - generate the inconsistent setup matrices in liveCache
Prerequisites
As well as the case described above (connection error to liveCache), we also recommend running the report before each consistency check for resources
Process
Report /SAPAPO/MATRIX_TO_LC_SEND must not be run in parallel. This is not necessary because the runtime is not critical. You can run other activities in the system.
Result
You can view the results list in the application log (transaction SLG1). Note that this log is not stored under the user name. You can find it under the object APO and sub-object PPDS.
/SAPAPO/REST02 - Internal Consistency Check for Resources
/SAPAPO/OM11 - Livecache Application log
/SAPAPO/ATPQ_CHKUSG - Internal Consistency Check for Product Allocations.
Subscribe to:
Posts (Atom)