This blog series discusses C4C tenants from the aspect of how many you need and examples of recommended tenant landscapes. The blog series includes the following topics:
2. Tenant landscape use case examples – this blog
Tenant Landscape Use Case Examples
In this blog we will look at several examples of tenant landscapes. All of the examples below are actual customer examples, following SAP’s recommendations.
Example 1: Basic Production Landscape
This example shows a basic production system. This subscription includes no SDK and no integration.
The test tenant normally referred to as the sandbox tenant, can be kept constant, or it can be decommissioned once you are live and you can create a new one as needed.
Example 2: Integration to SAP On-Premise
This example covers the scenario with integration to On-Premise. There is a tenant connected to quality assurance and a tenant connected to production.
In this scenario two test tenants are required: the subscription-booked test tenant and a purchased test tenant. This enables one tenant to be used to configure, decommission, re-create. The other test tenant keeps a permanent connection to QAS on-premise.
An important note is that all test tenants are the same. Meaning, the test tenant received when the subscription was booked could be used for the permanent integration to QAS. The additional test tenant that was purchased can be used as a sandbox – the one that can be decommissioned and a new one created at will. The important point is that for integration, an additional test tenant is purchased which ensures you always have a permanent connection to QAS and you always have a tenant to support configuration changes, test, lifecycle changes, that can be decommissioned and a new one created as needed.
Example 3: Integration to SAP On-Premise and SDK
In this scenario there is integration to QAS and PROD on premise, as well as SDK usage.
One tenant is reserved for SDK. This tenant should only have developers. No business users test or are active on this tenant. There is a test tenant integrated with quality and a production tenant. This scenario requires an additional test test.
Example 4: Integration and DEV test tenant
This example includes a development tenant used only by developers, another development tenant that is connected to SAP ERP OP DEV. In this example the SDK work is integrated with SAP OP, so extensive testing of this integration is required.
Two additional test tenants should be purchased to support this scenario. This is to support integration to quality and development OP systems.
In all of these scenarios you notice a separation of the development tenant. This is very important for consistency of the solution. Anytime SDK or integration is in scope, at least one additional test tenant should be purchased. Depending on the scenario, you may need two additional test tenants.
We have had customers take their test tenant, connect it to DEV on-premise, and then later switch all the connections to QAS on-premise. This is considered a high-risk approach and is not recommended. The cost of an additional test tenant is less than the risk of changing all the connections and managing the data inconsistencies.
When doing SDK work, it is recommended the tenants be separated by usage and the usage guidelines should be followed. The graphic below depicts the recommendation. This will be discussed again in a later blog on SDK deployment recommendations. The important point is that all SDK work is done on a separate development tenant that is used exclusively by developers and has only the required scoping and basic setup needed for the development work.
In the next blog we will discuss considerations for tenant copies.