Please find the Source Code and User Manual as links below.

Note:

Check this document regularly for latest version source code.

___________________________________________________________________________________________

      Whether it is a functional or technical transaction or a basis transaction, everything in SAP or for that matter in any technology, boils down to database, and as we know database means tables. Apart from the standard tables that SAP has, a business will usually have to create many ‘Z’ tables for its custom development. Many times a business ends up with hundreds of custom tables and always their maintenance is a real cause of concern as the usual maintenance tools in SAP have their own issues. Usually, a table in SAP can be maintained in three ways,   

            1.Through ‘SM30’ (Table Maintenance)

            2.Through SE11 

            3.Via custom transaction.

The concerns with each of this are listed below:

 

1. Through ‘SM30’ (Table Maintenance)

  • Logs the changes (Tcode – SCU3), but doesn’t record the field specific changes clearly (check table ‘DBTABLOG’).

 

  • Not so easy to restrict authorizations for a particular table for each individual user.

 

  • The screen is a narrow container and the user interaction is not so comfortable especially when the table has many fields or has long text fields.

 

  • When there are many entries to be entered in the table, there is no option to upload the entries from an Excel or CSV etc.

2. Through SE11

  • Logs the changes (Tcode – SCU3), but doesn’t record the field specific changes clearly (check table ‘DBTABLOG’).

 

  • Poor security.

 

  • No option to upload.

3. Via a custom transaction

  • Requires developing a standalone program for each table which again is a problem as it ends up in hundreds of programs to maintain hundreds of tables.

 

  • Again, problems with maintaining authorizations for each table for an individual user.

 

My tool, ‘SAP Table Maintenance Tool’ called ‘ZTMTOOL’  is a solution to all the above concerns and makes the table maintenance simple and secure. Some of the features of this tool are:

1. Security:

    Any table can be restricted or allowed for maintenance for any user just by adding an entry in a

    table ( called ZTMT_MATRIX).

2. Change History:

    All the changes (i.e., create,edit,delete) are logged into a table (called ZTMT_HISTORY).

3. Upload option:

    Records can also be created in  large numbers at once, just by uploading data as excel

    or CSV formats.

4. Look and Feel:

    All the maintenance can be done in a neat looking ALV Grid with a very easy user interaction.

5. Dynamic Selection:

    A dynamic selection screen for any table to view desired entries based on selection criteria.

 

6. Flexible ALV output:

    The ALV output displays the needed columns or fields as selected by the user.

 

7. Easy Maintenance:

    Apart from the key fields, a user can just opt to view and maintain only the needed fields.

 

8. Long  Text Fields:

    Simple maintenance of long text fields (> 128 characters) in a popup window with a text editor.

 

 

How to implement this tool?

  • Download the source code attached (Sourcecode.txt).

 

  • Goto TCode ‘SE38’ and create a new program ‘ZTMTOOL’.
  • Copy and paste the code from the downloaded file ‘Sourcecode.txt ‘.

 

  • Activate and run it.

 

  • In the initial run, the program prompts a decision popup to create; the authorizations table for this tool called ‘ZTMT_MATRIX’, changes log table called ‘ZTMT_HISTORY’ and the Tcode ‘ZTMTOOL’. Program automatically creates all these objects once the user clicks on ‘Approve’. If denied, the program retries and prompts again for the next  4 runs.
  • A user has to be authorized to maintain a particular table by maintaining an entry in the authorizations table ‘ZTMT_MATRIX’. Authorizations can be maintained for each specific maintenance operation such as ‘Create’,’Change’, ‘Delete’, ‘Upload’  by setting the relevant flag as ‘Y’ or ‘N’. The additional flag ‘FLG_CHK’ in ‘ZTMT_MATRIX’ is to tell the program if domain/checktable validations needs to be considered. If this is set as ‘N’, no validations take place and one can enter any junk value into the table.

On how to use this tool go through the user manual below:

 

Untitled.jpg

   This is cover page, click on the link below to download/view complete user manual:

 

   ZTMTOOL Manual.pptx – Google Drive

   Source Code

To report this post you need to login first.

37 Comments

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

  1. Vinay Kumar Dalapathirao

    Hi Rashmith,

    I have gone through your tool. That’s very useful instead of giving table SM30 view to user or writing so much lines of code for maintenance screens. I observed that we can give authorizations for user to particular table. I ran the program and got to know one functionality that was creating tables in the first run of program automatically. Thanks for sharing with us such a nice tool. Keep sharing.

    Thanks,

    Vinay Kumar Dalapathirao

    (0) 
  2. Colleen Hebbert

         Any table can be restricted or allowed for maintenance for any user just by adding an entry in a

         table ( called ZTMT_MATRIX).

    That is not good security.


    You mention reason why security is hard:


    Not easy to restrict authorizations for a particular table for each individual user unless one is a Basis expert


    That’s basic PFCG security build for access to S_TABU_NAM or S_TABU_DIS. It’s the same access you would need to provide for a user to have access to your Z table ZTMT_MATRIX, however, you would have change documents and users would receive access via role assignments (easier to mass maintain)


    A developer should know how to build security role and code an authority check.


    If a z table requires mass updating then a program with business logic validation built into it would be a better option than direct updates to a table.



    (0) 
    1. Simone Milesi

      All Colleen wrote, plus why this choice?

      Change History:

           All the changes (i.e., create,edit,delete) are logged into a table (called ZTMT_HISTORY).

      What’s wrong with standard SCDO and change history management?

      It’s a bit long to write, but can be done without any big problem to develop a generic wrapper for using the FM generated by SCDO

      (0) 
    2. Rashmith Tula Post author

      Thanks Colleen Lee – SCN Member of the Month June 2014, and Simone Milesi

      Thanks for your opinion/feedback. I agree with you. I didn’t mean that the authorizations are not possible in SAP. I know authority checks and PFCG role, but what I meant was different (Thank you, I corrected my document).

      Through SM30 and SE16 we wouldn’t not know who changed what and when in a table, which is possible through this tool. And, when some minor urgent maintenance has to be done to a Z table, instead of getting the authorizations assigned and roles modified, this is comparatively an easy and quick alternative where a senior technical lead would control the authorizations through the table ‘ZTMT_MATRIX’ saving the time and getting the work done with the changes logged in ‘ZTMT_HISTORY’ which are easy to understand for anybody, like in CDPOS. Ofcourse, SCDO logs the changes, but for each table, it generates few includes and a FM which have to be included in our custom maintenance program which will again lead to the same problem as I have mentioned in my document.


      3. Via a custom transaction

      • Requires developing a standalone program for each table which again is a problem as it ends up in hundreds of programs to maintain hundreds of tables.


      Regards,

      Rashmith.

      (0) 
      1. Simone Milesi

        It’s a bit long to write, but can be done without any big problem to develop a generic wrapper for using the FM generated by SCDO

        Using the words from Anne McCaffrey’s characters “It had already been done. Could be done.”

        (0) 
        1. Rashmith Tula Post author

          Yes Simone Milesi, you are right.I never said that it can’t be done. Try to understand.


          This tool is developed to avoid many individual programs for many individual tables for even simple maintenance. But, by SCDO, we end up again in the same problem.

          (0) 
          1. Simone Milesi

            No, it’s exactly what i’m saying: you can develop  a single generic wrapper that manage the all the SCDO FMs so you can call it for every table you want.

            If i find my old project with it, i’ll post here to explain better 🙂

            (0) 
  3. ajay anireddy

    Thank you for sharing this tool. It would make the life easy for a developer with proper authorizations to update different tables using this tool.

    (0) 
  4. Matthias Bucher

    Thanks for sharing your source code. We solved this by extracting the ERPs SE16N (located in CO module) to be used in plain NW ABAP systems also. SE16N contains generic, auth & change history already.

    (0) 
    1. Rashmith Tula Post author

      That’s nice. Could you please explain more in detail what you actually did so that it will be helpful for those whoever visit this page.

      (0) 
      1. Matthias Bucher

        we copied the SE16N relevant content from the CO package WUSL in our namespace. But this is not sufficient to get it running on a blank netweaver abap due to usage of other ERP DDIC objects.

        So we replaced all dependencies to ERP related stuff with objects in our namespace. This caused some work because the package checks (in the source system) are not sufficient to detect all of these dependencies. So we need to transport our /…/SE16N version again and again in a blank system to find & remove all ERP usage.

        But finally we have a “generic” /…/SE16N with our permission checks, &sap_edit and all the protocol tables. Due to HANA, also the original SE16N was revised, so we can understand and merge these changes to our code.

        Please keep in mind that it might not a good idea to ship a copy of SAP code to customers which don’t have the appropriate (in this case) ERP license.

        best regards,

        Matthias

        (0) 
    1. Rashmith Tula Post author

      Hi Robert Forster

      First of all Thank you very much for patiently going through my document. I am sorry that I couldn’t put my point across appropriately (Thanks, I corrected it now). I didn’t mean that the changes cannot be logged at all, I meant that the field specific changes can’t be logged. Of course, they are logged in table ‘DBTABLOG’ but the field ‘LOGDATA’ is in unreadable format (hexadecimals). So, in effect I said that the changes are not logged. All that we can know is which key is edited by whom, when and through which transaction but we can’t read which field was changed from what to what like in ‘CDPOS’ table. But, through this tool changes are very clearly logged.

      Regarding upload, I know BRF+ but I didn’t know that uploads can be done through it. Please share how this can be done, in detail if possible.

      And Thanks for your advice.  I’ll learn the basics 🙂 .

      Regards,

      Rashmith.

      (0) 
  5. Juwin Pallipat Thomas

    Cardinality checks?

    Table specific validations?

    Option to view table logs?

    Idea is good, but I think you may need to simplify a lot of things and try to use SAP provided functionality in a better way (eg. what @simone.milesi has mentioned above).

    Thanks,

    Juwin

    (0) 
    1. Rashmith Tula Post author

      Please comment after you test the tool yourself. No imagination please. Checks, Validations and Table logs, everything is accommodated.

      (0) 
  6. Jelena Perfiljeva

    Obsolete function modules, hard-coded texts, Z tables, BDC, tons of variables like “WA TYPE REF TO DATA”, “seperator” and that’s just from a quick look… Nice idea but I’ll pass, thanks.

    (0) 
    1. Matthew Billingham

      Obsolete function modules and BDC are particularly risky since these are prone to change from version to version.

      Meaningless variable names and a huge number of global variables is a risk since it means the code is more likely to be buggy.

      Notwithstanding the utility (or otherwise) of this program, it would never get to production in most of my clients’ sites, on the grounds of not very good design.

      (0) 
      1. Rashmith Tula Post author

        Thanks Matthew Billingham for your feedback, I have noted your suggestions and they will surely help me for my future work.


            I ensured that the obsolete FMs that I have used didn’t change from last version and these are simple ‘POPUP’ FMs which, even if change wouldn’t have any effect on the functionality of the tool.


           This tool have so much functionality that so many variables have to be declared. In some complex functionalities, for a one time simple operations, separate variables have been declared instead of re-using already used ones to avoid unnecessary bugs and complexity. As far as possible, these variables are named very reasonably and for other variables, I preferred to keep their names one lettered for simplicity.


           BDC is used only during the first run of the program to auto create ‘PF-Status’ for users’ convenience. But, this wouldn’t even get executed if user has already created it. Even if the BDC fails, an alternative standard PF-Status is used.


          As far as the design is concerned, I have already got positive feedback from many users and its in the production of few known clients. But, will try to address few concerns you have raised.


        Regards,

        Rashmith.

        (0) 
        1. Matthew Billingham

          Customers are only concerned with the look and feel, not with the internal architecture. I don’t doubt that many people love what you’ve written as an application.

          I know a commercial SAP application that was well liked by the end users. But when the company was asked for additional features, because they actual coding was so poorly designed, they couldn’t make those changes quickly enough (the code kept breaking as they tried to change it). In the end, the customers went elsewhere for their additional features.

          Another issue is that if code posted on SCN isn’t optimal, it’s not a good example for newbies.

          The biggest issue for me is the number of globally defined variables. That indicates poor encapsulation.

          On that subject, here’s some reading for you.

          http://c2.com/cgi/wiki?GlobalVariablesAreBad

          Are you writing “evil” ABAP code?

          If you must use Forms instead of OO, then parameterise them. Decent encapsulation is key to writing good, maintainable ABAP code.

          (0) 
            1. Rashmith Tula Post author

              😆 Good example but I think not exactly relevant,


                   Unauthorized Access: I assure that this program is very safe to be used in any production systems. If you may say that this tool may help unauthorized people modify very confidential/sensitive tables, then you need to think that if he has authorization to create a new program in ‘SE38’ and copy this code (ZTMTOOL), it means that he also has authorization to write ‘Create, Update and Delete’ statements for any table in his program. So, in effect, this tool doesn’t pose any additional risk.


                   Security: For the concernthis tool may even subvert its own securityexpressed by Paul Bakker,  I already explained ‘Nobody can use this tool unless they have been given authorizations in ‘ZTMT_MATRIX’ table. Even to edit ‘ZTMT_MATRIX’, one needs to have authorizations maintained in itself(ZTMT_MATRIX)’. And the authorization to change ‘ZTMT_MATRIX’ is intended to be only in the hands of some BASIS admin or so. If anybody manages to somehow manipulate ‘ZTMT_MATRIX’ programatically, nobody can help it. Then this question can be raised even for SAP standard applications.


                   Obsolete FMs: I ensured that the obsolete FMs that I have used didn’t change from last version and these are simple ‘POPUP’ FMs which, even if change wouldn’t have any effect on the functionality of the tool.


                   Hard-coded Texts: Selection Texts and Headings are hard-coded instead of Text-Symbols, only for users’ convenience. Otherwise, for anyone its difficult to copy so many selection texts and create Text-Symbols. I understand that it is not the ideal practice, but I don’t think it is worse considering user’s ease.


                   Z tables: I don’t think its crime when they are well designed. What’s the option if we need to make it simple for the user to see the changes log without having to do additional configuration?


                   BDC:  BDC is used only during the first run of the program to auto create ‘PF-Status’ and the two Z tables, just for users’ convenience. But, this wouldn’t even get executed if user has already created them. Even if the BDC fails, an alternative standard PF-Status is used and the tool still works without those two Z tables.


                   Tons of variables: Yeah! not a good practice. Pardon me! I am helpless. Users’ ease and convenience was my primary objective. I could have highly optimized the code by using classes and methods but it wouldn’t have been so simple (copy & paste) as now to implement this tool, rather I would have had to generate nugget and slinkee files complicating the whole execution.


              This is not to justify few mistakes that might have been committed. I highly respect your suggestions/corrections and thank you for that. But, there is no need of any apprehension about the tool’s potential harm/danger.

              Regards,

              Rashmith.

              (0) 
              1. Matthew Billingham

                The tons of variables issue doesn’t require OO to resolve. There are two things you should do.

                1. Declare variables locally to the FORMs, where the values don’t need to be transferred
                2. Use parameters on the FORMs where values do need to be transferred.

                The issue with obsolete FMs is that at any time in a new release, SAP may remove them entirely.

                (0) 
  7. Paul Bakker

    Huge effort, and very brave of you to put your code up for public scrutiny. Ah well, this is how we learn. 😎

    I don’t want to kick a fellow developer when he’s down, but here are my 2 cents:

    • the code is ‘challenging’ to read due to a serious lack of comments
    • this could be a dangerous tool because – by doing direct updates – it subverts any authorization checks on existing Z tables. And some of those tables may be very sensitive indeed.
    • might this tool even subvert its own security by manipulating the ‘MATRIX’ control and ‘HISTORY tables?
    • maybe you should consider using some more up-to-date programming techniques. BDC is not even allowed at my current client site.

    Keep on coding!

    (0) 
    1. Rashmith Tula Post author

      Thanks Paul Bakker.

      My privilege to have your comment on my document. I regularly follow your posts.


        Nobody can use this tool unless they have been given authorizations in ‘ZTMT_MATRIX’ table. Even to edit ‘ZTMT_MATRIX’, one needs to have authorizations maintained in itself(ZTMT_MATRIX).

          BDC is used only during the first run of the program to auto create ‘PF-Status’ for users’ convenience. But, this wouldn’t even get executed if user has already created it. Even if the BDC fails, an alternative standard PF-Status is used.

      As you know, there is no code without bugs (even SAP standard programs). We can only minimize bugs and I have ensured this by thorough testing.

      Regards,

      Rashmith.

      (0) 
  8. Nikos Giannopoulos

    Good evening.

    I have tried to create your program by copying the code in the text file.

    But in the code check i am receiving the message in the screen.

    Any suggestions?

    Thank you very much,

    Nikos

    /wp-content/uploads/2016/08/1_1007542.jpg

    (0) 
    1. Rashmith Tula Post author

      @swapnil.kokane

      Sorry for the late reply, I was inactive for few days due to my work.I didn’t notice that the source code attachment is lost in the migration of SCN to Beta. I have now provided the link for the source code. Please check.

       

      (0) 

Leave a Reply