Application Development 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: 

Transport ALE Configuration from Development to Production System

Former Member
0 Kudos
2,159

Hello All,

We have created ALE-IDOC scenario in the development system and its working fine. Now we want to transport it to the Production / Quality system. How can we transport the settings like logical systems, port definition, partner profiles, distribution model , RFC destinations from one system to another system??

Because the client numbers are different for development , quality and production systems.. Do we need to transport the logical system and client assignment using STMS or create directly in the target system??

Thanx in advance...

7 REPLIES 7

jaideepsharma
Active Contributor
0 Kudos
233

Hi,

You can transport logical systems by following menu path in SALE transaction.

Sending and Receiving Systems -> Logical Systems -> Define logical systems

Press F8 then follow Edit ->Transport->Include in Request.

You can transport the distribution model through BD64.

Choose the model then follow menu path Edit ->Model View->Transport

But I would suggest you to ask the basis team in your project to create them in individual systems according to partners defined for respective systems.

KR Jaideep,

Former Member
0 Kudos
233

Hi,

If you are using single application server with different clients (Development, quality, production) then no need to transport the logical systems because transaction BD54(creation of cross client) is cross client.

Thanks,

Asit Purbey.

Former Member
0 Kudos
233

The issue with transporting the ALE distribution model is that the source and target logical system names change between the dev, test and prod environments.

Assume an ECC6 and PI landscape with dev/test/prod called E6D/E6T/E6P and PID/PIT/PIP with all systems using client 100. By default (SAP recommendation) the logical system name for E6D client 100 is E6DCLNT100 and its PI partner in the dev landscape will be PID client 100 with logical system name PIDCLNT100. In test the logical system names will be E6TCLNT100 and PITCLNT100 and in prod E6PCLNT100/PIPCLNT100.

So, when a distribution model is set up in dev with a source system of E6DCLNT100 sending messages to a target system PIDCLNT100 everything works nicely. This assumes that the PIDCLNT100 logical system partner in WE20/WE21 is mapped to a port which maps to an RFC destination pointing to client 100 of PID.

When this model is transported to the test system it won't work because the logical system names are wrong.

It is possible to create a logical system name called PISERVER in SALE and then map that, via WE20/WE21 to point to the corresponding PI instance. Thus in E6D, WE21 would map logical system PISERVER to the RFC destination for PIDCLNT100 but in E6T the mapping would link to RFC destination PITCLNT100 and in E6P to PIPCLNT100. In this way any ABAP programming trying to use the ALE distribution model would send messages to PISERVER and would be transportable.

However, setting up the source system in the same way appears to be impossible. When attempting to generate partner profiles, transaction BD82 stubbornly insists that the source system for which it will build profiles MUST be the logical system name defined for the execution client in SCC4. Theoretically, mapping similar to that for PISERVER could be performed for ECC6SERVER and the ALE distribution model could be built to send messages from ECC6SERVER to PISERVER but BD82 won't honour this source system.

This appears to make it impossible to transport an ALE Distribution Model. Can anybody provide a process to overcome this apparent architectural limitation?

alex_m
Active Contributor
0 Kudos
233

Do Model View(BD64) & partner profile(WE20) in each target system and all other you can transport.

Former Member
0 Kudos
233

It's not clear to which part of this thread your one-liner refers. Could you please elaborate as to which part of the problem described above this fixes and then expand with a litte more detail as to what, exactly, you are suggesting should be done. If your response was directed to my architectural concern, it would be really helpful if you could describe the steps you recommend in terms of the system names used to illustrate my example landscape.

Former Member
0 Kudos
233

I HAVE A KNOWLEDGE ABOUT HOWTO CREATE AND DITRIBUTE IDOC'S BUT I WANT TO KNOW WHAT EXACTLY WE GIVE TO THE ENDUSER SO THAT THE CUSTOMER CAN USE OR ACCESS TO THESE CONFIGURATION DONE DO TRANSPORT PROGRAMM OR SOME THIN ELSE I MEAN TO SAY WHAT IS THE THING WE GIVE AS PROJECT OUTPUT SO THAT WE CAN SAY PROJECT IS DONE AND TRASPORTED PLEASE REPLY

Former Member
0 Kudos
233

So does that mean there is no concrete solution to transport the ALE configurations in a dev > qa > reg > prod environment?

I just checked Murrah's response to this thread and seems like the SAP Transportation systems is really stubborn in such scenarios. Do you have any other views?

Sorry for opening an old thread..yet again.

Regards, Amol

amudee.com