Friday, December 30
ABAP Package Conept
ABAP applications server’s one of the most important innovations is ABAP package concept , owing to the reason that it allows the development of software considered to be ‘soft’ helping in the evolution of any software system .
Reasons for lesser usage
ABAP package concept is not used by many customer development projects and most of the developers don’t have an idea about it . The possible reasons at the beginning of any development project would be either the naming convention issues or the issues related to software logistics . Usually the naming is done in order to define a group of objects that have some similar peculiar factors . An example would be to group them as FI development , HCM , etc .
Applications of ABAP package
ABAP package can be of use only in the smaller development projects, but it can cause serious problems in larger ones. One example would be when there is a task of implementing A2A and B2B processes ; and then we could use the package SAI from the web service infrastructure . The first one of it to be shipped was 6.20 , then the further releases were 6.40 ,7.0 and NW 7.0 SP15 , with incompatible changes . If we had used only the functions of the package interface SAI , there would have been very few changes to be made .
The same rule applies to the custom development also .Like when we create our own application , with the database persistence , application layer and the UI which has to be used by some other application , a proper API has to be defined in order to guarantee authorization .
Problems without package interface
• Many of the developers are ignorant of the fact that the ABAP classes or function modules are belonging to the public API . In this case , the naming convention comes to no use , as these names we assume cant be thought to be widely known .
• It so happens that the developers think certain classes of ABAP to be private and use accordingly , and start making changes like refactoring or optimization , which is actually incompatible and this too much dependency leads to side effects in case of making changes .
• So it always best for us to changing our programming style accordingly . While coding applications , it would be a better option to define a proper interface to help the developers use the tool in a proper way . And when we need to reuse the SAP standard parts , we should first take a look at the package interfaces , which helps in learning the usage of SAP standards faster and better , with lesser to do after release upgrade .
Uses of package concept
• It cab be used in the nesting process of the packages hierarchically , with the top n=most level being the application .
• You would be able to create stable APIs , helping you to distinguish between the public and private parts, which are changeable .
• We can define dependencies of packages to other packages of SAP and also with our own package . which can be :
1. We can use it to define dependencies to SAP standard . By doing this we can help ourself in the SAP software updates since we are using only stable APIs , ultimately helping in the impact analysis of SAP switches and business functions of EhPs .
2. In case of larger development projects it gives us a chance to structure our own application . As we can develop stable APIs , we can instruct the developers to protect certain parts we would want to change in the future ,which would be a very vital aspect if we want to decouple applications for the purpose of independent release cycle .
3. In case we are delivering software components with the help of the add on assembly kit ,it is necessary to guarantee the installability of the custom made SCs.
ABAP package concept would prove to be one of the most essential tools in the software side , being the usage of package checks as part of the extended syntax checks and the code inspector to help in checking of the violations of package interfaces . The package check modes can be of two types – restricted and r3enterprise . many of us have a question as to why this concept is difficult , its because SAP did not have another chance as the software of R3 was quiet complex and the unwanted dependencies were high . To start with , SAP had to face and solve many problems while coming up with ECC 6.0 ; where the introduction of EhPs allows to define packages which get activated after switching into the business function on the system of the customer . Hence it is very important to control the dependency. The package concept would prove to be a very useful one in development of the switchable units . Hence SAP had to define the check modes that allowed violations in the package interfaces
Packages and Software Components (SC)
Usually the SAP and ISVs deliver their software as software components , which are found in the CVERS , which are transparent tables . These SCs can be considered as special transports which have metadata , installed by the transaction SAINT .
There are few interesting differences that one should be aware of here . In terms of JEE of JAVA , SC is defined as the persistence unit , but the concept of it is totally different in ABAP which are internal modus and LUW . Where JAVA SCs have DCs , the top level DCs are those which define the visible objects of an SC .
Packages and SCs are entirely different concepts .They both should not be mixed up . The SCs are an artifact of the software logistics , and they can have complete packages but they do not have representation in the ABAP workbench , whereas the packages are used to be assigned to the software components .
In JAVA and SAP NetWeaver CE there are the concepts of accessibility , but there is nothing of that sort in ABAP . In JAVA there can be compilation errors due to the even circular dependencies .
Reuse of Development Objects
One of the most important factors to keep in mind while using the concept of packages is that we need to keep control on the reuse .If we need to use these ABAP packages , we should use only those development objects that are used that way . There are a number of developers who think of SAP standard as very high collection of data elements which can be reused in their programs . But to do this in the right manner is very important . It can be done by using the data elements of the data model of SAP standard application .But it should be remembered that misuse of these will always lead us into trouble. Most of the cases it is due to the incorrect documentation and short texts . It can also lead to the software being not merger ready with the SAP tools . The defining of own data elements will help us to define the texts properly and help in proper documentation .
Before we are ready to customize or change anything in the SAP data , its always wise to check if in the custom developed application , the merger is ready . SAP tools like SAP LT works with ABAP level domains , have the capacity to change values of domains irrespective of whether they are transparent or in - transparent tables . All of these applies to the DDIC domains as well.
Lets consider that we need to define a role of the SAP business partner application . Here we need to create a new data element to define short texts . In such a case we may need to reuse BU_PARTNER domain of SAP standard , to analyze this as a proper extension . In case we use domains like CHARxyz , it Is always better to check if they are In package interfaces an also to which application they belong to . This helps us to avoid unwanted dependencies to those applications of SAP which we don’t use .
ABAP message classes are not recommended in most cases . They are used for define error messages in BAPIRET –messages , in business application log (BAL ) and also rarely in case of controlled dumps . In case of such an error message occurring , you should make use of the ABAP code from the use access . But in case of reusing error messages from SAP standard, it would be a tough task then and its not that easy to find the proper code line . Another reason is also that long text is not helpful in the case of custom applications .
Reasons for lesser usage
ABAP package concept is not used by many customer development projects and most of the developers don’t have an idea about it . The possible reasons at the beginning of any development project would be either the naming convention issues or the issues related to software logistics . Usually the naming is done in order to define a group of objects that have some similar peculiar factors . An example would be to group them as FI development , HCM , etc .
Applications of ABAP package
ABAP package can be of use only in the smaller development projects, but it can cause serious problems in larger ones. One example would be when there is a task of implementing A2A and B2B processes ; and then we could use the package SAI from the web service infrastructure . The first one of it to be shipped was 6.20 , then the further releases were 6.40 ,7.0 and NW 7.0 SP15 , with incompatible changes . If we had used only the functions of the package interface SAI , there would have been very few changes to be made .
The same rule applies to the custom development also .Like when we create our own application , with the database persistence , application layer and the UI which has to be used by some other application , a proper API has to be defined in order to guarantee authorization .
Problems without package interface
• Many of the developers are ignorant of the fact that the ABAP classes or function modules are belonging to the public API . In this case , the naming convention comes to no use , as these names we assume cant be thought to be widely known .
• It so happens that the developers think certain classes of ABAP to be private and use accordingly , and start making changes like refactoring or optimization , which is actually incompatible and this too much dependency leads to side effects in case of making changes .
• So it always best for us to changing our programming style accordingly . While coding applications , it would be a better option to define a proper interface to help the developers use the tool in a proper way . And when we need to reuse the SAP standard parts , we should first take a look at the package interfaces , which helps in learning the usage of SAP standards faster and better , with lesser to do after release upgrade .
Uses of package concept
• It cab be used in the nesting process of the packages hierarchically , with the top n=most level being the application .
• You would be able to create stable APIs , helping you to distinguish between the public and private parts, which are changeable .
• We can define dependencies of packages to other packages of SAP and also with our own package . which can be :
1. We can use it to define dependencies to SAP standard . By doing this we can help ourself in the SAP software updates since we are using only stable APIs , ultimately helping in the impact analysis of SAP switches and business functions of EhPs .
2. In case of larger development projects it gives us a chance to structure our own application . As we can develop stable APIs , we can instruct the developers to protect certain parts we would want to change in the future ,which would be a very vital aspect if we want to decouple applications for the purpose of independent release cycle .
3. In case we are delivering software components with the help of the add on assembly kit ,it is necessary to guarantee the installability of the custom made SCs.
ABAP package concept would prove to be one of the most essential tools in the software side , being the usage of package checks as part of the extended syntax checks and the code inspector to help in checking of the violations of package interfaces . The package check modes can be of two types – restricted and r3enterprise . many of us have a question as to why this concept is difficult , its because SAP did not have another chance as the software of R3 was quiet complex and the unwanted dependencies were high . To start with , SAP had to face and solve many problems while coming up with ECC 6.0 ; where the introduction of EhPs allows to define packages which get activated after switching into the business function on the system of the customer . Hence it is very important to control the dependency. The package concept would prove to be a very useful one in development of the switchable units . Hence SAP had to define the check modes that allowed violations in the package interfaces
Packages and Software Components (SC)
Usually the SAP and ISVs deliver their software as software components , which are found in the CVERS , which are transparent tables . These SCs can be considered as special transports which have metadata , installed by the transaction SAINT .
There are few interesting differences that one should be aware of here . In terms of JEE of JAVA , SC is defined as the persistence unit , but the concept of it is totally different in ABAP which are internal modus and LUW . Where JAVA SCs have DCs , the top level DCs are those which define the visible objects of an SC .
Packages and SCs are entirely different concepts .They both should not be mixed up . The SCs are an artifact of the software logistics , and they can have complete packages but they do not have representation in the ABAP workbench , whereas the packages are used to be assigned to the software components .
In JAVA and SAP NetWeaver CE there are the concepts of accessibility , but there is nothing of that sort in ABAP . In JAVA there can be compilation errors due to the even circular dependencies .
Reuse of Development Objects
One of the most important factors to keep in mind while using the concept of packages is that we need to keep control on the reuse .If we need to use these ABAP packages , we should use only those development objects that are used that way . There are a number of developers who think of SAP standard as very high collection of data elements which can be reused in their programs . But to do this in the right manner is very important . It can be done by using the data elements of the data model of SAP standard application .But it should be remembered that misuse of these will always lead us into trouble. Most of the cases it is due to the incorrect documentation and short texts . It can also lead to the software being not merger ready with the SAP tools . The defining of own data elements will help us to define the texts properly and help in proper documentation .
Before we are ready to customize or change anything in the SAP data , its always wise to check if in the custom developed application , the merger is ready . SAP tools like SAP LT works with ABAP level domains , have the capacity to change values of domains irrespective of whether they are transparent or in - transparent tables . All of these applies to the DDIC domains as well.
Lets consider that we need to define a role of the SAP business partner application . Here we need to create a new data element to define short texts . In such a case we may need to reuse BU_PARTNER domain of SAP standard , to analyze this as a proper extension . In case we use domains like CHARxyz , it Is always better to check if they are In package interfaces an also to which application they belong to . This helps us to avoid unwanted dependencies to those applications of SAP which we don’t use .
ABAP message classes are not recommended in most cases . They are used for define error messages in BAPIRET –messages , in business application log (BAL ) and also rarely in case of controlled dumps . In case of such an error message occurring , you should make use of the ABAP code from the use access . But in case of reusing error messages from SAP standard, it would be a tough task then and its not that easy to find the proper code line . Another reason is also that long text is not helpful in the case of custom applications .
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
You are welcome to express your views here...