Customer-Specific Solutions and Template Solutions
In the article “Scalable Solutions, Solution Templates, Customer-Specific Solution showing the difference”, Ralf Baumann introduced the different solution types that can be developed using SAP Business ByDesign studio or SAP Cloud Developer studio.
In this document, I will provide some background information on the different solution types. The following table shows an overview on the different solution types and their properties.
|Customer-Specific Solution||Template Solutions|
|Target group||Reseller, implementation partner, customer||Reseller, implementation partner, solution partner|
||Create re-usable solutions that can be imported into custom-specific solutions|
|Selling Process||Can only be deployed for 1 customer||Can be imported in multple custom-specific solutions of different customers.|
|Deployment and Updates||
||Import into custom-specific solutions as self-service via the studio (no SAP involvement)|
|Tenant Landscape Scenarios||
|Availability||ByDesign, Customer OD, Travel OD, Financials OD, general available.||ByDesign, Customer OD, Travel OD, Financials OD, general available.|
(There is another solution type, local solutions which are available in SAP Business ByDesign studio. They are for test purpose only and therefore not listed in the table. It is deprecated as of ByDesign 1302.)
Customer-specific solution are dedicated for one customer. Download/upload is technically restricted to tenants having the same Customer ID.
- … can be downloaded/uploaded to tenants having the same ByDesign, CustomerOD, … version. Note: Normally the PRD and the TST tenants of a customer are upgraded by SAP at the same point in time, so that different SAP versions between PRD and TST tenant should not occur.
- … can be copied (“deep copy”), for example for testing, fixing a project milestone, …. (FP4.0).
- … support the same set of features as scalable solutions (FP4.0)
- … cannot be listed on the SAP Store
Three development scenarios are supported
- Development in a production tenant before go-live (PRD only): Please note that, the tenant cannot go live as long as at least one solution has status In Development . This option is deprecated as of version 1305!
- Development in a customer test tenant (TST + PRD, by default in the same physical system). This is the default scenario and has two limitations: (1) BC sets for SAP BCOs are not possible, (2) Loss of test data during patch creation. The test tenant can be dismantled after patching and build up again for new patch (“original” of the solution resides in the PRD tenant)
- Development in a partner dev tenant (PDEV + PRD, on different physical systems). Solutions for different customers in one tenant are possible. The partner maintains customer ID for each solution in the development tenant.
The following figure shows the development scenario 2:
Figure: Development Scenario for Customer-Specific Solutions: TST and PRD tenant
The different steps in this scenario are:
- Setup of the test tenant as a copy of the PRD tenant: This includes configuration, master and transaction data
- Custom development in the test tenant: You can develop a custom-specific solution, test it with a copy of PRD data, deploy to PRD tenant via studio and create patch, test and deploy.
- Business configuration in the test tenant: You can maintain business configuration and deploy (“merge back”) to PRD tenant in the Business Configuration work center. Note: You must deploy the custom-specific solution before you can deploy the business configuration to ensure consistency between the TST and PRD tenant.
You can find the documentation on custom-specific solutions in the SAP help portal: https://help.sap.com/studio_cloudhttps://help.sap.com/sdk, SAP Cloud Applications Studio, Complete help: Print version. In the documentation, see section “Lifecycle Management of Customer-Specific Solutions ”.
You can find the procedures for development of custom-specific solutions in the Business Center (authorized user reqired): https://wiki.sme.sap.com/wiki/display/AMI/What+to+know+about+development+of+customer+specific+solutions
Note: By default, write access to SAP business object is disabled. If you want to get this removed, open an incident from your test tenant and SAP will remove the restriction. Unfortunately this is necessary for security and legal reasons.Please check the following business center document for details: https://wiki.sme.sap.com/wiki/display/AMI/What+to+know+about+development+of+customer+specific+solutions
❗ It is important to know that assembly, download, upload and activation can only happen for a consistent solution. This means, all objects must be error-free. Therefore you have to remove all test object, orphaned objects etc., which may be left over from the development. Here are some recommendations:
- To avoid time preasure and project “panic”, keep your solution as consistent as possible during developent:
- Do an “Activate” and “Check” on solution level regularly (depending on your amount of your development work at least once per week)
- Do a “test export” using the “Download as copy” function in the implementation manager (for example one week before your “production” transport). The “copy” function produces a “deep” copy of your solution during assembly.
- To reduce waste in your “main” solution, use a separate solution for “sandbox” coding, for example if you want to test some alternative implementation.
By following these recommendation you can reduce the risk of getting blocked by incidents during the “productive” download/upload.
A solution template is a customer-independent solution that can be imported into customer-specific solutions. You can create all items that you want to reuse in a solution, for example, business objects, UIs, web services (exception: key user content, such as mash-ups). The solution template itself cannot be used in a production tenant, but only the customer-specific solutions derived from it.
- … are not dedicated for one customer.
- … cannot be used productively. They have to be imported into a customer-specific solution before they can be used in a production tenant.
- … can be exported/imported to tenants having the same ByDesign, CustomerOD, … version (or +1).
- … can be copied (“deep copy”), for example for testing, fixing a project milestone, …. (FP4.0).
- … must not contain key user tool content (forms, reports, mashups) and BC sets on SAP BCO. All other content types including translation and BC sets for partner BCO are supported.
Multiple templates can be imported into one customer-specific solution.
A template always has the status In Development. You cannot create a patch of a template.
Import of updated template into customer-specific solution is allowed.
Two development scenarios are supported
- Development in a customer test tenant (TST)
- Development in a partner dev tenant (PDEV)
- Creating a solution template on customers’s production tenant is not supported
You can import the solution template into a customer-specific solution in the same tenant or in test tenants of a different customers.
You can find the documentation on custom-specific solutions in the SAP help portal: https://help.sap.com/sdk, SAP Cloud Developer Studio 1.0, Complete help: Print version. In the documentation, see section “Solution Templates Quick Guide for Customer-Specific Solutions”).
The solution template is a zip that you can store at any place. The content is not encrypted but, the content is protected against modifications outside the studio.
SAP provides some solution templates as how-to guides in the Business Center, Wiki, SAP Business ByDesign Studio, Best Practice for Implementation ( https://wiki.sme.sap.com/wiki/x/UIcqCwhttps://wiki.sme.sap.com/wiki/x/UIcqCw ), section “How-To Guides with Solution Templates” (requires an authorized business center user).
ℹ There have often been misunderstandings about partner dev tenants and test tenants. As it is allowed to develop custom-specific solutions and templates in the test tenant, customers see this from an semantical point of view as the “dev tenant” for the customer/partner. But there are differences:
- Test tenants:
Test tenants are upgraded, ususally together with the production tenant. The custom-specific solutions and templates also undergo the upgrades.
- Partner Dev Tenants:
There is currently no official supported way to upgrade such tenants. The procedure is the partner have to request an dev tenant in release n+1.
Solution templates can simply be assembled in release n and uploaded to n+1.
Custom-specific solutions need to be upgraded within the customer system for which they are build for. After this upgrade they can be assembled from this tenant (even from an production tenant) and uploaded to the partner dev tenant
With release 1302 we will simplify this process. There it will be allowed to install custom-specific solutions solutions which are assembled in 1302 in an release 1305, so that there is no difference to Template solutions
Customer-Specific Solutions and Tenant Isolation
In this section, I will describe the deployment of customer-specific solutions for customers with multiple tenants, for example for a customer that has one production tenant and several test tenants, for example for custom development, testing, migration tests, and so on.
- By default, all tenants of a customer are located in the same physical system.
- Development and patch development (updates) of the customer-specific solution is done in a dedicated tenant. The development version is only visible in this tenant.
- Updates are imported into the production tenant (PRD).
- Additional tenants of the same customer are updated automatically after import of the update into the PRD tenant. In other words there are at maximum 2 versions of the software available in the landscape: one version for update (patch) development (in a dedicated TST tenant) and one version for the PRD tenant and all other tenants. The additional tenants are updated with the latest patch only if the first version is already deployed in those tenants. The deployment of version 1 of the solution into any tenant is to be done explicitely.
Figure: Deployment of a customer-specific solution for a customer with more than two tenants