Exact copy of SRM PRD to DEV ? :-(

[diegohs]

Hi guys,

This is a question for SRM gurus:

The facts:

- I have 2 servers: SRM Production & SRM Development

- In SRM Dev I have 3 clients created (100, 120 and 200)

The need:

- I want all my clients equal to my PRD environment

So, In R3 is very common to make an exact copy (Configuration & Data), but in SRM what implications does it have ?

One day I tried to do this but I had a problem with some product categories, and all my configuration is directed to the PRD RFC connection.

The question:

- Somebody has done this before ?

- Any recommendation/risk ?

Thanks so much for your help guys !!!

Kind regards,

Diego

[yann_bouillut · Accepted solution]

Hi Diego,

You can ,as you said, copy Prod to dev.

However you have afterwards, to correct every data where logical system is a key (product category...)

You have some transactions such as BDLS that enable you to do this logical system conversion.

Kind regards,

Yann

[diegohs · Accepted solution]

Hi Yann,

2 questions:

- have you made this before ?

- Is there any risk or a very difficult task ?

Or everything is feasible ? 😃

Thank you !

Regards,

diego

[yann_bouillut · Accepted solution]

Hi Diego,

This was done on some of my previous SRM projects.

However, basis guys were in charge of doing this (basis responsability), i never done it myself.

Please note that this is a standard solution provided by SAP AG Basis.

This transaction has the following criteria:

- Old logical system name

- New logical system name

- Option to convert client-dependent tables only

- Test run option

- Option to check existence of new names in tables

- Number of entries per commit

- List of tables to be converted

Here are the advantages:

- This is a standard solution provided by SAP AG Basis.

- The solution has limited protection against misuse, i.e. it checks that client copy is not active, and that two BDLS conversions are not running at the same time.

- It includes special processing routines that can be added to table BDLSEXT for handling special objects. This is only used for non-configuration tables such as partner profiles in SRM.

- The solution handles all database tables.

- Tables are locked during conversion.

- The transaction can be scheduled by using the underlying report RBDLSMAP.

- Only fields with domain ‘LOGSYS’ are converted

Disadvantages:

- There is a risk of users directly running transaction BDLS deliberately or accidentally.

- There is a high risk of error if users run transaction BDLS directly as there is no protection over which tables can be changed.

- The solution handles all database tables – this is not desirable for SRM. Only nominated configuration tables should be converted as tables that hold organizational structures or replication data have there own specialized transport/replication programs. Therefore there is a high risk of wrong or additional tables being converted.

- The transaction would need to be scheduled multiple times with multiple report variants to perform all the conversions needed – i.e. a variant for each source/target logical system combination.

- Complex to maintain. As new backend systems are added to the landscape new report variants would need to be created and the job scheduling changed.

- If the list of tables is not provided, the transaction examines ALL tables. It has been suggested that some improvements could be made to BDLS, e.g. to limit the number of tables called in SRM.

- performance of the transaction is poor even when the list of table names is restricted. For every run BDLS generates a conversion program including conversion routines for each table prior to executing the job itself.

- As BDLS has to be scheduled as a separate job to run after each transport including client copies, there is a high risk that in a 24*7 environment the job would be long-running and would result in unnecessarily long down-times while the job completes.

- Transaction BDLS is not automatically included in the transport process – there is a high risk that the system may be reopened after transport without the BDLS job being run or before the BDLS job has completed.

- Audit trail of the success or failure of conversions is not kept with the relevant transport log or client copy.

These data were provided by Jocelyn Dart.

Kind regards,

Yann

Message was edited by: Yann Bouillut

[Former Member]

Diego,

on service.sap.com/srm, you could find a doc named 'transporting EBP system'.

It was designed for EBP 3.0 or 3.5, but it will give you lot of information about client copies.

First mandatory steps after client copies:

- delete RFC destination to production

- delete distribution model with production

- run BDLS in SRM & R/3 to aapt each receiving/sending logical systems = that mean 4 runs of BDLS

If you also copy R/3 at the same time, it is ok. Otherwise you have de-synchronized systems, and then you need to re-customize some SRM customizing points and re-replicate some data....

Rgds

Christophe

[diegohs]

Hi Guys,

Thanks a lot for your help!

Basis guy will make the SRM copy. I'll do the tasks SRM related.

By the way, I cant find the document =( Could you share the pdf file (diegohs@gmail.com) ?

Thank you !!!!

Best regards,

Diego

[yann_bouillut]

Hi Diego,

Document sent )

Kind regards,

Yann

[diegohs]

Document received 😃

Thanks man !

- diego

[diegohs]

points rewarded 😃

[diegohs]

Hi Yann / Christophe,

Regarding to this topic, I began to execute this task today...and... I failed :O(

What I did:

- basis people make a SRM client copy from PRD to DEV

- In SRM, I deleted RFC connections that points to R3 Prod. Environment

- In SRM, I deleted the ALE distribution model and some records (logical systems)

- In SRM, I executed transaction BDLS just one time.

My questions:

- Should I execute BDLS in R3 also right ?

- Should I execute BLDS 2 times in R3 and 2 times in SRM for what reason ? (Should I flip the sender/receiver?)

- After that, my Org. Unit will be updated with the new values in all its attributes ?

- How can I check that everything is ok ? I mean, I would like to avoid a missing "pointer" to my Prod. Environment =(

Thanks so much for your help guys !!! 😃

Regards,

Diego

[Former Member]

You will need to update attributes in the org strucutre

Transaction SE38

Enter RHOMATTRIBUTES_REPLACE

Enter your attributes/old org unit/new org unit. make sure to check the sub string box as well.

You will also have to re-start your workflow.

Tracey

[Former Member]

Hi Diego,

you have to run BDLS 2 times in SRM:

- convert old SRM LS (prod) to new SRM LS (dev)

- convert old R/3 LS (prod) to new R/3 LS (dev)

and 2 times in R/3

- convert old SRM LS (prod) to new SRM LS (dev)

- convert old R/3 LS (prod) to new R/3 LS (dev)

BDLS does not update attributes, you must use RH_OM_ATTRIBUTE_REPLACE for this.

Rgds

Christophe

[diegohs]

Hi guys 😃

Thanks a lot, Ill try your recommendations in a minute 😃

Regards from Mexico

Diego