- SAP Managed Tags:
Hi All,
Preface
This document describes the basic development and deployment life-cycle for SAP Cloud for Customer custom development using the SAP Cloud Applications Studio. The SAP Cloud Applications Studio is a client application installed on the developer’s computer and connects using a secure SSL connection to the SAP Cloud for Customer System. One physical system can host multiple Cloud for Customer tenants. A tenant is an secure and isolated runtime with one URL. Using this technique, SAP is capable of hosting multiple SAP Cloud for Customer instances for one or more customers on one system.
The SAP Cloud Application Studio gives the developer an easy development environment where he can develop event and script based without knowing the system internal architecture.
All entities created with SAP Cloud Applications Studio are stored in the common area of the system. They are invisible for all customers but the customer for which the solution has been developed. Only this customer can activate the solution in his tenants. There is a recommended way to set up a system landscape that includes custom development.
Terminology
There are a few words that are often misunderstood and mixed up.
| Term | Explanation |
| System | One system is usually powered by two or more servers. How much hardware is powering a system is usually not important to know. One system is one SAP ECC installation containing multiple clients and tenants. System are named with three letter identifiers like "LEF" or "KLB". |
| Client | One SAP ECC installation can host up to 999 clients. The clients are used to host tenants. There is a 1:1 relationship between the client and the tenant. clients are named by a 3 digit number like "010". Usually they come together with the system like "LEF 010" or "LEF/010". |
| Tenant | A tenant is one SAP Cloud for Customer instance running inside a SAP ECC installation. A tenant is running inside a SAP ECC client. The tenant is named by the tenant URL. It is build by the following notation: "https://my<tenantID>.crm.ondemand.com". The tenant ID is stable and should be used to identify a tenant. A tenant can be moved and therefore the client and the system hosting the tenant can change. |
| Deployment | A deployment describes the life-cycle step which copies (deploys) a solution using the SAP Cloud Applications Studio from one tenant to another. The deployment process does not necessarily involve SAP. The development party can download a solution to their computer (it is a zip archive) and upload and activate it on the target tenant. |
| Solution | A solution describes a custom developed AddOn, which has been built using the SAP Cloud Applications Studio. A solution is named like this "YDF1D4GKB2_ (My PDI Solution)". The prefix starting with Y..... is the unique identifier for the solution and should be used when communicating with SAP. |
| Role Code | Each tenant has a so called tenant role code. There are two role codes in SAP Cloud for Customer: "Test" and "Preproduction". The role code "Test" is used for test and development tenants. The role code "Preproduction" is used for production or production-like tenants. The tenant role code indicates in which landscape the tenant is hosted. This is important to know when it comes to upgrade cycles and downtime planning. |
Default Landscape
When a customer signs up for SAP Cloud for Customer, SAP provides a test tenant as initial tenant, which is used to start the implementation project. It can act later on as test tenant. Over time a development tenant (if required) and a production tenant will be added.
The customer does not know on which server his tenant is located. This information is not required on customer side. However, it plays a role when setting up a SAP Cloud Applications Studio (also known as PDI for "Partner Development Infrastructure") landscape, due to its deployment architecture.
The recommended landscape for PDI development is a 3 tenant setup:
- One development tenant (additional tenant, minimal configuration only for developers)
- One test tenant (fully integrated and primary test system)
- One production tenant (fully integrated for production use)
In a SAP Cloud for Customer contract, two tenants are included. This is enough for customers that do not need custom development. A third tenant should be bought in addition to build a full custom development landscape.
This picture shows the full process. The document will describe how to get there.
The landscape is usually built along the development progresses. We will have a closer look at the landscape step by step.
SAP provides the customer a test tenant. The customer uses this tenant to start the implementation project and configure it to his needs. Once configured, the customer requests a production tenant. The configuration gets copied over.
When the customer needs custom development, he (or the authorized development party) could connect to this test tenant with the SAP Cloud Applications Studio and start with the development. This is not recommended as this tenant is most likely integrated and well configured. Doing PDI developments will make this tenant incompatible with a later test or production tenant. Therefore it is necessary to order a dedicated development tenant (which technically is also a test tenant where PDI developments happens).
If an additional test tenant is requested before development is performed, the configuration from the initial tenant can be taken over. Once custom development has been performed, a test tenant can still be created, but the configuration must be redone manually as the configuration profile is now incompatible.
SAP only knows about two tenant types: "test" and "production". The full landscape for custom development contains two test tenants. Which of both is used for development doesn't matter. The term "development tenant" is used for the test tenant, that is used for development.
To make it simple, these are the possibilities:
- Option 1 (preferred): Request an additional test tenant. Start development on the new test tenant. Keep testing activities on the initial tenant.
- Option 2: Start development on the initial tenant. Request an additional test tenant. Move all testing activities to the new test tenant.
It is important to separate development from testing.
Phase 1: Perform Custom Development using SAP Cloud Applications Studio
The development party will create a solution, which is called "Original Solution". The actual solution name is the generated prefix value "ABCDE1234_". This prefix identifies the solution. This prefix is used in multiple places and is unique. Once a PDI solution got created, the tenant is now a development tenant. The developments are immediately visible in the system.
The developments can be tested in the development tenant. The development tenant should be configured only so much, that the developer can test. Do not rely on test data nor integration on the development tenant as there will be a change that will break both in Phase 3.
At the end of phase 1, there is one development tenant with a basic configuration and a test tenant which can be fully configured as far as possible without the custom developments.
The graph contains also the physical system AKL as example. This is only relevant when copying entire tenants. This is explained later. To be conistent in this document, the system is visible in all graphs.
Phase 2: First Deployment of Custom Development to the Test tenant
At a certain stage the custom development is either finished or at a stage where you want to test it in a well configured tenant. Then the solution should be transferred to the test tenant. The development party has to prepare the solution for the initial deployment. The solution must be error free and a Business Adaption Catalog entry must be created (developer task).
The development party can now deploy the solution to the test system.
PHASE 3: Switch the Development Tenant to Bug fix Mode
It is always advised to prepare the system for bug fixing, even if there are no bugs right now. Once a bug is found, the fix must usually be created as fast as possible, so it makes sense to perform these steps early. This is required only once in the entire solution life-cycle.
- Step 1: Create Initial Patch: The development party creates the initial patch in the development tenant.
After step 1, changes in this patch are not visible for business users. The patch solution is a new solution in the tenant and step 2 will set this solution visible and the original solution invisible. This step is only required once and will not affect any other tenants.
Business users do see the active solution (orange). Changes in an inactive patch solution are invisible.
- Step 2: Activate Patch Solution: The development party sets the patch solution active.
Activating a patch solution will disable the original solution. The patch solution has a different unique prefix. This has an effect on the runtime data. 
To understand the consequences, some technical details should be understood. Example BO model from original solution ABCDE1234_:
businessobject ExampleBO {
[AlternativeKey] element ExampleBO_ID:ID;
element Name:LANGUAGEINDEPENDENT_MEDIUM_Name;
}
This will generate SAP ABAP entities on the server with names containing the solution prefix.
Package: $ABCDE1234_
BO: ABCDE1234_EXAMPLEBO
- NODE: ROOT
- ELEMENT: ABCDE1234_EXAMPLEBO_ID
- ELEMENT: ABCDE1234_NAME
Runtime data is stored in the generated business object. In parallel to the original solution (1), there is now the patch solution with a different prefix. This results in new business objects, elements, etc. So technically the patch solution is a full solution copy of the original solution. It looks the same on the frontend. Therefore from the frontend side, the user can see no difference. For the business user, is looks like the data has been deleted.
Activating the patch solution will set the patch solution active (2). Therefore all runtime data stored in the original solution will be invisible.
Tasks to perform:
- Adapt integration with solution created web services to use the new name-space
- Recreate solution specific fine tuning
- Recreate test data
This step must only be performed in the development tenant. It does not affect any other tenants. This is the reason why it is advised to not rely on the development tenant test data/configuration.
The patch solution is now active.
- Step 3: The patch solution is active from PDI perspective and even if the status is "Active for Business Users" it actually means, that the solution is visible in the system scoping. Before it really gets visible for business users, it must be scoped and configured. If the original solution was scoped before and configuration was done, the steps must be performed again.
Activating the patch solution, will first remove the original solution from scoping and then add the patch solution to the scoping. This resets the solution configuration.
PHASE 4: Life-cycle for patching and bug fixing
The tenants are now ready to run the full deployment and bug fixing cycle. Each development requires three activities:
- Create new patch version (1)
- Perform development
- Deploy to test tenant (2)
The deployment process can convert a patch solution between the original solution and the patch solution namespace. Based on the tenant type, you can select to either create a patch on this tenant or replace the original solution. This conversion is called "aliasing". In the regular deployment process you will never need to create patch solution using a deployment. Usually you want to replace the original solution.
Phase 5: Deployment to production
A production system can be requested at any time from the test system, once the test system exists. If a production tenant got requested, it usually comes without the PDI solution. It is then possible to deploy the PDI solution to the production tenant and then merge back the configuration from test to production.
The developed solution can be deployed to production either from the development or from the test tenant.
It is okay to download the solution from the test tenant and deploy to production. However, it is not necessary as it would result in the same file, which was uploaded to the test system. So the file can be reused. The patch file also contains the full solution, so you only need to deploy the latest version.
Upgrade Life-cycle
In contrast to the SAP on-premise products, SAP Cloud for Customer is upgraded on a quarterly basis. Due to the fact that the systems are used by multiple customers, the upgrade times are static and cannot be changed. The SAP Cloud Landscape is divided into a test landscape and a production landscape:
- Test Landscape: Maintenance windows on weekdays, release upgrades two weeks prior to production. All tenants in this landscape have the tenant role code "Test".
- Production Landscape: Less customers per Server, maintenance windows on weekends/outside of business hours, upgrades are performed two weeks after the successful test landscape upgrade.
Implications for PDI:
PDI solutions are compatible with up to two higher releases, but not to a lower release. The release which a PDI solution belongs to is the tenant release at the time when the PDI solution got downloaded. For example: A PDI solution got downloaded from a tenant with release 1411. This solution can be uploaded to a tenant with release 1502 and 1505. The upload will fail on a system with release 1408 (lower release) and 1511 (3 releases ahead).
The test systems are upgraded two weeks prior to production. In this two weeks, a patch created in the test landscape cannot be implemented in production.
- Option 1: Wait until production is upgraded and upload the patch afterwards
- Option 2: Use the intermediate bug fix functionality and fix production directly (only code is supported, functionality must be enabled by SAP)
- Option 3: SAP can provide a temporary tenant (copy from production) which can be used to create a patch on the lower release and patch production immediately. This process is a lot of effort and should only be followed for very critical issues / escalations and can only be performed by SAP.
SPECIAL CASE: Tenant Copy
In order to copy a tenant with custom development in it, a few topics need to be taken into account. Here it is necessary to know the system setup. SAP Hosting is usually taking care, but they do not always know about the exact purpose of a tenant. Therefore it is important to align with them to avoid stepping in one of the traps described below.
This is especially important when a tenant copy process was not trigger from the system, but via an incident or other non-official ways.
In this chapter we always focus on a full tenant copy where the PDI solution is included in the copy process. Please keep in mind that the PDI solution is not included in a solution profile copy or a copy without master data.
Scenario 1: Copy Development Tenant with only initial Development on same system
Details: The initial development (see Phase 1) is performed in the Original Solution. The solution is in status "In Development". The same solution in this status can only exist on one tenant on one physical system. If the Cloud Applications Studio detects the same solution twice in status "In Development" on one physical system, it will disable both solutions and further development will not be possible until one solution has been removed (SAP support activity)
Options:
- If the solution gets downloaded using the "Download and Assemble" function in the Implementation Manager, the solution status is set to "Assembled". In this status a tenant copy to the same physical system is possible. After the copy, it is possible to create a patch in one of the tenants.
- It is possible to copy a tenant with an "In Development" solution to another physical system. You have then two development solutions that are independent. There is no way to sync the solutions later on. This can only be advised as a temporary solution where one of the tenants will be deleted afterwards or for demo or POC purpose where the life-cycle is not important.
Scenario 2: Copy Development Tenant with an Original and a Patch solution on the same system
Details: The Original Solution is no problem in this scenario. The patch solution is in status "In Development". See "Scenario 1".
Options:
- If the solution gets downloaded using the "Download and Assemble" function in the Implementation Manager, the solution status is set to "Assembled". In this status a tenant copy to the same physical system is possible. After the copy, it is possible to create a patch in one of the tenants. This is not a good solution as it is possible to create a patch on both tenants and this would result in two "In Development" solutions.
- It is possible to copy a tenant with an "In Development" solution to another physical system. You have then two development solutions that are independent. There is no way to sync the solutions later on. This can only be advised as a temporary solution where one of the tenants will be deleted afterwards or for demo or POC purpose where the life-cycle is not important.
- It is possible to "Download and Assemble" the solution and then deploy it on the same tenant to update the Original Solution. Then delete the Patch solution, perform the tenant copy and create the patch solution again from the Original Solution. When recreating the patch solution, you must perform the steps described in "Phase 2,3 and 4" again.
Scenario 3: Copy Development Tenant with only an Original Solution to another tenant
This scenario is supported. If the Original Solution is in Status "In Development" you will end up with two development tenants that are independent. Make sure that the solution gets assembled on one tenant and that further development is performed only on the other tenant after the copy. Or assemble the solution before the copy is performed and create the initial patch only on the future development tenant.
Scenario 4: Copy Development Tenant with a Patch and an Original Solution to another tenant
This scenario is supported. You will end up with two development tenants. Make sure that further development is only performed on one tenant. Also take into account that on both tenants the Patch solution is active. Therefore it is advised to delete the patch solution on one tenant and activate the original solution. Be aware that activating the Original Solution will result in the same consequences as described in chapter Phase 3.
Scenario 5: Copy a Test Tenant to another system.
This scenario is supported and a recommended option.
Scenario 6: Copy a Test Tenant to another tenant on the same system
This scenario is supported. Be aware that a solution on multiple tenants on one physical system must have the same version. If a patch is deployed for example to tenant 112, the solution will also be updated in tenant 113 (or the other way around).
Best Practice: Changing the development tenant
Sometimes it is necessary to move the PDI development to another tenant. How this can be done depends on the status of the PDI solution that needs to be moved. If custom development has not yet been assembled for a deployment, the landscape should look like this:
The procedure in this case is simple:
- Download and Assemble the original solution in tenant 111
- Upload and Activate the solution in tenant 112 (1)
- Create a patch in the new development tenant (2)
- Activate the patch for business users (3) see also chapter phase 3
- Activate the solution in scoping and configure it
Make sure that nobody is creating a patch on the original development tenant. Parallel development is not supported. If both tenants are on the same system, both patch solution would be disabled and the situation would require SAP to resolve the situation.
This process can be performed if the new development tenant is located on the same system as well as if the new tenant is on another system.
If custom development has also progressed and patches have been created, you are most likely in this situation:
The procedure in this case:
- Download and Assemble the patch solution in tenant 111
- Upload and Activate the solution in tenant 112 (1)
- Create a patch in the new development tenant (2)
- Activate the patch for business users (3) see also chapter phase 3
- Activate the solution in scoping and configure it
Make sure that nobody re-opens the patch solution in the original tenant. Parallel development is not supported.If both tenants are on the system, both patch solution would be disabled and the situation would require SAP to resolve the situation.
If you want to delete the patch solution on the original tenant, this must be performed before a patch is created in the target tenant when both tenants are on the same system.
About this document
This document has been written to answer common asked questions and it provides a full picture of the PDI deployment possibilities. The goal is to describe the solution life-cycle to partners, PDI-developers and project teams. Some processes have been simplified and are more complex under the hood. Following the described recommendations should save you from any PDI related lifecycle problems.
30 Comments
