Introduction

From time to time during an implementation there are Requirements risen, which occurs to be not necessary any more or outdated. While closing or withdrawing a requirement is quite easy, to stop an ongoing implementation with already created Work Items and transports needs some proper planing.

First to say is, Focused Build supports on documenting changes, helps you on not forgetting any changes done in the development system, and forces you to deploy a change into production, when it was already deployed into a test system. So to get rid of a change is not wanted by Focused Build.

This article discusses the different stages a Work Item/change can be in and proposes a solution when a Work Item/change is not needed any more.

Possible preconditions

1. Work Item is created but without transport.
2. Work Items is in status ‘in development’ or ‘to be tested’ and contains an unreleased transport.
3. Work Item contains already released transports.

Work Items may also have documentation attached. It is not possible to withdraw a Work Item with documentation attached. So if you have documentation in your Work Items you need to move the documentation to a different Work Item. How to do that is described here.

Please keep in mind if you undo a change you might also need to undo the changes done in the attached documentation. This documentation should be released afterwards to the production branch to guarantee that the documentation in the production is up to date. For releasing the documentation to the productive branch you can use a new Work Item (GC) and switch the documentation to that Work Item as described above.

Solutions

1. Work Item is created but without transport.

No change has been done in the system so you can easily withdraw the Work Item by using the action ‘Withdraw’.

Withdraw Work Item – Status ‘created’

Withdraw Work Item – Status ‘in development’ or ‘to be corrected’.

2. Work Item is in status ‘in development’ or ‘to be tested’ and contains an unreleased transport.

First you should keep in mind, a change in a system should always be reverted before a transport and/or a Work Item is withdrawn/deleted. The same is valid for the documentation attached as mentioned above.

Empty transport

If you don´t have any objects in the transport, you can switch the status to ‘to be tested’. The empty transport will be deleted by Focused Build.

Switch status to ‘Pass to test’

Afterwards you switch the status back to ‘provide Correction’.

Switch status to ‘Provide Correction’

Now you can easily withdraw the Work Item as shown above.

Transport contains objects

If the transport is not empty please create a task to the transport and put the UNDO of the change into the same transport.

After the UNDO has been done in the development system and assigned to the transport, you need to check whether a Transport of Copies was already sent to the QAS System. If so you need to send a Transport of Copies again to the QAS system to undo the change in the QAS system as well.

No Transport of Copies created.

If no Transport of Copy was created for the transport, no change has been shipped to the QAS system. Now you can decouple the transport.

To decouple the transport, you need to switch to the WEBUI by clicking on the Work Item title.

Switch to WEBUI.

Choose /SALM/ARCHTC role.

Decouple transport by marking the transport and choosing the ‘More’ button in EDIT mode.

Decouple Transport.

If a Transport of Copy was already created for the transport, a change has been shipped already to the QAS system.

Transport of Copies already created.

You cannot simply decouple the transport, you have to ship the UNDO into the QAS system first via a Transport of Copies.

To do so, you switch the status of the Work Item to ‘To be tested’.

Pass the Work Item to ‘to be tested’.

Wait for the import into the QAS system and afterwards switch the status back to ‘to be corrected’.

Wait for TOC to be imported.

Switch back to status to ‘to be corrected’.

Afterwards you can decouple the transport as shown above.

As soon as the transport is decoupled from Focused Build, the transport can be released manually in the DEV system (tx:se09) and afterwards deleted from the import queue of the QAS system.

3. Work Item contains already released transports.

If the transport in the Work Item is already released, it is not possible to decouple or delete the transport any more. In this case you have to deliver the change into production. But you can also create an UNDO and ship this UNDO together with the already released transport. For this you need to extend the SCOPE of the Work Package and create a new Work Item, where you create the UNDO transport and put the UNDO into.

Both, change and UNDO, needs to be imported into production together by handing over the Work Package to the release.

Extend Scope of Work Package.

Conclusion

You have learnt how to undo an change using Focused Build. Please keep always in mind, that a change not needed anymore needs to be reverted in the development system and all systems it has already been delivered to. Unreleased transport can be deleted in the end. Released transports must be imported into production together with the UNDO change/transport. You read also about the documentation, which might need adjustment and might be moved to a different Work Item (GC).

If you have any questions or input, please feel free to comment and share!

You are also encouraged to follow SAP Solution Manager tag here and the Application Lifecycle Management tag here.