2

There are parameters that I would not want to be transferred from production environment to QA system. Staff like network path and url's. The problem is that in ABAP everything is in the database and when the database is copied to the QA system you have to manually change those parameters. And this is prone to errors.

Is there a way to store configuration information in a way that won't get transferred with the database?

Thanks.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Igal Serban
  • 10,558
  • 3
  • 35
  • 40

3 Answers3

2

In short: no - at least that would be very unusual in a SAP environment.

If your QA system is set up as a system copy of your production environment (which is the usual path), there are quite a few steps to do to make the system work correctly. This includes some configuration, which can be as simple as filepaths such as you mention, but also the addresses and names of "partner systems". For example, one of my customers is a bank, so when copying his production system, he makes triply sure that no activity on the QA side accidentally trickles to the production side. Some other changes are made as well, for example obscuring peoples names and addresses so no mail gets accidentally sent etc.

There are a few ways to make applying these changes as easy as possible (look for some SAP documentation or books on SAP Transport and Change management, I had one by Sue McFarland Metzger or so that was quite good). From what I've seen, there is usually a set of transports that change the configuration and customizing etc. on the QA system to the appropriate values.

Hope that helps.

Thorsten
  • 12,921
  • 17
  • 60
  • 79
  • 1
    Thanks. What you describe is, more or less, what we do. It is just hard for me to believe that there is no better way. I still believe that somehow it should be a one click affair. But your answer is what I hear all the time. And scripting it is too fragile. so... – Igal Serban Jan 06 '09 at 22:44
  • Your comments are true .. but making a copy should be a pretty rare event. If not something else is wrong ... – Thorsten Jan 06 '09 at 22:46
  • Maybe something else is wrong. But we do it quite often on one of our qa, integration or training environments. – Igal Serban Jan 06 '09 at 23:24
  • 2
    We make quarterly copies as well, to both our QAS and Training systems. Unfortunately we have not found a better way to do this either. As part of the QAS Refresh Our Basis Team downloads the table contents of the necessary tables prior to the refresh and uploads it again afterwards. – Esti Feb 11 '09 at 03:17
0

You cannot prevent the configuration stored in the database from being copied to the cloned instance. However, you can design the configuration storage in a way that will prevent the copied entries from being used. You should check with your basis administrators if they can guarantee that the cloned system will get a new system ID (SID). If this is the case, then you can simply use the SID as key field in your configuration table. After the system copy, the SID will be changed and the cloned system will no longer access the original entries.

vwegert
  • 18,371
  • 3
  • 37
  • 55
0

your question is not clear, are you talking about standard or custom config ?

Greetings, assuming you are storing these paths in a Z table, then some shops put the sy-sysid ( system id ) as one of the columns. Maintain all systems in your dev and transport to production. This becomes painful after a while, so I would only suggest this for information that does not change a lot ( file paths might be good ).

T.

tomdemuyt
  • 4,572
  • 2
  • 31
  • 60
  • Lets say I want to write a file to some share. In production and in qa the share is in different path. Where should I store the path? – Igal Serban Jan 06 '09 at 21:52