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

Releases/Versions of Code and Marking Code as Obsolete

Former Member
0 Likes
676

Hi all,

I need to be able to have multiple releases of the same code available for use in the same system. The reason for this is that we cannot afford to retest every usage of a function/method every time we update it, so often we need to make a new "release" of that piece of code with our desired changes, but let the existing code continue to use the previous "release."

I keep putting "release" in quotes, because there does not appear to be a formal way to do this in SAP. The only way I know to accomlish this is to create a copy of the code that needs to be updated and change only the copy, thus leaving the existing code unchanged. There is an obvious problem with this, however. How do the other deveopers know that the function/method they are using is now effectively obsolete, such that they should update their code to use the newer version at the earliest opportunity?

Is there a way to mark code as obsolete?

Is there a way to raise an activation warning if an obsolete function/method is in the code being activated?

Thanks for any input,

-Chris

Hi all,

I need to be able to have multiple releases of the same code available for use in the same system. The reason for this is that we cannot afford to retest every usage of a function/method every time we update it, so often we need to make a new "release" of that piece of code with our desired changes, but let the existing code continue to use the previous "release."

I keep putting "release" in quotes, because there does not appear to be a formal way to do this in SAP. The only way I know to accomlish this is to create a copy of the code that needs to be updated and change only the copy, thus leaving the existing code unchanged. There is an obvious problem with this, however. How do the other deveopers know that the function/method they are using is now effectively obsolete, such that they should update their code to use the newer version at the earliest opportunity?

Is there a way to mark code as obsolete?

Is there a way to raise an activation warning if an obsolete function/method is in the code being activated?

Thanks for any input,

-Chris

3 REPLIES 3
Read only

andreas_mann3
Active Contributor
0 Likes
594

The reason for this is that we cannot afford to retest every usage of a function/method every time we update it,

-> so what quality shall you and your company expect from that procedure?

A.

Read only

0 Likes
594

The situation I am describing is one where the procedure is working properly for several usages, but we desire to alter it for a new usage or to fix a problem in another specific usage. The alteration will be made in such a way that it will still work for those existing usages that were working properly, so if we had unlimited resources, we could just alter the procedure directly and retest everything to assure quality. Since we cannot afford this approach, we need to have two versions of the procedure. The original version will continue to be used in the cases where it was functioning properly, thus assuring no degradation in quality without incurring testing expenses. The new version will be used in the case that required the alteration and must be tested regardless. As time goes on, we will likely find that changes must be made to the code where the older version of the procedure is still being used, and can update that code to use the newer version at that time without incurring additional testing cost. Until such a time, however, there is no reason to update the older version of the procedure since it works correctly for the case in which it is being used.

An example might be a function that resolves the value of a PM partner to its corresponding name. Suppose you originally wrote such a function to only work with partners based on personnel number and not organization number. You are using this function in many places where partners will only be based on personnel number, so it is fine. At some point, however, you find that there are separate situations that require both personnel numbers and organization numbers to be resolved to names from partner values. If you want to have a single function that works for all, then you either have to follow the approach that I suggested above, or you have to change the existing function and retest all usages.

Read only

0 Likes
594

Sounds like a VERY good reason to be utilizing ABAP UNIT test methods....If you built in those, and added a specific test method for each new functionality, ABAP UNIT could test both original and new functionality with a couple of mouse clicks and report success or specific test method failure.

Seriously, your approach is unworkable; adequate testing of software changes is cheap compared to the cost of the consequences that await if you don't do the testing.