SAP Cloud for Customer Tenant Landscapes: SDK deployment recommendations
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:
- Determine how many tenants you need
- Tenant landscape use case examples
- Considerations for tenant copies
- Tenant landscape recommendation with SDK
- SDK deployment recommendations – this blog
When using the SDK it is important to plan the landscape and how the solution will move through the tenant landscape. This blog highlights key topics discussed in the Deployment Recommendations with SDK presentation.
The presentation provides details on the following topics:
- Recommended Standard Landscape for SDK Development
- Advanced Options with more than 3 Tenants
- Solution Template Option
- Solution and Patch Process in Detail
This blog highlights the major points from the presentation.
Recommended Standard Landscape for SDK Development
As stated in the previous blogs, the recommended landscape is a separate DEV tenant that is used only for development. When setting up the development tenant, there are some very important considerations:
- Development tenant is a normal test tenant which is used solely for SDK developments.
- Create the development tenant from the (main) test tenant. Usually full copy, to copy the solution profile and test data.
- The test tenant remains the leading tenant for implementation configuration.
Use these tips to avoid obstacles:
- Do not assign the PDI work center to business users.
- Do not use the SDK development user for tests in frontend.
- Do not use the development tenant for integration, data migration preparation, report adoption and master/page Layouts, because of namespace switch in patch process.
Advanced Options with More than 3 Tenants
Whenever a test tenant is purchased, by default it is on the same system as your other test tenant. With multiple test tenants on the same system, both tenants must have the same version of the SDK solution. This may not be what you need.
Example:
In your company you have developers working on a DEV tenant. There are administration/key users testing on the TEST tenant. Additionally, you have user acceptance testing going on regionally. The user acceptance testing is done by a group of business users. It could be that while user acceptance test is going on, the key users are testing an updated version of the solution that has not yet been rolled out to the user acceptance testing. In this situation, the user acceptance testing may be on version 2.0 of a SDK solution, while the developers and key users are testing version 2.5 of the custom solution.
In order to support the previous example, the user acceptance testing needs to be on a different version of the SDK solution. This requires that the user acceptance tenant be located on a different system.
When test tenants are purchased and created, by default the system where they are located will not be known to you. You need to create an incident when requesting the test tenant and request it be on a different system in order to support multiple versions of the SDK solution.
Solution Template Option
Some consultants prefer to develop using solution template. This enables you to start coding when the design is not ready. There are disadvantages as well, for example business configuration content cannot be created. The presentation describes the pros and cons to help you make your decisions.
Solution and Patch Process in Detail
In order to deploy the solution to the (main) test tenant and production tenant, you need to assemble the solution in the development tenant and upload and activate it in the target tenant. Once the solution is assembled, all further developments and enhancements are done via a patch and must be compatible to previous versions. This means that deletion of objects (BOs, fields, BCOs, etc.) as well as change of data types is not allowed in a patch. However you can add new fields and objects and change the business logic in a patch. When the patch is then deployed to production, the entire solution is deployed to production. There are no ‘delta’ deployments. The actual deployment is a manual step, consisting of uploading a locally stored solution file to the target tenant and activation of the solution in that tenant. There is no transport mechanism between the tenants.
For more details on SDK landscape see Stefan’s Blog: http://scn.sap.com/community/business-bydesign/studio/blog/2015/08/27/sap-cloud-applications-studio-deployment-landscape-basics
Thanks, Eduard! Great blog and presentation!!!
Jaroslava Mruzova
Eduard - I'm talking with one of our partners now. The question is - when you are doing SDK with the DEV tenant - do you do the adaptation for custom fields, do we recommend that you do this on the DEV tenant, or do the custom fields in the configuration tenant and redo or download/upload.
-ginger
Jaroslava Mruzova - the answer from Eduard and our other SDK experts is the following:
1. If you know the custom field will require business logic, create the field in the SDK.
2. all other extension fields created by the adaptation tools (key user tools) - are created in the main config tenant. if you later find they need logic, export, import them into the DEV tenant.
That's our official recommendation.
Hi Ginger and Jaroslava,
the recommendation is to create KUT extension fields in the Test tenant and ex-/import them to the Dev tenant if required.
However if you require business logic for this field, I recommend to add the extension field with SDK, not KUT.
I will update the the blog to make that explicit.
Best regards,
Eduard
Thank you, Eduard Stelle - we really appreciate your guidance and deep insight! Thanks for updating the blog as well - you are 'de best!!
Hi Eduard,
Thanks for this informative blog. This is very helpful especially where you have 3 system landscape.
What if we do not have the original solution and only have the patch solution? Can we safely deploy just the patch?
We tried this in our test environment. Although it gives errors but imports the patch solution successfully and also activates it without issues. Not sure what those error mean.
Again is it possible to get your original solution back? I tried enabling the original solution in PDI but it reverts it to the immediate previous version but not the original solution.
Regards,
Sandeep
Hi Sandeep,
A (patch) assembly contains the complete solution, so you can deploy the most recent (patch) version to a "fresh" tenant right away without deploying previous versions before.
In the development tenant you can switch between the original and patch solution by de-/enabling the solutions. However original solution does not necessarily mean the first version of the solution. If you deploy a new version to a system, the solution will be updated in all tenant in this system where the solution is available. Check pages 8 and 9 in this presentation: http://http://scn.sap.com/docs/DOC-65100
This becomes important if you have a 4 or more tenant landscape in place.
Regards,
Eduard
Thanks Eduard,
We already did a small POC with this combination in one our QA tenant with a dummy solution and importing the latest patch went in successfully.
The only thing we noticed is that if you have PDI_AUTHORISATION_FIX WC assigned to you, you may get an Production Authorization fix error message, so the solution for this is to remove this and import the patch.
Thanks and Regards,
Sandeep
Thanks Eduard
I would like to know more about the Change Project tenants when it comes to later additions of SDK development. I mean, when Production is running and the client wants to engage in additional functionality development and deployment, do they need to know of what they can and what they cannot do in the Change Project tenant after requesting it from SAP Operations?
Hi Eugene,
This is a good questions.
In the change project case you should also follow the 3 tenant landscape approach. The change project should point to the main configuration tenant, not the development tenant. Once you deploy the custom solution to the test tenant with the change project, you will be able to scope the new custom solution to the solution workspacec. Before merging the workspace to production, the custom solution has to be deployed in the production tenant first.
Please check also this blog series on Change Projects: http://scn.sap.com/community/cloud-for-customer/blog/2015/08/04/understanding-change-projects
The actual custom solution is independent of any implementation/change project. Everithing you can do before go live, you can do after the go live as well. Of course you need to consider existing data in the system. If for example you introduce an extension filed automatically calculated in the BeforeSave event with the new solution, the extension field will remain empty for all existing records unless they are changed and saved after successfull deployment and activation of the new solution.
However there are limitation with patch solution, basically it is not allowed to do incompatible changes like delete objects or change data type. For further details on limitations in patch solutions please check the help document: http://help.sap.com/studio_cloud
Best regards,
Eduard
Thank you s much Eduard. You have answered my question almost fully.
There's only one minor thing for me to ask. Here it is: if a customer wants to use one of its existing Test tenants as a Change Project tenant instead of requesting a new one from SAP, can the customer do it? Can they ask for a decommissioning of that tenant after the solution has been merged with the Production?
Or they have to request a new Change Project tenant every time they need to modify some of their functionalities?
Thanks in advance for your answer.
Cheers,
Gene
Hi Eugene,
The question is answered in the blog series on Change Projects: http://scn.sap.com/community/cloud-for-customer/blog/2015/08/04/understanding-change-projects
You can use an existing test tenant for the change project, but you should not use the development tenant.
You can request decomissioning of the test tenant afterwards, but you don't need to. You can use the same test tenant for subsequent change projects.
Best regards,
Eduard
Thank you Eduard very much. I have thoroughly read the blog and found many of its points exceptionally important. I will use those points in my dealing with customers.
There's one point, however, somewhat missing from the blog, namely, what is the SAP main recommendations for the public cloud customers. I don't think it's a question for you specifically but rather a generic statement that our customers very often are looking for.
Cheers,
Gene
Hi Eduard,
One quick pointer and a very important one which can be added in your blog
When you try to download a copy of a solution from a tenant it will ask for description to give, you need to give the description same as the solution or else when you upload the Zip file in another tenant it will create a new solution with different namespace. So it will make things very complex for later patches for the solution.
This happens when you select Download a Copy not when Assemble and download.
We got to know about this in hard way.
Thanks and Regards,
Ajith J