BASIS provides administrative tools for SAP. It is a logical collection of R/3 software components. Basis is the layer between the hardware and R/3 system software.
BASIS provides for the following
Tools for administration:
Basis includes various administration tools for managing the system resources like hardware, software and printers. It includes tools for monitoring the system performance, monitoring user sessions, setting up alerts and deriving various statistics and graphs which give indications of the system performance.
User Administration:
This includes creating user ids, modifying user details and deleting users ids, viewing system users, sending messages to multiple users.
Runtime environment for the user:
The runtime environment for the user includes the default menu path for the user, the date format for the user, the default printer for the user, changing user’s password.
Provide Authorisations to the users:
In order to enable the user to access the various transactions, it is essential that the users have the correct set of authorisations. Setting of authorisations for the users based on their job roles. An authorisation tool is used to create the user authorisations. Once the authorisations have been created, profiles are created and the authorisations are attached to them. Each profile can have many such authorisations attached to them. The profiles are created based on the role definition of the user in the company. After the authorisations and profiles are created, user ids are created and the profiles are attached to the user profiles. Each user id could have multiple user profiles attached to them. For example, if we create a user profile for a business head, then that user id could have profiles relating to various departments / job definitions attached to it.
Printer Administration:
This includes installing the network printers and local and remote printers for the users, setting up printer queues, and managing printer spooler.
System Administration:
This includes starting and stopping the SAP service manager, diagnosing the system start-up, monitoring work processes, viewing transaction codes, clearing locked entries, monitoring system updates, transport of customising change requests and ABAP change requests at the OS level.
Database Administration (including Backup and Restore):
Database management including database backup and restore, database performance monitor, and analysing database activity.
Interfaces with non-SAP products:
BASIS also includes tools for interfacing with non-SAP products, which will continued to be in use in the organisation.
ABAP/4
ABAP is the development tool in SAP. All SAP Transactions and Reports are developed in ABAP/4. ABAP/4 aids in the development of new reports, batch conversion programs and data entry screens (module pool programs) and interfaces with third party standard software.
SAP software is totally transaction based. All the menu paths in SAP point to a particular transaction. A transaction is a four-letter alphanumeric code, which executes a program in SAP. Everything in SAP is a transaction. For e.g.- Creating a Purchase Order is a transaction, Changing the Purchase Order details is another transaction. Transactions are also used to run various reports. Each report has a unique transaction code. Each transaction code is unique in the SAP system.
ABAP/4 Reports
There are following types of ABAP/4 reports that can be developed.
Simple Lists:
ABAP/4 can be used to generate simple lists as well as interactive reports.
Interactive reports
Event Driven Reports: These reports are generated on click of a button.
Drill Down Reports: Reports are initially shown as simple upper level lists. If the user is interested in getting further details, then he can drill down on a particular item like material code or project number and get further details. Thus many levels can be incorporated into the report based on the user requirements.
Graphic Reports: Reports can be developed to provide a graphical representation of the data.
Layout Sets: ABAP also facilitates developing of various documents sent to external parties like customers and vendors. These documents require special formatting and printing of company logos. This can be done through ABAP Layout sets tool, which enables the programmer to specify various fonts, set the logo in the format and perform special formatting in the document.
ABAP/4 Batch Data Conversion
Batch Data Conversion programs are developed to import the data from legacy systems into SAP. Batch programs are written specifically for the particular transaction. For example, to upload all the purchase order data from the legacy system, a BDC for the purchase order transaction is developed.
Online or Scheduled: BDCs could be online or they could be scheduled to run at a particular time / date or after a particular other BDC has run.
ABAP/4 Job Scheduling: The user can schedule the running of reports / BDCs on a periodic basis (monthly / weekly).
ABAP Module Pool Programs: These are new data entry screens that can be developed in ABAP based on the user requirements.
ABAP Queries: ABAP Query is a quick and effective tool, which is used to create queries and generate simple lists.
ABAP Module Pool Programs: To build interactive data entry screens, Module Pool programs are developed in ABAP/4
SAP software is totally transaction based. All the menu paths in SAP point to a particular transaction. A transaction is a four-letter alphanumeric code, which executes a program in SAP. Everything in SAP is a transaction. For e.g.- Creating a Purchase Order is a transaction, Changing the Purchase Order details is another transaction. Transactions are also used to run various reports. Each report has a unique transaction code. Each transaction code is unique in the SAP system.
ABAP/4 Reports
There are following types of ABAP/4 reports that can be developed.
Simple Lists:
ABAP/4 can be used to generate simple lists as well as interactive reports.
Interactive reports
Event Driven Reports: These reports are generated on click of a button.
Drill Down Reports: Reports are initially shown as simple upper level lists. If the user is interested in getting further details, then he can drill down on a particular item like material code or project number and get further details. Thus many levels can be incorporated into the report based on the user requirements.
Graphic Reports: Reports can be developed to provide a graphical representation of the data.
Layout Sets: ABAP also facilitates developing of various documents sent to external parties like customers and vendors. These documents require special formatting and printing of company logos. This can be done through ABAP Layout sets tool, which enables the programmer to specify various fonts, set the logo in the format and perform special formatting in the document.
ABAP/4 Batch Data Conversion
Batch Data Conversion programs are developed to import the data from legacy systems into SAP. Batch programs are written specifically for the particular transaction. For example, to upload all the purchase order data from the legacy system, a BDC for the purchase order transaction is developed.
Online or Scheduled: BDCs could be online or they could be scheduled to run at a particular time / date or after a particular other BDC has run.
ABAP/4 Job Scheduling: The user can schedule the running of reports / BDCs on a periodic basis (monthly / weekly).
ABAP Module Pool Programs: These are new data entry screens that can be developed in ABAP based on the user requirements.
ABAP Queries: ABAP Query is a quick and effective tool, which is used to create queries and generate simple lists.
ABAP Module Pool Programs: To build interactive data entry screens, Module Pool programs are developed in ABAP/4
SMARTFORMS
Steps to create a simple SMARTFORMS
Read the abap program in step 5 first to see how the data is begin pass to the internal table.
1. Create a new smartforms
2. Define looping process for internal table
3. Define table in smartforms
4. To display the data in the form
5. Calling SMARTFORMS from your ABAP program
1. Create a new smartforms
Transaction code SMARTFORMS
Create new smartforms call ZSMART
The followings screen format will appear :-
- Form ZSMART Form ZSMART
- Global settings Description New form
- Form attributes
- Form interface
- Global definitions General attributes Output Options
- Pages and windows
+ %PAGE1 New page
You can click at the Form Painter button to view the graphical display layout of your smartforms.
2. Define looping process for internal table
Pages and windows
First Page -> Header Window (Cursor at First Page then click Edit -> Node -> Create)
Here, you can specify your title and page numbering
&SFSY-PAGE& (Page 1) of &SFSY-FORMPAGES(Z4.0)& (Total Page)
Main windows -> TABLE -> DATA
In the Loop section, tick Internal table and fill in
ITAB1 (table in ABAP SMARTFORM calling function) INTO ITAB2
3. Define table in smartforms
Global settings :
Form interface
Variable name Type assignment Reference type
ITAB1 TYPE Table Structure
Global definitions
Variable name Type assignment Reference type
ITAB2 TYPE Table Structure
4. To display the data in Smartform
Make used of the Table Painter and declare the Line Type in Tabstrips Table
e.g. HD_GEN for printing header details,
IT_GEN for printing data details.
You have to specify the Line Type in your Text elements in the Tabstrips Output options.
Tick the New Line and specify the Line Type for outputting the data.
Declare your output fields in Text elements
Tabstrips - Output Options
For different fonts use this Style : IDWTCERTSTYLE
For Quantity or Amout you can used this variable &GS_ITAB-AMOUNT(12.2)&
5. Calling SMARTFORMS from your ABAP program
REPORT ZSMARTFORM.
* Calling SMARTFORMS from your ABAP program.
* Collecting all the table data in your program, and pass once to SMARTFORMS
* SMARTFORMS
* Declare your table type in :-
* Global Settings -> Form Interface
* Global Definintions -> Global Data
* Main Window -> Table -> DATA
*
* Written by : SAP Hints and Tips on Configuration and ABAP/4 Programming
* http://sapr3.tripod.com
*
TABLES: MKPF.
DATA: FM_NAME TYPE RS38L_FNAM.
DATA: BEGIN OF INT_MKPF OCCURS 0.
INCLUDE STRUCTURE MKPF.
DATA: END OF INT_MKPF.
SELECT-OPTIONS S_MBLNR FOR MKPF-MBLNR MEMORY ID 001.
SELECT * FROM MKPF WHERE MBLNR IN S_MBLNR.
MOVE-CORRESPONDING MKPF TO INT_MKPF.
APPEND INT_MKPF.
ENDSELECT.
* At the end of your program.
* Passing data to SMARTFORMS
call function 'SSF_FUNCTION_MODULE_NAME'
exporting
formname = 'ZSMARTFORM'
* VARIANT = ' '
* DIRECT_CALL = ' '
IMPORTING
FM_NAME = FM_NAME
EXCEPTIONS
NO_FORM = 1
NO_FUNCTION_MODULE = 2
OTHERS = 3.
if sy-subrc <> 0.
WRITE: / 'ERROR 1'.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
call function FM_NAME
* EXPORTING
* ARCHIVE_INDEX =
* ARCHIVE_INDEX_TAB =
* ARCHIVE_PARAMETERS =
* CONTROL_PARAMETERS =
* MAIL_APPL_OBJ =
* MAIL_RECIPIENT =
* MAIL_SENDER =
* OUTPUT_OPTIONS =
* USER_SETTINGS = 'X'
* IMPORTING
* DOCUMENT_OUTPUT_INFO =
* JOB_OUTPUT_INFO =
* JOB_OUTPUT_OPTIONS =
TABLES
GS_MKPF = INT_MKPF
EXCEPTIONS
FORMATTING_ERROR = 1
INTERNAL_ERROR = 2
SEND_ERROR = 3
USER_CANCELED = 4
OTHERS = 5.
if sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
Application Link Enabling
What is ALE?
ALE stands for Application Link Enabling and is a remote connection technology allowing the decentralization of business processes by connecting decentralized systems together.
Using ALE, it is fairly easy to synchronize several SAP systems so that they contain the same data objects at anytime. These objects may be master data (customers, vendors, GL accounts, cost centers, ...) or transaction data (FI documents, purchase orders, ...). To enable the synchronization, ALE supports not only mass transfer of data between systems but also selective data transfers of objects changed since the last transfer.
How does it work?
Viewed from a high level perspective, the process is straight and simple: a sender system selects the data that needs to be distributed, packs it in a standard format and sends it to one or several receiving systems. When a receiving system gets the data, it unpacks the standard format and records the data.
In fact, 3 layers are involved in this process:
• An application layer which selects and records data in R/3.
• A distribution layer which filters and converts data.
• A communication layer which ensures the actual communication of records generated in a standard format.
The senders and receivers are determined thanks to a so-called distribution model which defines the transfer rules (who sends what to who?). The definition of the distribution model must be known by all systems involved (either as sender or receiver) and must consequently exist on all those systems.
The Intermediate Document (IDoc)
The data transferred using ALE must have a SAP standard format to be understood from all partners in the communication. This format is the Intermediate Document (IDoc) which represents an intermediary structure between raw SAP data and EDI formats. This structure is not constant, it depends on the data to be transferred and SAP provides the structures for most SAP standard objects such as customers master data, sales orders, ...
An IDoc with a specific structure is said to have a specific type. The IDoc type is nothing more than a version of a specific IDoc structure designed to contain data for a specific object type. For example, the IDoc type DEBMAS05 is the fifth version of a structure that represents a customer master data. The management of versions for IDocs structures is necessary because the objects evolve with time and tend to become more and more complex with new data fields or tables being added regularly.
The conversion of raw data forth (for the sender system) and back (for the receiver system) to the IDoc format is also ensured by SAP standard function modules as long as you transfer standard objects. For non standard objects (enhancements), you must define your own IDoc structure and write your own conversion function modules.
RFC connections
The data communication between the SAP servers may be done by several ways. The 2 most common ways are the transactional RFC and the file. The RFC connection is used to make a direct connection between servers while the file interface speaks for itself, it uses a file containing the IDocs from the sender system as input in the receiver(s) system(s).
The selection of a communication method is made though the ports configuration as we will see in the next section. For the purpose of this article, we are going to choose the most efficient method: the transactional RFC method. To set it up, we first need to define the RFC destinations of the partner systems.
An RFC destination may be seen as a set of settings necessary to connect to a system using the RFC protocol. These settings include the address and type of the partner system along with connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to include in the distribution model. The transaction to use for this purpose is SM59.
Definition of the communication ports
The communication ports determine the type of data communication that must occur between systems. When the communication is to use the RFC protocol, transactional RFC ports must be created specifying the RFC destinations of the partner systems. Use transaction WE21 for this purpose.
Partners profiles
In SAP, all partners systems involved in a distribution model have a profile. There exist several profile types such as customers profiles, vendors profiles, ... but this distinction between profiles is generally not necessary and you will create in most cases your partners profiles using a generic Logical System type.
Before entering the settings of the logical systems partners, you have to create them in customizing. Also, each system in the distribution model must be assigned in its own system its own logical system that represents it. This assignment is done at client level and not at system level. This is not easy to explain nor to understand so let's take a simple example. Let's consider we have a simple distribution model made up of a sender system (S01) and a receiver system (R01). We need to transfer data from S01 / client 100 to R01 / client 200. In both the systems, we will define the logical systems S01_100 and R01_200. But in sender system S01, the logical system S01_100 will be assigned to the client 100 while in the receiver system R01, it will be R01_200 that will be assigned to client 200. With such a configuration you see it is even possible to transfer data between two clients from the same system.
A partner profile is used to determine a lot of important settings that will be involved in the data transfer. These settings vary depending on the role of the partner system (sender / receiver) and are defined per message type. A message type is more or less a version independent IDoc type. It is mainly a convenient way of defining settings and identifying IDocs using a criterium independent of the partner system.
For a sender partner system (inbound parameters are filled in), following important settings are set per message type in the partner profile:
• A process code used to indicate which function module will be used to convert the IDoc data to SAP data.
• The time of input of the IDoc: as soon as the IDoc is created in the system or on request (using program RBDAPP01).
• The post processing agent who will have to treat the data input errors if need be. The post processing agent may be either a user or any other HR organizational unit.
For a receiver partner system (outbound parameters are filled in), following settings are specified in the partner profile:
• The receiver port to which the data will be sent.
• The sending method: one IDoc at a time or by packets.
• The IDoc type that will be sent to that partner. For a given message type, the IDoc type sent may vary depending on the receiver system. Indeed you may have different versions of SAP in your system landscape.
Definition of the distribution model and data filtering
We have already seen that the distribution model is used to decide who sends what to who. But, as you guessed, there is a little bit more to be said about it and the way to manage it.
The distribution model is maintained in a central transaction (BD64) which lets you access the most useful environmental settings necessary to set up the model. Before creating the model, you must first decide on which system you are going to create it. Indeed the model must exist in all partners systems and two possibilities exist to achieve this.
Either you create the model on each system manually (with the same model technical name), which is feasible only with few systems and/or simple models. Either you create it in a specific system (usually the source system) and distribute it to the other systems thanks to the distribution command in the BD64 transaction menu.
If we want to copy the customers master data from the production system to the other systems in the maintenance line for example, we may create the distribution model on the production system and distribute it to all partners systems.
The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems. You may afterwards add more sending and receiving systems in the model as well as more message types.
For each message type defined between a sender and a receiver, you may set filters on specific fields of the message type so that IDocs be generated only when these specific values are matched. For example, you may decide to send only customers of a specific account group. These filters are set by selecting the 'no filter set' text under message types in BD64.
There exists also another kind of filters which are segments filters. They do not filter IDocs creation based on values like we have just seen but filter unconditionally segments of created IDocs which must be excluded from the transfer (transaction BD56).
ALE stands for Application Link Enabling and is a remote connection technology allowing the decentralization of business processes by connecting decentralized systems together.
Using ALE, it is fairly easy to synchronize several SAP systems so that they contain the same data objects at anytime. These objects may be master data (customers, vendors, GL accounts, cost centers, ...) or transaction data (FI documents, purchase orders, ...). To enable the synchronization, ALE supports not only mass transfer of data between systems but also selective data transfers of objects changed since the last transfer.
How does it work?
Viewed from a high level perspective, the process is straight and simple: a sender system selects the data that needs to be distributed, packs it in a standard format and sends it to one or several receiving systems. When a receiving system gets the data, it unpacks the standard format and records the data.
In fact, 3 layers are involved in this process:
• An application layer which selects and records data in R/3.
• A distribution layer which filters and converts data.
• A communication layer which ensures the actual communication of records generated in a standard format.
The senders and receivers are determined thanks to a so-called distribution model which defines the transfer rules (who sends what to who?). The definition of the distribution model must be known by all systems involved (either as sender or receiver) and must consequently exist on all those systems.
The Intermediate Document (IDoc)
The data transferred using ALE must have a SAP standard format to be understood from all partners in the communication. This format is the Intermediate Document (IDoc) which represents an intermediary structure between raw SAP data and EDI formats. This structure is not constant, it depends on the data to be transferred and SAP provides the structures for most SAP standard objects such as customers master data, sales orders, ...
An IDoc with a specific structure is said to have a specific type. The IDoc type is nothing more than a version of a specific IDoc structure designed to contain data for a specific object type. For example, the IDoc type DEBMAS05 is the fifth version of a structure that represents a customer master data. The management of versions for IDocs structures is necessary because the objects evolve with time and tend to become more and more complex with new data fields or tables being added regularly.
The conversion of raw data forth (for the sender system) and back (for the receiver system) to the IDoc format is also ensured by SAP standard function modules as long as you transfer standard objects. For non standard objects (enhancements), you must define your own IDoc structure and write your own conversion function modules.
RFC connections
The data communication between the SAP servers may be done by several ways. The 2 most common ways are the transactional RFC and the file. The RFC connection is used to make a direct connection between servers while the file interface speaks for itself, it uses a file containing the IDocs from the sender system as input in the receiver(s) system(s).
The selection of a communication method is made though the ports configuration as we will see in the next section. For the purpose of this article, we are going to choose the most efficient method: the transactional RFC method. To set it up, we first need to define the RFC destinations of the partner systems.
An RFC destination may be seen as a set of settings necessary to connect to a system using the RFC protocol. These settings include the address and type of the partner system along with connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to include in the distribution model. The transaction to use for this purpose is SM59.
Definition of the communication ports
The communication ports determine the type of data communication that must occur between systems. When the communication is to use the RFC protocol, transactional RFC ports must be created specifying the RFC destinations of the partner systems. Use transaction WE21 for this purpose.
Partners profiles
In SAP, all partners systems involved in a distribution model have a profile. There exist several profile types such as customers profiles, vendors profiles, ... but this distinction between profiles is generally not necessary and you will create in most cases your partners profiles using a generic Logical System type.
Before entering the settings of the logical systems partners, you have to create them in customizing. Also, each system in the distribution model must be assigned in its own system its own logical system that represents it. This assignment is done at client level and not at system level. This is not easy to explain nor to understand so let's take a simple example. Let's consider we have a simple distribution model made up of a sender system (S01) and a receiver system (R01). We need to transfer data from S01 / client 100 to R01 / client 200. In both the systems, we will define the logical systems S01_100 and R01_200. But in sender system S01, the logical system S01_100 will be assigned to the client 100 while in the receiver system R01, it will be R01_200 that will be assigned to client 200. With such a configuration you see it is even possible to transfer data between two clients from the same system.
A partner profile is used to determine a lot of important settings that will be involved in the data transfer. These settings vary depending on the role of the partner system (sender / receiver) and are defined per message type. A message type is more or less a version independent IDoc type. It is mainly a convenient way of defining settings and identifying IDocs using a criterium independent of the partner system.
For a sender partner system (inbound parameters are filled in), following important settings are set per message type in the partner profile:
• A process code used to indicate which function module will be used to convert the IDoc data to SAP data.
• The time of input of the IDoc: as soon as the IDoc is created in the system or on request (using program RBDAPP01).
• The post processing agent who will have to treat the data input errors if need be. The post processing agent may be either a user or any other HR organizational unit.
For a receiver partner system (outbound parameters are filled in), following settings are specified in the partner profile:
• The receiver port to which the data will be sent.
• The sending method: one IDoc at a time or by packets.
• The IDoc type that will be sent to that partner. For a given message type, the IDoc type sent may vary depending on the receiver system. Indeed you may have different versions of SAP in your system landscape.
Definition of the distribution model and data filtering
We have already seen that the distribution model is used to decide who sends what to who. But, as you guessed, there is a little bit more to be said about it and the way to manage it.
The distribution model is maintained in a central transaction (BD64) which lets you access the most useful environmental settings necessary to set up the model. Before creating the model, you must first decide on which system you are going to create it. Indeed the model must exist in all partners systems and two possibilities exist to achieve this.
Either you create the model on each system manually (with the same model technical name), which is feasible only with few systems and/or simple models. Either you create it in a specific system (usually the source system) and distribute it to the other systems thanks to the distribution command in the BD64 transaction menu.
If we want to copy the customers master data from the production system to the other systems in the maintenance line for example, we may create the distribution model on the production system and distribute it to all partners systems.
The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems. You may afterwards add more sending and receiving systems in the model as well as more message types.
For each message type defined between a sender and a receiver, you may set filters on specific fields of the message type so that IDocs be generated only when these specific values are matched. For example, you may decide to send only customers of a specific account group. These filters are set by selecting the 'no filter set' text under message types in BD64.
There exists also another kind of filters which are segments filters. They do not filter IDocs creation based on values like we have just seen but filter unconditionally segments of created IDocs which must be excluded from the transfer (transaction BD56).
Change and Transport System
The CTS is the central tool for managing changes to customizing and repository data that we make in the IMG
or ABAP workbench.
As we have discussed earlier, a transport request cab be either customizing request or ABAP workbench
request.
A customizing request can be created by the customizing tool IMG.
An ABAP workbench request can be created by ABAP workbench tool. Any changes or objects we develop
through ABAP workbench are stored in Repository tables of SAP database.
As an ABAP developer you will be working with ABAP workbench and thus you create work bench requests.
A functional consultant works with configuration tool IMG (SAP Implementation Guide) T-code SPRO, thus
creating customizing requests.
Transport organizer:
Transport organizer is the tool provided by SAP which records and documents all changes to objects in the
repository and customizing. The transaction code for transport organizer is SE10 or SE09.
Transport organizer is fully integrated with ABAP workbench and customizing tool IMG. That means you can
navigate in both directions from transport organizer to ABAP workbench and reverse also.
Development class:
Development classes are used to group similar work objects that are being developed in a project.
While creating development class we must assign it to the transport layer.
All the objects assigned to that development class can be transported according to the routes defined in the
transport layer.
Defining transport layer and routes is SAP BASIS administrator job. The transport layer defines transport
route between the systems included in system landscape.
The development classes are themselves objects in the ABAP workbench.
The development class of a development class is always itself.
Change Request:
Information source in the transport organizer that records and manages all changes made to repository
objects and customizing settings during a development project.
Task:
A task is assigned to a change request.
It is the information carrier in the transport organizer for entering and managing all changes to repository
objects and customizing settings performed by employees within a development project.
4.6c
In SE10, tick the followings :-
• Customizing requests
• Workbench requests
• Transport of copies
• Modifiable
• Released
• Hit Enter and a changed request lists will be displayed (click Releaseddirectly button or press F9)
STMS - Transport request from Developerto Production (depending on your company settings)
• Import Overview
• Double the Target System
• Select the request to transport and click Import request or Ctrl + F11
or ABAP workbench.
As we have discussed earlier, a transport request cab be either customizing request or ABAP workbench
request.
A customizing request can be created by the customizing tool IMG.
An ABAP workbench request can be created by ABAP workbench tool. Any changes or objects we develop
through ABAP workbench are stored in Repository tables of SAP database.
As an ABAP developer you will be working with ABAP workbench and thus you create work bench requests.
A functional consultant works with configuration tool IMG (SAP Implementation Guide) T-code SPRO, thus
creating customizing requests.
Transport organizer:
Transport organizer is the tool provided by SAP which records and documents all changes to objects in the
repository and customizing. The transaction code for transport organizer is SE10 or SE09.
Transport organizer is fully integrated with ABAP workbench and customizing tool IMG. That means you can
navigate in both directions from transport organizer to ABAP workbench and reverse also.
Development class:
Development classes are used to group similar work objects that are being developed in a project.
While creating development class we must assign it to the transport layer.
All the objects assigned to that development class can be transported according to the routes defined in the
transport layer.
Defining transport layer and routes is SAP BASIS administrator job. The transport layer defines transport
route between the systems included in system landscape.
The development classes are themselves objects in the ABAP workbench.
The development class of a development class is always itself.
Change Request:
Information source in the transport organizer that records and manages all changes made to repository
objects and customizing settings during a development project.
Task:
A task is assigned to a change request.
It is the information carrier in the transport organizer for entering and managing all changes to repository
objects and customizing settings performed by employees within a development project.
4.6c
In SE10, tick the followings :-
• Customizing requests
• Workbench requests
• Transport of copies
• Modifiable
• Released
• Hit Enter and a changed request lists will be displayed (click Releaseddirectly button or press F9)
STMS - Transport request from Developerto Production (depending on your company settings)
• Import Overview
• Double the Target System
• Select the request to transport and click Import request or Ctrl + F11
Program Management
The implementation of the R/3 System in large multinational corporations is a more time-consuming and complicated process than for mid-sized companies. For this reason , corporations need to observe certain procedures in order to control costs and avoid the delays that a lengthy rollout might entail. The following graphic shows an example of how global templates can be used to carry out a rollout. On the global level, that is, at corporate headquarters, it is necessary to co-ordinate all activities carried out during implementation and the maintenance/support phase after implementation.
Within Global ASAP, program management is regarded not as a project, but as the providing of official channels of support for the further development of the template, the ongoing work on group-specific standards and the rollout of the corresponding system functionality. These global activities need to be carried out and clearly defined centrally for all local systems.
Figure xx: Projects to Complete a Group Rollout
When local project activities are carried out, the program team at the global level is not actually responsible for the productive start of any systems at the local sites. This is the main task of the local project teams. Here it is important to differentiate between tasks carried out at the global and local levels, as well as to differentiate between resources used for development and resources used in the rollout itself.
The developments described here contain a global implementation strategy based on global templates and distributed system topologies. This is where R/3 customers will reap the greatest benefit. Within Global ASAP, further release strategies and enhancements containing new contents and functions which apply to the Global ASAP Roadmap will follow.
Subscribe to:
Posts (Atom)
