This process will provide you a flexibility where you can request for a tenant refresh of an existing test tenant. This service is available for Business ByDesign/Cloud for Customer/Cloud for Travel.
D4C/Edge customers cannot request this service.
The tenant refresh process contains of the following steps:
- Copy of the source tenant (which requires a downtime about at least 4 hours)
- Switch of the tenant identities (switch of tenant ID and tenant URL)
- Invalidation/Decommissioning of original test tenant
This means that we do a full copy of a source tenant (source will always be a productive tenant)and switch the identities (tenant ID and URL) of the test tenant which should refreshed.
In the end, the original test tenant will be decommissioned by this process.
The result of this process is to retain the URL and tenant ID of an existing test tenant and to refresh it with data of source tenant (Only productive tenant).
For example, a tenant refresh can be used for integration tests of a SAP Cloud for Customer test tenant which is already integrated with an ERP system and testing requires new data of the productive tenant.
- The customer is requesting a full copy (clone = 1:1 copy containing all data from Production to Test only)
- The customer is not LIVE yet and has not closed the first implementation project (Only possible before Go-Live)
- When customer-specific solutions (PDI solutions/one-off projects) are in place, this will only work when version of existing customer-specific solutions are the same in source tenant and tenant to be refreshed.
If you have open incidents on the tenant to be refreshed and you do not want to confirm them, we cannot execute this process.
There is a limitation for customers who have closed the first implementation project and are already LIVE. In this case, the tenant refresh process is not supported.
Upgrades & Restriction for the Tenant Creations
1. During upgrade, it is not advisable to terminate the tenants.
2. When a customer requests a production tenant during the upgrade or close to it, then the tenant delivery is delayed, because we have a upgrade version mismatch i.e. If a customer requests for a production tenant with the solution profile copy from test. At this point the test is upgraded to new or higher version, but the production systems are not. Hence, we have to wait until the production systems are upgraded to the same version. Then only tenant creation can be done.
How to Request a Tenant Refresh via an Incident
To request a tenant refresh, please create an incident out of your Cloud tenant.
Provide the following information in the incident to request tenant refresh:
1. Customer name.
2. Customer number/ID (Business Partner Number).
3. Tenant ID or URL of tenant which is source of the copy.
4. Tenant ID or URL of test tenant which should be refreshed.
5. Requested downtime of source tenant: Start time, start date during the tenant refresh creation, the source tenant needs to be stopped for 4 hours.(Please be specific about the time zone).
"A minimum downtime of 4 hours is required for the source tenant during a tenant refresh.
Please note that over and above 4 hours, downtime is subject to the size of the source tenant and will be estimated during request creation"
This activity can only be performed outside of the contractual maintenance window.
6. Confirmation about short downtime of test tenant to be refreshed and new tenant during identity switch.
7. Confirmation that you can agree with deletion of original test tenant (test tenant which should be refreshed)
8. Requestor/Contact Person It is important that you provide with the name and e-mail address of the person who should be informed when we face issues during this process.
1. The tenant refresh is generally provided within 1 business day of the customer making the request. The customer will be informed of completion via update on the incident.
2. Tenant refresh process is only available for the Customer tenants. Reference or Partner Development Tenants are NOT supported.
3. Communication systems and arrangements in the refreshed test tenant:
All communication arrangements have to be rebuilt for the refreshed tenant.
4. Certificates in the refreshed test tenant:
Certificate mapping should also be done again on the refreshed tenant.
5. Refresh is 1:1 data copy of production (clone) and hence would also have the certificates copied.
6. All incidents will be confirmed for the original test tenant to be refreshed.
7. If you want to refresh an existing development tenant, that you will save local all existing PDI solutions as the refreshed tenant is clone of the source tenant which will have only the PDI solutions of the source tenant.
SAP Business ByDesign, SAP Hybris Cloud for Customer, SAP Cloud for Travel
Tenant Refresh , KBA , tenant refresh , tenant refresh , SRD-CC , Cross Components , How To