May 11, 2009

SAP Implementation

Successfully Implementing SAP

Implementing a package can be a traumatic affair for both the customer and the vendor. Get it wrong and the vendor may get paid late or have to resort to lawyers to get paid and tarnish their reputation. For the company the new package may not work the way they expected, be late or cost a more than budgeted for and take management will take their eye off running their business.

Top five factors to consider would be:

1. Set up a Project Board,
2. Secure the resources,
3. Complete the GAP Analysis,
4. Have detailed Cut Over Plans,
5. Train the users.

Taking each one in turn:

The Project Board

The correct set up and operation of the Project Board in my view is major factor in the success failure of the project. The Project Board will consist of the stakeholders, key users and the vendor. The Project Board is part of the governance of the project. The Project Board will meet regularly to ensure that the project plans are created and being executed as planned, moves from stage to stage with all the deliverables being signed off is resourced properly.

The Resources

Three types of resources are absolutely necessary -- end users, change team and technicians.

Early involvement by the end users is absolutely necessary, as they will be the ones living with the system for hopefully many years to come. They will want to feel involved in its implementation. Buy in from the end users of the system is absolutely essential if the system is to have a long and stable life in any organization.

The Change Team will identify the gaps between the package and the business requirements, re-engineer some of the businesses process to cope with the package, train the users to ensure implementation is smooth as possible into the business.

The Technical Team will prepare the systems environment for the package, apply any software fixes from the vendor, implement the software in the best way possible for the organization set up and tune the software for the particular technical environment.

GAP Analysis

A through gap analysis will identify the gaps between how the business operates ad its needs against what the package can can't do. For each gap there will be one of three outcomes which must be recorded and actioned, GAP must be closed and customised software can be developed close the gap, GAP must be closed but software cannot be written therefore a workaround is required, GAP does not need to be closed.

In simple terms:

Gap means small cracks. In SAP world. In information technology, gap analysis is the study of the differences between two different information systems or applications( ex; existing system or legacy system with Client and new is SAP), often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as "the space between where we are and where we want to be." Gap analysis is undertaken as a means of bridging that space.
Actual gap analysis is time consuming and it plays vital role in blue print stage.

Cut Over Plans

Detailed plans need to be developed for cutting over from the old system(s) to the new. Parallel runs of what will happen over the conversion period using test data, convert and watch for a period after wards to ensure nothing unexpected happens.

Train Users

Well trained users will support and defend the system on site. Unsupportive users will continually undermine the system and eventually it will be replaced. Therefore the more effort you put into helping the users master the system early the better.

Difference between the User Exit & Gap analysis.

Both are quiet a different and has a small relation.

User exits are standard gate ways provided by SAP to exit the standard code and we can write our own code with the help of ABAP workbench. its not new functionality which we are trying to build in sap but its slight enhancement within the same code.

Gap analysis is start point of Realization and once blue print is finished we have to find the realization of sap system for client requirement and there will be certain gaps when compared to system fit. Those gaps can be closed either by re-engineering of business process to fit with SAP or we have to use USER exits in case of small deviations or complete enhancements with the help of ABAP to fit with the SAP system.

SAP LANDSCAPE

SAP LANDSCAPE:

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.


DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.

QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.

PROD may have something like a 200 Production.

These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage).

As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV).

The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.


In summary:

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT ---> QUALITY ----> PRODUCTION

DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server:

In the initial stages of any implementation project, You are given
a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server:

Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server:

This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production.

These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.

What is the meaning of "R" in R/3 systems?

R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

1)Presentation
2)Application.
3)Data base server.

May 9, 2009

EVENTS In ABAP

Event Block

•Reporting events

INITIALIZATION
START-OF-SELECTION
GET
END-OF-SELECTION

•Selection screen events

AT SELECTION-SCREEN OUTPUT
AT SELECTION-SCREEN ON VALUE REQUEST
AT SELECTION-SCREEN ON HELP REQUEST
AT SELECTION-SCREEN ON
AT SELECTION-SCREEN ON BLOCK
AT SELECTION-SCREEN ON RADIOBUTTON GROUP
AT SELECTION SCREEN
AT SELECTION SCREEN ON END OF

•List events

TOP-OF-PAGE
END-OF-PAGE
AT LINE-SELECTION
AT PF
AT USER-COMMAND

May 7, 2009

Cross Applications (Definitions)

1 Application Link Enabling (ALE)

The ALE concept supports the construction and operation of distributed applications.
The basic principle is the guarantee of a distributed, yet fully integrated, R/3 System installation.

It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled R/3 Systems.
The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:

• the applications services,
• the distribution services,
• the communications services.

2 Transaction Data

Transaction data is data that results from daily business management processes. Examples of transaction data are purchase order data and accounting data.

3 CO-PA

Abbreviation for Controlling - Profitability Analysis.

4 EDI - Electronic Data Interchange

Electronic Data Interchange is the electronic exchange of structured data (e.g. commercial documents) that is not limited to a single company, but which may take place between business partners at home or abroad who can be using different hardware, software and communication services.

5 Filter Object

A specific instance of the filter object type to which an organizational unit has been assigned, for example, "Plant" ® "Plant 0001".

6 Filter Object Type

A filter object type is a selection criterion in the distribution reference model that specifies the criteria which determine whether a function type can be used several times in a distributed system.

7 Function

A specific instance of a function type in the customer model.

8 Function Type

A function type defines a self-contained process in an application. An example of this is the posting for a movement of goods in inventory management.

9 Function Type, Distributable

A collection of function types which may be grouped together because of the related use of the various function types, and which may be seen as being distinct from other function types.

10 IDoc

Abbreviation of intermediate document (IDoc type )

11 IDoc Type - Intermediate Document Type

An intermediate document type is the structure of the data container used for transporting data from a system to a target system. It is independent of any specific application data.

12 Logical System

A logical system is a system in which different applications are integrated and run using common data. In SAP terms, this means a client in a database.

13 Information Structures

The most important key figures are selected from the mass of data arising from operational applications and are stored in special statistics files known as information structures. These include information on the time period, the characteristics and the key figures. An information structure can be distributed.

14 Key Figures

Key figures represent information that is periodically gathered or evaluated for characteristics (for example, lead time, deviation from schedule, capacity utilization, order stocks, quantities and rejects).

15 Bulk Processing

Several IDocs may be grouped into a packet and processed in a single step. This is called bulk processing.

16 Characteristic

A characteristic is a piece of information that can be used to effect a division in a group of objects, for example, plant, work center, material).

17 Message Type

The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the ORDERS message type is used for purchase order messages.

18 Periods

Periods include days, weeks, months and accounting periods.

19 Item Category

An item category is a classification that distinguishes between various types of item in, for example, an order (e.g. cost-free items, standard items). The way that processing is controlled depends on the item category.

20 Serialization

If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialization mechanism must be used that can spot "overtaking" and report it.

21 SOP

Sales & Operations Planning.

22 Customer Distribution Model

The customer stores the exact distribution of functions across his various systems in the customer distribution model. The logical systems and message flows are specified here, possibly based on defined listings.

23 Distribution Reference Model

The reference model is included in the standard delivery from SAP. It specifies which functions can be distributed and how, and which data is exchanged between the fucntions. The customer uses the reference model as the basis for his customer distribution model .

24 Workflow

A workflow is defined as a sequence of processing steps (work item ). There may be branching points within this sequence.

A workflow has a container. This holds the parameters used in the processing steps.
In order to terminate the processing steps of a workflow, an event is triggered. The parameters are passed from the current step to the workflow container.

The workflow manager checks which processing step should be called next. For example, if an 'Idoc read' step is terminated and a parameter indicating an error is passed, a step will be started that initiates manual processing.

An error will also cause an event to be triggered If a function module has been called directly. However, in contrast to the situation with a workflow, it does not cause a workflow step to be terminated, but rather an error workflow is started.

25 Work Item

A work item represents the run-time environment for a standard task that is defined once in the system. A standard task contains a method that can be used for processing a specific object.

Complete SAP Modules:

Complete SAP Modules:
SAP Basis
• Remote Function Calls (RFC)
• Common Program Interface Communications (CPI-C)
• Electronic Data Interchange (EDI)
• Object Linking and Embedding (OLE)
• Application Link Enabling (ALE)
• Customising (BC-CUS)
• Client Server Technology (BC - CST)
• Network Integration (BC - NET)
• ABAP Programming and Runtime Environment (BC - ABA)
• Basis Services/ Communication Interfaces (BC - SRV)
• Computing Center Management System (BC - CCM)
• Upgrade General (BC - UPG)
• Change and Transport System (BC - CTS)
• Operating System Platform(BC - OP)
• Database Interface, database platforms (BC - DB)
• Front End Services (BC - FES)
• ABAP Workbench (BC - DWB)
• Documentation and Translation Tools (BC - DOC)
• Security (BC - SEC)
• Controls and Control Framework (BC - CI)
• Business Management (BC - BMT)
• Middleware (BC - MID)
• Computer Aided Test Tool (BC - CAT)
• Ready to Run R/3 (BC - BRR)
• Authorisations System Monitoring with CCMS Workload Alert Monitor
SAP Hardware
• AS400
• AT&T
• Bull
• Compaq Digital
• HP
• IBM
• Sequent
• SNI
• Sun
SAP Database
• Adabas D
• DB2 for AIX
• DB2/400
• Informix
• MS SQL
• My SQL
• Oracle
• Sybase
Operating System
• AIX
• HP UX
• MS Windows NT OS/400
• Sinux
• Solaris
• Unix

ABAP/4 Programming
• SAP Script
• Business Workflow (BC - WF)
• ALE
• EDI
• Business Connector
• Business Server Pages
• Internet Application Server
• Mercator Report Painter
• Dialog Programming
• Repository Information System
• Menu Painter
• ABAP 00
• IDOCS
• LSMW
• Smartforms
• EBP
• ASAP methodology
• ALV reporting
• Report writer
• ABAP Query
• Data Dictionary
• Screen Painter

SAP FI (Financial Accounting)
• Accounts Payable (FI- AP)
• Accounts Receivable (FI - AR)
• Asset Accounting (FI - AA)
• General Ledger Accounting (FI - GL)
• Special Ledger (FI - SL)
• Funds Management (FI - FM)
• Travel Management (FI-TM)

SAP TR (Treasury)
• Cash Management (TR - CM)
• Treasury Management (TR - TM)
• Loans Management (TR - LM)
• Funds Management (TR - FM)
• Market Risk Management (TR - MRM)
• Information System
SAP CO (Controlling)
• Cost Centre Accounting (CO - CCA)
• Overhead Cost Controlling (CO - OM)
• Activity Based Coding (CO - ABC)
• Product Cost Controlling (CO - PC)
• Profitability Analysis (CO - PA)
• Material Ledger (CO - ML)
SAP EC (Enterprise Controlling)
• Consolidation (EC - CS)
• Profit Center Accounting (EC - PCA)
• Executive Information System (EC-EIS)
• Business Planning and Budgeting
SAP IM (Investment Management)
• Investment Programmes
• Investment Measures (orders/products)
• Appropriation Requests
• Corporation Wide Budgeting
• Depreciation Forecast
• Automatic Settlement of Fixed Assets
• Information System
SAP HR (Human Resource)
• Personnel Administration
• Benefits Administration
• Compensation Management
• Recruitment
• Travel Management
• Personnel Development
• Organisational Management
• Training and Events Management
• Personnel Planning
• Time Management
• Incentive
• Wages
• Workflow
• Internet Scenarios
• Payroll
• Information System
SAP SMB
• SAP SMB
SAP BW
• Data Warehousing
• BI Platform
• BI Suite - Business Explorer
• Development Technologies
• ODS Structures
• Info Cube
• Design Build
SAP IS (Industry Solutions) / SAP for Industries
• Aerospace & Defence
• Retail
• Consumer Products
• Defence & Security
• Insurance
• Industrial Machinery & Components
• Logistics Service Providers
• Mill Products
• Higher Education & Research
• Automotive
• Banking
• Telecoms
• Chemicals
• Pharmaceuticals
• Life Sciences
• Mining
• Media
• Public Sector
• Service Provider
• Utilities
• Healthcare
• Oil & Gas
• Postal Services
SAP SD (Sales and Distribution)
• Master Data
• Sales
• Special Business Transactions
• Shipping
• Billing
• Credit Control
• Sales Support
• QM in SD
• Internet
• Transportation
• Foreign Trade
• Sales Information System
• Electronic Data Interchange
SAP Logistics Information System
• Sales Information System
• Purchasing Information System
• Inventory Controlling
• Production Planning and Control Information System
• Plant Maintenance Information System
• Project Information System
• Retail Information System
SAP QM - Quality Management
• Planning
• Inspections
• Control
• Notifications
• Certificates
• Test Equipment Management
• QM-IS
SAP MM (Materials Management)
• Logistics (General)
• Logistics Information System
• Purchasing
• Inventory Management
• Invoice Verification
• Inventory / Valuations
• Materials Planning
• Workflow
• External Services Management
• QM in MM
• Warehouse Management
SAP PM (Plant Maintenance)
• Preventative Maintenance
• Service Management
• Maintenance Order Management
• Maintenance Projects
• Equipment and Technical Objects
• Structuring Technical Systems
• Maintenance Planning
• PM Processing
• Work Clearance Management
• Internet Scenarios
• Customising
• Information System
SAP CS (Customer Service)
• Service Processing
• Service Contracts
• Controlling
• Workflow in Customer Service
SAP PP (Production Planning)
• Make to Order (CR)
• Make to Order (PIR)
• Repetitive Manufacturing
• PP for Process Industries (PP - PI)
• PP - Processes
• Sales and Operations Planning
• Master Planning
• Capacity requirements
• KANBAN
• Production Orders
• Product Cost Planning
• Assembly Orders
• Plant Data Collection
• Information System
SAP CA (Cross Application Components)
• Application Link Enabling (ALE)
• SAP Business Workflow
SAP PS (Project Systems)
• Basic Data
• Operational Structures
• Project Planning
• Approval
• Project Execution and Integration
• Information System
• Work Breakdown Structure
mySAP SRM (Supplier Relationship Management)
• Self Service Procurement
• Service Procurement
• Plan Driven Procurement
• Spend Analysis
• Strategic Sourcing
• Catalogue Content Management
mySAP SEM
• Business Consolidation (SEM-BCS)
• Business Information Collection (SEM-BIC)
• Business Planning and Simulation (BW-BPS)
• Corporate Performance Monitor (SEM-CPM)
• Stakeholder Relationship Management (SEM-SRM)
mySAP CRM (Customer Relationship Management)
• CRM Enterprise
• Field Applications
• E-Commerce
• Interaction Center
• Channel Management
• Industry Specific CRM
mySAP Product Life Cycle Management
• Document Management
• Enterprise Content Management
• Engineering Change Management
• Classification
• Basic Data for Process Manufacturing
SAP SCM (SAP Supply Chain Management)
• SCM Process and Business Scenarios
• SAP Advance Planning and Optimization (SAP - APO)
• SAP Forecasting and Replenishment
• SAP Inventory Collaboration Hub (SAP - OCH)
• SAP Event Management (SAP - EM)
• SCM Basis

SAP Netweaver
• SAP Masterdata Management
• Portal Content
• Information Integration
• Process Integration
• Life Cycle Management
• Knowledge Management
• SAP Visual Composer
• SAP Business Intelligence
• People Integration
• Application Platform
• Security
• SAP Web Application Server
• SAP Business Information Warehouse
• SAP Enterprise Portal
• SAP Solution Manager
• SAP Mobile Engine

May 2, 2009

ABAP Performance Standards

Following are the performance standards need to be following in writing ABAP programs:

1. Unused/Dead code

Avoid leaving unused code in the program. Either comment out or delete the unused situation. Use program --> check --> extended program to check for the variables, which are not used statically.

2. Subroutine Usage

For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:

This is better:
IF f1 NE 0.

PERFORM sub1.

ENDIF.

FORM sub1.
...
ENDFORM.

Than this:

PERFORM sub1.

FORM sub1.
IF f1 NE 0.
...
ENDIF.

ENDFORM.

3. Usage of IF statements

When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND , place the mostly likely false first and for the OR, place the mostly likely true first.

Example - nested IF's:

IF (least likely to be true).

IF (less likely to be true).

IF (most likely to be true).
ENDIF.
ENDIF.
ENDIF.

Example - IF...ELSEIF...ENDIF :

IF (most likely to be true).

ELSEIF (less likely to be true).

ELSEIF (least likely to be true).

ENDIF.

Example - AND:

IF (least likely to be true) AND
(most likely to be true).

ENDIF.

Example - OR:

IF (most likely to be true) OR
(least likely to be true).

4. CASE vs. nested Ifs

When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.

5. MOVE statements

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.

MOVE BSEG TO *BSEG.

is better than

MOVE-CORRESPONDING BSEG TO *BSEG.

6. SELECT and SELECT SINGLE

When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to three times.

7. Small internal tables vs. complete internal tables


In general it is better to minimize the number of fields declared in an internal table. While it may be convenient to declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.

For example:

Instead of this:

data: t_mara like mara occurs 0 with header line.

Use this:

data: begin of t_mara occurs 0,

matnr like mara-matnr,
...
end of t_mara.

8. Row-level processing and SELECT SINGLE


Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple SELECT-SINGLE commands on a non-buffered table (check Data Dictionary -> Technical Info), you should do the following to improve performance:

o Use the SELECT into to buffer the necessary rows in an internal table, then

o sort the rows by the key fields, then

o use a READ TABLE WITH KEY ... BINARY SEARCH in place of the SELECT SINGLE command. Note that this only make sense when the table you are buffering is not too large (this decision must be made on a case by case basis).

9. READing single records of internal tables


When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should:

o SORT the table

o use READ TABLE WITH KEY BINARY SEARCH for better performance.

10. SORTing internal tables

When SORTing internal tables, specify the fields to SORTed.

SORT ITAB BY FLD1 FLD2.

is more efficient than

SORT ITAB.

11. Number of entries in an internal table


To find out how many entries are in an internal table use DESCRIBE.

DESCRIBE TABLE ITAB LINES CNTLNS.

is more efficient than

LOOP AT ITAB.

CNTLNS = CNTLNS + 1.

ENDLOOP.

12. Performance diagnosis

To diagnose performance problems, it is recommended to use the SAP transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and programs.

13. Nested SELECTs versus table views

Since releASE 4.0, OPEN SQL allows both inner and outer table joins. A nested SELECT loop may be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should either create a view in the data dictionary then use this view to select data, or code the select using a join.

14. If nested SELECTs must be used

As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:

Use this:
form select_good.

data: t_vbak like vbak occurs 0 with header line.
data: t_vbap like vbap occurs 0 with header line.

select * from vbak into table t_vbak up to 200 rows.
select * from vbap
for all entries in t_vbak
where vbeln = t_vbak-vbeln.
...
endselect.

endform.

Instead of this:
form select_bad.

select * from vbak up to 200 rows.

select * from vbap where vbeln = vbak-vbeln.
...
endselect.

endselect.

endform.

Although using "SELECT...FOR ALL ENTRIES IN..." is generally very fast, you should be aware of the three pitfalls of using it:

Firstly, SAP automatically removes any duplicates from the rest of the retrieved records. Therefore, if you wish to ensure that no qualifying records are discarded, the field list of the inner SELECT must be designed to ensure the retrieved records will contain no duplicates (normally, this would mean including in the list of retrieved fields all of those fields that comprise that table's primary key).

Secondly, if you were able to code "SELECT ... FROM FOR ALL ENTRIES IN TABLE " and the internal table is empty, then all rows from will be retrieved.

Thirdly, if the internal table supplying the selection criteria (i.e. internal table in the example "...FOR ALL ENTRIES IN TABLE ") contains a large number of entries, performance degradation may occur.

15. SELECT * versus SELECTing individual fields

In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performace gains can be substantial. For example:

Use:

select vbeln auart vbtyp from table vbak

into (vbak-vbeln, vbak-auart, vbak-vbtyp)

where ...

Instead of using:

select * from vbak where ...

16. Avoid unnecessary statements

There are a few cases where one command is better than two. For example:

Use:

append to .

Instead of:

= .

append (modify ).

And also, use:

if not [] is initial.

Instead of:

describe table lines .

if > 0.

17. Copying or appending internal tables


Use this:

[] = []. (if is empty)

Instead of this:

loop at .

append to .

endloop.

However, if is not empty and should not be overwritten, then use:

append lines of [from index1] [to index2] to .

Background Job Processing

Understanding Background Job Processing

In background processing, the SAP System automatically runs any report or program in the specified time or time intervals. The background processing system starts your job and runs the program(s) that you specify. Afterwards, you can check whether your job was executed successfully and display a log of any system messages.

Features:
* Running a report in the background does not tie up the SAP sessions you are currently working with.
* You can shift the execution of reports to the evening or other periods depending on load on the SAP System.
* Background processing is the only way you can execute long-running jobs.

Background jobs run in a special type of work process—the background work process—that is different from dialog work processes in two ways:
* A dialog step has a run-time limit that prevents users from interactively running especially long reports. By default, the system terminates any dialog step in a transaction that exceeds 300 seconds. Although the limit can be changed (in the system profile parameter rdisp/max_wprun_time ), it is always in effect for dialog work processes. No such limit applies to background work processes.
* Background work processes allocate memory differently than dialog work processes so that background work processes can become as large as they need to in allocated memory to allow for processing large volumes of data.

The clients 000, 001 and 066

Understanding the clients 000, 001 and 066


Clients 000, 001 and 066 are standard clients that are pre-delivered by SAP. These clients are not supposed to be used in development, quality and production environments.

Client 000 is basically used as working client only when you do support pack upgrade or ABAP load generations (SGEN) and implementing additional languages, etc. Otherwise, client 000 should not be used as a working client. The same applies to client 001. But the only exception with 001 is, with Solution Manager, 001 will be your working client. You will do all configurations and obtain support from SAP through this client. With other Systems like BW and CRM, this client (001) will not be a working client. Two standard users (SAP* and DDIC) are defined in the clients 000 and 001.

The client 066 is used only for EarlyWatch functions (Monitoring and Performance). The user EarlyWatch is delivered in client 066 and is protected using the password SUPPORT. This password needs to be changed for security purposes.

How to change Transport request from Released to Modifiable

Step 1: Go to SE38 – Execute Program RDDIT076.  Step 2: Give your released requests number and execute again. Step 3: After executing, yo...