Once all the processes and components that make up the SAP system are known, we can see how all these pieces come together to form a whole client/server Web AS system. The starting point is a server system (hardware point of view) with the required memory, disks, network controller cards, and operating system. On this first server, add the relational database management system with its corresponding database processes. At this moment, you have the database server. The database is, of course, installed on the disks connected to this computer server. Now, add basic Web AS services (work processes).We have added a printer to this system to get a connection between the SAP spool work process and the host spool system. Generically, we link the update and the enqueue work processes to the database. But, as stated in previous sections, there is a database interface component within the dialog and the background work processes that can directly access the database, too. At this moment, you have the database server and the SAP central instance (because it has all the basic services). From a software client/server point of view, the services provided by the central instance make up an application server.
When the central instance and the database are running together on the same machine, which is usual, this is known as a database server with central instance, or simply a database server. In the SAP naming convention, a service is a process (such as the message process) or a group of work processes. It is a software concept, and the component that offers those services is called a server. The software components that request those services are known as the clients. The clients can be servers at the same time. Because there already is a dispatcher process and dialog work processes, it is possible for presentation servers (clients) to connect to this system (server). It is also possible to configure the directly attached printers or network printers to the SAP system. This would be a centralized system or a two-tier client/server configuration. Include additional work processes (service types) on a different server, which make up an additional application server. Now it is a SAP Web AS three-tiered client/server configuration. A complete SAP system is the set of clients and server components that make use of or are assigned to the same database. The connection between the presentation process and the dispatcher is the one that makes the transition between the presentation and application servers. The update process is the one that makes the separation between the application and database servers.
SAP Business Framework
The SAP Business Framework is the architecture that SAP put in place for supporting seamless integration of components, thus making SAP products a set of integrated products that can be installed, managed, and upgraded independently, without affecting other systems' components. Business Framework was technically supported on integration technologies such as BAPIs and ALE as well as the underlying technology of the solid Web AS multitier client/server architecture, the standard communication protocol such as CPIC and RFC, the openness and independence of hardware platforms, or the portability of the applications based on the ABAP language. Business Framework architecture was based on the technological concepts of components, interfaces, and integration:
Client/server is a software concept that first appeared in the late 1980s but that was deployed seriously and with a solid technical foundation in the early and mid-1990s. As a software concept it included "service providers" (servers) and "service requesters" (clients). A specific program could act at the same time as provider and requester. So, for instance, the SAP Web AS typical application server was a service provider for the users (SAP GUI) but a service requester of the database server. The main point of this type of computing was the separation of the user-oriented tasks, the execution or application tasks, and the data management tasks. These three types of tasks are normally matched with the terms presentation, application, and data levels. With client/server computing, it was possible and easier to distribute the workload of computer applications among different and cooperating computer programs or processes. From the very beginning SAP Web AS systems were designed this way so that there was a presentation level (user interface or presentation server), an application level (application server), and a database level (database server).
The software services provided by client/server computing would communicate among them using predefined interfaces over standard communication protocols (for instance, remote SQL calls from the application server to the database server over TCP/IP). With the emergence of the Web, the ability to have a simple Internet browser as the user interface, and the development of ITS back in 1996, the classical three-tiered client/server architecture became a multitier system.
SAP Web AS multitier client/server architecture
The classical three-level or the multilevel client/server configurations offered a series of advantages that are still available in mySAP system environments:
RFC: A Key Communication Middleware
RFC stands for "remote function calls" and is the standard programming interface long used by SAP for making remote calls among programs located on the same or on different systems. This means that a function that is developed in one system could be remotely called by another program. Web AS has a function library where programmers can find useful subroutines to reuse in their ABAP programs. This library has the function modules organized in groups like arithmetic functions, character string manipulation functions, controlling functions, and so on. You can access this function library from the function builder transaction SE37. These functions can be documented as well as each of the interface parameters helping the programmer to understand how to call these functions from ABAP.
From release 2 SAP Web AS supports RFCs to call a function module from another Web AS system, from an R/2 system, or from external systems. This was a key factor in the current Business Framework strategy. The first types of RFC were synchronous RFC, allowing a program to call a function in another Web AS system and get the results online. SAP provided libraries for non-SAP environments in order to call these function modules, like C and C+ + libraries in the supported SAP operating systems, including Windows, UNIX, Linux, OS/390, or OS/400. There has been also support for DLL and ActiveX in Windows or Java-RFC. For transactional environments SAP developed the tRFC (transactional RFC) in release 3.0. In this case the program calls the remote function and the system guarantees the delivery of the call, recalls in the case the partner system is not available, and assures that the function is executed only once. tRFC is asynchronous but if the partner system is available is executed as soon as possible.
With release 4.6B a new extension of tRFC was made, and it was called queued RFC (qRFC) in order to define an order and queue the calls that are executed one after the other. The queue can be in the source or in the target system. This qRFC can be downloaded to versions 3.11 of R/3.
With release 3.0 SAP started the object-oriented approach. From that release there is a Business Object Repository containing the SAP Business Objects like a purchase order or a customer. These business objects have attributes or properties and methods like Create, Release, and others depending on the object type. The methods of the Business Objects are implemented mainly as function modules, so they can be called in an object-oriented view or directly like function modules. Some of these methods were flagged by SAP as stable methods. This means that SAP guarantees that the method interface (exportimport- table parameters) will not change in two major SAP releases. These stable methods are called BAPIs (Business APIs). BAPIs were announced for general availability in release 3.1G. There are more than 1100 BAPIs in release 4.6. SAP has published the BAPI catalog, allowing the developer community to develop external programs with a guarantee in the developing investment, because the program will work even if customers change their SAP release. These BAPIs were used also by SAP internally to develop initial load programs faster than the old batch input method and to integrate the different SAP applications with these BAPI calls.
IDOC history is related to the EDI interface. EDI stands for Electronic Data Interchange and was one of the first efforts to define a flat text format for business documents, like invoices or sales orders so that they could be exchanged between systems and applications. SAP supported EDI from the very beginning, since release 2. The major problem to support EDI was that actually there are several substandards in EDI, like EDIFACT, ANSI X-12, ODETTE, and others (Europe, America, Automobile Industries) and there is the need for translating your internal documents to the substandard your partner speaks. In order to support this, SAP defined its own standard representation of the document, known as IDOCs or intermediate documents. Then the customer should choose certified software that understand the IDOC format and translate it to the EDI substandard chosen, which is also in charge of sending and receiving them. You can see a list of certified software third parties at www.sap.com/csp.
At the beginning SAP defined IDOCs mainly for the type of documents used in EDI. Then SAP realized that these IDOC could be used directly if the partner system was another SAP system, so it started to use it to send and receive documents between SAP systems as well. IDOCs from older releases can be interpreted by newer SAP releases and new releases can adapt the IDOC release depending on the target system. This was the foundation of ALE.
ALE stands for Application Link and Enabled, and the idea was to be able to integrate applications in different SAP or non-SAP systems in a loosely coupled way. Imagine the scenario.
We want to have a central Web AS system with all the financial and controlling in our headquarters and one Web AS system in our sales office in Houston, another Web AS system in our factory in New Jersey. So it is possible to have different Web AS systems, autonomous but integrated between them. When, for example, a relevant financial document is created in our sales office, this is sent to our central financial system automatically. This could be useful for different reasons:
Some large organizations have subsidiaries in different continents and perhaps it makes little sense for support reasons to have the Web AS system for the plant in Singapore in the U.S. headquarters. This could be useful from the network point of view; the users are connected to their system in Singapore and not via expensive lines to the central system with the bandwidth required for an online user. Other reasons are organizational in nature (in some cases they are nearly autonomous business units) or relate to performance: to distribute the load. This is why SAP developed the ALE inside R/3. With ALE you can define which systems participate in your ALE network (in the ALE world a system is an external system or a client of an Web AS system) and which data should be sent from one system to the others.
In ALE it is possible to distribute master data (customers, materials ...), document data (purchase orders, financial documents, invoices ...), and also customize data (entries in selected customizing tables). In the case of distributing master data, you can define one system where you maintain centrally the materials and then distribute the creation or changes to the other systems. But the system can be defined also with ranges and filters (for example, to define centrally some materials but allow the plants to have their own range for internal use, or even define a bidirectional maintenance in which changes in any system are replicated to the other). This is defined in the ALE model.
ALE started using IDOCs in order to send and receive documents between systems (SAP or non SAP). In the case of SAP systems, the IDOCs are sent usually by tRFC to the other system. If the partner is a non-SAP system, an IDOC translator can be used that understands IDOCs and speaks with the other system via EDI messages, or uses file or CPIC interface.
When the BAPIs appeared the ALE also included BAPIs for the new scenarios. For example, the Central User Administration scenario uses only BAPIs to exchange the user definition and roles between Web AS systems. Now this is used between mySAP components. ALE uses workflow for error resolution and has tools for supporting multiple restore situations and systems synchronization. ALE is the foundation for what SAP called Business Framework. At the beginning the ALE scenarios allowed integration between the different logical systems in the ALE network, but not the whole integration if all the components were in one central system. You have to look at each scenario's documentation to know which restrictions apply compared to a central system. Then the first complete application that was decoupled was the HR module. With HR, all the possible interfaces between HR and the different applications were supported in ALE. In this way it's possible to have a system with the HR module integrated with other SAP systems.
One of the advantages of this approach is that you can change the release of one of the components of the Business Framework without changing the release of the others. Perhaps the customer needs the new release for the HR module due to legal reasons but can maintain the financial system in the same release without involving the FI people in the upgrade project. In the case of HR this has other advantages, like improved security in an isolated system.
With mySAP, the Business Framework and its Internet evolution is even more used than before. With mySAP CRM, E-procurement (B2Bp), APO, SEM, and other systems integrated between them and the Web AS backends, it is possible to change the release of one of them without disturbing the others.
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.