SYSTEM KERNAL :
In SAP terminology, a service means a service provided by a software component (software-oriented view). This component can consist of a process (compare work process) or a group of processes (compare application server) and is then called a server for that service.
Software components that use this service are called clients. At the same time, clients can also be servers for specific services.
A server often also means a computer (host) on which software components that provide specific software.
The fundamental services in a business application system are presentation services, application services, and database services.
In a one-tier R/3 System configuration, all processing tasks are performed on one server, as in classic mainframe processing.
Two-tier R/3 System configurations are usually implemented using special presentation servers that are responsible solely for formatting the graphical user interface. Many R/3 System users use Windows PCs for example as presentation servers. An alternative two-tier configuration (not shown) is to install powerful desktop systems and to use these for presentation and applications also (two-tier client/server).
This type of configuration is particularly useful for processing-intensive applications (such as simulations) or for software developers, but due to the additional administration requirements is usually used for test purposes only.
In a three-tier configuration, separate servers are used for each tier. Using data from the database server, several different application servers can operate at the same time. To ensure that the load on individual servers is as even as possible and to achieve optimal performance, you can use special application servers for individual application areas such as distribution or financial accounting (logon and load balancing).
Interpreter and ABAP Interpreter are presented here. Another topic is data exchange with the
database.
The central process in the R/3 application layer is the dispatcher. Together with the operating system, the dispatcher controls the resources for the R/3 applications. The main tasks of the dispatcher include distributing transaction load to the work processes, connecting to the presentation layer, and organizing communication.
User screen input is received by the SAP presentation program SAP GUI, converted into its own format, and then sent to the dispatcher. The processing requests are then saved by the dispatcher in request queues and processed according to “first in / first out”.
The dispatcher distributes (dispatches) the requests one after the other to the available work processes. Data is actually processed in the work process. The user that sent the request through the SAP GUI is usually not assigned the same work process, because there is no fixed assignment of work processes to users.
Once the data has been processed, the processing result from the work process is sent through the dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user with the help of the operating system on the frontend computer.
During initialization of the R/3 System, the dispatcher executes the following actions, among others:
it reads the system profile parameters, starts work processes, and logs onto the message server (this service will be explained later).
Today, large amounts of data are usually administered using relational database management systems (RDBMS). These systems store the data and the relationships between the data in two dimensional tables, which are known for their logical simplicity. The definitions of the data, tables, and table relationships are stored in the data dictionary of the RDBMS.
Within ABAP, SAP OPEN SQL is used to access application data in the database, independent of the corresponding RDBMS. The R/3 database interface converts the open SQL statements from the ABAP statements into the corresponding database statements. This means that application programs written in ABAP are database-independent. Native SQL commands can be used in ABAP.
When interpreting open SQL statements, the R/3 database interface checks the syntax of these statements and automatically ensures the local SAP buffers in the shared memory of the application server are utilized optimally. Data frequently required by the applications is stored in these buffers so that the system does not have to access the database server to read this data.
In particular, all technical data such as ABAP programs, screens, and ABAP Dictionary information, as well as some business process parameters usually remain unchanged in a running system, making them ideal buffering candidates. The same applies to certain business application data, which is accessed as read-only.
The operating system views the R/3 runtime system as a group of parallel, cooperating processes. On each application server these processes include the dispatcher as well as work processes; the number of work processes depends on the available resources. Work processes may be installed for dialog processing, update, dialog free background processing and spooling.
n In addition to these work process types (dialog processing (D), update (V: for the German
“Verbuchung”), lock management (E), background processing (B), spool (S), the R/3 runtime
system provides two additional services for internal and external communication (below are the restrictions on the number of work processes):
. The message server (MS or M) communicates between the distributed dispatchers within the R/3 System and is therefore the prerequisite for scalability using several parallel-processing application servers.
. The gateway server (GW or G) allows communication between R/3, R/2 and external
application systems.
. Dialog: Every dispatcher requires at least two dialog work processes
. Spool: At least one for each R/3 System (more than one allowed for each dispatcher)
. Update: At least one for each R/3 System (more than one allowed for each dispatcher)
. Background processing: At least two for each R/3 System (more than one allowed for each dispatcher)
. Enqueue: Only one enqueue work process is needed for each system
n The lock mechanisms in today’s relational database systems are usually not able to handle business data objects (such as customer orders) that affect several database tables. To coordinate several applications simultaneously accessing the same business object, the SAP System provides its own lock management, controlled by the enqueue work process.
n In order for the system to execute lock requests, you must first define a lock object in the ABAP Dictionary. The lock object contains tables whose entries are to be locked. A lock object consists of a primary table. You can also define additional secondary tables using foreign key relationships (the name of a user-defined lock object must begin with "EY" or "EZ").
n You can specify the lock mode ("S”: shared lock or "E”: exclusive lock) for a lock object. An exclusive lock (mode "E") can only be set if no other user has set a lock (“E” or “S”) on the data record. The same user can request additional "E" or "S" locks within a program call sequence (call chain).
n If a lock object is activated, the system generates an ENQUEUE and a DEQUEUE function module.
These function modules are called ENQUEUE_
n A transaction corresponds to a logical unit of work (LUW).
n However, as today’s database systems do not support cross-process transaction flow, we must differentiate between the elementary processing steps (LUWs) in the SAP System and those in the database system (SAP - LUW / DB - LUW). A DB - LUW is either committed or not updated (rollback). The DB - LUW moves the database from one consistent state to the next. This means that the data must be logical and correct before as well as after the LUW; this applies to both DB – LUW and SAP - LUW.
n The start of an SAP transaction is also the start of an SAP - LUW. SAP - LUWs are completed either by a "COMMIT WORK" in the ABAP code, or by the completion of the corresponding asynchronous update (second part of the SAP - LUW). As explained previously, each dialog step in an SAP - LUW is processed by one work process, as is the case for the DB - LUW. Each database change is executed in its own DB-LUW.
n The asynchronous updating usually used in an SAP - LUW allows the system to temporarily collect changes made by users and then, at the end of the dialog phase (in the second part of the SAP - LUW), make the necessary changes to the database in a separate update work process. To ensure data consistency, the resulting database change (which includes every “dialog step change”) is executed in only one final DB - LUW.
n Background work processes are designed for periodic tasks such as reorganization or the automatic transfer of data from an external system to the R/3 System.
n Background processing is scheduled in the form of jobs. Each job consists of one or more steps (ABAP reports, external programs, or other operating system calls), that are processed sequentially.
You can also set priorities (from "C" to "A") so that certain jobs are prioritized.
n Job processing is not generally triggered immediately (immediate start). Instead you specify a start date and time when you schedule the job. It may also be necessary to start jobs periodically, for example, system control jobs repeated on a fixed cycle. Using the program SAPEVT, you can trigger a job start at the operating system level.
n The background scheduler is responsible for automatically triggering the job at the specified time.
The background scheduler is an ABAP program that regularly looks in the scheduling table for jobs to be executed and then ensures that they are executed (RDISP/BTCTIME, default 60 s).
n Spooling refers to the buffered transfer of data to output devices such as printers, fax devices, and so on. In distributed systems, networked administration is necessary for this output.
n The R/3 System spool mechanism can supply print requests to printers and external spoolers both within a local network as well as across wide-area networks (WANs). The spool mechanism works with the local spool system on each server.
n Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.
n When data is to be printed, a print request is generated for a spool request. This print request is processed by a spool work process.
n Once the spool work process has formatted the data for output, it returns the print request to the operating system spool system.
n The operating system spool takes over queue management and ensures that the required data is passed to the output device.
n An instance is an administrative unit that combines R/3 System components providing one or more services. The services provided by an instance are started or stopped together. You use a common instance profile to set parameters for all the components of an instance.
n A central R/3 System consists of a single instance providing all the necessary R/3 System services.
n Each instance has its own SAP buffer areas.
n The example illustrates how an additional background processing server (a) and dialog server (b) are set up. These instances, which provide specific services, generally run on separate servers, but can also run on the same server, if needed.
n The message server provides the application servers with a central message service for internal communication (for example, trigger update, request and remove locks, trigger background requests).
n The dispatchers for the individual application servers communicate through the message server, which is installed once in each R/3 System (it is configured in the R/3 System profile files).
n Presentation servers can also log on to an application server through the message server. This means that you can use the message server performance database for automatic load distribution (logon load balancing).
COMMUNICATIONS :
n The R/3 System ensures portability by using industry-standard interfaces that support the interaction of applications, data, and user interfaces. The system can interact with various operating systems, databases, and networks. The R/3 System uses open industry standards, such as TCP /IP, EDI, OLE, and open interfaces.
n The R/3 System is an open system. It supports a variety of network communication protocols. Information can be exchanged between R/3 Systems and other R/3, R2, or non-SAP systems across a network.
n SAP supports the Transmission Control Protocol / Internet Protocol (TCP/IP) and System Network Architecture: Logical Unit 6.2 (SNA LU6.2) protocols. Communication within the R/3 System uses the standard protocol TCP/IP. LU6.2 was developed by IBM and is used to communicate with mainframe-based R/2 Systems.
n R/3 application programming supports the following communication interfaces: common
programming interface communication (CPI-C), remote function call (RFC), and object linking and embedding (OLE) automation.
n For more information about communication, see the online documentation. You can also order an “Interface Adviser” Knowledge CD from SAP that uses many practical examples to explain communication in the R/3 System. SAPNet also contains additional information, such as under the alias /int-adviser.
n Remote Function Call (RFC) is a communications interface based on CPI-C, but with more functions and easier for application programmers to use. You can use R/3 and R/2 Systems as well as external applications as RFC communication partners.
n For communicating with R/2 Systems, additional software (SNA gateway) is required on at least one application server. See also R/3 Note 13903.
n RFC is the protocol for calling special subroutines (function modules) over the network. Function modules are comparable with C functions or PASCAL procedures. They have a defined interface through which data, tables and return codes can be exchanged. Function modules are managed in the R/3 System in their own function library, called the Function Builder.
n The Function Builder (transaction SM37) provides application programmers with a useful
environment for programming, documenting and testing function modules that can be called locally as well as remotely. The R/3 System automatically generates the additional code (RFC stub) needed for remote calls.
n You maintain the parameters for RFC connections using transaction SM59. The R/3 System is also delivered with an RFC-SDK (Software Development Kit) that uses extensive C libraries to allow external programs to be connected to the R/3 System.
n The only difference between a remote call of a function module to another server and a local call is a special parameter (destination) that specifies the target server on which the program is to be executed.
n There are three types of RFC calls:
. Synchronous RFC call: The calling program stops until the function module has been processed on the target server and any results have been returned to the caller. Only then does the calling program continue processing.
. Asynchronous RFC call: The calling program runs parallel to and independently of function module processing in the target system. Programmers are responsible for the processing of the results. In addition, the target system must also be available at the time of the RFC call.
. Transactional RFC call: Several function modules can be grouped into one transaction. They are processed only once in the target system, within an LUW, and in the sequence in which they were called. In the case of an error, a message is sent to the calling system that you can analyze using transaction SM58. For transactional RFC, the target system does not have to be available at the time of the RFC call. In addition, you can configure the frequency and intervals of individual queries.
n Object linking and embedding (OLE) is an object-oriented method for program-to-program communication. You can connect office applications that support OLE2 automation (for example, Word and Excel) to the R/3 System. In this way, users can use the R/3 functions within their usual desktop environment.
n The office programs’ OLE functions are specified in the R/3 System in the type information. This information contains a description of the methods, attributes and parameters. Type information can be language-independent.
n When using OLE, the R/3 System can play two separate roles:
. If the R/3 System is acting as an OLE client, then the user calls the desktop program from the ABAP application. OLE commands are transferred from the ABAP code as remote function calls (RFC) through the SAP GUI to the PC. The SAP GUI maps RFC calls to OLE commands for the PC application.
. If the R/3 System is acting as an OLE server, R/3 functions can be called from the desktop application. OLE commands are sent to the SAP automation server. The server converts them into RFC calls and passes them on to the R/3 System. In the R/3 System, function calls and BAPIs are triggered by business objects. After the data is processed successfully, the business object sends the data back to the desktop program through the SAP automation server.
n Business objects form the basis for communicating on high (user-friendly) network layers. For example, they enable the R/3 System to support the Internet, and desktop programs to be connected.
The goal of SAP’s object-oriented strategy is to integrate objects at a business level rather than on a purely technical level.
Business objects:
. Form the basis of well-defined communication between client / server systems.
. Are business-oriented: there are objects such as “customer", “order” or “employee”.
. Provide business functions (methods). For a “customer” object, for example, there are
“Create customer” and “View customer” methods. These names support clear and therefore
error-free programming.
. Are managed centrally in the R/3 System in the Business Object Repository (BOR).
Business Application Programming Interfaces (BAPIs) are functional interfaces. They use the business methods from the business objects. BAPIs may be addresses within or outside the R/3 System.
For specifications and more information about BAPIs, see the alias “bapi” in SAPNet.
R/3 System technology integrates security mechanisms on several levels:
.Presentation: The SAP GUI software uses check sums to check for integrity each time the R/3 frontend is started. This also recognizes any computer viruses.
.Network / Communication: A firewall and the SAProuter protect the internal network. You can also use additional security mechanisms by integrating external security products such as SECUDE (or Kerberos).
.Application: The authorization concept prevents unauthorized access to data and transactions.
Users must authenticate themselves using their user ID and password. The lock mechanism within the R/3 System also prevents users from making changes to the same data simultaneously.
.Internet: The R/3 System supports current Internet security standards, such as HTTPS.
.Database: Only database administrators can access data in the R/3 database from outside the R/3 System. The database manufacturer's security mechanism is active here.
.Passwords: Preconfigured users exist in clients 000 and 001 after the R/3 System has been
installed. These default users, DDIC and SAP*, have comprehensive authorizations. You should, therefore, change their initial passwords as soon as possible.
The R/3 System provides system administrators with a number of powerful tools to perform their daily tasks.
You can find the following functions in some of the transactions listed above:
. Display server, user, work process, and background job overviews
. Manage locks and updates
. Lock transaction codes
. Create system messages
. Monitor system and cross-system components (see related information)
Using the Computing Center Management System (CCMS) you can monitor, control and configure an R/3 System. You can use the tools to analyze system load and determine the resource consumption of various system components, among other tasks.
CCMS provides you with a number of graphical monitors and administration functions:
. Starting and stopping the R/3 System
. R/3 System monitoring and analysis
. Automatic reporting of system alerts
. Dynamic user distribution
. R/3 System configuration: Editing system profiles (not authorization profiles)
. Processing and controlling background jobs, scheduling database backups
Transaction RZ20 provides a system monitoring structure allowing centralized monitoring of many system parameters and includes links to other analysis tools.
Open interfaces allow the incorporation of other system monitoring tools (including non-SAP tools).
several R/3 Systems can be monitored provided an RFC connection with the other system is possible and configured.
You can create your own system monitor views. These can be used to provide specific people with only those alerts they are interested in.
All threshold values can be easily changed.
The average dialog response time in the last 15 minutes is an example of a typical monitoring attribute.
SAPNet - R/3 Frontend
. SAPNet - R/3 Frontend provides SAP’s extensive database of notes, which users can consult if they have any questions or if any problems occur, before they create a problem message.
. In SAPNet you can find current messages, documentation, tools (QuickSizer) and much more.
You can also use the discussion forums to offer and search for information. Our goal is to make the vast store of customer knowledge available to a wide audience.
GoingLive and EarlyWatch:
. The GoingLive check occurs shortly before an R/3 System is used in production. This test checks that the system meets the requirements set. An EarlyWatch session recognizes performance bottlenecks in an R/3 System before they become a problem, and proposes suitable solutions.
Remote consulting:
. During a remote consulting session, an SAP consultant accesses your SAP System at a time you specify and attempts to analyze and solve the problem in your system from their workstation.
Additional services: Remote upgrade, remote archiving, conversion, migration, security, and euro services.
In SAPNet, you can:
Write system problem messages to SAP
Search the Note database for help
Request developer keys for developers and for SAP standard objects
Use Support Packages to install corrections in your R/3 System
Find up-to-date SAP training information
Allow an SAP employee to dial in to your system for fast problem solving (through a service connection).
An enterprise structure is mapped to SAP applications using organizational units. Organizational units handle specific business functions.
Organizational units may be assigned to a single application (such as a sales organization assigned to Sales and Distribution, or to several applications (such as a plant assigned to Materials Management and Production Planning).
The highest-level element of all organizational units is the client. The client can be an enterprise group with several subsidiaries. All of the enterprise data in an R/3 System implementation is split into at least the client area, and usually into lower level organizational structures as well.
Flexible organizational units in the R/3 System enable more complex enterprise structures to be represented. If there are many organizational units, the legal and organizational structure of an enterprise can be presented in different views.
By linking the organizational units, the separate enterprise areas can be integrated and the structure of the whole enterprise represented in the R/3 System.
An enterprise is structured in the SAP R/3 System according to business functions that must correspond to the functionality assigned to the organizational units.
Examples:
. A Company Code is a unit included in the balance sheet of a legally-independent enterprise. It is the central organizational element of Financial Accounting.
. The Controlling Area is the business unit where Cost Accounting is carried out. Usually there is a 1:1 relationship between the controlling area and the company code. For the purpose of companywide cost accounting, one controlling area can handle cost accounting for several company codes in one enterprise.
. In the context of Sales and Distribution, the Sales Organization is central organizational element that controls the terms of sale to the customer. Distribution Channel is the element that describes through what channel goods and/or services will be distributed to the customer.
. In the context of Production Planning and Control, the Plant is the central organizational unit. A plant is the place of production or simply a collection of several locations of material stocks in close physical proximity.
. A Storage Location is a storage area comprising warehouses in close proximity. Material stocks can be differentiated within one plant according to storage location (inventory management).
Data records that remain in the database for a long period of time are called master data. Master data includes creditors, vendors, materials, accounts, and so on.
Master data is created centrally and can be used in all applications.
Example:
. A customer is master data that can be used in customer requests, deliveries, invoices, and payments.
Master data also has an organizational aspect as it is assigned to organizational units.
Master data has cross-component usage
Examples:
. Customer master data uses the same data for financial accounting and sales
. Customer master records can be assigned to the following organizational units:
company code
sales organization
distribution channel
division
When creating a customer master record, you enter:
. Shared data on the client level
. Company code-specific data for each company code
Data on the client level can be used by all company codes. The customer account number is assigned on this level. That means, the same customer has an explicit accounts receivable number in all company codes from a financial view.
If you also have SAP Sales and Distribution implemented, there are additional fields you can maintain. These fields contain information and control data that are necessary for processing the business activities in the Sales area.
Fields for customer master data are divided into Accounting and Sales areas. Address data is used from both areas. In the Sales area, information recorded can be accessed by Financial Accounting and vice versa.
Note:
The structural logic for customer master records/accounts receivable is also valid for vendor
master records/accounts payable.
The material master represents the central source for releasing material-specific data. It is used by all of the SAP Logistics components in the R/3 System.
Integrating all of the material data in one single database object means that the problem of data redundancy is not an issue. The stored data can be used by all areas, such as purchasing, inventory management, materials planning, invoice verification, and so on.
The data contained in the material master is required, for example, by the following functions in the SAP Logistics component:
. Ordering in Purchasing
. Updating movement of goods and managing the physical inventory in Inventory Management
. Posting invoices in Invoice Verification
. Processing sales orders in Sales
. Planning requirements, scheduling work in Production Planning and Control
The structural logic that applies to vendors and customers is also valid for material master records.
Transactions and documents :
When creating an order for a customer, you must take transport agreements, delivery and payment conditions, and so on, with business partners into consideration. To avoid re-entering this information each time for every activity related to these business partners, relevant data for the activity from the master record of the business partner is simply copied.
In the same way, the material master record stores information, such as the price per unit of quantity,and stock per storage location that is processed during order entry. This concept is valid for processing data for each master record included in the activity.
When performing each transaction, applicable organizational units must be assigned. Assignments to the enterprise structure in the document are generated in addition to the information stored for the customer and material.
The document generated by the transaction contains all relevant pre-defined information from the master data and organizational units.
A document is generated for each transaction carried out in the R/3 System.
Each time you save a quotation request, order, outline agreement, delivery note, Production papers and so on, an output format is generated by the document. This output format represents a message (message type). The message is then placed in the message queue and it can be released for printing or output via EDI, for example. Messages can be released either automatically or manually using a message control program.
You can release individual messages during processing using different communication media, provided that the relevant message types and communication media have been pre-defined. You can define when and how messages are sent for each document type.
A form can be defined for each message type that contains the format for the message.
Message control can be a default value from the master record of the business partner.
The SAP Business Workflow is a support tool that can be used to optimize the execution of activities. Work steps carried out consecutively can be automated to coordinate flow of information.
Workflows enable the electronic workflow management of structured flows that:
. Cover a sequence of activities
. Always occur in the same or similar form
. Involve several departments or people
Workflows control the information process flow according to a predefined model and are especially suited for structured organizations divided into departments/divisions.
Workflows bring the “right” work in the “right” order at the “right” time to the “right” people. This can be achieved through automated mail or through a workflow item.
A workflow item is a workflow task that has itself been generated from a Workflow and appears in the inbox of the office component. If human/manual intervention is required, employees can handle the messages from their electronic mail boxes.
What Workflows are not: E-mail, EDI, ALE, or screen sequence management within a transaction.
Workflows use all these processes.
SAP’S MAJOR INTERNET INITIATIVIES :
SAP Business-to-Business Procurement is a solution for the entire procurement cycle for
maintenance, repair and operations (MRO) items and services.
SAP Online Store lets customers market their products and services on the Internet. To tap the full benefits of SAP Online Store, customers need only a standard Web browser, and the online store provider must implement the functionality of R/3 Sales and Distribution. The business-to-consumer sector represents the classic playground for this type of sales front-end.
Employee Self Service (ESS) functionality gives employees complete control of their own data -they can request vacation at their PCs, enter trip costs, and record working hours using the browser of their company's intranet system.
mySAP.com is a comprehensive, open, e-business solutions environment comprising of portals, industry-specific enterprise applications, Internet applications and services, as well as XML-based technology - all of which combine to enable companies to participate in the Internet economy.
Integration in the “old” economy meant business process integration.
. ERP made SAP R/3 a worldwide standard system
. Since 1996 SAP R/3 has been e-commerce capable
. SAP products incorporated business technology for the future allowing customers to be ready for the future without system change
Integration in the “new” economy requires integration of processes between enterprises.
. Collaboration
. More than working together
. Processes, where many users participate, can be executed simultaneously as one-step-business All products offered by SAP today will be made available with the mySAP.com system. The focal point is the role -specific menus that are used to select the required function. In practice, it looks like this: A user is assigned to one or more roles. Business Scenarios contain various roles. The Business Scenarios reflect functionality used in the different industries.
In addition to the R/3 System, there are the New Dimension Products and industry-specific solutions. All the functions provided on the Solution Map are organized according to Business Scenarios (for example, Purchasing or Employee Self-Service via the Internet).
mySAP.com places the Internet at the center of SAP's activities. It leverages all of SAP's key assets, including its extensive product portfolio, customer base, partner community, and expertise in integrating business processes.
mySAP.com is the collaborative environment providing personalized business solutions on demand.
The Workplace contains links inside and outside a company's boundaries. Links can be made to:
Non mySAP.com components: External systems using open internet standards
. mySAP.com components: Classical and new web-based R/3 transactions (R/3 Standard System, New Dimensions, industry solutions) , Reports (for example, Business Information Warehouse reports with BW 2.0a) , Knowledge Warehouse contents
. mySAP.com Internet services: my.SAP.com Marketplace
. Any Internet or intranet web sites
The mySAP.com Marketplace consists of the four majoe elements:
. Community
. Content
. Commerce
. Collaboration
Marketplace Portal is a place on the Web where communities can exchange goods and services electronically.
Workplace is an application on a users desktop that cooperates with a Web browser and provides a personalized, role -specific view on the entire business world. This business world includes marketplaces, applications, services, and content provided by a company over the Intranet or other companies via the Internet.
0 comments:
Post a Comment