Distributed systems

Development                                                  Q/A – Test                                      Production

I -> Transports ---à                                        I-> Transports --à                           I

Clients                                                            Clients                                                  Clients                   

110-Configuration                                          210-Q/A –Testing                             410-Production

120-Sandbox                                                   220-Training no.1

130-Development –Test                                 230-Training no.2

The development environment is where the majority of implementation work takes place. It should have a minimum of three clients: sandbox, configuration, and development testing. The sandbox client is used to test configuration ideas and theories at any time. It is also where all system design work should take place. Once you are comfortable with your configuration solution in the sandbox client, you can re-create your solution in the configuration client. The configuration client is also called the transport client. This is where all final configuration that needs to be moved through the testing cycle, and finally into production, takes place. The configuration client has automatic transport recording turned on [covered in the next section, “Transports”]. Ideally, the configuration client should also be your “golden” client that is, no transactions or testing should take place in this client. Once a transport has been created, it should be moved to the development-testing client. Once the configuration is in the development-testing client, the transport should be thoroughly unit-tested. Usually, only unit testing is conducted in the development system, some projects may conduct integrated [string] testing in this client as well. Once the transport has been successfully tested, it is ready to move into the QA environment. Normally, all transports for particular projects or rollout phases are moved into QA at one time.

The QA environment is where all final testing is conducted prior to moving transports to the production environment. Normally, this is where integration [end-to-end business process] testing and user acceptance testing [UAT] is conducted. There is a minimum of one QA client that is used to conduct testing. There may be additional clients you can use in the QA environment to test different transaction for testing, data conversion, and user sandboxes. Once the entire project solution has been tested successfully in QA, it is ready to move to production.

The production environment is where all day-to-day business activities occur. This is the client that all end users use to perform their daily job functions. There is usually only one production client per SAP installation. It is very important to move into production only transports that have passed all testing cycles. Inadequately tested or understand changes to the system can lead to production system issues. These production issues generally occur if you, as the configurator, do not fully understand the integration points between the modules effecting the change and [generally] FI/CO. production issues can be as catastrophic as the company’s inability to ship goods or post cash.

A new approach to system customization

For many years, organizations struggled with extremely long project timelines in order to develop information systems that met their specific requirements. Most IT projects used structured development methodologies that were very unforgiving in terms of missed or changing business requirements. The development of custom code was a tedious process requiring armies of programmers as well as significant end-user involvement.

The project timeline was also extended because often business owners didn’t know what they wanted until they saw it, which led to what is commonly referred to in the IT industry as analysis paralysis in projects. Upon project completion, large IT staffs needed to be retained to maintain the custom programming and to update the programs with requirements that may have changed during the long development cycle. Numerous companies also had departmentalized systems, which oftentimes did not share information. These numerous departmental system became “Information Silos” within the organization. Separate systems per function and/or department can lead to inconsistent results.

These disparate and numerous systems also created the need for many distinct interfaces between systems that were not designed to talk with each other. Despite the interfaces, the systems would never be integrated. Worst of all, accounting systems were updated with financial data by means of batch programs. Batch programs are run on a fixed schedule, generally daily, weekly, or monthly, which means that the data is never current.

To fulfill the new requirements of information systems, a new breed of software systems, now called Enterprise Resource Planning [ERP]systems, was created, ERP systems provide a single source of data with designed integrated between different functional modules [for example, Accounting, Sales and Distribution, Materials Management, Production Planning, and so on] to talk full advantage of an enterprise’s stored information. A common set of source code was needed for these packages so that changes in technology could be rapidly introduced via upgrades to the understand the client concept in this light when you are just starting out in SAP. In the standard project setting, there will be three environments: the development environment, the quality assurance/testing environment [QA], and the production environment. Within each environment there are different clients that are used for specified purposes.

Distributed systems [ALE]

Some SAP installations have more than one productive instance of SAP running at any one time. SAP provides a tool called Application Link Enabling [ALE] to allow two different SAP systems to share data with each other.

User menu

You can create your own user menu with your commonly used transactions. Then you can assign this personalized menu to your user ID in your user preferences. If you are developing a system to be used by a client site, user menus can also be set up for a group of users with limited access to the system. This includes users who might not use the system often enough to remember the menu paths they need to use to execute a transaction.

Jobs

A jobs is similar to a batch input session in that it executes a standard SAP transaction in the back ground, usually at night, jobs are set up and scheduled for processor-intensive transactions and reports. If you do not correctly specify the print parameters on a print request, your print request will be stored as a job. This means that when you start a print transaction from within SAP and you do not check the print immediately box the print request is stored in the print spool as a job and has to be manually released through the job manager to print. Your company’s basis group usually manages jobs.

Batch Input Session

A batch input session stores values to be entered during a normal system transaction. Some transactions automatically create batch input sessions because of the heavy processing required. To complete the transaction, you must select the batch input session and then run the batch input session manager. Most data transfer programs are executed via batch input sessions. A good way to think of a batch input session is to think of it as a macro. A macro uses standard functioning to input data that is stored to automate a repeated task. You can use transaction code SM35 to run and manage batch input sessions.

Parameter ID

A parameter ID is a special identifier given to some fields in SAP. It can be stored in your user profile with its default values. For example, the parameter ID for company code is BUK. A user who is responsible only for entering document is company code 1000 would set up the BUK parameter ID with a default of 1000 In their user profile. By specifying this parameter ID, the user  will never have to enter the company code in a transaction the company code will automatically default to 1000. Parameter IDs are stored in the Technical Information field box. An explanation of how to display the Technical Information box is included in “Finding the Table to Configure”.

Transaction code

A transaction code [tcode] is generally a four-character code [later versions of SAP have introduced longer tcodes] that is entered in the command field on the toolbar. Transaction codes are not case sensitive’s. SAP provides two ways of executing a transaction, via a menu path and a transaction code. It is important to note that, unless you are at the main SAP menu or the main menu of a sub module such as G/L, it is necessary to include /N or /O before the transaction code in order to execute a transaction in a different module. For example, if you are currently in the Cost Center a accounting module in the screen used to create cost centers and you want to enter a G/L document [transaction code FB01], you must enter /NFB01 or /OFB01 to execute the transaction. /N takes you back to the root menu and then execute the transaction code. /O opens up a new session and then execute the transaction code. Remember, you can have only six open sessions of SAP at once.

Variant

A variant is a specific setting that is saved when a program is executed. Some data input screens allow you to save and execute variants. Variants can also be created in the program maintenance screen of the program. Using variants is a good way to save time because they allow you to execute a routine transaction without having to enter all of the parameters needed by the program every time.

Menu path SAP, like most client/server applications, utilizes menus to allow a user to navigate through the system. When we refer to or list menu paths in the book, we are starting from the root menu and progressing down through each menu hierarchy to reach the needed transaction. When we refer to only the menu path, we are talking about the implementation Guide [IMG] menu path. SAP application menu paths are explicitly noted.

SAP Terms

Now that you understand how the different SAP products break down, you’ll need to become familiar with some common terms that explain different parts of the SAP system you will see the following terms used throughout the below references.

ABAP [ABAP/4] ABAP/4 stands for Advanced Business Application programming/4^th Generation language. SAP is coded in ABAP.ABAP is also used for extensions and extra programs that are written for SAP. ABAP is similar to other fourth-generation language and is a first cousin of COBOL, without the JCL.

Basis generally, SAP projects, and the folks who work on them, are lumped into two groups technical and functional. The technical system includes ABAP, Data base administration, transport management, security, authorizations, and so on. Basis is a subset of the technical group and consists of the folks who take care of all technical components of the system except for ABAP. The basis group, in more common terms, consists of your project database administration [DBA s] plus more.

SAP Products

SAP has slowly evolved in terms of its product offerings. You will still come across SAP consultants who refer to the SAP system as SAP R/3, but as SAP’s product offerings have broadened, the reference to R/3 has been dropped. R/3 initially referred to SAP’s only product, the Enterprise Resource Planning [ERP] system, but today SAP offers a host of products of which SAP ERP Central Component is the heart [often referred to as SAP ECC]. The SAP ERP Central Component is where the original ERP [R/3] functionality is housed, and it is where all the data processing/business process transacting takes place. This above references is focused on the Financial [FI] and Controlling [CO] modules found in SAP ECC version 6.0.

The goal of these references is not to teach you how to implement one specific solution but to teach you how to configure the SAP system. Attempting to cover every possible configuration scenario you might encounter would be an impossible task, but after reading the book, you will be able to apply what you have learned and configure your system based on your business requirements.

SAP has now introduced many areas of functionality from its data warehouse often referred to as its business warehouse [BW] or, now more correctly, business intelligence [BI] which includes a host of reporting tools and functionality, not limited to business objects.

SAP also offers the following software sites.

Supplier Relationship Management [SRM]

Strategic Enterprise Management [SEM]

Catalog Content Management

Compliance Management for SOA

Supply Chain Management [SCM]

Product Lifecycle Management

Customer Relationship Management [CRM]

Introduction to SAP

SAP stands for systems, Application, and Products in data processing. Founded by five German engineers in 1972, SAP is the world’s leading provider of business software, offering applications and services to companies of all sizes across more than 25 industries. SAP offers an integrated system, which means that all SAP modules are designed to share information and automatically create transactions based on various business process.