Modifications can be categorized as 'critical' if:They affect numerous other Repository objects (such as Dictionary objects or function modules) Modification adjustment is either difficult (as with menus, pushbbuttons, and GUI interfaces up to 4.5A) or not supported by a tool (transaction codes, message classes, logical databases).Withbout the Modification Assistant (prior to Release 4.5A), both modifying GUI statuses and GUI titles, as well as assigning customer function modules to SAP function groups, should be considered 'critical' activities.SAP only changes the following Repository objects in an upwardly compatible manner. They should therefore be considered 'uncritical' by customers who want to call them:
Function modules that have been released
BAPIs
Includes for user exits
Screen, program, menu, and field exits
After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant .You must be familiar with the processing logic of your application in order to be able to adjust programs properly.Modification adjustment is not necessary if you avoid making changes to SAP objects.Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.From Release 3.0, you can use Online Correction Services to import and cancel Support packages and patches automatically (instead of having to insert preliminary corrections manually).
Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.
Choose copying instead of modifying if:
You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.
ABAP development projects can be evaluated according to the following criteria:
What will implementation cost, measured in manpower (creating the concept, implementation, testing)?
How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?
By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.
Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).
The following naming conflicts can occur:
An SAP Repository object and a customer Repository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions.
Two customer Repository objects conflict
Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.
RELATED POSTS
LESSON 1 SAP NAVIGATION
Function modules that have been released
BAPIs
Includes for user exits
Screen, program, menu, and field exits
After an upgrade, you must test customer reports that call SAP objects, as well as all objects displayed in the upgrade utility SPAU. This is also true for Repository objects that have been automatically adjusted using the Modifications Assistant .You must be familiar with the processing logic of your application in order to be able to adjust programs properly.Modification adjustment is not necessary if you avoid making changes to SAP objects.Use program enhancements and appends with SAP tables to enhance SAP objects in such a way that your changes cannot be overwritten by SAP at upgrade.From Release 3.0, you can use Online Correction Services to import and cancel Support packages and patches automatically (instead of having to insert preliminary corrections manually).
Modification has the advantage that your live Repository objects do not lose their connection to the SAP standard. Copying, on the other hand, has the advantage that no modification adjustment will be necessary for your live Repository objects during subsequent upgrades.
Choose copying instead of modifying if:
You have to make numerous changes to an SAP program
Your requirements will not be met by the standard in future R/3 releases
During copying, pay attention to a Repository object's environment as well. You should only decide whether to modify or copy after having informed yourself of the consequences for the main program, as well as for all of the includes attached to the main program. The same holds true for function groups and function modules.
ABAP development projects can be evaluated according to the following criteria:
What will implementation cost, measured in manpower (creating the concept, implementation, testing)?
How will the ABAP development project influence:
Production operation performance?
The amount of adjustment at upgrade?
By calling SAP objects in your own Repository object, you can drastically reduce the amount of effort needed to implement your object. However, any changes that SAP makes to the Repository object you choose to call may make extra adjustment necessary after an upgrade. For example, SAP could conceivably change the user interface of a screen for which you have written a batch input program.
Naming conventions allow you to avoid naming conflicts and give your Repository objects meaningful names (that can be understood by others).
The following naming conflicts can occur:
An SAP Repository object and a customer Repository object conflict
SAP Repository objects and customer Repository objects should be separated from each other by strict adherence to SAP naming conventions.
Two customer Repository objects conflict
Naming conflicts can also occur between customers Repository objects in decentralized
Development scenarios where more than one development system is being used. You can avoid naming conflicts in this area by reserving a special namespace for development areas within the customer namespace. The Workbench Organizer checks to make sure that you adhere to these conventions by making entries in view V_TRESN.
RELATED POSTS
LESSON 1 SAP NAVIGATION
No comments :
Post a Comment