Wednesday, September 30, 2015

SAP Cloud for Customer; system landscape challenges

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

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?
The majority of C4C customers will answer one of these questions, and maybe both, with Yes. If this is the case then you might want to consider adding a development C4C system and I will explain why.

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
Change project
Extension fields
Master and page layouts
Code list restrictions
Key user adaptations
Code list mapping
Custom objects
Language adaptations
Business roles
Workflow rules
Mashup authoring
Report assignment to workcenters
Email / Fax settings
SLA’s and much more
Activity list configuration
Project scoping

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.


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.

1 comment: