Download
summary of the sap ecosystem and functional software n.
Skip this Video
Loading SlideShow in 5 Seconds..
Summary of The SAP Ecosystem and Functional Software PowerPoint Presentation
Download Presentation
Summary of The SAP Ecosystem and Functional Software

Summary of The SAP Ecosystem and Functional Software

213 Vues Download Presentation
Télécharger la présentation

Summary of The SAP Ecosystem and Functional Software

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Summary of The SAP Ecosystem and Functional Software

  2. Review • Last time – we looked at various topologies for implementing enterprise systems • This time – we will look at how SAP provides a “fairly” complete infrastructure for • System configuration • System development and customization • System testing • System deployment

  3. Lecture Structure • It’s a high-level overview of SAP / R3 • Breadth not depth at this point • I’ll breeze through many screens to demonstrate navigation through the SAP GUI

  4. Course Simulations • We will use various separate SAP instances throughout this course • Global Bike configuration • ABAP • Web Dynpro • And possibly some sort of integration tool

  5. Introduction (Roles and Responsibilities) • This is my taxonomy • Developers customize SAP • Administrators designate roles to other users and tune the system • Responsible for security administration • Responsible for deployment activities • Implementers configure SAP • Third party integrators interface SAP with other software packages • And of course, the users

  6. SAP Architecture (Introduction) • Keep in mind that • this is the most complex software package that you have ever seen • It’s been around for a very long time and has remained backward compatible • It’s written in and developed by Germans

  7. SAP Architecture (Introduction) From BC ABAP Programming

  8. SAP Logical Architecture (1) • Underneath, there is a database and a database management system • SQL Server, ORACLE, MaxDB, and HANA are supported • The R/3 Basis is really an operating system within an operating system • The Basis is it’s own virtualization system too • There is no user contact with the underlying operating system

  9. SAP Logical Architecture (2) • ABAP workbench is the development environment with which you write, debug, and test ABAP applications • ABAP is the programming language of SAP and resembles COBOL • An R/3 application has special meaning • It’s an ABAP program • It’s has a well-defined structure

  10. SAP Logical Architecture (3) • Our presentation component will be the NetWeaver program that you used in IS 365 • All user interaction is through the presentation component

  11. SAP Layers • SAP is built using three layers

  12. SAP (Database Layer) • SAP interacts with other RDMSs • (ORACLE, SQL Server, DB2, INFORMIX, etc… • However, the database layer stores everything for the entire SAP “instance” • ABAP code • User accounts • EVERYTHING!

  13. SAP (Application Layer) • Application servers run ABAP applications • We typically have many of them • The server group is load balanced • A message server communicates state information between application servers • More later

  14. SAP (Presentation Layer) • It’s NetWeaver • We will not get into the topic yet but there is much that can be done with Netweaver • The presentation layer interacts with the application layer in a very structured way • As you complete screens, you perform dialog steps” • Control passes back and forth between the presentation layer and application layer

  15. SAP (Presentation Layer)

  16. Application Server (Structure) • Application servers are responsible for two things • Dispatching work across a network of application servers • Performing work (work processes) • Execute dialog steps • Gateways communicate with other application servers • Shared memory is used to persist application context

  17. Application Server (Illustration)

  18. The SAP Programming Model (1) • This discussion is based on the cardinal rule that the database can never be left in an inconsistent state or a transaction be lost • But we might have thousands of users concurrently recording transactions • You should see the synchronization problem

  19. The SAP Programming Model (2) • Executing an application (transactions) is done by completing one or more dialog screens • Each screen is called a dialog step • Each dialog step corresponds to a database Logical Unit of Work LOW • ABAP provides constructs to bundle several DB LUWs into a SAP LOW

  20. THE SAP LUW

  21. Structure of a Work Process

  22. Types of Work Processes • Work processes have different types • Dialog work process operate with user requests to execute dialog steps • Update processes execute database updates that are parted of a bundled SAP UOW • Background processes are executed without user interaction • Enqueue processes are used for locking • Spool processes are used for printing and archiving

  23. Summary • An applicationprogram has one or more screens which are processed by the screen processor of a work process • The processinglogic of a program gets data from screens, processes it, and returns data to screens

  24. Screens • Unlike the VB form with which you are familiar, the ABAP screen is much more structured • Two types • Screens have a definition and flow logic created using a screen painter • Selectionscreens and lists provide a simplified way to select data for a list or report

  25. ABAP Program Structure • ABAP programs execute within individual dialog steps • A program is divided into processing blocks

  26. ABAP Program • Declare global data here • Create selection screen definitions • Dialog modules, event blocks, and subroutines are all processing blocks • We will delve into the structure more later

  27. Types of ABAP Programs (1) • A program’s technical attributes and capabilities are determined by its type • Type1 programs are executable programs • They do not need to be controlled by screens • Type 1 programs are often called reports • Type M programs are controlled through screen flow logic and must be started from a transaction code

  28. Types of ABAP Programs (2) • TypeF programs are function modules containing reusable functiond • TypeI programs are includes • Includes just break up programs into smaller chunks.

  29. Administrator (Overview) • Performance • User and role management • Deployment of test and production systems

  30. Administrator (Tuning) • Significant system management and performance tuning is necessary in large enterprises • We can tune and monitor memory management • In some enterprises we have HTTP and other services • System monitoring

  31. Administrator (User Groups) • User groups allow user administration to be distributed among several administrators • Groups are also used to perform “mass maintenance” on several users • Transaction code SUGR to show user groups

  32. Administrator (Roles) • Access to resources is granted through roles • Roles are hierarchical and have different types • Single roles contain authorization data • Composite roles are created using multiple composite roles, which are then assigned to users • SAP ships with predefined bundle of standard roles (single and composite)

  33. Administrator (Roles) • Transaction code PFCG to view roles • We are in role Z_ABAP

  34. Administrator (Roles) • Roles

  35. Administrator (Deployment) • SAP manages deployment of system changes from development to training to test to production • Other system types can be defined • The process is called transport (more in a moment)

  36. Administrator (Other) • Data must be archived • System performance needs to be monitored and tuned

  37. Implementer (Introduction) • In my opinion a formal definition gets a bit fuzzy here • We use the IMG to configure (customize) the system • We use the SAP system itself to create all sorts of “master data” • Production schedules • You did some of this in IS 365

  38. (IMG) Introduction • IMG is short for Implementation Guide • It contains all of the actions to implement, control and document the SAP system • General Settings • Enterprise Structure • Financial Accounting • And all of the functional sub systems

  39. (IMG) General Settings • Country settings (countries in which we do business) • Currencies in which we do business • Public calendars containing holidays, workday configuration • Once configured these are either hard to change or cannot be changed

  40. (IMG) (Illustration)

  41. IMG (Enterprise Structure) • Here, we describe our organizational structure to the SAP system (Organizational Units) • It’s not easy to change the organizational structure once it has been created

  42. IMG (Enterprise Structure – Parts) • Financial accounting • Controlling accounting • Logistics • Sales • Materials Management • Plant Maintenance • Production • HR

  43. Definement and Assignment • Configuration of the enterprise structure (and many other components) requires a two-step process • Definement • Create organizational structures • Assignment • Assign those organizational structures to other organizational structures

  44. Definement and Assignment (Examples) • You define company codes and assign them to a company • You define credit control areas and assign them to a company code • There are hundreds of these • We will get through many of the core functions in this course

  45. IMG – Business Configuration (BC) Sets • In this class, we will “globally” configure system elements using the “SAP Reference IMG” • In practice, we use BC sets • BC sets can be created for specific processes • These BC sets can be deployed separately • SAP provides numerous BC sets for industries and industry sectors • We can create our own BC sets too

  46. BC Set (Implementation) • Types: • Simple BC sets contain configuration data • Hierarchical BC sets contain other BC sets • The hierarchy can be nested • Attributes • Name • Type • Release information • Change information (person, date time)

  47. SAP Transport (1) • In SAP, instances (clients) are provisioned into different types • Development (created from production backups) • After development is complete, the system is copied to a “test / QA” system • Then to a “consolidation system” • Finally, the test system is deployed to the production system • Custom intermediate systems can also be created

  48. SAP Transport (2) • The Transport Organizer is the tool used to mange transport of BCs and development code from one instance to another • Transaction code for the Transport Organizer is SE01 • STMS for the Transport Management System

  49. SAP Development • THIS IS A MONSTER • Unlike most development environments you are used to, all code (programs) are stored inside of the SAP instance itself • Code is deployed using transports mentioned previously • There are different types (categories) of code

  50. SAP Development (Interface) • The ObjectNavigator is the entry point into the ABAP objects (programs) (Transaction code SE80) • The ABAP Editor is used to create, edit, test, and debug ABAP applications • The Data Browser lets you look at the SAP tables from the SAP / ABAP API • … And Much More