Questions ???
Use Transaction code to access the Logon screen of SAPNet - R/3
Frontend (OSS)The R/3 System can be tailored to meet customer
specific business requirements in the following ways: Customizing:
Setting up business processes and function menus with the
Implementation Guide (IMG). Personalization: Changes to the global
display characteristics of fields (pre-determining some input
values, removing other input fields from certain screens), and
user-specific menus. Modification: Customer changes to R/3
Repository objects (also called SAP objects). When updating to a
new R/3 Release, the corresponding SAP objects may need to be
adjusted to conform to the customer's modifications. Before R/3
Release 4.5 A, these "modification adjustments" are made manually
using upgrade utilities. As of R/3 Release 4.5A, this process is
largely automated by the Modification Assistant. Enhancement:
Creation of customer-defined Repository objects that are
referentially included in R/3 Repository objects through user
exits. Customer Development: Creation of customer-defined
Repository objects. All customer-defined Repository objects are
created and maintained using the ABAP Workbench.
All Repository objects that are created and maintained through
the ABAP Workbench are recorded to change requests. Change requests
provide the basis for transporting changes to downstream systems
for testing, training, or inclusion in the production R/3 System.
The Workbench Organizer provides the means for users to document
each new development or change to a Repository object. It is
recommended that all changes be accompanied by a description of
their purpose and status. Change requests specify which developers
may work on the development project. All developers on the project
have access to all the Repository objects assigned to the project
change request. This structuring facilitates teamwork. After
completion of the project, the change request is released, and a
new full version of each object contained in the change request is
written to the version database. If a Repository object is
subsequently corrected, a new version is again stored in the
version database. Displaying and comparing different versions of
Repository objects allows for a better understanding of development
activity, and enables older versions to be reconstructed. When a
Repository object is assigned to a development project, only
project participants may make changes to that object. Locking the
object during development, prevents unauthorized access, and
ensures that no unintentional changes are made to the object. The
Workbench Organizer is used to create, manage, release, and analyze
change requests for development. To access the Workbench Organizer,
from the R/3 initial screen, choose Tools -> ABAP Workbench
-> Overview -> Workbench Organizer, or Tools ->
Administration -> Transports -> Transport Organizer ->
Environment -> Workbench Organizer (or use Transaction SE09).
All Workbench change requests that belong to a specific user are
displayed according to a set of standard selection criteria.
Selection options include user (owner), request type, request
status, and date. The area Global Information gives you a quick
graphical overview of the status of transported change requests and
repairs.
The Workbench Organizer displays a tree structure containing all
the change requests for a specific user. This structure enables the
user to explore the contents of change requests and tasks. The
change request records the changed Repository objects or table
entries. The actual contents of a change request (the changes) are
stored in a task corresponding to a specific developer. With the
Workbench Organizer, authorized users can: Create a new change
request Add additional developers to a change request (by creating
new tasks) Change the owner of a change request or task Additional
Workbench Organizer functions facilitate change request management.
Examples include: Setting a standard (default) change request so
developers are not prompted for a change request number Setting the
type of sort sequence for the display of all requests Merging
change requests The three types of Workbench change requests are:
Transportable, Local, and Unclassified.
At the start of a development project, the project leader
creates a change request and assigns the project team members to
it. The system assigns a number (K9, for example, DEVK900001) to
the change request, and creates a task for each project team
member. If a project team member assigns a change to the change
request, the object is recorded in that member's task. A task thus
records all the changes which a project team member has made for
that project. As project team members finish their work on a
project, they release their tasks. When all project team members
have released their tasks, the project leader releases the change
request. A change request thus contains all the changes that are
created in a project. All ABAP developers must be registered with
SAP Software Change Registration (SSCR) which is accessed through
the Online Service System (OSS). Only registered developers may
create or modify Repository objects. As a result of the
registration process, each developer is assigned an access key. The
access key is saved on the developer's system. The access key is
associated with the developer's logon ID and the R/3 System's
license number. The developer is prompted for the access key on the
initial attempt to create or change a Repository object. Developers
only need to enter each access key once in the R/3 System. The
system will not request the access key during subsequent attempts
to create or modify Repository objects. There two locking
mechanisms when Repository objects are being modified: 1. The
editor program which works with the enqueue work process to ensure
that only one user at a time can modify an object in the system,
and 2. The Workbench change request which ensures that the
developer modifying the object is assigned to a valid task within
the Workbench change request. When a Repository object is assigned
to a task within a Workbench change request, that object can only
be modified by the developers associated with that change request.
This prevents users outside the development team from making
changes to any of the objects in the change request. An object list
is associated with each task. Each user working on an object has a
corresponding entry in the object list of their task. The object
list records which users have actually edited the object. Objects
may be manually entered in the object list of a task or request.
These objects are not automatically locked if they are entered
manually. To manually lock the object, in the Workbench Organizer
Initial Screen, choose Request/task -> Object list -> Lock
objects.
After the development tasks are completed, a change request is
released so that the changes can be transported to another R/3
System. Releasing a task or change request requires: The person
releasing the task or change request must be its owner and have the
correct authorization Objects in the task or change request are (or
can be) locked Releasing a change request requires that all tasks
were documented and released. A released task can no longer be
modified, but additional tasks can be created to modify the objects
in the released task. A released task cannot be deleted. However,
if the task is empty, it is deleted when the change request is
released. Releasing a transportable change request records a
version of all the objects included the change request, and then
exports the objects (copies the objects from the database to an
operating system file). Releasing a local change request records a
version of the objects in the change request, but does not export
them to a file at the operating system level.
When a change request is released, a new version of each
Repository object in the change request is written to the version
database, which thus contains a complete change history of all
Repository objects. In addition to the versions created
automatically by the release of change requests, users can also
create temporary versions at any time. To do this, in the
maintenance transaction for the Repository object, choose Create
version. You can access version management from: Repository Browser
(Transaction SE80) Workbench Organizer (Transaction SE09) Display
and maintenance transactions for all Repository objects. In the
Version Overview, the active and temporary versions are displayed
in the development database, and versions saved as a result of
released change requests are displayed in the version database. The
version database resides in the development system. Versions cannot
be transported between R/3 Systems. If the development system is
removed from the system landscape, all versions in the version
database are lost.
An overview of transports and repairs can be accessed easily
from the right-hand side of the initial screen of the Workbench
Organizer (Transaction SE09). The traffic-light icons indicate
transport errors (red) or unconfirmed repairs (yellow). To access
the overview of transports, under Global Information choose
Transports. A hierarchical list is displayed with released
transports and their transport steps, grouped according to target
system. The success of individual transport steps is indicated by
the color of the entry, the comment, and the return code. When the
cause of an error has been identified and corrected, the request
attribute can be changed to Error corrected by pressing the Error
corrected icon at the top of the Display Transport screen of the
Workbench Organizer. This action is recorded in the action log. If
you choose Error corrected without correcting the change request
error, a message is displayed indicating the error has not yet been
analyzed. In the display, you can delete transports with the
attributes Error corrected or Tested. To display transport logs, in
the Workbench Organizer display screen choose Goto -> Transport
logs. The Object Directory is a catalog of all Repository objects
in the R/3 System, including all R/3 standard Repository objects
that are delivered with R/3 Systems, and all Repository objects
created by the customer using the ABAP Workbench. Attributes for
each Repository object are assigned by the system. With the
appropriate authorization, users can modify the development class
and person responsible for the object. (To protect Object Directory
entries, only user DDIC can modify all attributes except original
language). To modify Object Directory entries from the Workbench
Organizer choose Tools -> ABAP Workbench -> Overview ->
Workbench Organizer -> Goto -> Tools -> Object Directory
(or select the expert tools icon). Some Repository objects may be
generated automatically by the system as a result of Customizing
activities. In the Object Directory, these system-created objects
are flagged as "generated". Modifications to SAP objects or to
objects that are not in their original system (such as objects
being modified in the quality assurance system after having been
created in the development system), are termed "repairs". In the
Object Directory, these objects are flagged as "repaired". For each
entry in the Object Directory, the primary key is comprised of the
following fields: program identification (PGMID), object type, and
object name. The PGMID is usually R3TR. Other PGMIDs are R3OB and
LIMU. Examples of object types are PROG (ABAP programs), DEVC
(development class), VIEW ( table view), FORM ( ABAP form), COMM
(command file), and CHD0 (change document).
R/3 Repository objects should only be changed in the R/3 System
where the system identifies them as original objects. An object is
the original in only one system, the system where it was created.
All other systems may only contain copies of the object. This
ensures that changes are only made to Repository objects in the
development system. When a Repository object is transported to a
downstream system, it exists there as a copy. When changes are
necessary, to prevent inconsistencies between versions, you should
change the original in the development system and transport it to
the other systems. Changes to copies are only made in exceptional
cases and are termed repairs. In all customer systems, including
the customer's development system, SAP-delivered Repository objects
are copies. Repairs to SAP objects are termed modifications. The
system change options selected when setting up the Workbench
Organizer (Transaction SE06) control which Repository objects can
be modified in the R/3 System. Only in the development system
should be set to permit changes to customer-developed objects and,
if necessary, SAP objects. Objects saved as local objects are not
transported.
A distinction is made between two types of development tasks:
development/correction (changes in the original system) and repair
(changes in a system other than the original system). When changing
an object that is not an original, the system prompts the user to
specify Object for repair. For the object specified, a repair flag
is set to prevent the object from being overwritten by imports into
the system. Thus, the object is locked exclusively for the task of
type repair. Unlike changes to original objects, repairs do not
allow access to other developers listed in the same change request.
To enable another developer to edit the object, make that person
the owner of the repair using the Change owner function in the
Workbench Organizer. When a task of type repair is released, the
system prompts the user to indicate whether or not the repair
should be confirmed. Confirming a repair deactivates the repair
flag for the objects contained in the repair, which are then no
longer protected from being overwritten by imports. A repair task
that was released without confirmation, can be confirmed later by
selecting the task in the Workbench Organizer, and then choosing
Request/task -> Confirm repair. The development class of the
Repository object determines whether the change request type is
transportable or local. If the assigned development class has a
valid transport layer, a request of type transportable is used.
Otherwise, a local change request is used. Before changing
SAP-delivered Repository objects (performing a modification), you
must not only be registered as a developer in SAP Software Change
Registration (SSCR), you must also register each SAP object you
intend to change. Registering the object gives you an access key
which you apply only once to the object. When performing a
modification, the Workbench Organizer prompts you for a change
request in the same way that it does when you make changes to
customer-owned objects. Since the object is owned by SAP and not
the system itself, the change will be saved to a task of type
repair. All SAP objects have SAP-defined development classes. All
new customer Repository objects must be assigned to a
customer-created development class. Development classes are used to
group objects in the project and transport them along the same
transport route. After the repair task or transportable task is
complete, the developer releases the task, and the lock on the
object is transferred to the change request. Confirming the repair
removes the repair flag. At the end of the project, the change
request is released. This releases all locks and records a version
of the changed objects (both SAP and customer objects) in the
version database.
Before changing SAP-delivered Repository objects (performing a
modification), you must not only be registered as a developer in
SAP Software Change Registration (SSCR), you must also register
each SAP object you intend to change. Registering the object gives
you an access key which you apply only once to the object. When
performing a modification, the Workbench Organizer prompts you for
a change request in the same way that it does when you make changes
to customer-owned objects. Since the object is owned by SAP and not
the system itself, the change will be saved to a task of type
repair. All SAP objects have SAP-defined development classes. All
new customer Repository objects must be assigned to a
customer-created development class. Development classes are used to
group objects in the project and transport them along the same
transport route. After the repair task or transportable task is
complete, the developer releases the task, and the lock on the
object is transferred to the change request. Confirming the repair
removes the repair flag. At the end of the project, the change
request is released. This releases all locks and records a version
of the changed objects (both SAP and customer objects) in the
version database. Registering in SAP Software Change Registration
(SSCR) is required for all developers and all SAP objects that are
to be modified. After registering a SAP object in a system and
applying the access key, the key is stored in the database and
further changes to that object do not require SAP Software Change
Registration. The key will remain valid through R/3 Release
updates. The following SAP objects are excluded from SAP Software
Change Registration: matchcodes, database indexes, buffer settings,
customer objects, precorrections, and Repository objects generated
by Customizing. What are the benefits of the SAP Software Change
Registration (SSCR)? Rapid error correction and high system
availability: All changed SAP objects are recorded by SAP, so that
the SAP Customer Service can identify potential error situations
with a system and thus increase the availability of the customer
R/3 System. Development reliability: The need to register any
modification of an SAP object greatly reduces the possibility of
changing an object unintentionally and increasing the reliability
of development. Making upgrades easier: Having only registered
modifications speeds up the process of merging modifications and
new SAP standard functionality. If a new version of an SAP object
is imported into the customer system, as part of an upgrade,
adjustments must be made to the repaired SAP object. (Modifications
are also considered repairs.) This may involve making the same
customer changes to the new SAP object. Before the upgrade, all
open repairs must be confirmed and released. This check is
performed by the upgrade check routines of the tool PREPARE. To
adjust the ABAP Dictionary during an upgrade, use Transaction SPDD.
To merge all other Repository objects, use Transaction SPAU.
Modification upgrades are not automatic. Customers must decide
which development efforts and modifications they wish to keep,
bearing in mind that the new SAP functionality may quite possibly
make the modification unnecessary.
Customizing is the process of setting up the business
transactions required by a particular enterprise in R/3.
To illustrate the the kinds of business transactions an
enterprise may need to customize in R/3, consider the example of an
international company which sells printers wholesale. To enable
customers at a particular outlet to place a wholesale order for
printers, the company must customize R/3 to recognize its own
particular structure of sales organizations, distribution channels,
and so on. Most Customizing is client-dependent and affects only a
particular client. However, some changes such as pricing conditions
are client-independent and affect all clients in an R/3 System.
Customizing changes are usually saved to multiple tables through
table views. A view is a virtual table which presents data that is
physically stored in multiple tables. SAP provides different
implementation tools for Customizing and development. For
Customizing: The Implementation Guide (IMG) is the main Customizing
tool. Once you decide which R/3 modules you require, the IMG
automatically generates a hierarchical list of steps (or
Customizing transactions) for Customizing. The Customizing
Organizer (CO) (Transaction SE10) records Customizing changes in
change requests (of type CUST) which can be released to the
transport system for export to other systems in the R/3 System
landscape. For development: The ABAP Development Workbench provides
access to development tools, which cover the entire software
development cycle. These tools may be used both for
customer-specific development and SAP enhancements of R/3
applications. The Workbench Organizer (WBO) (Transaction SE09)
records ABAP Development Workbench changes in change requests (of
type SYST), which can then be released to the transport system for
export to other systems in the R/3 System landscape. The CO and the
WBO are completely integrated in the Transport Management System
(TMS).
A Customizing transaction is a transaction for setting table
entries in Customizing. To use a Customizing transaction, you do
not have to know about the technical aspects of where and how a
business object is held, or which transactions are used to access
and change which fields in which tables. After a change is made
using a Customizing transaction, it should be saved. When a client
is configured to automatically record changes, the system settings
are automatically saved to a change request managed by the
Customizing Organizer. If the client is not configured for
automatic recording of changes, the Customizing change is saved but
the change is not recorded in a change request. All Customizing
transactions in the IMG also allow entries to be saved to a change
request manually. Automatic recording of changes is a client change
option and is maintained in the client maintenance table T000.
Customizing change requests usually contain changes or additions to
table entries in tables or views. The change request also contains
the select statements of the table entries to be exported. The
select statement includes the key value for the table entry. When
exported, this change request will extract the current table entry
values from the source database. Because of the dynamic accessing
of table entries during Customizing, both client-specific and
client-independent Customizing are not protected from being
overwritten. Table entries are locked while the Customizing
transaction is being used, but they are unlocked as soon as the
changes are completed and saved to a change request. For additional
information see OSS notes 1916 and 84052. To activate the logging
of changes to Customizing tables, use program RSTBHIST in the ABAP
Editor, or, from the main R/3 menu, choose Tools -> Business
Engineering -> Customizing -> Tools -> Table History (or
use Transaction OY18). Generally, all objects are transported to
the target system in the state in which they exist in the source
system. Objects transported from the source system overwrite
objects in the target system that have the same names. Objects are
deleted in the target system if they do not exist in the source
system.
The Customizing Organizer and the Transport Management System
are designed to work together. During normal Customizing work: The
project leader first defines a change request and the subsidiary
tasks for all users involved These users perform Customizing
changes that are recorded in the change request After Customizing
is completed, users must release their tasks The change request can
then be released from the source system for export to the operating
system The transport to the target system takes place on operating
system level
An export of a change requests copies table entries from the
database to a file at the operating system level. The key values
stored in the change request determine which data is copied. A
Customizing change request can be released and copied to a
transportable change request. It can no longer be modified, but is
not exported to the operating system level until it is released.
After releasing Customizing change requests, remember to verify the
success of the export using transport logs and action logs, which
are accessed from the Customizing Organizer (Transaction SE10).
Certain kinds of Customizing changes, known as data-only
Customizing changes, need to be carried out in a production client
without being saved as change requests. Examples of such data
include interest rates, health insurance premiums, pension schemes,
tax schemes, and currency exchange rates, which may require
frequent adjustment in R/3. Since these types of changes have no
effect on business processes, they are not subject to extensive
testing like other Customizing changes. To avoid having to use
change requests for these changes, SAP has introduced the Update
Settings function. Update Settings may be used within a production
client without impacting business flow related Customizing objects.
A list of SAP-approved Update Settings is kept in the table
CUSAMEN. SAP recommends that no customer changes be made to the
table. When using Update Settings in a production environment:
Client role is set to Production Client-independent object changes
are set to: No changes to Repository and client-independent
Customizing objects Changes and transports for client-dependent
objects are set to: No changes allowed
The most difficult task in the distribution of Customizing
changes is distinguishing between client-independent and
client-dependent Customizing and knowing which client-dependent
Customizing activities affect master data. To determine the client
dependency of IMG transactions in a Project IMG or Enterprise IMG,
from the IMG menu, choose Information -> Title and IMG Info.
-> Client-dependence. Client-independent Customizing affects
either: Client-independent Customizing objects, which are
Repository objects generated by Customizing demands. To ensure
proper transport, assign these Repository objects to a customer
development class. Examples of these objects are matchcodes,
condition tables, and hierarchies. Global Customizing settings,
which are the standard system settings and configurations in
various tables whose key value does not contain a client number.
Examples of these settings are calendars, printer settings,
communication settings, and schedules. While client-dependent
Customizing changes are recorded to Customizing change requests,
client-independent changes must be saved to Workbench change
requests. Thus, changes to client-independent Customizing objects,
global settings and Repository objects require a Workbench change
request
![COMPUTER ORGANIZATION & ARCHITECTURE · mov r3, h r3 m [h] add r3, g r3 r3+m [g] div r1, r3 r1 r1/r3 mov x, r1 m[x] r1 page 4 of 16 knreddy computer organization and architecture](https://img.pdfslide.us/doc/110x75/6144b5c334130627ed50859a/computer-organization-architecture-mov-r3-h-r3-m-h-add-r3-g-r3-r3m-g.jpg)
