Enable/Disable Solution and how to drive your customer nuts (all fields empty)!

If you have created a patch solution and all custom and extension fields are empty on the frontend, then this article is for you.

—

Update: I wrote another article about the optimal Cloud Application Studio Development Landscape which relates to this document here in Chapter “Phase 3”.

—

In the lifecycle of a Cloud Applications Studio Solution, there is the time where the initial development has been reached a level where the solutions should get deployed to a test system. But there is this one button a lot of people do not know the consequences of pushing it.

Let’s look at the deployment process first to understand the technology.

Step 1-3

When you need to deploy a solution to another tenant, you can download and assemble it. This will close the solution forever. Starting from now on, the original solution can only be updated using patches.

Step 4-5

In order to continue development or fix bugs, you need to create a patch. A patch is technically a solution copy. Lets think twice about the term solution copy. The solution is copied into a new namespace. So afterwards the same solution exists twice in the system. Everything is getting duplicated – the fields, the views, everything! Again, so you remember: everything got copied!

Step 6-8

Now the patch solution got created. But when you look at the frontend, you don’t see everything twice, right? So what happend?

Step 9-10

There is a mechanism in place, which hides the solution. After you have created the patch, nothing on the frontend changed, because the patch is disabled. Technically everything is there twice, but the patch solution is hidden per default (solution disabled).

Step 11-12

So maybe someone or some documentation told you, that you can enable the patch solution, so everybody can test it. This is very true, but before clicking this button, you need to understand what the consequences are.

Now think about what we have here. Everything is in the system twice. With this button you hide the original solution and you unhide the patch solution.

How does this look for the customer?

• All testdata in extension fields are gone
• All custom defined finetuning activities are empty
• All custom BO instances are gone
  
• All personalization on custom screens are gone
• Integration does work, but the values in ext fields do not show up
• Custom inbound webservices are not working anymore
• Reports are not showing new data
  

Technically nothing gets lost (except the finetuning data, because the solution got descoped), but the values are not visible, because they are in now invisible fields. Switching back to the original solution would also bring the data back (except finetuning).

Conclusion

Enabling the patch solution solves a lot of problems for the developer. It makes a lot of sense to perform this step. But everybody in the project team must understand the consequences and the time when this happens needs to be part of the project plan.

Finetuning must be redone and also the integration part needs to be adapted. All the entities in the system are prefixed with the Y*** prefix. This is the only thing that changes between the original and the patch solution. So this must be adapted in integration.

This patch solution namespace is only used in the development tenant. All other environments are not affected by this.

I hope this helps to understand what happens on solution enable/disable and lessens the amount of incidents that are getting created by customers and consultants.

If you do not have a dedicated development environment, things are more complicated as you would have the additional consequence, that you’re not able anymore to test the deployed version before deploying to production.

Have a good day,
Stefan