Variant Configurator and ALE

[Former Member]

Has anyone had any experience with using ALE to transport all aspects of the Variant Configurator set-up to another SAP instance? We had planned to go this route, but have had people tell us that they wrote custom programs to download data from one instance and then use BDC's to load them in the new system. Is there a problem with using ALE for VC set-up data or anything we should be aware off?

Regards.

[christian_wohlfahrt · Accepted solution]

Hi Cynthia,

I followed check list in

http://help.sap.com/saphelp_erp2004/helpdata/en/24/903b39878f4205e10000000a114084/frameset.htm

and it worked fine. Some parts of this list of 15 topics aren't as easy to make as others, but must VC scenarios can be distributed without problems.

Regards,

Christian

[Former Member]

Thank you for the validation of standard SAP. It just didn't make sense to write our own programs to do it, but I wanted to check.

Thanks.

[Former Member]

Hi Cynthia,

I have done this in the past. Definitely ALE is the way to go over BDC's etc.

The only thing you have to watch is the sequence that you send the data in. For example you must send dependency function module definitions before you can send any dependencies that call those functions. Otherwise you get an Idoc failure.

Where you get circular references (for example you have a characteristic which has a dependcy attached to it, and the dependency actually refers to the characteristic by name) then the best thing is to set the status of the dependency to deactivated, ALE it to the target system (syntax check will pass because its deactivated), ALE the characteristic, set the status back on the dependency, and then ALE it again.

Apart from occasional circular references, however, it works really well.

Another thing to watch is that when you set up your ALE distribution model, that you consider the possibility of concurrent development and ALEing between systems. For ease of administration, we set up our DEV system as the source for both QA and for PROD (rather than having DEV as source for QA and QA as source for prod) but this means that you shouldn't do any development on objects currently in QA as the latest changes will be ALE'd from DEV to PROD.

I think the general sequence of ALEing that worked the best was:

1. Characteristics

2. Function module definitions

3. Dependencies

4. Configuration profiles

I feel I have forgotten something there, but I guess you get the idea.

Last thing, you can't ALE the configuration profile user interface. So if you have designed your own layout for the characteristics (with tabs, and userexit buttons etc.) you have to recreate these manually in each environment. Not much fun when you have 10+ clients in your landscape. I kept meaning to write a program to handle it but, time got away from me.

Finally, you have to ask yourself why SAP didn't treat all this stuff as configuration though, and allow you to migrate using change requests. Wouldn't that be nice!!!

Hope that helps.

Cheers,

Brad

[Former Member]

Hi,

I just checked the help reference provided by Christian, and:

> you can't ALE the configuration profile user interface

is no longer true in 4.7!

I think that alone is worth upgrading for...

Brad

[Former Member]

Is there a way to get this 4.7 function (ALE the configuration profile user interface)only without upgrade the R/3 version to 4.7? Our R/3 version is on 4.6C.

Thanks,

Kalven