Customizing data create/update in Production Directly from Development system

[bharath_k6]

Dear Experts,

In our today's meeting, somebody raised a point that why can't we update the Database table in production from development system by executing a report program.

Issue is -

We have couple of customizing tables which are part of SPRO structure, in which entries are created in development system and they are carried forward to Quality, integration and production systems via transport request movement.

Transport movement happens to Quality and production systems once in every 2 weeks.

This customizing activity for few is very frequent and business can not wait for 2 weeks for transport release. If the customizing is done directly in PRD then Development, quality are lost the sync with production.

One of the colleague has suggested that, we will develop a program and execute it in Development system. It should Create/Update database entries in Quality and Production in a row directly from Development.

Although I had denied to do so as per SAP Best practices or guidelines. I am looking for a strong reasons to say why it is not recommended.

Could you please give me some valid thoughts why it should not be done?

I have some valid reasons which I expressed and debated.

1. SAP Does not recommend to do so as it against the system landscape.

2. Auditing perspective

Thanks in advance for your valuable suggestions and ideas.

Thanks,

Bharath.

[Former Member]

You can open production for direct update.  Then you can run SPRO there.  But that is considered pretty risky by most people.

Your suggestion above would seem to me to be more risky however!

Neal

[Former Member]

1.) The thing which you want to achieve that is possible through RFC call. There are chances of RFC failure.

2.) If it is available in DEV for execution there is possibility someone can execute it without knowing impact and there will be direct impact on production data.

3.) How you are going to track data changes ? Do you have some back up plan. Currently you have transports. If something went wrong then how you will revert it ?

Risk is more but you have to think how to achieve your requirement ? . As Neal suggested go with direct data maintenance in PROD.

Cheers,

Prakash

[bharath_k6]

Finally we have decided not to go with above mentioned approach since we are deviating from the SAP best practices and the original concept of CTS (Change and transport system).

Thanks to all of you for ideas and suggestions.

Thanks,

Bharath.

[nabheetscn]

Hi Bharath

I would recommend you to read why SAP has different clients for Dev/Prod/Quality.  What are the benefits of change requst management to understand it in more details. Search SCN you will find many good documents

Nabheet

[ThangaPrakash]

Hello Bharath,

You can achieve this through RFC connections.

But there is lot of risk involved in it, also it is very difficult to track the changes if you do so.

It is better to use the usual transport system through quality and production.

Regards,

Thanga

[Former Member]

Hi,

Transport movement happens to Quality and production systems once in every 2 weeks.

you can customize transport system once in every 1 week for example+

provide solution for manual transport express reqests  from dev to qa and prod

I recommend you to use standard transport system

[Former Member]

Hi,

SAP has given us options to make data changes in production directly for customizing table. The details are given in the note :

Note 356483 - Customizing: Current settings in the test system

The first thing you need to do for this is to deactivate transport path for the customizing tables/views in transaction SOBJ by changing the option to "No user recording routine" and save it.

Also, you need to tick the current settings for those tables.

It would be nice, if some BTE of type publish and subscribe are available so that changes made in development gets updated in quality and production (or maybe change pointers ).

Regards,

DPM