best practices for handling the sequencing of transports

[Former Member]

Hello everyone

could you please let me know what are the best practices for handling the release and sequencing of transports for an implementation type project in CHARM

And also please let me know if the user ignored the alert of cross system object lock,. how to handle it while releasing the transports to avoid override of the object

Your inputs would be highly appreciated

Thanks and Regards

Praveena

[Former Member]

Hello Tom

Thanks for the reply. I have new questions on this how to check whether downgrade protection is activate or not..

When i try to execute the report /TMWFLOW/TRMO from se38 im getting this function not possible error.

Could you please let me know on this. Is their anyway in solution manager which takes care of auto sequencing and auto release

[TomCenens]

Hi

/TMWFLOW/TRMO is a transaction

CHARM configuration puts transport handling in "single" mode meaning the big truck is gone from transaction STMS and import happens in the sequence in which the transport requests were released (one by one) and entered the import queue thus that should in theory ensure the right order.

However this is only valid if you have single project going on and you use a single project for everything because if you have multiple projects, you could mix up the requests.

90% of the time customers run multiple projects.

You can use multiple projects and if one would ignore CSOL then you can have project 1 with change 1 and project 2 with change 2 where change 1 should go into production before change 2. By ignoring the alerts you could thus end up in a situation where change 2 goes in first (by doing a release - production import of project 2 first).

Downgrade protection settings could stop this when it detects a possible over-taker situation. So DGP can stop the import into production.

So you can combine the different options to create an end-result that is pretty decent in terms of transport request order but since it's possible to cheat (some people might have too much authorization and could surpass CHARM or ignore the erorrs and continue anyway...) the safe option is to have collaboration / communication between the involved parties etc to avoid the situation in the first place.

Many customers are able to get this right by only leveraging CSOL.

/TMWFLOW/TRMO can indicate that transports went in with a different sequence thus it can be used to monitor things to a certain extent.

If it concerns two completely unrelated changes it doesn't matter either if the sequence isn't the same.

Kind regards

Tom

[Former Member]

Hello tom

Im very new to solution manager . Could you please let me know how can we check whether down grade protection is activated or not.

Meanwhile if the same object is included in more than A and B  transport where the transport A should go into production first  and then transport B shd go to production for the same objects of the transport. In such scenarios how can we handle. Could you please provide your inputs

And we have one implementation type  and maintenance type project for same  landscape. 

So we can sequence the transports depending on the order they release?

[TomCenens]

Hi Praveena

Use transaction SPRO - glasses - search for "Downgrade Protection". It will take you to the point of customizing but I guess it's best you read through the documentation on help.sap.com (you can use Google to quickly get to right location there ~ search for SAP Downgrade Protection for example).

When you add objects to a transport request, the active version of that object in the system, at the time of release is inserted into that transport request.

So this means that if you import one by one, based on the date/time of the release of the transport request, the order should by default be correct.

Transport A released at 17/07/2015 10:00 AM with object A version 1

Transport B released at 17/07/2015 11:00 AM with object A version 2 (you modified the object after transport A)

You can leverage CSOL cross project to prevent issues between projects with the same objects.

Sequencing them between different projects is something else though because at one point you will have to do a release of project A and at another point of project B

If you have this:

project A with transport A, C, E

project B with transport B,D,F

Then you'll need to make the call when project A will be released and when project B

If you then need project A with transport A and then project B with transport B and then project A with transport C to have a correct order (meaning you ignored CSOL and the same object is used across those projects) then the only way (unless you go outside of CHARM) would be to use "selective import" only import a single request, then do it again for the second transport etc

In case, CSOL never kicked in, you shouldn't have the same objects in project A versus project B and then it shouldn't matter that much in which order you release the projects. Unless you've got something specific like BI objects that have a requirements that a specific action takes place first in ECC for example ~ that's yet another exceptional case where you still need guidance / insight and perhaps manual steps to get things right.

So in the end, I would still advise to have the teams keep an eye on things. Yes, you can leverage these functions but I would still keep some view / control on things.

Kind regards

Tom

[Former Member]

Hi Tom

Thanks for your detailed explanation.

One last query:

We have our quality system moved to new server after hardware crash. Our SAP server is not remains as the old one  and the database is on a cluster This means that the managed system configuration and SLD entries are different now. In order for ChaRM to function, the Product System and Extended System ID must be correct and remain the same for the logical components . Can you assist me in ensuring this new managed system is configured to point to the old names?

[TomCenens]

Hi

What do you have now, SID + SID0001 or?

Best regards

Tom

[Former Member]

Hi Tom

The SID remains the same. From charm perspective what are things that needs to be taken care

[Former Member]

Hello Tom,

Could you please let me know the difference between development with release and development without releases phases clearly.

Thanks

Praveena Bingi

[TomCenens]

Hi Praveena

Check out blog posts from Dolores which have examples of each phase (see related links in the right pane) or check out SAP course SM200 (SAP Learning Hub can help there).

Best regards

Tom

[TomCenens]

Hi Praveena

It shouldn't have any specific impact in that case.

As long as you're not changing the logical component nor TMS landscape.

Kind regards

Tom

[Former Member]

Hi Tom

but the applications server and database server are changed. so need of updating them in logical components? usually it gets updated automatically from SLD? That has be done already

[TomCenens]

Hi Praveena,

With changed you mean the hardware changed, so hostname etc stay the same so there shouldn't be any change needed to the logical component.

Kr

Tom

[Former Member]

Hello Tom,

Hostname and database were changed. The details got updated from SLD to LMDB is there anything that we need to take care of logical components when the hostname are changed

[TomCenens]

Hi Praveena

In principal it should work out when you follow the process properly but since you already mention people ignoring CSOL this doesn't always work out in reality.

So in reality it's always advised to keep an eye on the situation and the actual release (the team[s] involved should do this).

CSOL is a tool to help the teams out, if they ignore it while they shouldn't or they just ignore it and do not take it into account then that's their responsibility.

In terms of tracking you can leverage /TMWFLOW/TRMO and in terms of releases I would advice for the productive release to use "status dependent & selective import" strategy so the operator gets a list of transport requests before the release takes place and the change documents are only imported if they have a specific status (according to your transport strategy customizing -> status dependant & selective import).

That way it's more secure and if something shouldn't pass to production, it can still be deselected.

Downgrade protection can also help to alert on possible issue situations.

If the order then turns out wrong, the teams in question will need to figure out what is in the wrong order and the operator can even still manually import those requests in the right order (you can always go outside of CHARM if really needed).

It's not really bulletproof because in the end it also still relies on humans . They can have quirks from time to time .

Kind regards

Tom