Custom Transaction codes overwritten during transports

[Former Member]

Hi,

When I create custom queries in my production client, assign transaction codes to them, and assign them to roles they get overwritten every time I perform a transport for those roles. We are still at an early stage of implementation and there are still some daily authorization changes that require a transport from test to production. When the roles are transported it wipes all my reports (transaction codes) assigned to these roles in the production system. Is there a way to perform a transport without wiping out the customizations made to the role in the production system like these?

Thank you,

Sergiy

[Former Member]

Hi Sergiy,

If you create your queries / transactions and assignments to roles in the same system which you are using for creating / changing the roles, then your problem would be easily solved by transporting them together - or at least keeping the systems in sync when you change a role which does not affect the queries transactions.

Changing roles in production is a "no-no" in many system landscapes...

Changing queries in production is a "no-no" in some systems too.

Cheers,

Julius

[Former Member]

Julius,

we are trying to have some super users create their own reports/queries. Also, learning these things, the book: SAP Query Reporting that I bought a couple of months ago actually recomends creating queries in the production client. Transporting them over every time you need to tweak a report just takes a lot of time. This would be fine but then how do you create transactions for those queries in production and not get them overwritten during the next transport for the role.

[Former Member]

Hello Gergiy,

There are other SDN Security forum contributors who are more more knowledgable about queries than myself... (I dont use it in production). So I suggest hanging on until tomorrow (when they are awake for an answer.

Certainly it would help to know which release and installed components you are talking about...

Generically speaking, changing roles in production is not a good idea. It will back-fire on you when you want to test the same role (or the access of the user...) for other changes in your test system or wipe out changes as you have experienced (keyword is "version management").

If my memory is correct, changing a role in production from PFCG will also require that your client is open for changes. That can have a bigger potential impact than just changes to roles.

Perhaps there is a workaround using "reporting tree menus" mentioned in the book you have mentioned?

Cheers,

Julius

[Former Member]

The answer is in the way one works with BI (or BW).

If the design is that queries are to be created in production (which is often used). As far as i know the only exception on the rule that everything should be build in DEV. And this is the only good way as you do not want end-users to work in DEV. There are some things to know about the way SAP works.

If a role is changed in DEV and transported to PROD all queries assigned to the role in PROD will be disconnected.

Solution a role to be used in PROD were queries will be assigned to should never be transported again.

Solution in detail, there should be roles for different use:

1. Access to Info providers in version read and write.

2. Access to publish reports in roles per query role.

3. Query/Menu roles per info area.

Roles 1 and 2 allow for access and can be transported as often as you want. Role 3 is only to be used as a container of queries to be used by end users and should NEVER be transported again (best practice is to delete if in DEV after transport and NOT assign it to a transport before deletion).

In the publisher role it can be arranged to which role(s) the publisher can assign reports. It is also possible to force users to use a report naming convention in this role.

[Former Member]

One additional remark. There is absolutely NO NEED To add queries with a customer transaction code in PFCG.

It can all be done in the BEX analyser by the publisher so no need to give access to PFCG to those people. which should never be allowed.

[Former Member]

Hi Auke,

Thank you for the infos and insights.