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.
https://help.sap.com/viewer/product/SAP_CLOUD_FOR_CUSTOMER/CLOUD/en-US?task=discover_task
The standard landscape of the system is based on a two-tier structure:
- Test System
- Production System
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:
- 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.
- 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?
- Communication systems (configuration of communication systems, what communication scenarios are connected to these systems, passwords for outgoing and incoming users, access paths → service URL for outgoing connections + port number, OData users)
- Mashups → collecting a list of custom mashups available on the test system, URLs to services (copy).
- Check if we have any unique business roles that are to remain (write down the role settings or transfer them to the production system in advance). I recommend transporting them to the production system.
- Write down the event notification configuration
- Write down the e-mail address settings for the site.
- Settings for SAP Commerce for ASM (AssistedServiceMode)
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
- Outlook integration settings. If we use the Outlook server integration for C4C, remember that the data will be deleted! It is worth collecting the data of the organization and integration profiles
- Collect system logos for branding and main background graphics. Just a look & feel for the purpose of distinguishing between tenants.
We save local graphic files, which we will later upload to the system again
- Download the test bus certificate for communication. Thanks to this, the C4C is lowered to the PO/CPI, remember that as well.
- For security purposes, the organizational structure, service categories, product categories, and territories configuration from the test system can be exported to a file. There is no step necessary. but for security purposes, it’s a good idea to export your data files, especially as C4C allows it.
- Collect a list of named administrator accounts worth restoring accounts to after the refresh
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.
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.
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.
8. Integration testing that messages go out and in to C4C
We communicate with other teams or messages come and go.
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.
11. Unlocking business users and putting the system into testing
When all tests are performed correctly, we hand over the system to the 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
- If we have active development (PDI) in production, the refreshed test tenant will also keep them.
- The minimum time to make a system backup is 4 hours (depending on the selected options). Production will be unavailable during this time.
- If we have scheduled system maintenance, we cannot make a backup of the system during this time
- Please note that the refreshed tenant will be available 8-10 hours after the source tenant is released (usually it takes a little longer). During this time, the refreshed tenant will also be unavailable for use.
- It is a good idea to perform a system restore point before refreshing the system.
- All communication systems must be recreated.
- Communication certificates will be copied from production.
- The source system can be test and production, and the target system only test.
- All open incidents for the refreshed test system will be confirmed automatically, i.e. they will be closed.
- Single sign-on (SSO) and Outlook integration (server site integration) must be reconfigured on the refreshed system.
- After the system is refreshed, the users and passwords from the production system will be copied from the production copy.
- The system ID and URL remain the same regardless of the selected refresh scenario.
- We cannot order a system refresh when we have a C4C system upgrade period (2 weeks, where the test is in a newer version than production).
- The transport paths will be copied.
- You must close any active implementation projects before performing a refresh
