Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Previous version comparison to avoid transport error

sudhahar_ramachandran
Active Participant
0 Likes
666

Friends,

Sometimes multiple developers need to work on a same object at a time. for example, users exits in PO, RFQ & Contract.

In such cases before moving a request to production, we have to check carefully whether previous version already moved to production to avoid transport error.

I'm developing a program with basic idea to check whether the previous version of all the objects assigned in a given request exists in production.

Please let me know if you have some idea about it already.

Thanks & Regards,

Sudhahar R.

1 ACCEPTED SOLUTION
Read only

kiran_k8
Active Contributor
0 Likes
625

If you are in ECC then you can check the possibility of encapsulating the customised functionality within Enhancement Spots by creating an Enh Implementation.This way neither there is a need to get the access key for changing the standard objects for user exits nor this will be affected during the upgrade and also different teams can work on the same object at a time without having any issues.

If you are in prior version to ECC then the only way is to have all the developers working on different user exits of the same transaction have an understanding about the TRs and their version.Each and every respective developer should compare the dev version with the production version everytime he is moving the TR from dev to QA and then to production.This way he can ensure that the TR has only got his current and valid changes and no other changes.

Thanks,

K.Kiran.

4 REPLIES 4
Read only

kiran_k8
Active Contributor
0 Likes
626

If you are in ECC then you can check the possibility of encapsulating the customised functionality within Enhancement Spots by creating an Enh Implementation.This way neither there is a need to get the access key for changing the standard objects for user exits nor this will be affected during the upgrade and also different teams can work on the same object at a time without having any issues.

If you are in prior version to ECC then the only way is to have all the developers working on different user exits of the same transaction have an understanding about the TRs and their version.Each and every respective developer should compare the dev version with the production version everytime he is moving the TR from dev to QA and then to production.This way he can ensure that the TR has only got his current and valid changes and no other changes.

Thanks,

K.Kiran.

Read only

0 Likes
625

Thanks Kiran for your valuable inputs.

Not only for user exists but for all versionable objects.

Human errors are bound to happen. in such cases, the impact will be more and will lead to firefighting. Just to avoid that, I'm trying to give the basis guy a transaction to run before moving any workbench to production so that he can be make sure / warn the developer.

Thanks & regards,

Sudhahar R.

Read only

kiran_k8
Active Contributor
0 Likes
625

It is Developers responsibility to ensure that correct version is moving to Production.Moreover there will be some instances

when we do some changes in development and move only till QA just for testing.In such a case checking whether the previous request got moved to production or not is not a valid check point.So,it is solely the responsiblity of the Developer and not the Basis team.

Thanks,

K.Kiran.

Read only

0 Likes
625

Thanks Kiran for your valuable input which I don't know...