Beruflich Dokumente
Kultur Dokumente
H A P T E R
o create a good IT infrastructure requires some awareness of the business functionality being addressed. The server, storage, and network infrastructure solutions presented in this book are focused on SAP business application software. The choice and conguration of these software components plays an important role for the hardware congurations and ongoing IT operations needed. There are operating system, database, and server platform dependencies of these software solutions that may impact the performance (including sizing), availability, and total cost of ownership of the IT hardware infrastructure. Thus, some introduction to SAPs business software solutions is useful and is presented here as the foundation for the remainder of this book.
description of SAPs business applications, including the well-known classic SAP R /3, however, is not discussed.
The mySAP.com Marketplace is SAPs portal for e-communities. The mySAP.com Workplace is the personalized Internet desktop and middleware layer. The mySAP.com Business Applications are the core business processing components. The mySAP.com Application Hosting element allows organizations to create, test, implement, and host solutions online. The mySAP.com electronic communities and marketplace portals will enable the evolution from traditional ERP to extended ERP, leading to what HP considers a Value Collaboration Network. Finding innovative ways to collaborate with partners is quickly becoming a business requirement for companies that want to stay competitive in the new Internet economy. By building the web-extended enterprise, businesses are able to achieve maximum value from their people and networksby integrating processes with those of their partners and suppliers to better respond to customer needs. The mySAP.com initiative is totally repositioning SAP AG and its business application products to establish a unique business software ecosystem for the interconnected world. The traditional SAP R /3 application software is now one of several business application components in the mySAP.com offering, along with the extended ERP application components, web-enabled marketplaces and workplaces. This new mySAP.com application components model results in increasing server, storage, and network infrastructure requirements, which is the primary focus of this book.
To seamlessly access all of the services now available both internally and on the Internet, some middleware or glue is needed to tie everything together. The mySAP.com Workplace offers a personalized environment to help navigate across all the application functions and services needed to perform business tasks. Because the mySAP.com Workplace is such an essential element to the mySAP.com IT infrastructure, it is also addressed further in this book. Beyond the electronic communities and marketplace portals lies the next paradigm shift, the world of e-services and pervasive computing. This enables business communication with anyone, including people, businesses, other services, or devices (mobile phones, Internet TVs, refrigerators, etc.). Several e-services, including those enabled by SAP applications, can be combined automatically to perform virtually any electronic task or transaction. This new world will also impact the IT department and infrastructure requirements as business services become more modular and can be outsourced more readily, including such things as processing power, data storage, and data mining. However, the tough work, the integration and compatibility of heterogeneous business applications via XML (or other protocol), still lies ahead. The Internet is simply the road or the highway infrastructure; more services and integration are needed for the paradigm shift to fully bloom. Although the mySAP.com Marketplace or the application hosting strategies will play an essential role in the e-services world, these topics are not discussed further.
Spin-offs of the standard SAP R /3 system for special purposes like Strategic Enterprise and Corporate Finance Management, the various Industry Solutions and the mySAP.com Workplace Server. These components consist of a modied SAP kernel and a single relational database; Middleware components like Internet Transaction Server and Business Connector deploy a non-SAP kernel and have no database; Mixed components like Advanced Planner & Optimizer (APO) with an SAP R /3 based kernel, a relational database, and some specialized components, such as the SAP APO liveCache. Enterprises do not have to implement all mySAP.com components. Usually the components that are needed to describe a companys business processes are implemented rst, before branching out to other more specialized solutions. The mySAP.com Workplace and the SAP R /3 system are mandatory, however, for any mySAP.com environment.
Figure 1-1
component systemsit is the central user-management system. One of the primary usability features is Single Sign-On (SSO). With SSO, a user has access to all mySAP.com application components without repeatedly entering his or her user ID and password for authentication. The SSO environment in the mySAP.com Workplace is available based on user ID and password or using X.509 client certicates. All of this information is passed via the mySAP.com Workplace Middleware to the browser, where it remains for the duration of the session (see Figure 1-2). The mySAP.com Workplace
Figure 1-2
Server is only accessed during user login to the mySAP.com environment and when updates are made (ex: favorites or Mini-Apps) in the LaunchPad. Thus, the load on a mySAP.com Workplace Server has a peak during initial logon of the employees (usually the morning hours). For the rest of the day, the mySAP.com Workplace Server will run with low utilization. The mySAP.com Workplace Server is based on a standard SAP kernel with a database and special add-on functions required one time per mySAP.com environment. This mySAP.com Workplace Server supports the full client /server architecture, although a single server box central system conguration is most common. The Drag&Relate service is implemented as a plug-in. As a central component, the mySAP.com Workplace Server should be highly available. Although inconvenient and difcult for users to keep track of all their user names and passwords, direct logon to each mySAP.com application component is still possible if the mySAP.com Workplace Server is unavailable. However, an HA cluster conguration or multiple, replicated servers are strongly recommended.
Workplace Middleware The mySAP.com Workplace Middleware provides a generic gateway between the common Internet protocol and the SAP protocol worlds. The middleware components consist of the Internet Transaction Server (ITS), the Business Connector (BC), and the DCOM Connector. The Internet Transaction Server (ITS) is responsible for transforming SAPGUI screens into HTML pages that can be displayed in a common web browser. SAP ITS is composed of the Application Gateway (AGate), the Web Gateway (WGate), and a common web server. One ITS instance per mySAP.com application component is required. The simplest ITS conguration is a single-host installation with the web server, WGate, and AGate installed on one computer. However, due to security issues, the components should be split between two computers (dual-host installation). The WGate is a small program that runs on the same system as the web server. The SAP Business Connector (BC) converts the proprietary RFC format to the eXtensible Markup Language (XML), the de facto standard for Internet business community collaboration. The Business Connectors convert IDocs to the XML format, supporting BAPI (SAPs Business Application Programming Interface) and ALE scenarios. SAP IDocs can be converted to structured documents with direct access to each single eld. The SAP Business Connector Server contains the mySAP.com Portal Connector that enables bi-directional communication between SAP systems and the Marketplace portal(s). Vendors without an SAP R /3 system who want to sell over the mySAP.com Marketplace need to license the Business Connector from webMethods (www.webmethods.com). In general, the mySAP.com Marketplace is hosted and operated by SAP. However, organizations that want to implement their own need a dedicated mySAP.com Marketplace system. The SAP DCOM Connector integrates SAP components written in ABAP with COM components written in Visual Basic, Visual C++, or Visual J++. The architectures of Internet Transaction Server, Business Connector, and DCOM Connector are further discussed in Chapter 12.
and revenues are immediately updated. SD generates a much higher load than FI because of the many steps to process a business case and the data exchange necessary with other modules. Depending on the functionality in use, high performance load can quickly arise. Prominent examples of such performance hot spots are online availability check and online price nding. To help keep the response times on the remaining application servers acceptable, it is possible to set up a dedicated server to perform the availability to promise (ATP) calculation within the standard SAP R /3 system. SAP Material Management (MM) comprises all activities related with material acquisitions (purchasing) and control (inventory, warehousing). The warehouse management (LE-WM) module manages complex warehouse structures, storage areas, and transportation routes. Stock is always controlled because every material movement is immediately recorded. SAP Production Planning (PP) provides a whole palette of production methods ranging from make-to-order production to repetitive manufacturing/mass production for discrete, batchoriented, and continuous production. This business area is a very complex part of SAP R /3, extensively integrated with SD and MM. The capacity requirements planning (CRP) and material requirements planning (MRP) batch processing runs create a signicant load on the system (hot spots). Related modules are Plant Maintenance (PM), Quality Management (QM), and the Project System (PS). SAP Human Resources The SAP human resources (HR) area includes business processes for personnel administration (applicant screening, payroll accounting, travel expenses, etc.) and personnel development (workforce planning, seminar management, etc.). The business processes associated with the HR modules are very country-specic to adhere to national laws concerning employment, tax, benets, and so forth. Because these laws are subject to change frequently, many enterprises deploy a dedicated HR system separate from the other systems to restrict the downtime necessary when implementing legal patches to the HR department. Other Functions Cross-application modules provide general-purpose functionality independent of specic modules. Applications include, among others, business workow automation, EDI support, document management system (DMS) with an archive link and product data management (PDM) including CAD integration. However, the most essential functionality is Application Link Enabling (ALE). ALE automates the data exchange between independent systems (R /3, R /2 , or external). This way, ALE provides the ability to synchronize the databases of distributed SAP systems. Reecting the customer business needs, the scenarios reach from systems distributed around the globe to physical consolidation in one or a few data centers. ALE is the technological basis for the coupling of mySAP.com components discussed later in this chapter. ALE also can be used for replicating a system to another location. ALE has an impact on the CPU and memory utilization, so it must be accounted for on the server(s) that is sending documents.
10
The SAP Computing Center Management System (CCMS) is a built-in management system. CCMS is delivered with the installation CDs free of charge (no other ERP vendor has a similar solution). However, CCMS is restricted to the SAP and database system management. To manage the complete infrastructure including clients and networks, a management system like HP OpenView is recommended. mySAP.com Industry Solutions SAP also offers a multitude of industry-specic solutions for a wide range of industries such as banking, healthcare, retail, and utilities. The mySAP.com Industry Solutions (IS) consists of modied and extended standard SAP R /3 modules, providing industry-specic business processing functionality. The technical architecture of IS congurations is identical to standard SAP R /3 systems. Because of these modications, Industry Solutions are incompatible to each other and to the standard SAP R /3 system in most cases. Developed by dedicated expert groups within SAP, every IS has its own release schedule. Due to the modications, standard maintenance (hot) packages are not always possible to apply to an IS system. Therefore, a separate setup is often recommended for each Industry Solution, interconnected by ALE to a standard SAP R /3 or other system. However, these systems can be consolidated onto the same physical server, as discussed in Chapter 2. A noteworthy Industry Solution example is mySAP.com for Retail. The business process modeled is the collection of daily sales data from the stores into a companys central headquarters system, called the point-of-sales (POS) upload. Then a replenishment planning calculation (batch process) is made, which generates resupply orders and delivery notes for trucks for stocking up the depleted store inventory. The POS upload and replenishment planning are very intense processes that require special care in the hardware-sizing estimate for the SAP system. SAP R /2 to SAP R /3 Migrations
Currently, there are still several hundred customers worldwide with SAPs rst ERP solution, called R /2. R /2 support has been scheduled to disappear soon, so SAP is encouraging R /2 customers to migrate to SAP R /3 as soon as possible. SAP R /3 4.6C is the last release supported for such a migration, and each migration project can take up to a year.
Multi-Language Support With globalization comes rapid growth of international markets. Nevertheless, even a global business world is still made of nations using different rules, laws, and special characters in their written languages. The variety of languages within a global company, including business partners, is a challenge to a companys organization or IT structure. For example, Germany is blessed with a complex legal system as well as additional unique characters, the famous umlauts , , , . As a German company, SAP understands well that each country has unique attributes.
11
Based on a multi-lingual architecture, the country-specic software is designed around an international core. SAP installations can be found in more than 50 countries, supporting more than 35 native languages including Kanji, Mandarin, and Thai. The different legal aspects are addressed by country versions. Some country-specic functionality is already included in standard SAP R /3, initialized by the country installation program and activated by customizing. These versions are compatible and can be used simultaneously; multiple country versions can be consolidated onto a single system. More country-specic functions are covered as add-on or modication solutions provided by local SAP subsidiaries or even by partners. Add-ons are compatible with the standard country version. The different native languages are addressed by language versions. A multinational enterprise may expect that all employees communicate in English. However, customers expect their name and address to be written with the correct character set. A phonetic transliteration (i.e., Missbach instead of the correct German Mibach) is not always desired. SAP delivers the translation for user interfaces (screens, menus, messages, online help, etc.) on the installation media. However, the translation of the master data, customer developments, printouts, and so on is the responsibility of the customer. Special considerations have to be taken into account when different languages are combined on an SAP system. Each language may require a special character set, represented in socalled codepages. Improper use of codepage settings can lead to corrupt data imported into the database (e.g., batch input, RFC, EDI, ALE, etc.). SAP supports any language combination without limitation as long as the required languages belong to one codepage (see Figure 1-3).
Thai Hebrew
Chinese Korean
Greek
Taiwanese
Bulgarian Russian Danish Dutch Finnish French Italian Norwegian Portuguese Spanish Swedish
English
Japanese
German
Turkish
12
All languages listed in one ellipse can be combined within a standard codepage SAP system. Unfortunately, it is most likely that a language combination required is not supported by a standard ISO codepage. In order to enhance the language coverage per system, SAP provides additional codepages blended from parts of standard ISO codepages (see Table 1-1). Table 1-1 SAP Custom-Blended Codepages
Supported Languages English, German, French, Italian, Danish, Dutch, Finnish, Norwegian, Portuguese, Spanish, Swedish, Japanese a English, Japanese a, Thai English, Japanese a, Greek English, Japanese a, Russian English, Japanese a, Chinese English, Japanese a, Korean English, Japanese a, Taiwanese English, Japanese a, Chinese, Korean, Taiwanese English, German, French, Italian, Danish, Dutch, Finnish, Norwegian, Portuguese, Spanish, Swedish, Greek English, German, French, Italian, Danish, Dutch, Finnish, Norwegian, Portuguese, Spanish, Swedish, Czech, Hungarian, Polish, Slovakian, Rumanian, Slovene, Croatian, Turkish, Greek, Japanese a
SAP Codepage Eurojapan Nagamasa Silk Road Trans Siberian Asian Unication C Asian Unication K Asian Unication T Asian Unication b Diocletian b SAP Unication b
Single Byte Katakana is not supported. These codepages are ambiguous (several characters have been assigned to a single common code point) and need special care when used.
b
The use of SAP-specic blended codepages does not differ from the use of an ISO standard codepage regarding the SAP R /3 system itself. However, the character sets used within the blended codepage must also be available in the peripherals (terminals, printers, etc.). In cooperation with operating system and database vendors, SAP has been preparing for Unicode support for a while. Unicode promises a single codepage for all characters (www.unicode .org). One of the primary reasons Unicode hasnt become commonly available so quickly is because of the lack of peripheral device support.
The SAP system does not use the codepage of the operating system. Therefore, several SAP systems supporting different codepages can be consolidated onto a single server (with the exception of the AS400). However, SAP reads the locales from the operating system. Locales are operating system interfaces for country/cultural conven-
13
tion aware programming, including things like date, time, and currency format. They are responsible for country-specic sorting order and rules for case conversion essential for match code. There are different locales for the USA and Britain, for example. On HP-UX, the most essential locales are installed by default; other operating systems may need a manual installation of the appropriate locales.
In business cases where a mandatory combination of languages is not available as standard or blended codepage, Multi-Display Single Process (MDSP) and Multi-Display Multi-Process (MDMP) installations allow the usage of multiple codepages within a single SAP system. In an MDSP system, the DB server and all application servers run in the same codepage, the front-end changes codepages dynamically. User data input needs to be restricted to the application servers codepage or a subset of it. In an MDMP system, the front-end and the application server both change codepages dynamically. However, the database is created in one particular codepage. A user logged in in another language will get a somewhat strange presentation of this data. The same situation occurs when SAP systems with different codepages exchange master data by ALE. There is a potential risk of corrupting data if users are not well trained to handle this situation. Therefore, SAP supports such systems only on a project by project basis. TIP Golden Rules for Multi-Language Scenarios
Users must restrict data entry to the native characters of the logon language. Use transliteration if necessary (i.e., converting to phonetic rendition using English letters). Do not update data owned by someone else, inform them of the error so they can correct the data AND the procedures. Key elds should only contain characters from the core character set (US-ASCII)this is the only way to really share data globally!
Business Intelligence
The Business Intelligence application area gathers the business application components related to knowledge and corporate nance management to support decision-making processes with the Business Information Warehouse (BW) as the core component. Business Information Warehouse (BW) Todays extended usage of IT systems in the enterprise generates a tremendous ood of information. To leverage the information assets for competitive advantages, visions of the future must be distilled from historical trends, requiring data to be consolidated and analyzed for correlation. SAP developed Business Information Warehouse (BW) as the mySAP.com business application specialized for online analytical processing (OLAP). SAP BW is thus positioned as the data warehouse backbone in the mySAP.com environment. In an online transactional processing (OLTP) system like SAP R /3, all data is stored in a normalized form for consistency. Related data (sums, averages, etc.) are calculated on demand. However, there is one major drawback for the analysis of large data setsall of the data must be accessed for each analysis or report, even when only certain sums are necessary. This causes a
14
heavy performance load on the OLTP system, especially the database server and its I /O system. Therefore, OLAP systems such as mySAP.com BW deploy so-called Infocubes to provide a multidimensional view of data (see Figure 1-4). Infocubes are special data structures where related numbers are calculated in advance to help improve performance. Because the data is no longer in a normalized form, the redundancy causes the SAP BW database size to become very large.
Figure 1-4
In the traditional SAP R /3 system, all tables containing cost accounting data have to be accessed for monthly nancial reports with the CO module. These tables can have millions of records, each which must be independently read. This can take several hours for month-end closing processing. Within this timeframe, online response time degrades due to the massive resource consumption. Reporting with SAP BW is an alternative to ofoad the job from the core SAP R /3 system. Therefore, SAP BW is the rst choice for reporting in a mySAP.com environment. Because the SAP BW system offers so much value, it is often the next business application implemented after the initial SAP R /3 system. Here are some of the primary reasons for implementing an SAP BW system: It provides useful information that is otherwise hidden in SAP R /3 the typical benet of a data warehouse. Those reports that cause performance problems in the SAP R /3 OLTP systems can be ofoaded (on average, 50 60% of the SAP R /3 system resources are used for reporting). It is time consuming and expensive to create new reports within SAP R /3. Once the data is in SAP BW, creating reports is easier and more intuitive. Reporting tools for different SAP R /3 modules look quite different. SAP BW offers a unied approach to reporting. When reporting requirements exist for different systems, data
15
can be consolidated in SAP BW so that it can provide information in a unied and consistent way. For new (future) business processes, there will be no additional SAP R /3 reports delivered by SAP. The SAP BW Business Content, on the other hand, will be enhanced on a regular basis. SAP BW is not only positioned as a reporting tool but as a real data warehouse with all the powerful features normally possible. SAP BW provides predened queries and key performance indicators (KPIs) for benchmarking; business content specic to industries including consumer, retail, and media; and business scenarios addressing areas such as supply chain and business-tobusiness procurement. SAP BW Reporting Agent runs queries in the background to push information onto a personalized mySAP.com workplace, to monitor exceptions and trigger follow-up actions. The geographic information system (GIS) combines the SAP BW data analyses with geographic visualization to identify relationships between spatial information. From a technical point of view, SAP BW uses the same client /server approach as SAP R /3 (leveraging the SAP kernel and database approach). For smaller installations, SAP BW may be executed together with the database on a single server. Larger installations consist of a dedicated database server and one or more application servers. TIP SAP BWA Fast Data Warehouse Implementation
On the SAP R /3 system, a special plug-in is used to extract data into the SAP BW system. Traditional data warehouse projects spend a lot of effort on designing the data extractors for the source system, which is already done for standard reports in the SAP BW and SAP R /3 case. Consequently, an SAP BW implementation can show useful results very quickly. This data extractor interface can then be enhanced if more complex data sets are required, which is one of the reasons why implementing an SAP BW data warehouse is an ongoing process and not a one-time project.
Knowledge Warehouse Management The SAP Knowledge Warehouse Management component provides a central repository for online documentation, training courses, and project-specic documentation. SAP includes the contents of its standard training courses. SAP Knowledge Warehouse Management consists of an SAP R /3 system, one or more Content Servers, and the associated Cache Servers. The SAP R /3 system contains the structures that dene each piece of content, the necessary control data, and the associated user authorizations. The Content Servers contain the actual physical les, such as slides, text, sound, and video les. When a user requests a piece of content, it checks the users authorization and sends the content structure to the users PC. The actual content is then automatically loaded from the Content Server and stored on the Cache Server for improved local access speed, useful for remote sites across a WAN. This architecture provides signicant performance benets in that communication with the SAP R /3 system (which can be located anywhere) requires only minimal bandwidth, while the data-intensive loading of the content takes place locally.
16
Strategic Enterprise Management SAP Strategic Enterprise Management (SEM) is an analytical solution providing a Management Cockpit with Balanced Scorecards and Key Performance Indicators (KPIs). In addition, SAP SEM provides tools for business planning and simulation, stakeholder relationship management, business information collection, as well as business consolidation for legally required consolidation (US-GAAP, IAS, German-HGB, etc.). The SAP SEM system is based on the SAP R /3 kernel and can be integrated with SAP BW, which stores the metadata and application data for all SAP SEM components. However, it comes with an integrated database (SAPDB) to be utilized in case no SAP BW system is available. You can have a centralized or decentralized installation (several SAP SEM systems linked together). There are three different technical installation scenarios for SAP SEM congurations: 1. As a stand-alone application. The SAP BW technology necessary to operate it is included, and data can be extracted or consolidated from one or more SAP R /3 systems. 2. As a data mart linked with an existing data warehouse (SAP BW or a third-party solution). In this case, the data from various SAP R /3 systems is already consolidated on the SAP BW system, so SEM extractors for SAP R /3 are not required. 3. Executed as an application on top of SAP BW using the same hardware and software basis. The data basis is created in the enterprises SAP BW. Thus, SEP SEM extractors for SAP R /3 are not required. Corporate Finance Management SAP Corporate Finance Management (CFM) supports the demands of modern nance management. SAP CFM provides a virtual in-house bank that allows companies to optimize their intergroup payment transactions. In addition, there are analyzers for portfolio performance, market and credit risks together, as well as tools for processing nancial transactions and liquidity planning.
17
Chain Cockpit provides a congurable, graphical user interface for maintenance of extended supply chain models (plants, distribution centers, etc.), factory layout (machines, storage locations, etc.), schedules, exceptions, and so forth. The technical infrastructure for SAP APO is based on the SAP R /3 architecture (an SAP kernel, specialized modules, and a database) with two additional components: liveCache server and optimizer servers. To provide the planning or ATP functions using a database with its data primarily on disk drives is not sufcient when huge amounts of data must be analyzed. In addition to an objectoriented data model, extremely fast access to data is necessary to enable complex real-time scheduling calculations. Therefore, SAP developed a memory-based data structure optimized for SAP APO, called liveCache. Use of liveCache memory resident computing technology enables forecasting, planning, and optimization functions to be executed in real time. The technology basis for liveCache is SAPDB (formerly ADABAS ). This approach grants sufcient performance and avoids slow disk access. SAP APOs liveCache, made feasible by the current availability of highcapacity main memory (RAM) at low prices, almost completely eliminates the need to copy data back and forth between hard disk and main memory during transaction processing (except for high availability). A large SAP APO system consists of one or more application servers, a database server, one separate server for liveCache, and multiple optimizer servers executing the optimization algorithms (see Figure 1-5). For smaller installations, database and application can be consolidated to one server and the optimizer software can be executed at the front-end PCs. For the liveCache, however, a separate server is recommended due to the large memory demand. The biggest challenge for the SAP APO solution is using a liveCache server that can address enough memory with some level of fault-tolerance.
18
Business to Business Procurement The objective of SAP Business to Business Procurement (BBP) is the cost-saving procurement of high-volume, low dollar transactions for C-material or MRO; equipment parts and supplies; as well as services, such as temporary help. BBP enables end users to handle the complete procurement process, from creating a requirement to approving the invoice, all through a web front-end. However, expenditure control is ensured by exible approval routing and tracking features. This way, purchasing personnel are free to focus on strategic sourcing and agreement negotiations. The SAP Catalog is bundled into BBP together with interfaces to other online catalog systems and external content aggregators, such as Aspect, Harbinger, and Commerce One. SAP BBP is based on an SAP R /3 nucleus executed on a dedicated BBP server. An Internet Transaction Server (ITS) is mandatory, a catalog server is optional. Large installations may include multiple ITS servers, one or more SAP BBP application servers, and a dedicated database server. The BBP Mobile Edition, introduced on HPs Jornada handheld PC, provides the possibility to hold a selected part of the catalog, to enter any order, and to transmit the requisition later to the system via the web. An SAP E-Commerce Starter Pack is available as a bundle with the necessary components to quickly have an Internet presence. These include the SAP ITS, mySAP.com Workplace Server, SAP BBP, and a Catalog, plus the SAP Online Store (a web interface to the back-end SAP R /3 SD module). Although these can all be combined on one server for testing, production use would require some segregation for security reasons. Environment, Health & Safety The SAP Environment, Health & Safety (EH&S) component supports all processes required for manufacturing and distributing dangerous goods with regard to international and national legislation. As the transport and shipping of dangerous goods crosses the boundaries of countries and continents, regulations have been synchronized on an international level. EH&S supports the automatic setup of a hazardous substance log according to the German Hazardous Substance Ordinance and provides incident /accident management and the generation of risk assessments, site inspection plans, and standard operating procedures. In addition, EH&S offers functionality for product safety, industrial hygiene, and occupational health, observing the various regulations, laws, and guidelines (Occupational Safety and Health Act 1970). It allows management of all data concerning the properties and composition of pure substances, mixtures, and dangerous goods and substances.
19
components and other mySAP.com business application components like SAP R /3, SAP BW, SAP APO, or legacy systems. SAP BW is used as a data source for SAP CRM, while data is also delivered to SAP BW for consolidation and analysis. SAP APO provides integration to Supply Chain Management and executes Available-to-Promise (ATP) checks. The mySAP.com Workplace Server stores user proles and provides Single Sign-On. However, depending on actual business requirements, not all mySAP.com application components need to be installed.
Figure 1-6
Internet Sales Scenarios The Internet sales component supports Business to Customer (B2C), Business to Business (B2B), and Business to Retailer (B2R) scenarios as well as Employee Self Service (ESS). Customers can congure and order products or services from catalogs via the Internet using the Internet Pricing & Congurator (IPC) component. IPC is designed as a separate component to ensure high access performance. The data is downloaded from the SAP R /3 system to the database of the IPC. Product catalogs are exported to the index-server component for faster browsing and searching of the catalog data. Multimedia data attached to catalogs are stored in the SAP Knowledge Provider (KPro) component. The ITS is mandatory for Internet sales scenarios. The IPC, as well as the index-server component, can be executed on ITS or on separate servers for scalability reasons.
20
Field Sales and Service Support The CRM Field Sales and Service solutions supports sales representatives and service engineers in the eld. A replication mechanism ensures actuality of the local database installed on their laptops or other pervasive devices, such as HPs Jornada product family. The connection is established via a Communication Station (transforming the Microsoft proprietary DCOM calls into SAPs proprietary RFC calls). In addition, the Communication Station can host the CRM Administration Console, used to administer sales data distribution. The CRM Server provides a central data storage and distribution unit. The CRM Mobile Application Workbench provides tools to customize the mobile client software. The Workbench is installed on separate workstations as part of the development environment. Customization information is stored in the CRM repository database to be called by the mobile client. Customer Interaction Center Customers may use the telephone, fax, or email to reach the sales or service representatives. The SAP Customer Interaction Center (CIC) provides SAP standard APIs, SAPConnect, and SAPPhone. The SAPConnect interface in conjunction with SAP workow routes emails from the enterprise mail server to SAPOfce depending on the receivers address. SAPPhone interfaces to a Computer Telephony Integration (CTI) server connected to the private branch exchange (PBX) to provide call center functions. SAPPhone supports various telephony control functions such as initiating and transferring calls, processing incoming call information, and predictive dialing and Interactive Voice Response (IVR). CIC provides interfaces to other call center solutions, extending its functionality with session management, automatic call distribution (ACD), and smart dialing features. Employee Self Service SAP Employee Self Service (ESS) is a set of easy-to-use components that empower employees to view, create, and maintain their data in an SAP R /3 system via the intranet. SAP ESS services extend SAP R /3 functionality to all employees in an organization. SAP ESS enables employees to care about and update their own master data, including name, address, telephone number, and other changes. SAP ESS primarily includes human resources capabilities but also offers logistical, nancial, and ofce functionality.
21
tors for transaction and master data and are essential to enable the tight integration needed. For example, the SAP APO Plug-In, also known as CoreInterFace (CIF), extracts from SAP R /3s complex data set only those objects that are needed in SAP APOs data structures for individual planning and optimization processes. In addition to initial data provision, the SAP R /3 Plug-In also guarantees an incremental supply of relevant data changes to SAP APO. A similar situation applies to the SAP BW Plug-In, which enables the extraction of data from SAP R /3 to build the Infocubes in an efcient manner. The SAP R /3 Plug-Ins are constantly enhanced to ensure that the integration between a given SAP R /3 standard release and the latest version of mySAP.com application components works also for the new functionality. TIP Impact of Extractors
From an IT infrastructure perspective, the important impacts to consider when using SAP R /3 Plug-Ins are the administration and the performance of the source system. SAPs general claim is that any SAP R /3 Plug-In performance impact due to data transfers is offset by reduced reporting requirements. This may not always apply to all systems or operational timeframes, however.
22
and the database tier stores the business data. The SAP system architecture supports heterogeneous environments and provides a high degree of system scalability and exibility. With the introduction of the Internet middleware, SAP systems are now considered to be structured in a multi-tier architecture.
The presentation tier, typically installed on a PC, provides the SAP Graphical User Interface (SAPGUI). The interface is also available through a web browser. In this case, an additional middleware tier transforms the SAPGUI DIAG protocol into HTTP. The access is via TCP/IP and consumes very little network bandwidth. Essential for WAN links, SAP has the lowest network bandwidth demand of all ERP solutions. The application tier executes the business logic, responsible for processing client transactions, print jobs, running reports, coordinating access to the database, and interfacing with other applicationsthe heart of the SAP R /3 system. Because the application logic can be executed in parallel, the workload can be distributed between multiple servers if the system load exceeds the capacity of a single machine. The database stores both the business-generated data and also the SAP application programs, which are loaded into the SAP application servers from the database at runtime. SAP supports several database platforms, so the customer is free to determine the vendor. The database license is part of the SAP contract, although price differences exist between each database. The database software is delivered with the SAP installation media. In general, each SAP system can deploy only one database instance. All business and application data associated with a single SAP system is located in one database. Therefore, the server executing the database is the component with the highest demands on reliability, availability, and performance and ultimately determines
23
the scalability of the entire SAP system. (In theoretical terms, the SAP R /3 system is considered a single server queuing network model.) Depending on system workload and available computing power, the software tiers are executed on separate servers or consolidated onto fewer ones. The presentation tier is always considered distributed to the users workplace. Development and test systems, as well as small production systems, commonly consolidate database and application instances onto one server (central system or two-tier). Large productive installations typically deploy a separate database server and multiple application instances on separate servers for increased scalability. For demo purposes, however, it is possible to combine all of the SAP software tiers onto one laptop computer.
Figure 1-8 SAP R /3 Work Processes and Instances (Spool & Gateway processes purposely not shown)
24
Dialog work processes (D) are responsible for carrying out the online user transaction load. A dialog process can handle the requests of several users. However, a sufcient number of dialog processes must be available to prevent user requests from waiting for a free dialog process. At least two dialog work processes are required for each SAP R /3 instance. Batch work processes (B) carry out background tasks that dont require an online response, for example, data loading from a le. Update work processes (V) perform the actual updates to the database, asynchronously to the dialog and batch processes. Spool work processes (S) support print spooling. More than one spool process is supported per SAP R /3 instance with SAP R /3 release 4.0 and above. The gateway work process (G) provides communication between applications on the same or on an external system (for example, between an SAP R /3 and an R /2 system). Only one gateway process is needed per SAP R /3 instance. The work processes described belong to the SAP application instance, of which there can be many in one single SAP system. There are two additional processes, however, that are unique to each SAP system: The enqueue server (E) and the enqueue table help to manage the locks on database updates to guarantee data consistency as seen from the business process level, even across database transactions. The message process (M) is responsible for communication between the various application servers. Users logging on to the system are assigned (by the message process) to the application server with the lowest load. However, this load distribution mechanism is at logon time only. If an application server goes down, the message process routes the new logon requests to the remaining application servers, providing a basic level of availability. The instance running the enqueue and message work processes (along with dialog, batch, and the others) is called the Central Instance (CI). A conguration with a single central instance executed together with the database on one single machine is called a central system (i.e., twotier system). All of the application instances require the proper functioning of the Central Instance. Because there is only one CI possible per SAP system, it is a single point of failure, and is therefore subject to high-availability solutions described later in this book. Note
If an application server is running more than one SAP instance, there is one dispatcher for every instance but still only one message and enqueue server with the central instance. If the server is running more than one central instance (i.e., multiple SAP systems), there is a dispatcher for every instance together with a message and enqueue server for each central instance.
25
The Database Server Although SAP software is generally independent of any one particular relational database management system (RDBMS), there are some important software architecture concepts that apply to each database. Just like SAP software, each RDBMS has a kernel, or a set of executables that enable the database application to run. These kernel les are compiled specically for each server OS platform. The actual data stored in the database is logically stored as rows within relational tables.
26
Physically, however, the data is stored in data les on disks, congured with a le system or as raw disks (discussed further in Chapter 4). Changes to the data are tracked by a log writer process and stored in log les. At some point, the changes stored in the log les are ushed out to the database data les by the database writer process. Transactions that are being processed but not yet committed as nal are stored in the database rollback (or equivalent) tables or table areas (spaces). If a transaction aborts for any reason, the database can then be rolled back to a consistent state. Data needed for temporary use, such as for table joins, are written onto the disks in temporary storage. To access data quickly, index tables are used to reference the actual data. Often, logs, roll, temp, index, and data areas are each kept on separate disks for performance reasons. More information about the database architecture and its impact on disk systems is covered in Chapter 4. Because the database server stores all the business data, it is the most critical system (including its disks) in any one SAP system. It needs protection from failure, from disasters, and needs to be scalable to avoid performance problems when processing activity increases.
27
companys business processes. A test system is used to verify the development code before going into production. In some cases, a separate integration system is used to consolidate the changes of multiple development teams. Most of the mySAP.com application components (SAP BW, SAP APO, etc.) use development, test, and production systems in the complete landscape.
The minimum recommended conguration is a three-system landscape. However, due to budgetary reasons sometimes a different setup can be chosen. Development and Test /QA systems can be combined on one server. This is the case for the precongured Ready-To-Run packages from SAP, which are more cost sensitive. In any case, it is still useful to have a minimum of three logically separate systems, although there may be fewer physical servers. Figure 1-10 shows a sample landscape with a few mySAP.com application components and two separate SAP R /3 systems. Not all Development and Test /QA systems possible are shown, however. The main point is that there are potentially many different server boxes (and storage) required to support a full mySAP.com environment. TIP System Consolidation for mySAP.com
Scalability is one of the major benets of the SAP architecture. With increased system load caused by a growing number of users, the number of application servers per component can be extended accordingly. Separate servers need to be added for SAP APO (liveCache) and ITS (AGate, WGate) due to architectural and security reasons. Together with the demand for separate development systems for each component, the result is a proliferation of servers, which increases the management effort as well as investments in data center environment (oor space, cooling, electric power, etc.). In the past, it was generally not recommended to run more than one production SAP system per server due to performance issues. Newer, high-performance servers are allowing the consolidation of multiple SAP systems and mySAP.com components onto one single box without impacting the system performance scaling or throughput. This has the potential to reduce the overall hardware management and environmental costs. Several consolidation approaches are described in Chapter 2.
28
'
Figure 1-10
Summary
To implement the IT infrastructure, it is useful to know something about the business applications being implemented. The business applications determine the important data processing requirements, from a performance, availability, and total cost of ownership view. SAP introduced many new business applications as part of the mySAP.com initiative. The rst part of this chapter provided a brief introduction of the major mySAP.com business application components. The terms dened are referenced in the remaining chapters in this book. Here are some of the important points in this chapter: There are many business application components in the mySAP.com solution offering. However, a mySAP.com Workplace system and an SAP R /3 system are the minimum required. Application Link Enabling (ALE) provides the ability to synchronize the databases of distributed SAP systems. ALE is the technological basis for the coupling of mySAP.com business applications. SAP supports multiple national languages. However, some language combinations cause additional administrative effort. The SAP architecture is based on distinct tiers for user interface (presentation), business logic execution (application), and business data storage (database). An additional tier (middleware) is mandatory for browser access to mySAP.com business applications. Because the application logic in any one system can be executed in parallel, the workload can be distributed between multiple application servers. Each system only has one database server, so it is critical for all operations.
Summary
29
Depending on system workload, application and database tiers can be consolidated onto a central system, executed on a single server. Multiple SAP application components can be executed in parallel on one server. Multiple SAP application and database instances can be executed on a single server box, if needed for consolidation purposes. The message and the enqueue work processes are unique in each SAP system. The instance running the enqueue and message work processes is the Central Instance (CI). Theres only one CI possible per SAP system. A typical SAP System Landscape includes at least a development system, a test system, and the production system. This applies to most of the mySAP.com components. Many of the mySAP.com components are based on an SAP basis kernel and a single database instance. Middleware components like Internet Transaction Server and Business Connector deploy a different kernel and have no database.