Do I need to send CLASS's defination as well, otherwise is it dumps?

[former_member194142]

Hello,

We have a custom CLASS, say its name is ZCL_ALREADY_EXISTING_CLASS and it has 2 methods (say, ALREADY_EXISTING_METHOD_1 and ALREADY_EXISTING_METHOD_2) and 2 ATTRIBUTES (ALREADY_EXISTING_ATTR_1 and ALREADY_EXISTING_ATTR_2)

(already existing means, its there in production already)

We have 2 transports,

1st TR's owner (1st ABAPer) added the 6 new methods, few attributes to THIS already existing custom CLASS, hence we can see the CLASS's DEFINATION, CLASS PUBLIC HEADER, CLASS PRIVATE HEADER, NEW METHODS etc. under this TR's task, well

2nd TR's owner (2nd ABAPer) created a new report program, wherein he/she used all the below already existing components of class ZCL_ALREADY_EXISTING_CLASS in his/her newly developed report prog

ALREADY_EXISTING_METHOD_1, ALREADY_EXISTING_METHOD_2, ALREADY_EXISTING_ATTR_1 and ALREADY_EXISTING_ATTR_2

Now we want to send only the 2nd ABAPer created report prog. (2nd TR) to production, pl. let us know that sending just 2nd TR causes any dumps because the DEFINATION saved in another (1st) TR? any issues / conflicts / TR fail? or is it OK/safe?

Pl. note if we check the VERSION MANAGEMENT for this class between DEV and PRD system then there will be differences bcz of 1st developer's 1st TR's changes

Thank you

[former_member194142]

Any help pl.?

Thank you

[michael_kozlowski]

Hi,

it's difficult to answer your question without having the full insight about all involved objects.

But according to your explanation it seems to be okay to send 2nd ABAPer created report prog. (2nd TR) to production.

If I understand right, the 2nd ABAPer created report only uses existing components of the productive version. However check 2nd TR that there are no object of the class are included. If 2nd TR doesn't include class objects the created report and class in production should be consistent.

If transport-chain equipped with a QS-system, I suggest to import TR first into QS and check if it works.

Br

Michael

[former_member194142]

Thank you.

Yes, the ABAPer2 / TR2 is using the CLASS's components (methods, attributes) which are already existing in production

I didn't get your below statement, pl. elaborate

However check 2nd TR that there are no object of the class are included

QA system: DEV and QA is in synch bcz we imported TR1 and TR2 into QA last months

[michael_kozlowski]

analyze the objectlist of the 2nd TR if there are any components of the class included. If not anything is fine.

Hope this will be helpful.

[AbhishekSharma]

Hi,

You need to check dependencies on objects that APAPer1 and APAPer2 worked on.

If APAPer2 have used any of the new created DDIC objects by ABAPer1 which are not in Production yet, then surely sending only new created report program by APAPer2 will give dump.

Any how you need to send at least the common objects which are used in Report Program created by ABAPer2 first.

Just curious to know do you use CHARm to send Transport Request in different systems?

Just a good practice we should have a common Transport Request just for DDIC objects any thing ex table, structure, views any thing in one Transport, and this transport should go first in any system while moving code base.

benefit from this will be you no need to worry on these kind of dependencies of using DDIC objects, and there is no harm in sending these objects to production or any other system without being used, because any Transport following this DDIC containing Transport will have objects (Report program, Function Modules etc) which are going to use these.

If you will follow this process then in future you will never get into these kind of problem.

For now as a workaround you can remove DDIC objects from ABAPer1 transport which are used in ABAPer2 report program and add in same Transport Request of ABAPer2 and send it to different system.

Keep in mind once you remove these Objects from ABAPer1 transport you need to LOCK them in Second Transport you should see a LOCK SIGN for those objects.

Hope this will help.

Thanks-

Abhishek

[matt]

I'm not sure why previous posters have such complicated replies. It is actually very simple.

So long as transport 2 doesn't contain any components of the class, and the report only calls methods of the class that exist in the production system, there won't be any issue.

[former_member271600]

Sometimes Developers Overthink or possibly has other things in mind that might be missing in the posters inquiry so they tend to say everything that they can think of just in case.

Cheers!  

[matt]

I think partly is that many developers have no clue how CTS works and expect some kind of magic to happen. Which with XPRA can be the case!

[former_member271600]

Hi SAP SAP SAP,

As long as the 2nd developer ONLY USED(or called) the Class in his report. It should be fine.

The Class and the Report program are 2 different objects.

But IF the 2nd Developer ADDED a NEW method or NEW attribute in the class via SE24, then you should include this in your Transport.

Thanks.

[former_member185587]

Hi SAP SAP SAP,

You can think of an answer yourself by considering a standard class in place of your custom class.

If SAP upgrades an existing class with a new SP level, do you think the programs, which are currently using the methods of the class and attributes of the class start dumping (Would be a MAJOR issue with the application, if it would be so... NO would be the answer)?

I hope you understand it now.

Regards,

Kiran