ChaRM - 4 tier

[shaun_kitching]

Hi all

We are about to implement Solman 7.1 and I have a quick ChaRM question around 4 tier landscapes.

Lets just say we have DEV > QAS > PRE-PROD > PROD

There will be transport of copies between DEV and QAS which can happen an unlimited number of times.  Which is fantastic because it reduces the amount of transports going to PROD.

However, after the testing of the copies has passed in QAS, the original transport is released.  It will then be imported to QAS (before this point only the copy had gone here), PRE-PROD and eventually PROD.

Now after the transport gets migrated to PRE-PROD it will go into the buffer for PROD.  But what happens if PRE-PROD testing fails.

This means the transport will still go to PROD even though you don't want it to.

I know I'm going to get replies that say "Yes, the transport still goes to Prod, however you need to create a Defect Change and fix the issue this way".  But what happens if this change can't occur before the phased release?

For example, we have a phased release into PROD every two weeks (for break/fix maintenance changes).  What happens if a failed transport is sitting in the Production buffer but a fix cannot be created in time for a new transport?

Does that mean we have to manually remove the transport from the buffer (which is dangerous) or do we simply let it go into Production with issues (again, which is dangerous).

Also, now that I think about this, as soon as the transport gets imported to PRE-PROD, it will be in the buffer for PROD.  What happens if testing cannot occur in PRE-PROD in time and there is no sign-off for the change to go to Prod.  The transport will still go to Prod as it's in the buffer!!!!!!!!!!

Am I just confusing myself or does 4 tiers simply not work?????

Cheers

Shaun

[shaun_kitching · Accepted solution]

Hi Jansi

Thanks for your reply.  I fully understand how TOCs work and I know they never progress to PRD.

Are you saying you ONLY test TOC and don't retest the original transport after it's released?

As per SAP documentation, the process is outlined as follows:

TOCs: Unit Test in QA

Original Transport (after TOC has been successfully tested): Scenario Test in QA

What happens if the scenario test fails?

Are you saying all testing should occur against the TOC and no testing occurs against the transport which will eventually go to PROD?

Thanks

Shaun

[Former Member · Accepted solution]

Hi,

if your scenario test fails also, correct with emergency correction or other corrections and fix.

I am just trying to say, if error occurs also, you can easily fix with the CHARM maintenace and project cycle work flow with less risk.

Regards

Jansi

[shaun_kitching · Accepted solution]

Thanks Jansi, I REALLY appreciate you taking the time to respond

I understand the above logic is ok for implemenation projects.  You would make emergency corrections and then retest and you wouldn't change the phase of the project to "Go-Live" until testing has 100% passed.

I fully understand this and I think it works great.

However, I'm very confused when it comes to maintenance projects (ie. break/fix, business as usual incidents).

As mentioned in my first post, we have a RELEASE CYCLE for maintenance EVERY two weeks.  Therefore, every two weeks the phase of the project will be changed to "Go-Live".  However, there will be some transports in the Production buffer that may need emergency corrections (follow up transports) to resolve issues.  So these should not be imported to Production but they will be as they're in the buffer

With Implemenation Projects, the phase would never be changed to Go-Live until completey ready, with our maintenance project it will definitely change to Go-Live every two weeks and will import changes with issues or changes that are still undergoing scenario testing.

Does that make sense????

[Former Member · Accepted solution]

Hi Shaun,

So what is the problem? if you dont want some changes to be in buffer for PROD system, dont release them in QAS.

And these changes will decouple from task after phase TEST to Emergency correction, in new maintenance cycle these changes will autoassign to the project again so you can postpone if you dont sure to import this to PRD.

And you can always ask Basis team to remove from buffer... there is many ways to solve.

But best way if you encounter such a changes to offten mb you need to work with planing for developments more closely...

Regards Dan

[shaun_kitching · Accepted solution]

Hi Daniyar

That is exactly the problem.  Transport of Copies can ONLY go to QAS.  So to do testing in PREPROD, they MUST be released from QAS.

We only release items once they have been unit tested.  However, as per SAP best practice, you should then do integration testing against the original transport (either in QAS (3 tier) or PREPROD (4 tier).  This is where the issue lies because the transport is then in the Production buffer and the integration testing hasn't even been completed yet.

I know there are workarounds such as removing from the buffer...but this is a dirty workaround as you're then removing/readding transports to the buffer manually and it's easy for things to get lost as it's not following ChaRM process.

As for your last sentence, honestly I'm not talking about this happening all the time (defects after released). I'm more concerned about the transports being imported to Production before the FINAL testing (against original transport not TOC) has finished.  This would be a major problem for audit.  As mentioned several times, this wouldn't be an issue with Implemenation Projects, only projects which have a release cycle periodically (in our case every 2 weeks).

Thanks

Shaun

[Former Member · Accepted solution]

Hi Shaun,

Ok now i understand you, we have 4 tiers in charm as well but not did yet configured charm for this.

So i think i will encounter same problem as you now.

If i understand right you need possibility to block transports when release cycle periodically import all project buffer in production?

okay i will look and if find solution will post here.

Regards Dan

[shaun_kitching · Accepted solution]

Hi Daniyar

Exactly!

However, I also see the same issue for 3 tier.  In order to test the "original" transport it MUST be released (cannot go to QA without being released).

Once in QA, it will be in the buffer for Production.

If integration testing isn't finished or signed off against the original transport the change will still go to Production.

Does that make sense?

To back my words up with pictures, please see below link and click on PICTURE 1:

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2012/06/19/how-to-integrate-the...

On the right hand side of this picture (Preliminary Import Process) there is a process called "Transport in Production Buffer".  This picture indicates this ONLY happens if the original transport is tested successfully.  This is NOT true as the transport will still appear in the Production buffer even if testing does not occur or if testing fails. The TOC has already been tested on the left hand side of this picture under "Successfully Tested".

Again, it all comes back to the maintenance cycle having release to Production every 2 weeks....everything in the buffer will be imported even though testing is not finished (as per picture in above link).

Cheers

Shaun

[Former Member · Accepted solution]

Okay Shaun

I thinked and found some workaround for this.

1. You copy these transport to new ones with all objects in NEW NC.
2. Do downgrade Actual NC with transports ( f.e. create separate NC for downgrade ) that downgrades your changes, put it in project buffer as well till go-live.
3. 2 NC will go production your changes will be downgraded and you have open TR's in DEV. And even more you dont need to break project buffer and by this scenario you will follow Best Pratcice.

I think i will do like this ...But if you find somethings else please share

Regards Dan

[shaun_kitching · Accepted solution]

Hi Dan

Excuse my ignorance, but what does NC stand for? 

Shaun

[shaun_kitching · Accepted solution]

NC = Normal Change

Sorry, I'm used to using SC (Standard Correction

[Former Member · Accepted solution]

NC - normal changes where your transport requests are.

but point is in the downgrade:

you can downgrade all objects in transport and then put it to new TR and import this to prd.

then!! you craete new transport and put back version before downgraded version.

its not so hard for developers they will play with transport objects.

Ask you developers and basis team.

Regards Dan

[shaun_kitching · Accepted solution]

I was just reading this:

Flexible Import Options: Status Driven Import

The Import-Job from Tasklist only imports transports of Normal Changes (and Urgent Changes) which are in a certain state (does not import all TR's).

e.g. all transports are imported to production which belong to normal changes in status "Successfully tested"

Note:

- standard behaviour is still "IMPORT_PROJECT" - you need to activate this function via Customizing

- use only in combination with Downgrade Protection, to avoid inconsistencies

This is EXACTLY what I wanted!  Thanks very much Dan.  Although I still need to do some reading on Downgrade Protection as I'm not sure exactly how this works or what I have to setup.  Do you have any links to his??

Thanks

Shaun

[Former Member · Accepted solution]

yeah this is what we need, i had workshop for flexible and downgrade.

yes i have links and much more

Give your mail!

[Former Member · Accepted solution]

Shaun can you please show where you read this :

Flexible Import Options: Status Driven Import

The Import-Job from Tasklist only imports transports of Normal Changes (and Urgent Changes) which are in a certain state (does not import all TR's).

e.g. all transports are imported to production which belong to normal changes in status "Successfully tested"

Note:

- standard behaviour is still "IMPORT_PROJECT" - you need to activate this function via Customizing

- use only in combination with Downgrade Protection, to avoid inconsistencies

I think its some Charm Framework settings.

p.s. sended docu to your mail

Thanks Dan

[shaun_kitching · Accepted solution]

Hi Dan

https://websmp210.sap-ag.de/~sapidb/011000358700000608182012E.pdf

(Page 19)

Thanks very much for the email.  I will read through some of this documentation tonight.

I did notice in your email that CSOL (cross system object lock) needs to be activated.  Isn't this for when you have multiple Development clients feeding into QA?  We only have one Development client feeding QA so does CSOL still need to be activated and would this cause issues?

Thanks again.  I will close this topic after I read through some of your documentation

Cheers
Shaun

[Former Member · Accepted solution]

Hi Shaun,

CSOL is a prerequisite for DGP no need to  configure this just activate.

Here SAP text:

On top of that CSOL is the basis for Downgrade protection feature in SP5. DGP is using the same infrastructure (CSOL table) to find possible downgrades. So CSOL is a prerequisite for DGP and with that for the correct working of ChaRM flex

Thank you and good luck with solution, i hope you wont forget me when i need it too

[shaun_kitching · Accepted solution]

Thanks Dan, legend

[Former Member]

Shaun, we planing to configure Charm for our tier 4 systems in Jule and we have sap max attenation so i will come with solution 100% but not now.

Regards Dan

[shaun_kitching]

Hi Dan, thanks again.

My email is skitching9@gmail.com

Any information you have on flexible and downgrade would be much appreciated!!!

[Former Member]

hi

we worked n 5 tier, nt n 4 tier

as per my understanding, its not automatically move the TR to the PRE -PRD buffer.

You need to manually move the TR via tasklist to PRE -PRD, if you have additional testing.

in this case, no worries,you can test and move.

Refer the note Note 1531565 - Four System Landscape in Change Request Management

Please check

Thanks

Jansi

[shaun_kitching]

Thanks Jansi.

Please see my above reply....I also see this as a problem for 3 tier as well.

I understand you have to import the TR via the tasklist (that's fine).  However the transport will be in the buffer automatically (this is standard SAP).

So even with 3 tiers, there is going to be transports in the Production buffer that haven't been fully tested???

We have a fortnightly release cycle for BAU changes and it will be changed to "Go-Live" every 2 weeks regardless of where all changes are (some will still be in development, some will still be getting tested and some will be fully tested)

[Former Member]

hello

This is not the problem in 3 tier at all... even in 4 tier also...

its the process.. 

you need to test everything properly with TOC in QA, TOC will never goes to PRD,

without testing, how you pass  the test in QA,  if you pass the test in QA only it goes to PRD s t?

you have high risk n moving wrong TR to PRD if there is NO CHARM. but after CHARM is highly controlled. This is what the whole implementation of CHARM

Please check

Thanks

Jansi

[shaun_kitching]

I was just thinking about this some more and really, the same logic kind of applies to 3 tier:

DEV > QAS > PROD

Transport of copies goes to QAS where Tester performs Unit Testing

* Transport is then released*

Original transport is then imported to QAS where Tester peforms Scenario Testing.

But what happens if testing doesn't finish in time or testing fails.  In the mean time, the release cycle is changed to "Go-Live" and the change will be imported to Production even though scenario testing hasn't occured yet.

I must surely be missing something here.  How do you only get approved/fully tested transports in the buffer of Production???

Please assist.

Thanks
Shaun

[shaun_kitching]

I apologise for replying to my own messages (this will be my last time haha).

For implementation projects this won't be such an issue.....the phase won't be changed to "Go Live" until the project is ready for implemenation.  If there is fixes from testing, the phased would be changed to "Emergency Correction"....once everything is tested and its working fine, the project would be set to "Go Live" and everything would then be imported to Production.

However I'm talking about maintenance projects (business as usual, generic break/fix type changes).

We have a fortnightly release cycle which will ALWAYS happen.  Therefore every two weeks the phase will change to "Go-Live" and everything in the buffer for that project will be migrated to Production.

However, out of the transpots in the buffer, ALL of them have been unit tested (transport of copies) but only a handful or a certain percentage will have been scenario tested (original transport).

How do other people get around this?  My head hurts! 

[Former Member]

hi

Adding for your second query, in such a case, you need to correct your error with urgent changes,

You can create N number of maintenace cycle for current project, once the cycle ends, all your open TR, which is not tested, or tested with error automatically appends on the new cycle. so no way you can skip these corrections.

More over in the live scenario, we never set the golive as you said, there would be proper testing and qa check also on board.

I suggest you to read the

Thanks

Jansi