Custom-specific Solutions - Process Details

[ThomasSchneider]

In my document Customer-Specific Solutions and Template Solutions I introduced the features and functions of custom-specific solutions and solution templates. In the discussion on this article, many questions on the process of custom-specific solutions have been raised. I tried to answer them, but I think it is helpful to summarize the discussion and introduce some figures to make the behavior more clear.

Let me start with the basics: Customer data reside in a tenant, a tenant belong to a system. SAP code, structures and database tables are cross-tenant artifacts; they are shared between the tenants of a system. Customer data are tenant specific and physically separated from each other. The tenant-to-system assignment is not visible to the customer and cannot be influenced by the customer. As a rule of thumb, tenants of one customer reside in the same system.

Each custom-specific solutions consist of cross-tenant artifacts and tenant-specific artifacts. Cross-tenant artifacts reside in a shared system area; the access to these objects is controlled by tenant-specific filters. If no filter exists in a tenant of the filter is switched off, the objects are not visible. Cross-tenant artifacts are, for example business objects, database tables and service interfaces with their proxy structures.

Initial Deployment

Figure 1 shows the initial setup of the development of a custom-specific solution. The solution mySol has been developed in a test tenant (TST). The filter is automatically created during solution creation and the cross-tenant artifacts are generated during activation of the respective object. During initial deployment, the tenant-specific artifacts and the filter is being created.

Figure 1: Initial Deployment

Notes

• The deployment consists of the following steps:
  • Assemble and download (in the source tenant, in the Implementation Manager of the SDK)
  • Upload and activation (in the target tenant, in the Implementation Manager of the SDK)
  • BC scoping and deployment (in the target tenant, in the Business Configuration work center): After the activation, the mySol solution is visible in the business configuration, but not yet in scope and therefore not visible for business users.
    • During initial deployment, you have to set the solution in scope (in the Business Configuration work center) and trigger a BC deployment (by clicking the “Finish” action for your changes in the BC change project).
    • During patch deployment, the BC deployment is triggered automatically as part of the activation process (“Data Update phase”).
• On upload, the system performs the following checks:
  • The customer number of the custom-specific solution (=customer number of the source tenant) must be the same as the customer number of the target tenant.
  • The SAP system version of the custom-specific solution must be the same as the version of the target tenant. This check gets relevant in two situations. (1) If you have downloaded the solution some time ago and the system is upgraded. In this case assemble and download the solution again in the source tenant (here: TST). (2) If the TST tenant and the PRD tenant reside in different systems with different SAP versions.
  • If a production tenant exists (in the system), the upload into a test tenant is not possible (see details below, see Figure 6 and the related explanations)
• You can request the dismantling of the TST tenant. If you want to continue with development/patch, you can request a new test tenant TST’ as copy of the production tenant. The test tenant TST’ contains the mySol solution and you can continue to create a new patch (see more details on tenant copy below, see Figure 5 and the related explanations).

Patch Creation

Figure 2 shows the patch creation. A new solution myPatSol, a new namespace and a new filter is created. The objects of the mySol solution are copied and the namespace is replaced by the new namespace of the myPatSol solution. Now, you can start developing the patch without modifying the objects of the original solution with your development users. Your development users have “privileged” access to the objects of the patch solution; you can see the objects of the patch solution. But for business users the changes are not yet visible, because the switch Pat for the myPatSol solution is still turned off.

Figure 2: Patch Creation

Enable Business User Testing

Figure 3 shows the next step “Enable Business User Testing”. In this step, the switch of the mySol solution of turned off and the switch of the myPatSol solution gets turned on. Now, business users see the objects of the patch solution.

Figure 3: Business User Testing

Note:

• BC deployment of the entities of the patch solution is possible only after the “Enable Business User Testing” step.

Patch Deployment

At patch deployment (assembly, download, upload, activation), the objects of the patch solution (having Version n+1) are deployed to the PRD tenant. In addition to the initial deployment, two activities are performed. (a) The namespace of the patch solution is copied back to the original solution (aliasing). (b) In an after deployment step, the tenant-specific parts of the solutions in other tenants are updated (automatic distribution).

Figure 4: Patch Deployment

Notes:

• During patch deployment, the BC deployment is triggered automatically as part of the activation process (“Data Update phase”).
• After patch deployment, the original solution and the solution are on the same version. When creating a new patch, a new version of the objects are created in the (existing) patch solution. (This means there is only one patch solution for all patches, not one patch solution per patch.)
• If you do not upload and activate version V(n+1) into the production tenant or if the activation fails, you can continue to create patch V(n+2) and upload this patch into the production tenant.
• If you request the dismantling of the TST tenant and a patch is still in development (not deployed), the open development is lost. You can continue with development/patch by requesting a new test tenant TST’ as copy of the production tenant (see more details on tenant copy below, see Figure 5 and the related explanations).

Tenant Copy

You can request a new tenant in the Business Configuration work center. The test tenant is created as a copy of the production tenant (or as copy of an existing test tenant). Figure 5 shows the following example: A production tenant PRD and a test tenant that is used for custom development exists. You have requested a new tenant for migration test (called MIG in this figure), which is created as a copy of the PRD tenant. As a result, the mySol solution is active in MIG tenant.

Figure 5: Tenant Copy

Notes:

As mentioned in the introduction, the MIG tenant will be created in the same system as the PRD tenant. But even if the tenant is created in a different system, this will make no difference for you as a developer of a custom solution.

Patch Deployment (With Additional Tenants)

Figure 6 shows the patch deployment for a landscape with multiple tenants. In addition to the situation shown in Figure 4, an additional automatic distribution step that updates the MIG tenant is performed.

Figure 6: Patch Deployment (Multiple Tenants)

Notes:

• If a production tenant exists (in a system), you cannot upload a custom solution into a test tenant (exception see next bullet point). In particular, you cannot upload a version n+1 or higher into another test tenant, if the PRD tenant is on version n. The reason for this check gets clear from Figures 4 and 6: An activation of a patch with version n+1 would change the cross-tenant artifacts, which are shared with the PRD tenant. This would lead to inconsistencies in the production environment.
• If you request a tenant copy of the PRD tenant before the initial deployment of the mySol solution was done, the copy MIG does not contain the mySol solution. Subsequently, it will not be included in the automatic distribution (shown in Figure 6). You can deploy the mySol solution to the MIG tenant; it must have the same version as version in the PRD tenant.

SAP Version Upgrade

No activities are required for the SAP system upgrade (=new SAP product version is applied). After the upgrade

Notes:

• By default, all tenants of a customer reside on the same system and therefore they are upgraded at the same point in time. If the TST tenant and the PRD tenant do not reside on the same system and the systems are upgraded at different times, you cannot deploy solutions from TST to PRD in the time between the upgrades. The SAP system checks the version of the custom-specific solution at upload.
• You should check your solution for deprecation of SAP entities once between two SAP upgrades and adopt you solution.

Outlook

In my next article(s) I will describe the process around solutions templates and partner development tenants and give an outlook on the future development planned for lifecycle management.