Skip to Content
avatar image
Former Member

Question about security in ABAP developer client

We are in the middle of an implementation and now preparing to allow programmers to start developing ABAP programs. Do you allow programmers to have business function transactions in the ABAP developer client? Our developers are asking for business transactions so they can test changes without making those changes active. We are just looking for gotchas or best practices in setting up this developer client.

Thanks,

Andy

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

6 Answers

  • Best Answer
    Sep 14, 2010 at 01:41 PM

    Hi Andy,

    You will probably get a lot of different opinions here.

    My take on it is that I am happy granting access to business tx in the dev client. The developers cannot code in isolation and good developers will have sufficient knowledge of the process to check for expected outputs from the code. An area for consideration is ensuring that they are correctly processing the business transactions to ensure that their development works in the context in which it is intended. For this reason the dev client should also include up to date configuration and some master data.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      > You will probably get a lot of different opinions here.

      Which triggers me to post a (rare) "me too". I second Alex' opinion and for the same reason.

  • avatar image
    Former Member
    Sep 14, 2010 at 07:45 PM

    How is the developer going to unit test their application if they or a test user they have access to cannot start or use the transaction?

    Do you have productive data in your development system which developers should not have access to? That is not a good idea...

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 14, 2010 at 07:46 PM

    Disclaimer: I'm a developer and thus you might find my posting a bit biased... 😉

    By definition a developer should at least have access to transactions like SE38, SE37, SE80 and debugging authorization. Using those you can already roam around fairly good even if you don't have business transactions (especially a skilled developer can whip up lots of stuff in short time). So what additional harm could they cause if they have <em>business transactions</em>? I can't see any, unless you have really crappy developers screwing the system - but they most likely do actually more harm by coding than by using the business transactions.

    The more interesting question is in my opinion what data you have available in the development client. Obviously it's impossible to hide any data via security settings from a developer: They must be able to create programs, so they can write any query they want (and even the encrypted data like credit card information is most likely not safe). I feel that having a client that reflects as much production as possible is ideal, because it allows easy testing of business functionality and moreover facilitates writing of good and efficient programs (kind of tough otherwise to optimize for example queries). Obviously a company might actually need though to keep some data secret - if that's just a small subset, the ideal solution would be in my opinion just to change/obfuscate those data sets. It's unfortunate if that's not possible.

    Our developers are asking for business transactions so they can test changes without making those changes active.

    Now this came as a surprise to me. Maybe I'm missing some important piece here, but I'm fairly convinced that you cannot test inactive changes outside of the coding environment. I.e. if I write a program in SE38 I don't need to activate it, but I can test already my inactive version (and everybody else who'd try to execute the program would get the current active version). However, if I write for example a BAdI implementation to code some additional functionality in an existing business transaction, I'd have to activate my changes to test it (and please anybody correct me if there's some nice new functionality that I'm missing). So to me the arguments from your developers sound a bit fishy. However, by not granting access to business transactions I think you basically just make their life harder and provoke less quality in the developments.

    Cheers, harald

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 14, 2010 at 08:34 PM

    Thank you for the helpful replies.

    In our development system we have a prototyping client (130) and an abap developer client (120). Our developers are just now starting to develop code and we want to be sure to setup the 120 client the best way the first time. The Basis view was for the developer to activate the code and verify with data in the prototyping client and no data or transaction access in developer client.

    I can see the need to have data in the developer client so that can do a visual check that the program runs. I can also see that it will be easier to just give them the transactions they have already have in the prototyping client in the developer client. This does not sound out of line with what other people are doing.

    Andy

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      The prototyping client and developer client are both in our DEV system. Full testing is done in QAS. I think this is what you mean.

      Andy

  • Sep 15, 2010 at 03:57 AM

    Hi,

    One common pattern which I see is to have 3 clients in DEV box. The first client is used for development and config only. Here developers and functional guys create their transports with all changes. Another client is used for unit testing. This client has a small sample of master data. The released transports from the first client are automatically imported into this client therefore config is "synchronized". No direct changes in config are allowed here. Only changes via transports (sometimes with help of SCC4). This helps you to keep this client in good shape for unit testing. Usually, there is another sandbox client which is open for changes and anybody can do whatever he wants. This is wild wild west and quality goes down pretty quickly. Hence usually is very often refreshed from unit testing client.

    Some customers want to keep the first client free from any master data or transactional data. So it might be helpful to do not add authorization to run any business transaction in this client but I can tell that developers are really lazy persons :-). It's easier to log on to another client than create your own data for testing. So if functional guys don't create any testing data in development client then they won't bother to run business transactions. Only SAP scripts are pain in the ass for this scenario.

    Cheers

    Add comment
    10|10000 characters needed characters exceeded

    • Hi,

      I mentioned that they are imported automatically after release to QA system. The order might be a problem. But you import only config cause development objects are client independent (for simplicity ignore SAP scripts). I've never said that this is the best option. I just wrote my advantages and your wrote disadvantages 😊

      Cheers

  • avatar image
    Former Member
    Sep 15, 2010 at 09:41 PM

    This message was moderated.

    Add comment
    10|10000 characters needed characters exceeded