Skip to Content
Author's profile photo Stefan Hagen

SAP Cloud Applications Studio Deployment & Landscape Basics


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.


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>”. 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_

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.

Bildschirmfoto 2015-08-27 um 17.00.21.jpg

Bildschirmfoto 2015-08-27 um 17.00.37.jpg

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.

Bildschirmfoto 2015-08-27 um 17.04.10.jpg

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.

Bildschirmfoto 2015-08-27 um 17.04.10.jpg

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.

Bildschirmfoto 2015-08-27 um 17.11.03 1.jpg


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

Bildschirmfoto 2015-08-27 um 17.16.59.jpg

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)


  • 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


Bildschirmfoto 2015-08-27 um 17.20.04.jpg

Details: The Original Solution is no problem in this scenario. The patch solution is in status “In Development”. See “Scenario 1”.



  • 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

Bildschirmfoto 2015-08-27 um 17.22.19.jpg


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

Bildschirmfoto 2015-08-27 um 17.24.09.jpg

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.

Bildschirmfoto 2015-08-27 um 17.25.36.jpg

This scenario is supported and a recommended option.

Scenario 6: Copy a Test Tenant to another tenant on the same system

Bildschirmfoto 2015-08-27 um 17.26.25.jpg

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:

Bildschirmfoto 2015-08-27 um 17.27.23.jpg

The procedure in this case is simple:

  1. Download and Assemble the original solution in tenant 111
  2. Upload and Activate the solution in tenant 112 (1)
  3. Create a patch in the new development tenant (2)
  4. Activate the patch for business users (3) see also chapter phase 3
  5. 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:

Bildschirmfoto 2015-08-27 um 17.48.45.jpg

The procedure in this case:

  1. Download and Assemble the patch solution in tenant 111
  2. Upload and Activate the solution in tenant 112 (1)
  3. Create a patch in the new development tenant (2)
  4. Activate the patch for business users (3) see also chapter phase 3
  5. 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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pushkar Ranjan
      Pushkar Ranjan

      Please tag this content with the tag c4c so that it shows up in the c4c community as well.

      Thank you.

      cc. Ginger Gatling

      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Done. Thx for the hint!

      Author's profile photo Swapnil Borkar
      Swapnil Borkar

      Hi Stefan

      Is there a way to identify which objects were modified in a patch solution ?


      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Swapnil,

      not out of the box.

      I have set up a git repository for my Projects folder in:


      Then I have set up a script doing a git commit every day:

      git pull && git add -A && git commit -m "Update `date +'%Y.%m.%d %H:%M'`" && git push

      Using this technique I can look when the last patch was assembled and can see the changes that have been made in a certain time frame.

      The downside is, that it also captures all generated content and metadata changes, which clutteres up the commit pretty much. This could be fine tuned, by setting up a .gitignore that ignores everything but the related filenames (bo/xbo/absl/uicomponent etc).

      Best Regards,

      Author's profile photo Swapnil Borkar
      Swapnil Borkar

      Hi Stefan

      In  section "Best Practice: Changing the development tenant  "  you mentioned Parallel development is not supported  .

      If we have a copy of DEV tenant into a new DEV tenant on a different physical system - in this case also parallel development is not supported ?

      What is your recommendation to have tenant which has latest patch solution but acts as  a sandbox for learning and trying out new things in SDK on top of existing patch solution.



      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hello Swapnil,

      If you copy a development tenant, you can of course develop in both copies then. But you can't do parallel development in a way that you merge the two patch solutions on a test system.

      You need to decide which development system is the future development system and only apply patches from this source system to test and production. The development system copy (you call it sandbox) must not be used to create patches for test + production.

      Best Regards,

      Author's profile photo Swapnil Borkar
      Swapnil Borkar

      Thanks Stefan .

      Author's profile photo Former Member
      Former Member

      Hi Stefan,

      When we are deploying patches from Dev to QA or from QA to PROD, is it necessary for all the business users to log off before the patch is activated?



      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Sandeep,

      While a deployment is running, Business Users may experience dumps when they're working in objects while they're being updated.

      My personal opinion is, that it depends on the size of the development. If it is a small one, I would do it in the evening or at "low usage" times. If it is a bigger one, it might be better to notify the users than exposing them to the risk of running into errors.

      Best Regards,


      Author's profile photo Former Member
      Former Member

      Thanks Stefan,

      This effectively means that we may need to advice users about possible downtime to deploy patches. As If there are fields being introduced on the Standard BO for e.g. Sales Quote then the user might see dumps if they are trying to Save the Quote object.

      Is there a way to automate patch deployment process rather than manually upload and activating the patch?


      Sandeep Chavan

      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Sandeep,

      A feature like this is not on the roadmap. You need to manually click the activate button.

      Best Regards,


      Author's profile photo Former Member
      Former Member

      Hi Stefan,

      thanks for the information! During the upgrade cycle, it is possible to implement a bug fix right? Either via the intermediate bug fix functionality or via a temporary tenant copy. However, how do we get back to a clean state after the patch? Does the direct patch actually create a patch solution in the prod tenant or is it simply possible to edit the source files? After both systems are on the same release, we would need to discontinue the current test tenant and request a new one as a copy from the prod one, right?

      Thanks in advance!

      Florian Rogner

      B4B Solutions

      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Florian,

      There is a production bug fix feature that enables you to do ad-hoc fixes in production and in the deployed solution directly. This will not generate a patch. You can directly change production code (ABSL only).

      After a production change has been made, you have to manually double maintain the change in the development tenant. Otherwise the change would be overwritten with the next patch.

      The prod tenant copy approach for patching purpose is very risky and should be avoided.

      Best Regards,

      Author's profile photo J. Cosijnse
      J. Cosijnse

      Hi Stefan,

      Is there a way to get the actual Solution ID ?  We use a link in the code where we use this SolutionID - as variable. (For now I use the Context.IsPatchSolution()) - but the code must be changed to get it working in the Dev-Tenant.  In Production this ID remains the same.


      Jeroen Cosijnse

      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Jeroen,

      we do not have a reuse library. Did you try to just write the solution ID in your ABSL script?

      To my knowledge the aliasing (namespace change) is doing a search and replace through all files. We had the issue in the past that the namespace in BO and ABSL scripts got aliased. You should be able to use this to your advantage. If you "YABCDE_" is your namespace, just write

      var namespace = "YABCDE_";

      variable namespace should contain YABCDE_ in dev and the aliasing would change it to the original namespace when downloading the solution.

      Then you can check the namespace with an if statement like: if(namespace.contains("ABCDE")) { ... }.

      Be careful. You can't write if(namespace == "YABCDE_")... because this would also be rewritten and the if statement would be always true.

      Best Regards,

      Author's profile photo Sathya Kumarasamy
      Sathya Kumarasamy

      Hi Stefan, This is great explanation. Thanks for that.

      I have a question here, When we are in Private Tenant the PDI development tenant needs to be created in separate system.

      Now Say I have 3 test tenants, which are used for Test(for config), QA (testing), UAT(testing) . If all these tenants are created in the same system. Then When we deploy the solution in first Test(for Config). The remaining tenants(QA & UAT) also automatically have that deployed solution ?



      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hello Sathya,

      I'm a little late with my answer. I still want to give you one. If you first deploy the solution to Test, it will not automatically show up in QA and UAT.

      But when you continue and deploy to QA, you can only deploy the same or a higher version to QA to the one that has been deployed to Test. If you deploy a higher version to QA, Test will also be updated automatically.

      The same is true for UAT. Deploying the solution to Test and QA will not implement it in UAT. But once the solution has been uploaded to UAT, it must be in sync (same version) with QA and Test.
      If you upload a higher version to UAT, it will automatically update QA and Test as well.

      Does this make sense to you? A solution is never automatically deployed to a tenant, but it will be automatically updated, in case it got deployed before.

      Best Regards,

      Author's profile photo Stefan Moeller
      Stefan Moeller

      Hi Stefan,

      Thanks a lot for this very comprehensive blog on PDI lifecycle management practices. Much appreciated!

      I have a few follow-up questions / concerns in regards to changing into patch mode.

      1. Namespace Issue

      After the switch into patch mode, as you have described, e.g. extension fields in a web service are in the patch solution namespace. Your recommendation is if I understand it correctly, to adjust all integrations from external systems (e.g. ECC via PI, third party systems) to account for this namespace. This is not very practicable, since typically cusotmers operate in a 3 tier landscape as well, and the integration code they develop in DEV has to run unmodified in TEST as well. Therefore, I am switching to a 4-tenant C4C strategy as soon as in patch mode, which has of course subscription cost implications. Better would be to avoid the external (xml) namespace to be changed for a patch solution.

      2. Deletion / Incompatible Change of Extension Fields

      After switch into patch mode, extension fields on a standard BO cannot be deleted anymore, or incompatibly changed (e.g. chnage of data type). The SDK help explains that this is to prevent data loss. But from my perspective, it is too restrictive. For various reasons, I think it's typical that you switch into patch mode already quite early before UAT / go live. In these stages, it would often be helpful to be able to do some refactoring of the solution, which is for example in this case prevented.

      Finally, we ran into the described issue of tenant copy, while the original solution was still in development. This already forced us to assemble the solution, and create a patch. See issues 1. and 2. 😉 ... shouldn't it be prevented technically, that a copy on the same tenant goes through in this case? There is sometimes different people doing different things in the project. In our case, the person requesting the copy had no knowledge of the implications.



      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hello Stefan,

      to 1) There is a java script snipped available to build a switch in the integration mapping so that the content can be transferred between all tenants, but the namespace is switched for the dev tenant:

      to 2) Yes, switching early to the patch solution is a good idea. The assumption is that the Partner develops as solution to a point where it's almost complete before it gets transported to the test tenant. At this point a refactoring is unlikely. If major changes to a BO model have to be made, it is still possible by introducing new fields and keep the old ones in the data mode.

      We are aware that it would be nice to have the possibility to delete such entities later on. There are ideas that are currently being evaluated to support this.

      to 2 paragraph 2) To my knowledge, there is a technical check available. I'm not sure why it does not catch all these scenarios. I'm not working in operations.

      Best Regards,

      Author's profile photo Matt Symes
      Matt Symes


      Excellent and comprehensive article - wish I'd stumbled across it earlier!

      Author's profile photo Fabian Szymczak
      Fabian Szymczak

      Hi Stefan,

      thank you for this blog.

      We are saldy facing the situation to just have one test tenant available for development, integration and testing.

      What exactly do you mean by saying: "Doing PDI developments will make this tenant incompatible with a later test or production tenant". What exactly are the impacts which we are going to be confronted with when we finished developing and fine-tuning etc. and when we then want to request the production tenant?

      I also don't understand why it is not possible to test my solution after I switched to patch. From my point of view it seems like I can just create the solution, do basic implementation and the switch to patch. After that I just use the patch for further development, integration and testing. Is it necessary to first deploy the solution to production tenant or can I just deploy the patch to it?

      Thank you and best regards


      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hi Fabian,

      everyone starts with a 2 tenant setup. Once you know that you're going to do custom development you should order an additional test tenant for development.

      Why this tenant will become incompatible with test/production tenants is why I wrote this article. I can't explain it again in a comment here. Read chapter "Phase 3" again.

      Best practice is:
      - get an additional test tenant
      - create solution + BACElement
      - create patch right away
      - activate patch for business users
      - start your development in patch on the development tenant

      If you stick tight to this, you'll face the least amount of problems later on.

      Best Regards,

      Author's profile photo Fabian Szymczak
      Fabian Szymczak

      Hi Stefan,

      thank you very much for your fast response.

      Excuse my imprecise explanation. I am pretty sure we won't be able to order a second test tenant. So I wanted to make sure that "incompatible" does not mean that it isn't possible  to have sdk development in a 2 tenant setup?

      What would you say will be the main issues with developing in a 2 tenant setup? Are there any restrictions after I created the patch, adjusted the integration flows and recreated test data which are not just connected to a bigger effort but maybe to technical restrictions or issues which could effect the production tenant?

      Also special thanks for your best practise advice! I assume I can also use it for 2 tenant setup?

      Thank you very much, I really appreciate your help.

      Best regards


      Author's profile photo Former Member
      Former Member

      Hello Stefan,

      Super interesting post.

      I tell you what we have done to see if you can give me a hand with this problem.

      We have requested a tenant refresh in the development tenant. We checked the environment (once the tenant refresh was finished) and had all the data with the configurations and others correctly. At the POI level, only the source solution that comes from the production environment (by the tenant refresh) is displayed.

      When creating and activating the solution patch, the Z objects that made reference to the source solution disappeared, and Z objects were created that refer to the patch solution without data.

      Do you know if there is a way to not lose that data (from the source solution) or to migrate the data from the source solution to the patch solution?

      I thank you in advance for the support. Stay tuned to reply.

      Greetings, Omar.

      Author's profile photo Former Member
      Former Member

      Excuse me, it's not POI, it's PDI.

      Author's profile photo Stefan Hagen
      Stefan Hagen
      Blog Post Author

      Hello Omar,

      sorry for the late reply. A tenant refresh, technically, is a tenant copy with an identity change afterwards. So by refreshing a development tenant, you would loose your development solution and it gets replaced with the productive one.

      You can create a development solution (patch solution) from the productive (original solution) again, but as you have seen, the custom objects (you call them Z objects) are empty afterwards.

      So ideally you won't refresh a development tenant. It's a rare scenario as far as I can tell, because mostly, production data is not wanted in the development tenant.

      However, you can "refresh" the configuration with the following workaround:

      1. make sure that the original solution in DEV has the same version as the original solution in PROD
      2. activate the original solution for business users (in PDI)
      3. request a solution profile copy from production to the DEV tenant.
      4. activate (and scope) the patch solution again for business users
      5. configure missing PDI business configuration

      This way, you would bring over the business configuration from production to development without loosing any data in custom objects.

      You would loose the business configuration parts that have been created with PDI (custom BCSets mainly) and you need to maintain them again in step 5.

      Best Regards,

      Author's profile photo Quyen Nguyen
      Quyen Nguyen

      Thanks Stefan Hagen for details bog.

      If I have may solutions, but many logics in differences solutions is conflicting . So how can I set up the execution order of those solution in the same tenant ?

      Can you please give me some ideas?

      Thanks lot !


      Author's profile photo Narpreet Singh
      Narpreet Singh

      Hi Stefan,

      I am facing some issues in opening the UI Designer after the creation of BO from the cloud application studio.

      It says "UI Designer has caught an exception. XRepositoryException (0)The request was aborted: Could not create SSL/TLS secure channel."


      Can you please help me out with this issue? I have tried 2733402 note as well. Nothing happened.

      Your prompt will be really helpful and appreciable.



      Narpreet Minhas


      Author's profile photo Praveen Kumar Mannala
      Praveen Kumar Mannala

      HI Stefan,


      currently we are implementing c4c utilities product which is yet to go live.

      currently we have development tenant lets say X. it is stand alone and not connected to S4 system. we are developing solutions ( changes to the solution, patch creation ) in this tenant using cloud SDK. once developed,  then solution is assembled and we are  moving it to different teanant, lets say Y, which is connected to S4 back end ( unit testing system ). once changes are unit tested, then we are deploying solutions to tenants which are in ITC cycle.


      it is taking longer development cycles to develop and  test the code because tenant X is not connected to the S4. so we are thinking to use tenant Y to develop solutions and patch creation  now onwards because it is connected to S4 and avoid doing the changes using X tenant. Both X and Y are test type tenants.


      can you please suggest how we can achieve this and Is there any risks associated with this approach ?

      Author's profile photo Kamalika Barua
      Kamalika Barua

      Hi Stefan,


      I know you have answered this question 5 years ago but I would like to ask this again on the basis of the Current capabilities of SDK solutions.


      Can we have two source development tenants for a test tenant? What are the issues that we can face?


      What is the best practice for us to ensure we can separately deploy project solutions (release will be slower) and bug fix solutions (release more frequent) without each interfering with the other?


      Thanks in Advance!