Skip to Content

Steps to Content Submission on SDN

Are some of you baffled by the acceptance criteria when you submit a Code Sample or an article to SDN as an external Contribution? Here are the steps you followed: 1) You went to submit content. 2) You downloaded the document template and dutifully filled in: Document Title, Applies To, Summary, and Table of Contents. You even added a picture and a brief author Bio. 3) You cut and paste your code sample and offset it in the template. 4) You went to submit content and “agreed” to the Terms and Conditions. image You attached your file and pressed Next….. image And…..you waited for response about your submission, perhaps even a number of weeks.

What is being evaluated

For those of you submitting code samples, it is the origniality, coding style, and preceived value of the code that is being looked at. Think of your code as a “mini utility” for a user to plug and try. Will someone be able to use this? Are there like samples out there already? Is my coding style compliant with SAP recommendations? Huh? What SAP recommendations, you may ask?

ABAP Syntax Contructs- a Small Guide

A number of years ago, some of my ABAP students asked me to explain why certain language contructs became obsolete with the advent of ABAP Objects. In looking for a coding “style guide”, I came across some excellent documentation in the ABAP “help” that explained why certain keywords such as TABLES, LIKE (in the context of referring to Dictionary objects), and OCCURS were to be avoided. Many of your ABAP coding samples are being rejected because they fail to adhere to some simple rules that have evolved over the past few years. Use of certain statements is to be avoided. ABAP programs submitted with key words such as TABLES, OCCURS, and LIKE (in the context of a reference to a dictionary object) will fail to be published, just as they would fail to pass the syntax check in the stricter context of ABAP Objects. Hopefully, the following Guide to Obsolete Abap Constructs will help you from inadvertantly using inappropriate ABAP coding style in your submissions and better your chances of having your code samples published.

Some further criteria

Code samples that represent already published content and examples also risk rejection. We are also looking for elements that go beyond freely available documentation. Use graphics judicially, but do illustrate when logical. When using graphics, do supplement them with coherent and instructional text. The goal of all these warnings and instructions is to ensure that our repository is rich with valuable, useful and coherent examples, representing those utilities and concepts that you find indispensable. It isn’t out of meanness and ingratitude that we reject your offerings. We are really hoping to maintain quality and provide value to as many of our readers as possible and that means adhering to some criteria and acceptance standards. In general, we are very pleased with the quality and quantity of participation in the contribution programs. After making my own feeble attempts to provide blog content or a Syntax guide, I must admit, I am truly filled with admiration for our users who take pains and expend so much energy enriching our community. Happy Content Creating!

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Jayanta Choudhuri
    Apart from SAP PRESS books the other widely read ABAP books do not promote any prescriptive style. Some like the “21 day …” book are often an ABAPErs 1st intro. Feet firmly on the ground they focus on FMs, Search Help LDBs etc.

    I read Marilyn’s document “Obsolete ABAP Language Constructs” carefully. It is useful indication of high European standards.

    ABAP is cryptic by nature. MARA MAKTX EKBE EBELN are not good names.
    It is more important to have plenty of half-line comments more than split hairs on “LIKE is obsolete” but “TYPE is OO”.

    Frankly  I find “LIKE” likeable and more “semantic” than the drab “TYPE” word.
    Tables with header lines are an ABAP marvel combining 2 objects in 1.
    When I write BAdIs or OO screens then I have no choice!

    I love LDBs and think they are one of the brilliant inventions of SAP.
    1000s of SAP programs are based on LDB. SAP HR programmers depend on LDB.
    SQ00 SQ01 SQ02 SQ03 are the life-blood of functional consultants and mostly use LDBs.
    I think that the “Obsolete ABAP Language Constructs” does not meet basic reality checks.
    OO should embrace LDB & give OO events for GET & GET LATE and objects for NODES!

    Extended Syntax check does not do all the “Obsolete checks”.

    -jnc/Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Thanks for your comments, and I couldn’t agree more about the importance of good documentation.  Well said.

      About the LIKE keyword I beg to differ however much you like LIKE (and believe me, after years of using that keyword, I too, was cranky about switching styles).  It makes more syntactic sense (hope that’s a word) to have a TYPE point to a dictionary object (and more consistent) and a LIKE point to a local DATA object.  Previously LIKE could point to either and that actually seems less intuitive.  As far as the TABLES statement is concerned, those of you who have had experience with these in the context of passing workareas in the interface of a subroutine in a function module know that the use of these workareas can be tricky and the workarea overwritten  inadvertently.  So “disallowing” TABLES in ABAP OO, is actually a way of forcing integrity.

      Of course rather than nit-pick, I would be very happy to see code that has plenty of clear embedded documentation as you so elegantly stated above.  But understand that if one is training newbies, and that is also an objective of these code samples, it makes sense to train them using recommended programming styles, rather than obsolete style.  As for the LDB, although throughout my 8 years with the ABAP language I have seen major performance improvements, and they make report writing “easy”, I have also experienced that when “ill-used” these can be a performance nightmare (think about the dictum against nested SELECT statements).  The best way to ensure your code is efficient is to make liberal use of performance tools: runtime analysis, SQL trace, and of course the debugger.

      Happy efficient, documented, and elegant coding…
      cheers,
      Marilyn

      (0) 
    2. Horst Keller
      Hi,

      just some remarks:

      1.

      We can’t change all what is already coded in ABAP or already written about ABAP in books. Its part of ABAP’s almost 30 years of history as an ever evolving language. But what we can do is, to try to convince the ABAP community – and what better place is there to do so than SDN – to always do the best with and use the best of ABAP. And with the best, we do not mean features that are still available for historic reasons only.

      2.

      MARA MAKTX EKBE EBELN are no ABAP names!

      Those are type names declared in the data dictionary. Everybody can go and declare what he wants there. Of course it is recommended to use understandable English names nowadays.

      ABAP itself has – admittedly – two Germanisms: sy-uzeit and sy-datum. But the rest of ABAP language and language related data types is clean.

      3.

      There is a clear and simple semantic distinction between TYPE and LIKE. With TYPE, you refer to data types, with LIKE you refer to the bound data types of data objects. That you can refer to dictionary data types with LIKE is unfortunately enforced by ABAP’s bondage to downward compatibility. Therfore, it is not question of liking LIKE but a question of clean programming stayle where to use TYPE and LIKE.

      4.

      I just don’t want to discuss internal tables with header lines any longer (see point 1).

      5.

      LDBs are part of ABAP’s procedural heritage, we have to live with. Nevertheless, if you would invent such a service nowadays, you would offer it object oriented. Therefore, using existing LDBs (and preferrably via function LDB_PROCESS) is no problem. But one should refrain from creating new ones.

      Last but not least:

      “ABAP is cryptic by nature” – It is exactly this negative perception of ABAP that is adressed when we recommend to use only modern ABAP features and to discard the old and obsolete ones. We are working hard in trying to maintain ABAP’s status of a high-level and modern business programming language. Sticking to old and “cryptic” language features just because they are there (for downward compatibility) doesn’t really help us here.

      Already following some simple guidelines – e.g., as they are enforced by the syntax rules of ABAP Objects and in Unicode programs – will make programs more correct, maintainable, well-structured, readable, and robust.

      With kind regards

      Horst

      (0) 
  2. Jayanta Choudhuri
    Apart from SAP PRESS books the other widely read ABAP books do not promote any prescriptive style. Some like the “21 day …” book are often an ABAPErs 1st intro. Feet firmly on the ground they focus on FMs, Search Help LDBs etc.

    I read Marilyn’s document “Obsolete ABAP Language Constructs” carefully. It is useful indication of high European standards.

    ABAP is cryptic by nature. MARA MAKTX EKBE EBELN are not good names.
    It is more important to have plenty of half-line comments more than split hairs on “LIKE is obsolete” but “TYPE is OO”.

    Frankly  I find “LIKE” likeable and more “semantic” than the drab “TYPE” word.
    Tables with header lines are an ABAP marvel combining 2 objects in 1.
    When I write BAdIs or OO screens then I have no choice!

    I love LDBs and think they are one of the brilliant inventions of SAP.
    1000s of SAP programs are based on LDB. SAP HR programmers depend on LDB.
    SQ00 SQ01 SQ02 SQ03 are the life-blood of functional consultants and mostly use LDBs.
    I think that the “Obsolete ABAP Language Constructs” does not meet basic reality checks.
    OO should embrace LDB & give OO events for GET & GET LATE and objects for NODES!

    Extended Syntax check does not do all the “Obsolete checks”.

    -jnc/Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Thanks for your comments, and I couldn’t agree more about the importance of good documentation.  Well said.

      About the LIKE keyword I beg to differ however much you like LIKE (and believe me, after years of using that keyword, I too, was cranky about switching styles).  It makes more syntactic sense (hope that’s a word) to have a TYPE point to a dictionary object (and more consistent) and a LIKE point to a local DATA object.  Previously LIKE could point to either and that actually seems less intuitive.  As far as the TABLES statement is concerned, those of you who have had experience with these in the context of passing workareas in the interface of a subroutine in a function module know that the use of these workareas can be tricky and the workarea overwritten  inadvertently.  So “disallowing” TABLES in ABAP OO, is actually a way of forcing integrity.

      Of course rather than nit-pick, I would be very happy to see code that has plenty of clear embedded documentation as you so elegantly stated above.  But understand that if one is training newbies, and that is also an objective of these code samples, it makes sense to train them using recommended programming styles, rather than obsolete style.  As for the LDB, although throughout my 8 years with the ABAP language I have seen major performance improvements, and they make report writing “easy”, I have also experienced that when “ill-used” these can be a performance nightmare (think about the dictum against nested SELECT statements).  The best way to ensure your code is efficient is to make liberal use of performance tools: runtime analysis, SQL trace, and of course the debugger.

      Happy efficient, documented, and elegant coding…
      cheers,
      Marilyn

      (0) 
    2. Horst Keller
      Hi,

      just some remarks:

      1.

      We can’t change all what is already coded in ABAP or already written about ABAP in books. Its part of ABAP’s almost 30 years of history as an ever evolving language. But what we can do is, to try to convince the ABAP community – and what better place is there to do so than SDN – to always do the best with and use the best of ABAP. And with the best, we do not mean features that are still available for historic reasons only.

      2.

      MARA MAKTX EKBE EBELN are no ABAP names!

      Those are type names declared in the data dictionary. Everybody can go and declare what he wants there. Of course it is recommended to use understandable English names nowadays.

      ABAP itself has – admittedly – two Germanisms: sy-uzeit and sy-datum. But the rest of ABAP language and language related data types is clean.

      3.

      There is a clear and simple semantic distinction between TYPE and LIKE. With TYPE, you refer to data types, with LIKE you refer to the bound data types of data objects. That you can refer to dictionary data types with LIKE is unfortunately enforced by ABAP’s bondage to downward compatibility. Therfore, it is not question of liking LIKE but a question of clean programming stayle where to use TYPE and LIKE.

      4.

      I just don’t want to discuss internal tables with header lines any longer (see point 1).

      5.

      LDBs are part of ABAP’s procedural heritage, we have to live with. Nevertheless, if you would invent such a service nowadays, you would offer it object oriented. Therefore, using existing LDBs (and preferrably via function LDB_PROCESS) is no problem. But one should refrain from creating new ones.

      Last but not least:

      “ABAP is cryptic by nature” – It is exactly this negative perception of ABAP that is adressed when we recommend to use only modern ABAP features and to discard the old and obsolete ones. We are working hard in trying to maintain ABAP’s status of a high-level and modern business programming language. Sticking to old and “cryptic” language features just because they are there (for downward compatibility) doesn’t really help us here.

      Already following some simple guidelines – e.g., as they are enforced by the syntax rules of ABAP Objects and in Unicode programs – will make programs more correct, maintainable, well-structured, readable, and robust.

      With kind regards

      Horst

      (0) 
  3. Jayanta Choudhuri
    Apart from SAP PRESS books the other widely read ABAP books do not promote any prescriptive style. Some like the “21 day …” book are often an ABAPErs 1st intro. Feet firmly on the ground they focus on FMs, Search Help LDBs etc.

    I read Marilyn’s document “Obsolete ABAP Language Constructs” carefully. It is useful indication of high European standards.

    ABAP is cryptic by nature. MARA MAKTX EKBE EBELN are not good names.
    It is more important to have plenty of half-line comments more than split hairs on “LIKE is obsolete” but “TYPE is OO”.

    Frankly  I find “LIKE” likeable and more “semantic” than the drab “TYPE” word.
    Tables with header lines are an ABAP marvel combining 2 objects in 1.
    When I write BAdIs or OO screens then I have no choice!

    I love LDBs and think they are one of the brilliant inventions of SAP.
    1000s of SAP programs are based on LDB. SAP HR programmers depend on LDB.
    SQ00 SQ01 SQ02 SQ03 are the life-blood of functional consultants and mostly use LDBs.
    I think that the “Obsolete ABAP Language Constructs” does not meet basic reality checks.
    OO should embrace LDB & give OO events for GET & GET LATE and objects for NODES!

    Extended Syntax check does not do all the “Obsolete checks”.

    -jnc/Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Thanks for your comments, and I couldn’t agree more about the importance of good documentation.  Well said.

      About the LIKE keyword I beg to differ however much you like LIKE (and believe me, after years of using that keyword, I too, was cranky about switching styles).  It makes more syntactic sense (hope that’s a word) to have a TYPE point to a dictionary object (and more consistent) and a LIKE point to a local DATA object.  Previously LIKE could point to either and that actually seems less intuitive.  As far as the TABLES statement is concerned, those of you who have had experience with these in the context of passing workareas in the interface of a subroutine in a function module know that the use of these workareas can be tricky and the workarea overwritten  inadvertently.  So “disallowing” TABLES in ABAP OO, is actually a way of forcing integrity.

      Of course rather than nit-pick, I would be very happy to see code that has plenty of clear embedded documentation as you so elegantly stated above.  But understand that if one is training newbies, and that is also an objective of these code samples, it makes sense to train them using recommended programming styles, rather than obsolete style.  As for the LDB, although throughout my 8 years with the ABAP language I have seen major performance improvements, and they make report writing “easy”, I have also experienced that when “ill-used” these can be a performance nightmare (think about the dictum against nested SELECT statements).  The best way to ensure your code is efficient is to make liberal use of performance tools: runtime analysis, SQL trace, and of course the debugger.

      Happy efficient, documented, and elegant coding…
      cheers,
      Marilyn

      (0) 
    2. Horst Keller
      Hi,

      just some remarks:

      1.

      We can’t change all what is already coded in ABAP or already written about ABAP in books. Its part of ABAP’s almost 30 years of history as an ever evolving language. But what we can do is, to try to convince the ABAP community – and what better place is there to do so than SDN – to always do the best with and use the best of ABAP. And with the best, we do not mean features that are still available for historic reasons only.

      2.

      MARA MAKTX EKBE EBELN are no ABAP names!

      Those are type names declared in the data dictionary. Everybody can go and declare what he wants there. Of course it is recommended to use understandable English names nowadays.

      ABAP itself has – admittedly – two Germanisms: sy-uzeit and sy-datum. But the rest of ABAP language and language related data types is clean.

      3.

      There is a clear and simple semantic distinction between TYPE and LIKE. With TYPE, you refer to data types, with LIKE you refer to the bound data types of data objects. That you can refer to dictionary data types with LIKE is unfortunately enforced by ABAP’s bondage to downward compatibility. Therfore, it is not question of liking LIKE but a question of clean programming stayle where to use TYPE and LIKE.

      4.

      I just don’t want to discuss internal tables with header lines any longer (see point 1).

      5.

      LDBs are part of ABAP’s procedural heritage, we have to live with. Nevertheless, if you would invent such a service nowadays, you would offer it object oriented. Therefore, using existing LDBs (and preferrably via function LDB_PROCESS) is no problem. But one should refrain from creating new ones.

      Last but not least:

      “ABAP is cryptic by nature” – It is exactly this negative perception of ABAP that is adressed when we recommend to use only modern ABAP features and to discard the old and obsolete ones. We are working hard in trying to maintain ABAP’s status of a high-level and modern business programming language. Sticking to old and “cryptic” language features just because they are there (for downward compatibility) doesn’t really help us here.

      Already following some simple guidelines – e.g., as they are enforced by the syntax rules of ABAP Objects and in Unicode programs – will make programs more correct, maintainable, well-structured, readable, and robust.

      With kind regards

      Horst

      (0) 
  4. Jayanta Choudhuri
    I agree that TYPE is better and Tables with Implicit Header Line is not a best practice.
    The document “Obsolete ABAP Language Constructs” is an excellent guide to clean and current code.

    About LDBs I have doubts however.  The book “mySAP HR: Technical Principles and Programming (2nd Edition)” http://www.sap-press.com/product.cfm?account=&product=H967 Chapter 3 and Chapter 7 clearly indicate the central role of LDB in HR. With InfoTypes and Cluster Tables it is again brilliant SAP design for multi valued time dependent data.
    Some LDBs like ADA (fixed Assets) are light and easy. The SAP data model is wonderful but is not JOIN friendly. Leaving aside POOL & CLUSTER many tables have multiple rows like VBPA & MSEG (XAUTO).
    So we should not exclude SAP HR ABAP Programmers or LDB users from submitting SDN content – they must use TYPE and avoid Implicit Header Lines but can they avoid “PNP”. Moreover SDN code should reflect real working code in real installations many still on older releases that will add value to SAP technical community. Otherwise such code may never see light of day in SDN.
    I therefore request a review of the document to enable SDN to reach out to a wider range of ABAP programmers and not only the “SE24 masters”. SE38 & SE80 & SE37 is ABAP “Bread & Butter”.

    -jnc@Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Jayanta,
      I would really welcome some open and honest discussion around real working code in real installations, as you so aptly describe it.  And you are certainly correct in stating that many folks in the SAP technical community are still on older releases.

      I would like to find a good vehicle to broaden this conversation.  I certainly don’t feel comfortable being an “ABAP Police” and definitely wouldn’t want to inhibit our community from access to valuable code samples nor stifle folks from submitting valuable code.

      The biggest problem is that we don’t have at the moment a good collaborative publishing vehicle or wiki to evolve and review in a community mode, documents.

      Having such a vehicle is a fond wish and some community members (for example The Enterprise and the Bazaar have discussed community code development.  I myself would love to see community publication of a document such as “The Real ABAP Developer’s Guide to Programming” 🙂

      A while back, while posting a document about the older “ABAP Query” , I made such a plea from the community. I hoped that others would contribute to the Primer for Queries and each author would get contribution points for her/his chapters.

      I would love to broaden the conversation.

      Perhaps others will weigh-in and suggest ways of creating such a community guide.

      Thanks, for sparking these thoughts!

      Marilyn

      (0) 
  5. Jayanta Choudhuri
    I agree that TYPE is better and Tables with Implicit Header Line is not a best practice.
    The document “Obsolete ABAP Language Constructs” is an excellent guide to clean and current code.

    About LDBs I have doubts however.  The book “mySAP HR: Technical Principles and Programming (2nd Edition)” http://www.sap-press.com/product.cfm?account=&product=H967 Chapter 3 and Chapter 7 clearly indicate the central role of LDB in HR. With InfoTypes and Cluster Tables it is again brilliant SAP design for multi valued time dependent data.
    Some LDBs like ADA (fixed Assets) are light and easy. The SAP data model is wonderful but is not JOIN friendly. Leaving aside POOL & CLUSTER many tables have multiple rows like VBPA & MSEG (XAUTO).
    So we should not exclude SAP HR ABAP Programmers or LDB users from submitting SDN content – they must use TYPE and avoid Implicit Header Lines but can they avoid “PNP”. Moreover SDN code should reflect real working code in real installations many still on older releases that will add value to SAP technical community. Otherwise such code may never see light of day in SDN.
    I therefore request a review of the document to enable SDN to reach out to a wider range of ABAP programmers and not only the “SE24 masters”. SE38 & SE80 & SE37 is ABAP “Bread & Butter”.

    -jnc@Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Jayanta,
      I would really welcome some open and honest discussion around real working code in real installations, as you so aptly describe it.  And you are certainly correct in stating that many folks in the SAP technical community are still on older releases.

      I would like to find a good vehicle to broaden this conversation.  I certainly don’t feel comfortable being an “ABAP Police” and definitely wouldn’t want to inhibit our community from access to valuable code samples nor stifle folks from submitting valuable code.

      The biggest problem is that we don’t have at the moment a good collaborative publishing vehicle or wiki to evolve and review in a community mode, documents.

      Having such a vehicle is a fond wish and some community members (for example The Enterprise and the Bazaar have discussed community code development.  I myself would love to see community publication of a document such as “The Real ABAP Developer’s Guide to Programming” 🙂

      A while back, while posting a document about the older “ABAP Query” , I made such a plea from the community. I hoped that others would contribute to the Primer for Queries and each author would get contribution points for her/his chapters.

      I would love to broaden the conversation.

      Perhaps others will weigh-in and suggest ways of creating such a community guide.

      Thanks, for sparking these thoughts!

      Marilyn

      (0) 
  6. Jayanta Choudhuri
    I agree that TYPE is better and Tables with Implicit Header Line is not a best practice.
    The document “Obsolete ABAP Language Constructs” is an excellent guide to clean and current code.

    About LDBs I have doubts however.  The book “mySAP HR: Technical Principles and Programming (2nd Edition)” http://www.sap-press.com/product.cfm?account=&product=H967 Chapter 3 and Chapter 7 clearly indicate the central role of LDB in HR. With InfoTypes and Cluster Tables it is again brilliant SAP design for multi valued time dependent data.
    Some LDBs like ADA (fixed Assets) are light and easy. The SAP data model is wonderful but is not JOIN friendly. Leaving aside POOL & CLUSTER many tables have multiple rows like VBPA & MSEG (XAUTO).
    So we should not exclude SAP HR ABAP Programmers or LDB users from submitting SDN content – they must use TYPE and avoid Implicit Header Lines but can they avoid “PNP”. Moreover SDN code should reflect real working code in real installations many still on older releases that will add value to SAP technical community. Otherwise such code may never see light of day in SDN.
    I therefore request a review of the document to enable SDN to reach out to a wider range of ABAP programmers and not only the “SE24 masters”. SE38 & SE80 & SE37 is ABAP “Bread & Butter”.

    -jnc@Kolkata

    (0) 
    1. Marilyn Pratt Post author
      Jayanta,
      I would really welcome some open and honest discussion around real working code in real installations, as you so aptly describe it.  And you are certainly correct in stating that many folks in the SAP technical community are still on older releases.

      I would like to find a good vehicle to broaden this conversation.  I certainly don’t feel comfortable being an “ABAP Police” and definitely wouldn’t want to inhibit our community from access to valuable code samples nor stifle folks from submitting valuable code.

      The biggest problem is that we don’t have at the moment a good collaborative publishing vehicle or wiki to evolve and review in a community mode, documents.

      Having such a vehicle is a fond wish and some community members (for example The Enterprise and the Bazaar have discussed community code development.  I myself would love to see community publication of a document such as “The Real ABAP Developer’s Guide to Programming” 🙂

      A while back, while posting a document about the older “ABAP Query” , I made such a plea from the community. I hoped that others would contribute to the Primer for Queries and each author would get contribution points for her/his chapters.

      I would love to broaden the conversation.

      Perhaps others will weigh-in and suggest ways of creating such a community guide.

      Thanks, for sparking these thoughts!

      Marilyn

      (0) 

Leave a Reply