How many C4C systems do I need?Now that the number of customers using C4C is increasing, also the questions related to the tenant landscape are popping up more and more. 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. See for example this blog on SDN in which detailed information is available related to the possible setup of your landscape. 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.
The out-of-the box standard system scenario has always been that when you start with your C4C implementation you request a test system. On your testsystem you will configure the solution, perform finetuning etc, and when testing is completed you request a production system which is a copy of your test system. This system landscape setup is, in a simplified way, displayed in below picture.
|SAP C4C basic system landscape scenario|
The question is whether the above system setup is sufficient once you’ve gone live and want to support the implementation of small and bigger changes and also projects, additional roll-outs etc. The two most important questions you should ask yourselves to determine your system landscape approach are:
- Will I perform custom developments on C4C using SDK?
- Will I setup integration with a (SAP) back-end system?
Custom developments on C4C
When you plan to do some custom developments on C4C using the SDK (Software Development Kit) you want to test your custom development, not only from a functional perspective but also from a deployment perspective. Developing on a development system has two main advantages:
- You are developing on a separate system so it will not interfere with ongoing training or testing on your test system.
- Once your development is done, you can assemble it on development and deploy it on your testsystem.
Especially the second advantage is an important one when you want to minimize the risk of the deployment of the custom solution on your production system. Because if something goes wrong with the deployment it’s better to have issues on the test system rather then on the production system. If you do custom development on your test system you pretty much don’t have a dress rehearsal, deployment on production is your dress rehearsal and that doesn’t sound good, you want to practice first on test and fix issues if any! The result is 3 system landscape like displayed in below picture.
|SAP C4C 3-system landscape|
Integration with a (SAP) backend
The majority of customers using C4C will have some kind of backend integration, most likely either with SAP ECC or SAP CRM. Setting up this integration will require configuration/customizing and probably, depending on your scenario’s, some coding (in BADI’s). When you don’t have a development C4C system connected to your backend development system you can only test your backend setup after transporting it to backend test or quality. This is because your C4C test system is linked to the backend test or quality system. Technically it is possible to connect your C4C test system to multiple backend systems, development and test/quality, but that’s definitely not best practice and you might run into data related issues when you do this.
Especially for customers with a high degree of interfacing objects and backend custom development related to integration it might be beneficial to have a C4C development system connected to the backend development system. It will allow you to verify your integration setup, configuration and development without having to transport them to test/quality first. If you don’t have a development system you basically configure/develop in a black box, you will only know whether your setup works when you have transported your setup to test/quality.
How to keep C4C systems in sync
If this was a blog on SAP onpremise this would be a short paragraph, it starts and ends basically with moving transports via STMS. Keeping C4C systems in sync is not that straight forward, you will need to use various methods, depending on the type of content you want to synchronize, to keep your systems in sync. In below table the different synchronization methods and type of content are displayed.
Content transfer (download / upload)
Export / Import (download / upload)
Manual configuration on each system
Master and page layouts
Code list restrictions
Key user adaptations
Code list mapping
Report assignment to workcenters
Email / Fax settings
SLA’s and much more
Activity list configuration
|Synchronization options between C4C systems|
Content transfer between Test and ProductionYou can use the Content Transfer function to move your Master Layout and Key user adaptations (e.g. new KUT fields) from the test system to the production system. Both the export and import function is available from the Adapt function on the top right of C4C. It exports a XML file from your test system which can be imported on your production system.
|Content transfer via Export/Import|
Export / Import between Test and ProductionThe location of the export and import functions are different, depending on the object you want to export/import. The code list mapping options you can find under Business Configuration in the Silverlight user interface, for a Report under Business Analytics, for Document Templates under Application and User management and Language translation under Administrator.
|Export en Import functionality|
Change project between Test and ProductionWhen you are live with your implementation you should no longer perform all configuration (fine tuning and project scoping) on your productive system directly. It depends on the configuration you want to do whether you should do this directly on the production system or via a change project from test to production. This is displayed in the Activity list, options which have value “Add to shortlist” should be maintained via a Change project.
|Fine tuning as part of a change project|
The first step is that you have to create the change project on your production system (Via Business Configuration, Implementation projects, New) and the second step is that you request the solution profile which is created as a result of the change project creation, to be moved from Production to your test system. Copy of the solution profile of the change project is available via Service Control Center:
|Solution profile copy|
When clicking Copy Solution profile you will get a popup in which you can specify the source system / solution profile (production system) and the target system (test system):
|Solution profile copy|
I’ve come across this statement regarding change projects which is important to consider when working with change projects: when a test system hosts an already copied/active change project, then no other change project can be copied to this test tenant unless the change project is cancelled or completed. Whether this is true I have not validated yet but whether it’s possible or not, you might want to prevent working with multiple change projects at the same time because it might cause inconsistencies like described in this blog.
So let’s recap on the main question this blog tries to answer; how many C4C systems do I need? This depends per customer but like described in this blog, when you have an integration with a back-end system and custom developments in C4C there are certainly advantages of using a development system. When making this decision you should know that an additional development system is not free, you have to pay for it so knowing this some customers might decide not to use a development system. To be advocate of the devil, when you have a fairly standard integration without custom developments in your backend, have no or limited custom developments in C4C, you might be better off with only a test and production system. It will cost you less money and your system landscape is a bit easier to maintain.