如何存储配置数据以便在数据库复制时不复制它?

发布于 2024-07-11 06:44:44 字数 163 浏览 7 评论 0原文

有些参数我不想从生产环境转移到 QA 系统。 工作人员喜欢网络路径和网址。 问题是,在 ABAP 中,所有内容都在数据库中,当数据库复制到 QA 系统时,您必须手动更改这些参数。 而且这样很容易出错。

有没有一种方法可以以不随数据库传输的方式存储配置信息?

谢谢。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

网白 2024-07-18 06:44:44

简而言之:不 - 至少这在 SAP 环境中是非常不寻常的。

如果您的 QA 系统设置为生产环境的系统副本(这是通常的路径),则需要执行很多步骤才能使系统正常工作。 这包括一些配置,可以像您提到的文件路径一样简单,还包括“合作伙伴系统”的地址和名称。 例如,我的一个客户是一家银行,因此在复制他的生产系统时,他会三重确保 QA 方面的活动不会意外地渗透到生产方面。 还进行了一些其他更改,例如模糊人们的姓名和地址,这样就不会意外发送邮件等。

有几种方法可以使应用这些更改尽可能简单(查找一些 SAP 文档或有关 SAP Transport and Change 的书籍)管理方面,我有一本苏·麦克法兰·梅茨格(Sue McFarland Metzger)写的,相当不错)。 据我所知,通常有一组传输将 QA 系统上的配置和自定义等更改为
适当的值。

希望有帮助。

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.

暗藏城府 2024-07-18 06:44:44

您无法阻止将数据库中存储的配置复制到克隆实例。 但是,您可以以防止使用复制的条目的方式设计配置存储。 您应该咨询您的基础管理员是否可以保证克隆的系统将获得新的系统 ID (SID)。 如果是这种情况,那么您只需使用 SID 作为配置表中的关键字段即可。 系统复制后,SID将发生变化,克隆的系统将不再访问原始条目。

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.

沫雨熙 2024-07-18 06:44:44

您的问题不清楚,您是在谈论标准配置还是自定义配置?

您好,假设您将这些路径存储在 Z 表中,那么有些商店将 sy-sysid ( system id ) 作为列之一。 维护开发中的所有系统并将其传输到生产环境。 一段时间后这会变得很痛苦,所以我只建议对于不会发生很大变化的信息(文件路径可能很好)。

T。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文