SLCM Audit Development in Mixed ECC 6 / ECC 6 EhP3 Landscape?

[Former Member]

Hello,

Is anyone aware of any issues that might be encountered if I was to perform SLCM Audit-related development on a machine with ECC 6.0 (no enhancement packs) and then transport the developments to another machine with ECC 6.0 (Enhancement Pack 3)? Specifically, are there any table modifications, changes to the parameters of any functions or class methods, etc... that I would need to be concerned about?

Thank you,

Eric

[former_member583013 · Accepted solution]

Eric,

I suppose it depends on what you mean by 'developments'. Are you just talking about BADi implementations for Filters and Conditions, or something else?

Michael

[Former Member]

Hi Michael,

Unfortunately, I can't limit the question to just BAdI implementations. I think I've seen a "storage prevention" flag mentioned before. Presumably, this sits in one of the t7* tables associated with SLCM Audit. I suppose that transporting data from a version of this table without the flag to one that has it could be perilous?

So, my question is about any customizable portion of SLCM Audit. And, actually, I should account for the scenario where I might have modified z-copies of PIQ_AUDIT and some of the CL_HRPIQ00AUDIT_* classes as well, but I'm almost afraid to ask that.

Thanks,

Eric

[former_member583013]

Eric,

You're in interesting territory here. Of course the response from me is going to be that you should not try to transport customizing objects from one version to another. Normally you apply the enhancement pack to the sandbox, then DEV, then QA, and so on, and transport objects 'up the line'. That way, when you apply the upgrade, you can see what conflicts might result from your prior modifications.

Generally, though, transporting a customizing entry from old to new in this area should not harm anything. Even when there are new customizing entries in the tables. The flag you refer to for storage prevention of empty requirements is a new customizing switch value (which you could also just apply to your older version, as we released that via an OSS correction anyways).

If you modified class libraries, I definitely would advise against transporting from old to new, though!

Michael

[Former Member]

OK, thank you, Michael.

This is not actually "interesting territory" that I am willingly in. Part of the problem is that our DEV box does not have master data that at all reflects our production environment. So, I have been developing BAdI implementations and making customizations on it, transporting them over to one of our sandboxes (which has a full and recent set of master data), and then creating subrequirements on that sandbox rather than on the DEV machine. I have not been allowed to develop the subrequirements on our QA box. Now, the EhP3 boom is being lowered on the sandbox that I have been using to develop the subrequirements. If I pack up everything in my current sandbox and move to our other sandbox, I will be under significant time pressure in the face of a refresh from our production system, because the other projects on that machine want the refresh.

So, basically, I am being squeezed from all directions, and was hoping to be able to sustain development as is. But, I think your answer could be interpreted as a "no".

I don't know if you have any recommendations for us in this particular situation. But, if you do, I would be grateful.

Eric