SAP Cloud for Customer; system landscape challenges

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. 

Before 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. SAP advises to use the development system only for SDK development. 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. 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. 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. 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. Technically the options under export/import might work between development and test but because you already have to do the majority of configuration manually it makes sense to also maintain these as a manual activity on your test system. 

Synchronization options between C4C systems

So basically the only thing that you synchronize between development and test is your SDK solution (assemble your SDK solution on development and deploy it on test), all other configuration should be done manually on the test system. Like displayed in the table, from the test system you can use different methods to synchronize with your production system. So wrapping up; there are no automated tools you can use to transfer configuration between development and test, these automated tools do exist but should only be used from test to production.

Content transfer between Test and Production

You 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 Production

The 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 Production

When 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.

Conclusions

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.