Question about security in ABAP developer client

[Former Member]

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

[Former Member]

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.

[jurjen_heeck]

> 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.

[Former Member]

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

[Former Member]

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

[Former Member]

> 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.

Now that you mention it, I faintly suspect that possibly but hopefully not, this "development client" is in the same SID as the "productive client"...?

Some programs have a test or simulation mode, which do rollbacks (shiver at the thought of debugging in this client...) or simply don't commit any work. Some but not all of them check display authority for the functionality if the test-flag is set, otherwise it checks the update activities as usual.

Could be...?

Cheers,

Julius

[Former Member]

In one of my recent projects We had Developer roles ( Developer/configurator client )

built which contained all that a developer needs but removed all critical transactions including Basis and security roles.

We eventually gave a SAP_ALL type Developer role because of the 101 security requests

Did the same for configurators .

But in UNIT testing client we tried our best to have a

Developer display role. ( superficially close to 100% display )

Configurator display role. -"-

just to make sure they dont make any changes in the UNIT test client

[Former Member]

In one of my recent projects We had Developer roles ( Developer/configurator client )

built which contained all that a developer needs but removed all critical transactions including Basis and security roles.

We eventually gave a SAP_ALL type Developer role because of the 101 security requests

Did the same for configurators .

But in UNIT testing client we tried our best to have a

Developer display role. ( superficially close to 100% display )

Configurator display role. -"-

just to make sure they dont make any changes in the UNIT test client

[Former Member]

Julius, I understand what you're saying, but my comments were meant more restrictive on coding level, not on a data level. I.e. if I do any code changes, I usually have to activate my changes (there's few exceptions where changes are automatically immediately active). Now, without that activation, I can still test my inactive version from a coding transaction like SE38, but if I'd implement a BAdI for equipment updates, I wouldn't see any of my inactive functionality when running the business transaction IE02.

[Former Member]

> But in UNIT testing client we tried our best to have a Developer display role. ( superficially close to 100% display )

Essentially this means that your developers probably did not do any production support. Otherwise you'd shoot yourself in the foot with such limitation...

p.s.: Usually [unit tests|http://help.sap.com/saphelp_tm70/helpdata/en/a2/8a1b602e858645b8aac1559b638ea4/frameset.htm] are done in the development client, often as part of running code inspector. Most people stick to the [Wikipedia unit test|http://en.wikipedia.org/wiki/Unit_test] definition and I suspect you mean something like your test or quality assurance system. Sorry for this little terminology sidetrack...

[Former Member]

Hi Harald,

I understood (and agree) but thought "out of the box" for a moment that the development client might be "inside the box"...

Lets wait for the OP to clarify why there is a concern in DEV.

Cheers,

Julius

ps: In one of my recent projects I got Chuck Norris to do an ENDLOOP before the next recursive SELECT.

Edited by: Julius Bussche on Sep 14, 2010 10:28 PM

[Former Member]

Hi The UNIT test client resided in the DEV landscape itself

UAT /integration testing client resided in the QA environment.

[Former Member]

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

[Former Member]

Seems like an overkill to me...

They might start writing programs with client specified selects and not remove them.

Rather give them a sandbox and a usefull test system and keep important config in DEV and transport it.

People find all sorts of workarounds when transporting is too painfull from DEV to TEST systems...

Cheers,

Julius

[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

[martin_voros]

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

[Former Member]

> The released transports from the first client are automatically imported into this client therefore config is "synchronized".

Well... there is the catch ...

A released transport cannot be modified, so you might as well import it (automatically?) so you might as well use a transport landscape with a QAS (or pre-QAS) system accessible to the developers, but with QAS roles (and not client-specific roles).

You also need to consider all client-independent changes and "hot-fixes" of those for testing purposes.

I have a system landscape running on 9-tier SIDs, 55 clients in total, 3 different release levels within the same "pipeline" and the user admin is managed from a CUA.

SolMan does not support parrallel maintenance of roles, so we have to do that part manually in two parallel DEV systems. (release dependent SU24, upgrades, PFCG, etc).

That is an extreme example, but also for less complex landscapes mixing development work with prototyping and realistic testing in the same SID is error prone.

Many security related tasks are client indepndent. Transaction Su25 steps 2a and 2b are good examples.

Su25 2c and 2d less so, particularly if you have used composite roles and someone releases a transport while you are upgrading DEV....

IMO it is always best to keep things as simple as possible, and people understand SIDs (if nothing else). The system does the same to a large extent. In the case of roles this is very important and often misunderstood.

Cheers,

Julius

[martin_voros]

Hi Julius,

just some notes. I didn't say that customers don't not have QAS. The transports are imported into another client automatically after release to QA system. As I said this helps you to keep unit testing client in good shape for testing. So developer can feel more confident after running his unit tests in testing client before releasing for another round of testing in QA system. It also helps developers during development. You can make your change and test it immediately (test it with some limitations). Obviously, it has some restrictions as you mentioned. For example you are limited what you can prototype because some things are client independent.

Cheers

[Former Member]

Hi Martin,

Imagine over time how many released transports you have which are not imported.

Imagine someone importing them in the wrong sequence, or all of them?

I prefer to keep it simple per SID and control MANDT via SCC4 if needed. System debugging is only on sandboxes

That way you can classify the systems (some might have prod data..) and assign roles SID specifically (with only SID in the naming convention of the role, and not MANDT).

Works for me and you dont need a rocket scientist at the helpdesk...

Cheers,

Julius

[martin_voros]

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

[Former Member]

This message was moderated.