Custom Search

Client Concepts

Client Concepts and Types of Data in SAP System

Data in an SAP system can be divided into two categories:

1. Client-specific data:
Client-specific data such as user master and application data, which affects only one client.
2. Cross-client data:
Cross-client data such as cross-client customizing data and all Repository
objects, which affects the whole system environment.

The ABAP Dictionary is a data dictionary that is part of the ABAP Repository. Each piece of the ABAP Dictionary information is entered only once and is then available anywhere in the system at any time. The ABAP Dictionary automatically supplies all new or changed information, thus providing current runtime objects and ensuring data consistency and security.

A client is a self contained unit in technical terms, wit its own master data.

The following are examples of client-specific data:
User master data, such as parameters, authorization, user groups

Customizing data, such as organizational units, assignments, and document types

Application data, such as business transaction data, and material master data

The SAP client concept can integrate several companies or subsidiaries in a single client by using company codes and the SAP authorization concept. Company codes define the smallest corporate organizational units for which a complete self-contained set of accounts can be drawn up for external reporting.
The SAP authorization concept enables the parent company to access all subsidiaries for report purposes, while subsidiary-specific data is protected against access from other subsidiaries through company code definition.

The standard client roles fulfill the optimal minimum requirements of your SAP system.

Client CUST, development and customizing, is the central customizing client where complete adaptation of the SAP system to customer-specific needs takes place. All changes performed in this client are recorded so they can be supplied to the other clients using the Transport Management System.

Client QST, quality assurance, is used to test and verify the new customizing settings in the application.

Client PRD or production is the client for production activities, that is, where your company’s business is carried out. Customizing changes imported into this client have to be first tested carefully in the QST client in order to ensure that production operation is free of disruption.

Types of RFC (Remote Function Calls)

Types of RFC

Synchronous RFC (sRFC)
For communication between different systems and between SAP Web AS and SAP GUI.

Asynchronous RFC (aRFC)
For communication between different systems and for parallel processing of selected tasks.

Transactional RFC (tRFC)
A special form of asynchronous RFC. Transactional RFC ensures transaction-like processing of processing steps that were originally autonomous.

Queue(d) RFC (qRFC)
Queued RFC is an extension of tRFC. It also ensures that individual steps are processed in sequence.

RFC is a superordinate term for various implementation variants. sRFC is the synchronous call of function modules. This means that the client waits until the server has completed its processing. In an SAP system, an RFC can also be performed asynchronously in another work process. This variant is called aRFC.

There is also tRFC, the transactional Remote Function Call. Transactional RFC is asynchronous and ensures that data that is sent more than once due to network problems, can be recognized at the server side, by assigning a Transaction Identifier (TID). This allows you to prevent data being processed more than once, leading to erroneous information in the application. Due to the asynchronous processing, however, parameters can only be transferred from the client to the server in this case. Returning information or status information directly is not possible.

qRFC with Send Queue is an extension of tRFC. It creates a layer between applications and the tRFC and only allows the tRFC to transfer a Logical Unit of Work (LUW) to the target server when its predecessors are no longer in the associated wait queues. After a qRFC LUW is executed, the qRFC manager automatically processes the next waiting qRFC LUW in accordance with the sequence in the wait queue.

Fundamentals of RFC (Remote Function Calls)

Fundamentals of RFC

Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system. You can also call a function module in the same system as an RFC; however, RFCs are usually used when the calling and called function modules are running in different systems.

In the SAP system, the RFC interface system provides this function. The RFC interface system allows function calls between two SAP systems or between an SAP system and an external (non-SAP) system.
RFC is an SAP interface protocol that is based on the Common Programming Interface for Communication (CPI-C) and allows cross-host communication between programs. This means that ABAP functions can be called from external applications and tools, and that external applications can be called from the SAP system.

RFC means that the ABAP programmer does not have to write his or her own communication routines. For an RFC call, the RFC interface Converts all parameter data to the format required in the remote system calls the communication routines that are required to communicate with the remote system handles errors that occur during the communication.

Transport types

The transport types:

K type: The system owner does not get changed with K type transport. This kind of transport is only allowed to consolidation and production system. After the K type of transport is done no correction is allowed to those objects. Any changes to K type transport objects in consolidation system are called repair.
The repairs can be done to those objects if the change option is selected in SE06 and change option is there in client level selection in T00 table. Generally K type transport is used for stage and production environment.

C type: With the C type transport the ownership of that object is also transferred to the target. After the transport is done, the target system is the owner of the transported objects. The objects will be originals of the target system. These kind of transports are generally done in a four tier architecture, where a bundle of development objects can go from the sandbox environment to development environment or development environment to integration environment and vice versa. SAP recommends doing these transports when the objects should move to another system for further development work.

T type: T type is called a transport of copy. The ownership of the object remains with the source; the target system just gets the copy of the objects. When a sap patch is applied to the development system and transported to other systems, those are perfect example of T type transports.

Free download SAP Basis Week 5.pdf

Free download SAP Basis Week 5.pdf

http://rapidshare.com/files/57141272/BASIS_Week5.pdf

Free download SAP Basis Week 4.pdf

Free download SAP Basis Week 4.pdf

http://rapidshare.com/files/57141180/BASIS_Week4.pdf