The concept of Table buffers – For functional consultants – Part one

First of all I would like to thank all my SAP friends from all over the world for the emails that you sent me. As well as I would like to thank SAP business community team for the motivation that they have given to me. Thank you guys! I really appreciate it.

Today I’ll talk about the concept of table buffers on SAP. This topic is pretty interesting and gives certain implications on ABAP programming model. I think it’s really useful to the functional consultants to have certain amount of knowledge on this subject.

As we all know, a well developed ERP system should try to optimize its performance by using every possible way. Especially the response time it takes to process the requests from the business user should be minimize as much as possible. By taking this factor into consideration SAP has designed the concept called ‘Table buffer’.

This concept has been developed by considering two main factors.

1. The network traffic between the application server and the database server

As I explained on my earlier posts the SAP database server and the application server can be located on two different physical servers. So every time the application server requests some data from the database, it should be transferred through the network from the database server to the application server which may lead to high network traffic on a typical SAP installation where multiple requests will be passed per second. This factor would slow down the system.

2. The database load

When the programs processed by the application server, directly deal with the tables on the database to manage the data, it increases the database load which will slow down the database’s performance. This will affect a program which uses a specific table in the database as well as other programs which try to use some different tables in the same database.

Solution for the issue

The concept of table buffer simply load the data of a database table into the application server’s RAM. So the programs would access the data from the application server’s RAM rather than directly from the database table.
By buffering data, we increase performance in two important ways:

1.The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

2.The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.
According to the benchmark tests, buffering a table can cause a select statement to run 10 to 100 times faster or more.

The next question that SAP had was, whether to allow all the tables to be buffered or not. Obviously we all would say ‘Yes’. However, buffers are stored entirely on RAM, so space is limited by the amount of RAM available. In fact, there is so much more data than there is RAM, that tables must be buffered with caution to prevent overruns. If a buffer overruns, it might swap to disk, which can eradicate any performance gained by buffering. So SAP has developed this concept in such a way that each individual table can be configured to be buffered or not. But the tables containing a numeric data type as the primary key cannot be buffered

Buffering can be activated through the technical settings of any table. The following screenshot shows table T001, which has been activated to be buffered.

How does this concept work?

When an ABAP program issues an open sql statement, the application server will first check whether the table has been activated to be buffered or not, if the table has been activated to be buffered, the server will check the RAM for the buffered data.

If the buffer is available, the program will read the data from the RAM else it will read it from the database, populate the buffer and subsequently read from the buffer.

I think this post should have given you a basic idea about the table buffers. Definitely this concept improves the performance of the system, but we have to take certain facts into consideration when we try to activate the table buffer on any table. On my next post I will talk about the implications of table buffers in a more detailed way. As well as I will take a look at the multi application server environment and the table buffers.

Please send me your comments.

The concept of Data dictionary on SAP – For functional consultants

You should have heard about the word ‘Data dictionary’ on SAP. Today I thought I would explain the basic concept of data dictionary to the readers. As you know ERP software such as SAP heavily depend on database management systems. Frankly speaking an ERP system works as a front end to the database. Where we capture the data and store it in the database tables, and then we use the captured data to arrive at various business conclusions with the help of the programs provided by the ERP.

Most ERP systems store the configuration, transaction and master data in the database. But SAP has gone one step further and even stores the Program source codes in the database. It’s called SAP Repository. I’ll explain how the programs are being executed by the ABAP processor of the work processes, on a later post.

So as you can see, SAP has to deal with database heavily. As well as SAP has to allow the customer to enhance it’s capabilities, according to the business requirements, which may be done by modifying or creating various database objects such as tables, views and indexes. If SAP allows the customer to directly deal with the underlying database, it may lead to unnecessary problems and even lead the system to an unstable position. As well as it will not be possible to track the changes done to the database.

By taking all those into consideration, SAP has developed its software with a concept of ‘Data dictionary’. You can imagine the data dictionary as a mirror image of the actual database objects, which is part of the SAP itself, where the structures of the database objects such as tables have been replicated. For example every table in the actual database would have a corresponding table structure in the Data dictionary. ABAP programs will deal with the data dictionary objects which intern will connect to the actual database objects. For example if you check the table T000, which stores the client information.

The data dictionary object will look like the image shown below.

The details of same table on the actual database are shown below.

In addition, Data dictionary works like a remote control to the actual database. Developers create the database objects on the data dictionary and activate them; in the background the system will automatically generate the corresponding SQL statements and create the objects on the actual database.

As a strict rule the developers would never create or modify database objects such as tables directly on the actual database, in case if some one has created or modified a database object directly on the database, there is no way that the data dictionary could synchronize with the database object, which will lead to unnecessary problems and may affect the system performance and stability.

We can create objects such as Tables, Structures, Views, Data domains and Data elements on data dictionary. As well as SAP provides various tools to check the consistency between the database and data dictionary objects. I will look at each of those in detail on my future posts.

Please feel free to send me your comments.

Change the parked accounting document

Today we’ll see how we can control the access to the fields on a parked document, so that different groups of employees will only be able to change the fields to which they have been authorized to make any changes . The concept is very simple but I would say this is very effective and flexible to play around with. All we have to do is group the fields on the document into field groups and assign the field groups to the roles, which will then be assigned to the users. Simply follow the following steps to implement this concept on SAP.

Define Field Groups for Documents

Step one:

First we have to define the field groups. We can use the ‘Define Field Groups for Documents’ activity on SPRO

Select the object type as ‘Parked documents’. Please note that we can apply the same logic to other documents such as ‘Documents’, ‘External documents’. ‘Sample documents’, ‘Recurring documents’ and ‘Documents with preliminary postings’

Enter a Field group as a two digit numeric value and type a Description.

Step two:

As the second step we have to group the document fields. Use activity ‘Group Document Fields’ on SPRO to perform this step.

Select the object type as the ‘Parked documents’. Select the Field group that we have created in step one and assign the desired fields.

Step three:

As the next step we have to assign the field groups to the Roles which will then be assigned to the users. Every user can be given authorization to change fields in one or more groups. This means that a user may either change all or no fields of a document. The classification of the fields into groups should be carried out with this in mind.
Execute transaction code PFCG to maintain the roles. Select the desired role and add the desired field groups to the Authorization object ‘F_SKA1_AEN’

Bingo!!! That’s it. Now the users with the role Z100 attached to them would only able to modify the fields ‘Exchange rate’ and ‘Fiscal year’ on the parked documents while the others would not be able to modify any fields at all.

Field groups can also be used to filter the data on report ‘RFBABL00’ (‘Display of changed documents’)

I hope this post would have helped you to understand how SAP even allows us to control the access to each and every field on the documents. I strongly believe this flexibility with SAP is the main factor which makes SAP as the number one ERP in the world.

Please don’t hesitate to send me your comments.

Automatic table history

Some times it’s critical to monitor the changes made to the important tables on the SAP database. SAP provides a way to automate this function. Today I will take you through the steps that we have to perform in order to activate this functionality. After we have carried out the following steps we would be able to monitor the changes using the transaction code SCU3

Step one:

Activate the ‘Log data changes’ option on the technical setting of the selected table. By default this option would be activated for tables such as T000 (Client), T001 (Company code) by SAP.

Now you may ask me if the automatic table recording has already been activated for tables I mentioned above, why system gives the following error message when try to view the change documents using SCU3

Yes we have to do one more step to activate the automatic table history functionality on a given client.

Step two:

Maintain the client number, for which we want to activate the automatic table history, against the parameter ‘rec/client’ on the application server profile.

Bingo now we are ready to go. Now we can use transactions SCU3 to view the change documents.

Ok now let me explain how exactly this works. Every time when you perform an ‘Insert’, ‘Delete’, or ‘Update’ statement on an ‘Automatic table history’ activated table, it will maintain a log on the change document table ‘DBTABPRT’. Check the following screen shot to see the structure of the table ‘DBTABPRT’

Details such as Table name, Date of change, Time of change, Host name, Person who has changed, Transaction code that has been used to change, ABAP Program name, Type of the operation (whether is it insert , delete or update) and the data change will be recorded on the table DBTABPRT. Later when we use transaction code SCU3, it will fetch the data from this table and display the change documents.

But it’s not possible to activate the automatic table history to a table where the length of the primary keys is more than 86 bytes and the length of non primary keys is more than 500 bytes.

As well as consider the fact that activating the ‘Automatic table history’ may slow down the database operations since all the tables with the above option activated need to access the table DBTABPRT to update the change documents and which may lead to table locks. So it’s advisable to activate the 'automatic table history' only on the tables which are really crucial.

Please send me your comments about this post.

Parallel Accounting on MySAP Financials

Today I thought I would write about how we can maintain financial accounts according to multiple accounting standards. MySAP financials makes this process pretty simple with the new general ledger. On this post I will walk you through the steps that we have to do in order to maintain accounts per multiple accounting standards.

First we have to define the ledgers according to the number of standards on which we have to maintain the accounts. For maximum flexibility we can define one ledger per standard. But always consider the fact that we are going to duplicate the database entries per ledger for each double entry. So I advise that if you feel that there are standards which are pretty similar, use only one ledger for those similar standards.

There should be at least one leading ledger. Along with that we can define any number of non leading ledgers to satisfy our needs. When we define ledgers, system will automatically create ledger groups on a one to one relationship to the ledgers.

A ledger group is a combination of ledgers for the purpose of applying the functions and processes of general ledger accounting to the group as a whole. When posting, for example, we can restrict the update of individual postings to a ledger group so that the system only posts to the ledgers in that group. We can group the ledgers into the ledger groups with a representative ledger from which the system will determine and check the posting periods for that ledger group during postings.

After we have defined the ledgers we can specify the parallel currencies on which we want to maintain the accounts on leading and non leading ledgers for each company code. You can have up to three currencies per ledger per company code. But the non leading ledgers can only be maintained on the currencies that specified for leading ledger. But note that you don’t have to maintain non leading ledgers on all leading ledger currencies.

Another interesting functionality is that you can even specify different fiscal year and posting period variants to the company codes for the non leading ledgers than the leading ledger.

Even we can control how other components like ‘Cost Center’, ‘Consolidation’, ‘Business Area’, ‘Profit Center’, ‘Segmentation’ and ‘Cost of Sales Accounting’ will update the ledger by assigning the necessary scenarios to ledgers. A scenario determines which fields are updated when postings are received from other application components. We cannot define our own scenarios. For example we may only update the leading ledger with the cost center details while keeping the other ledgers untouched. This gives the ultimate flexibility to manage the trade off between the database performance and the financial information requirements.

We can add additional fields to the summery table and capture information that cannot be captured by the existing fields on the summery table FAGLFLEXT. Again we can assign the fields to the ledgers like we do to the scenarios as I explained above. I’ll talk about how we can assign additional fields to the summery table FAGLFLEXT on a different post.

My SAP financial even allows us to maintain multiple planning versions per ledger. For example we can use scenario planning techniques by defining different planning versions for individual ledgers which I feel really useful to the managers on this highly unpredictable business environment.

After we defined the ledgers and the ledger groups we can define the accounting principles on SAP system and assign them to the ledger groups.

Once we have carried out the above activities the next step would be to create the accounting document types and their number ranges for entry view. The important point I want to stress at this time is that we have to define number ranges for the accounting documents specific to the non leading ledger groups too. And we cannot use the same number range object we used for the leading ledger. The reason is when we post documents to a specific ledger group if we have the same number range assignment as leading ledger; it will create number gaps on the leading ledger accounting documents. So system will not allow you to specify the same number range object of leading ledger to be assigned to the non leading ledgers.

When it comes to Document types for general ledger view, we don’t have to do anything for leading ledger since in the case of this ledger, the document number in the entry view always corresponds to the document number in the general ledger view. We only have to make these settings for any non-leading ledgers that have a fiscal year variant that differs in at least one company code from the fiscal year variant of the leading ledger in this company code. In this case, the document number in the entry view does not correspond to the document number in the general ledger view and we have to define a separate document type with document number assignment for the general ledger view.

These are the basic settings that we have to do in order to carry out parallel accounting on MySAP Financials. Now we can use transaction codes FB50 and F-02 to post double entries into all the ledgers and transaction codes FB50L and FB01L to post double entries to selected ledger groups. We can generate the financial statements per ledgers when we need them.

This is a basic idea about how we can configure parallel accounting on MySAP Financials and hope that this post has given you a good idea about some of the new SAP general ledger functionalities. Please feel free to send me a comment.

SAP Application server – The Concept

Today I would like to have a look at the SAP application server architecture and how does it work. As you know when we want to work on SAP, as the first step we log into the SAP Application server using SAP GUI. From that moment the SAP application server processes each dialog step executed by the user and responds back to the presentation server. If the dialog step has some SQL statements to be executed, the application server passes the request to the SAP database server.

In an SAP landscape there can be multiple SAP application servers on one SAP system. So you may wonder how SAP determines the application server into which the new user has to be directed. This is the job of SAP message server, which makes the communications possible between the application servers, presentation server and database server. So when a new user logs in, first he will be connected to the SAP message server. SAP message server will determine the suitable application server based on the work load of each instance and will direct the user to an instance with less work load. You can view the details of the message server by executing the transaction SMMS

The following diagram shows the main components of the SAP landscape.

Dialog step

Once the user has been logged into the application server, he can start executing the programs. Each program can have many dialog steps. A dialog step is nothing but the process that will be processed by application server between two screens of the transaction. For example when we post the general ledger entries using the transaction code FB50, we enter all the relevant data and press the ‘Post’ button. You can notice after you have pressed the button, the screen becomes inactive and the data will be sent to the application server. Once the document has been posted the screen will become active again with the confirmation. So the activities done by the application server between those screens is called a dialog step.


Application server components

The Basis is the runtime environment for the ABAP programs. We can start the SAP application server by typing ‘startsap’ on the cmd command. When we start the application server a collection of R3 system files will be executed and will wait for the requests from the presentation server. We have to note that even though ABAP programs are operating system, hardware and RDBMS independent, the SAP kernel and the Basis system are OS, hardware and RDBMS dependant. Now let me introduce the main components which make the application server

1. Dispatcher
2. Work processes
3. Gate way – this is the interface for R/3 communication protocols
4. Shared memory

Dispatcher

When a presentation server requests a dialog step to be executed, the request will be sent to the dispatcher of the application server on which the user has been logged in. dispatcher will add the request to the dispatcher queue. Then the dispatcher will allocate the requests to the available work processes based on first in first out basis. As I said before one program can have many dialog steps and all the dialog steps of a given program need not always be executed by the same work process. This gives certain amount of implications to the ABAP programming model.

Work processes

Do you remember that I have written on the previous post that ABAP programs are executed by software processors rather than directly by the CPU? Yes work processes within application servers act as the virtual processors. Each work process will have the following components.

Task handler.
Screen processor – which processes the flow logic of the program
ABAP processor – which processes the ABAP program logic
Database interface

There are different types of work processes which perform different types of tasks. Such as dialog work processes, background work processes, spool work processes etc. the number of work processes and the type can be controlled by changing the parameters on the application server profile. Application server profile is a configuration file located at each application server which would contain the parameters and the values of the server.

You can view the application server profile by executing the transaction RZ10. From the menu bar of the transaction RZ10 select the Goto à Profile values à Of a server. Then double click on the server name. The following parameters will specify the number of work processes.

rdisp/wp_no_btc
rdisp/wp_no_dia
rdisp/wp_no_enq
rdisp/wp_no_spo
rdisp/wp_no_spo_Fro_max
rdisp/wp_no_vb
rdisp/wp_no_vb2

The system administrator can use the application server profile and manage the number of work processes to optimize the system performance. For example the administrator can set more dialog work processes during daytime and more background work processes during nights.

You can use transaction SM50 to view the activities on the work processes. Press and hold F8 to see the activities.

When the application server has been started the work processes will register themselves with the database layer. In other words each work process will act as a database client and open a dedicated connection to the database.

One of the fundamental concepts in business application development is that the database changes should be consistent before and after a sql operation has been carried out. In database world, we call it as transaction; a transaction will execute the entire sql set or rollback to the initial stage. In SAP world it’s being called as Logical Unit of Work (LUW).

The work process will execute the entire SQL statements belong to a dialog step as a LUW, this makes sure that the database is consistent before and after a dialog step has been executed by a work process.

But now you know that the dialog steps belong to one program might be executed by different work processes which mean it would have multiple LUW. So there is a chance that the database may be inconsistent if the program terminates after certain dialog steps are executed and the rest are not. For this issue there are bundling techniques provided by ABAP. One of those is SAP LUW which bundles the dialog steps with the underlying SQL statements.

Shared memory

All the work processes on an application server shares a common shared memory space. I will discuss the concepts of user contexts and roll area on a later post. We had a maximum memory limitation with the 32 bit computer processors but with the introduction of 64 bit processors the memory limitations are not an issue any more.

I hope that the above explanations would have given a high level understanding about the SAP application server and its components. We can optimize the performance of SAP system by manipulating the number of the application severs on an implementation and the number of work processes and their types on each application server. Please feel free to send me your comments by clicking on ‘Comments’ button shown below.

SAP system landscape – basic idea for functional consultants

As we all know SAP works on client server architecture. The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing.

I’ll explain the client server model using a small example. I’m sure that all of us have used Microsoft outlook to send and receive mails to our buddies. To send a mail we open the Microsoft outlook on our pc, type the new mail and press the send button. Here the Microsoft outlook acts as a client. Once we pressed the button outlook connects to the exchange server which will receive the request from the client and send the mail for you. Here the microsoft outlook as a client sends the request to the exchange server. server receives the request and process the tasks.

When the client and server programs both run on the same computer, the configuration is referred to as single-tier client/server. (A tier is the boundary between two computers.) When they run on different computers, the configuration is referred to as two-tier client/server.
A program can function as both a client and a server if it both requests information and replies to requests. When you have three programs in communication, the configuration is called three-tier client/server.

The main advantage of the software of this nature is that it can be fine tuned to give maximum performance for the given scenario. The client/server configuration enables the MySAP ERP system to spread its load across multiple computers. This provides the customer with the ability to scale the processing power of the system up or down by simply adding another computer to an existing configuration, instead of replacing a single computer that performs all of the processing, such as that which occurs in the mainframe world.

The main software components on a SAP system can be categorized as follows.
1.Presentation server
2.Application server
3.Database server

Presentation server

Presentation server is nothing but the laptop or PC which has sapgui.exe that you use to log into SAP system.

Application server

An application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. Application severs act like a mediators between the presentation server and the database sever. Application sever receives the requests from the presentation sever and process them on its work processes. I’ll talk about the work processes in details later on this blog. The important fact that I want to share with you is that the ABAP programs are processed by ‘Software processors’ and not directly by the CPU. I’ll discuss about the components of an Application sever later on this Blog too.

Database server

The database server is a set of executables that accept database requests from the application server. Database server will pass the requests to the RDBMS that has been used. As you should know SAP supports Database management systems from various vendors such as Microsoft SQL server, Oracle, Informix and Sybase etc. The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to the ABAP/4 program.

Some technical terms that useful to functional consultants

I think it’s appropriate to tell you the meaning for some terms used by technical consultants. If you hear a word MySAP ERP system or R/3 system, it means an implementation with one database. In other words, the implementation that you did for company A with one database as the backend is one system and the implementation at company B is another system

Another frequently used word is ‘Instance’ this simply means the application server. If your technical consultant buddy says we have one instance which means we have one application server. If he says five instances which mean five application servers are running on the environment. For example HP runs around 70 instances or application servers to manage its global transactions.

Different types of configurations

As we have seen above SAP is a client server based system which gives us enormous flexibility to configure the system to suit our environment. Presentation server, Application server and Database server can be put at different possible positions to get the maximum throughput from the system, which means there are virtually unlimited configuration possibilities.

1. SAP three-tier client/server configuration: the presentation servers, applications servers, and database server all run on separate machines. This is the most common configuration for large systems, and is common in production. As well as you can have multiple applications and database servers to share the work load.

2. SAP distribution presentation configuration: the application and database servers are combined on one computer and the presentation servers run separately. This is used for smaller systems, and is often seen on a development system.

3. SAP two-tier client/server configuration: the presentation and application servers are combined and the database server is separate. This configuration is used in conjunction with other application servers. It is used for a batch server when the batch is segregated from the online servers. A SAPGUI is installed on it to provide local control.

4. SAP central configuration: all servers are combined onto a single machine. This is rarely seen because it describes a standalone R/3 system with only a single user. I don’t think anyone will buy SAP with millions of dollars to install it on their PC :)

SAP is much more flexible than any other traditional ERP systems. It’s the duty of the technical and functional consultants to sit together to draft a technical system blueprint to maximize the performance of the SAP. As well as we should also consider the budget and hardware limitations when drafting a technical landscape.

I hope this article gave you a better understanding about the SAP technical landscape. Please feel free to send me a comment about this article by clicking on the ‘Comments’ button.