How to distinguish the ABAP Code in include program into different TRs

[Former Member]

Hello Friends,

In our current project, two teams are working on the developments. One team is for LES related developements and another team is for billing related developments. As part of developments, same programs are sharing by two teams, example -

Include - MV45AFZZ, the userexits in include are using by both the teams for their developments

Now the issue was, since the same program is using by both the teams, and during program activation , system automatically includes the code in both the team TRs. This was causing issue while testing and transport to other testing systems, since billing project is going live in next year and LES in coming november

Hence, we need to understand how we can differentiate the code which should not impact with other TRs.

Many thanks for your inputs

Best Regards,

Goutham

[Former Member]

Hi goutham

Try to create a Z* include for each team for their own code

[deepak_dhamat]

hi Goutam ,

There is simple solution for these .

Use proper comment / documentation in Program which will differentiate between two .

while changing in MV45AFZZ include there you can create one FORM ENDFORM which will be different for both

using proper condition .

regards

Deepak.

[andrea_olivieri]

Goutham wrote:

we need to understand how we can differentiate the code which should not impact with other TRs

Hi Goutham,

in my opinion split the source code of a userexit according to the development team name or a project is not a good approach.

Maybe, it might be more feasable to divide the userexit source code using the application id such as order management, delivery management, billing and so on.

Try to see if [this blog |/people/andrea.olivieri/blog/2010/01/12/best-practice-for-a-sap-ecc-consolidation-project-filter-dependent-badi-to-organize-the-user-exits-and-enhancements]can help

Regards,

Andrea

[Former Member]

Hi ,

Never got into a scenario to o write that code in include of MV45AFZZ but in my opinion i think having includes separated as

ZXX_LES_YYYY_01

ZXX_BIL_YYYY_01

u can try this option as adviced in reply 1.

If you two includes differntiated in above manner, i think you can handle transport in without much issues.

BR,

Vijay

[Former Member]

What I have seen done (and it was very effective) is a custom config (ZT...) table, with modification code or number an dON/OFF switch. The modification is assigned a change code, the code is entered into the table as ON or OFF, the exit coding is then wrapped inside logic that checks content of the table (read into memory once upon entry to the exit code usually in field mod, or somewhere similar) for ON. If the control table indicates ON, the code continues, otherwise it drops to the end of the ENDIF/ENDCASE statement. One merely changes the switch to ON when one is ready to test or to promote the code beyond development.

You probably know already to NOT put CHECK statements in those exits....use READ then IF or CASE if you employ this.

There is NO way that I'm aware of that will allow you to do what you've asked...if the code is changed it's always assigned to any open (not released) transport containing the same object name. To do othewise would introduce complete chaos into our systems.

[Former Member]

Hi,

1. create 2 zee include program in diferent transport request.

2. include those in main include.

3. call subprogram in main include like below

perform les_form if found.

perform bill_form if found.

4. create form in include programs.

5. make comment one include program in main include program which you don't want to transport.

Regards,

L.Velu

[Former Member]

i´m a lil bit irrritated. When e.G. TEAM1 changes MV45AFZZ and activates they get asked for a TR.

Once they input this, the object will be in the TR AND the object will be blocked for changes.

I dont really see how the same object could make its way into 2 seperate TR´s.

Even if you go for solutions like proposed with two Z-includes in MV45AFZZ you still will have to change MV45AFZZ itself in order to write your INCLUDE statements there, so your problem is not really solved it´s just more easy to come around it.

[former_member404244]

Hi,

I agree with Florian.. We cannot make two different TR'S....

Regards,

Nagaraj

[Former Member]

Thanks all for the quick reply..

I would like to brief more clear...

In current project, Team 1 is working for Logistics developments, Team 2 is for Billing developments. As part of project plan, Logistics is going live this november

When two teams are working on the same include, Team 1 is activated the changes then the task is updated in their TR, later when Team 2 has made changes in the same inlcude then the task was includeded in their TR. Now the problem facing was, Team 2 has developed statements like COMMIT WAIT WORK and also BAPI call etc... and these statements are causing performance issues and some other problems......

Recently Logistics related TRs are moved to testing system for testing, in that all the development TRs are moved into testing system and also code related to Billing project (Team2) as well.... when we cross check the reason then it was identified that the same include is using by both the teams for the development. Now we need distinguish the code specific to team whcih should not impact other...

Hope my explanation clear the criticality of the problem

Thanks

Best Regards,

Goutham

[Former Member]

well then go for the solution of two seperate includes in MV45AFZZ. you will only ONCE have to share an TR. The time when you maintain the INCLUDE statements.

After that one is done and released, every team just has to work with theri include.

But definiteley best solution would be to make one team wait until the other team is finished, tho i suspect you aint got the time frame to do so.

Another story is the usage of commit statements in SAPV45A scenario. NEVER EVER even think about it, you are most probably already in update task, and commits are are pure venom for here.

[matt]

Rather than use includes, which become part of the program structure, I would decouple to code entirely, using classes (or if you have to) function modules. This gives you the added advantage that a syntax error in the class (or function module) won't prevent SAPMV45A from activating.

One one site I worked at, they had to accomodate local developments in the same area, so all these things were done through the BADI framework - creating their own multiple use Z BADI through SE18. Then each team can make their own implementation without affecting the others

matt

[andrea_olivieri]

Thanks Matt.

I discussed this issue in my previous blog [Best Practice for a SAP ECC Consolidation project: filter dependent BAdI to organize the user-exits and enhancements|/people/andrea.olivieri/blog/2010/01/12/best-practice-for-a-sap-ecc-consolidation-project-filter-dependent-badi-to-organize-the-user-exits-and-enhancements]

I'm with you.

Andrea

[matt]

Well there we have it. Definitely a great way to handle these issues, and pretty much future proof. Handling not only the different team problem, but the whole knotted problem of independent multiple functionality in the same exit.

Nice one Andrea.

[Former Member]

Thanks a lot to all for your valuable inputs, I will update once the solution is implemented.

Best Regards,

Goutham

[andrea_olivieri]

Hi Matt,

Thanks a lot for your feedback, I really appreciate.

Andrea