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