SAP Cloud for Customer – tenant refresh


SAP Cloud for Customer – tenant refresh

SAP Cloud for Customer (C4C – Sales Cloud) is a CRM class system available in public and private cloud.

The SAP Cloud for Customer solution helps you manage day-to-day sales and service interactions efficiently by sending and receiving signals between front- and back-office solutions and providing a single view of the customer.
C4C login page

The standard landscape of the system is based on a two-tier structure:

We introduce all changes in the operation and appearance of the system to the test system. When the changes are accepted by the business, the changes can be transferred to production. However, with the uptime of the systems, the data (master data e.g. customers, contacts, products, sales documents, etc.) differs between the two systems. We also have changes on the test system that are still in the testing phase or will never be released into production. The systems are slowly “crossing” and maintaining this state of affairs is becoming more and more difficult. For example, the new process of handling service requests in production generated us real documents, while on the test system we have test data, a test unused part of the configuration, etc.

Therefore, it is worth thinking about refreshing the test system from time to time. Of course, we can also refresh the production system, but let’s focus on the scenario:

Refreshing the test system with a full copy of the settings and master data of the production system.

Of course, the official SAP Note can be helpful here –> KnowledgeBase 2751824 and it’s worth getting acquainted with. What is also worth determining before we start?

Create a reconstruction team consisting of people from the system owner (client), a company supporting the integration bus (SAP PO, SAP CPI, etc.), possible third companies supporting other integrated systems and we, the consulting company administering the system -> we determine the scope of the reconstruction, systems involved in the reconstruction, for example refreshing the SAP S4 quality test system, SAP Commerce test system, etc., time frames of individual activities -> assign tasks, steps, plan joint meetings, etc.

The most important thing is to get all people in time, steps, plan activities and … take your time. Haste is a bad advisor.

Procedure for rebuilding the test system with a copy of the production system data:

  1. We set the date and time of ordering the system from the production copy. This time must be the production bus stop time and the stop time for all other production systems to make copies. The downtime of the C4C production system is 4 hours, so it is worth planning it for the weekend. The time that SAP needs to recreate the test system is about 12 hours (possibly even 24 hours). Of course, the test production bus should also be stopped at the same time for several days before we start restoring the communication systems. The purpose of this action is to prevent messages from other systems from being lost and we will maintain the integrity of the systems concerned.
  2. We order a backup for the refreshed system, preferably the day before. This is known as a “system restore point”. This will allow us to restore the test system from before our actions in case of problems. The backup time is 4 hours (the test system will be unavailable at this time). Such a copy made by SAP has a validity period of 2 weeks, unless we have a system upgrade (every quarter), then the restore point is deleted.

3. We order a test system refresh. Remember about the correct selection of the scenario, source system and start time. It is recommended to order a system refresh at least 2 working days in advance so that SAP OSS is ready to prepare. Of course, during the system upgrade (2-week period) it is not possible to start this process. Therefore, let’s remember about the C4C update schedule 🙂

4. A very important step – Collecting the original data (settings) of the system to be refreshed. In other words, our test system will be almost a 1: 1 copy of the production system after refreshing. Therefore, we need to collect data to help us get the test system back working before the refresh. What will we need?

List of systems to be restored
Event notification
E-mail addresses for service requests

g) SSO login settings. After refreshing the system, you need to set SSO logon again

Download the client configuration file metadada.xml from SAP Cloud Identity and after refreshing, upload it to C4C

We save local graphic files, which we will later upload to the system again

From here, we will not download but upload the PO/CPI certificate

5. We set up a notification on the production system about production downtime (in advance). Before the entire process, we should notify system users about the production downtime. Thanks to this, after logging in, the user will receive information about the unavailability of the system.

Notification for employees about downtime

6. After the system has been refreshed and handed over by SAP, we log in with the production data. As mentioned before, this is an almost 1: 1 production system. Then we deactivate business users except for system restorers. We don’t want users to create new documents before handing over the system.

We block employees so that no one makes changes

7. The most time-consuming point -> We restore the settings of the collected data for the test system, which we collected in point 4.

Remember to adapt the data taken from production to remap the system ID from production to test. Without this action, data copied from production will not be output to the correct systems.

Adapt the integration content for the new tenant
Our goal, to restore the system as it was before

8. Integration testing that messages go out and in to C4C

We communicate with other teams or messages come and go.

We need to achieve this effect!

9. We restore test business users.

Sometimes test users are necessary on the test system, it is worth restoring them, e.g. a test trader, manager, customer service operator, etc.

10. Passage of test scenarios for individual processes with integrated systems.

For business, we create system acceptance scenarios with a detailed schedule of steps. The processes should be possible to perform as well as in production.

Several test scenarios

11. Unlocking business users and putting the system into testing

When all tests are performed correctly, we hand over the system to the users

We unlock users

The above procedure shows in a simplified way what tasks are required to refresh the test system. After this procedure, the test and production systems have the same settings and the data (master data) are identical (from the time the copy was made).

Tips for the refresh process

Contact Person

Blog writer

Krzysztof Pieszak

Senior CX Consultant

Vincit Bilot

Bilot & Vincit have joined forces!

See where the story continues 

You have Successfully Subscribed!

Vincit Bilot

Bilot & Vincit have joined forces!

See where the story continues 

You have Successfully Subscribed!