As a result you have to manually maintain the configuration under “content transfer” on your test system, it’s not an option to download/upload them from development to test. This is related to the namespaces which are used when creating SDK solutions, if you’re interested in the technical details please check this blog on SCN. This is because there are technical limitations when you create custom fields in SDK, you can’t use them in page layouts and export these to test. It’s not meant for any configuration activities with the intention of moving this configuration with one of the above automated methods to the test system. SAP advises to use the development system only for SDK development. This blog on SDN has a lot of (technical) details, in this blog I will try to keep it a bit more simple and focus on the most frequently used scenario’s.īefore we go into some of the details of these synchronization options let’s first determine which systems we can keep in sync with above methods because there is a limitation when you use a development system. See for example this blog on SDN in which detailed information is available related to the possible setup of your landscape.
So you are not the only one struggling with this! We see a lot of content online the last few month’s on how to setup your C4C tenant landscape.
Now that the number of customers using C4C is increasing, also the questions related to the tenant landscape are popping up more and more. With the introduction of cloud based solutions like C4C it’s not that obvious any more, in this blog we will give our point of view on how many C4C systems you should have and describe the approach on how to keep your cloud landscape in sync. In the old days it was pretty simple and straightforward, you would have a 4 (or sometimes 3) system SAP landscape consisting of a development, test, acceptance and production system.