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.
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.
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!
Now the patch solution got created. But when you look at the frontend, you don’t see everything twice, right? So what happend?
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).
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).
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,
Very useful document, Stefan. Thanks a ton for sharing this !
Great Document, Stefan Thank you so much .............
Finally a concrete blog on this topic with out any confusion 🙂 . Appreciate your effort Stefan Hagen
Had one webservice integration that stopped functioning right after, wished to see this before that magic click. Thanks a ton! Stefan
Is the problem that was calling the events from the original solution and the patch solution together, even though one of the two solutions is not active, solved?
I do not understand everything.
When you say ALL custom fine-tuning activities, all BO instances, etc. Is it for this specific solution you are enabling/disabling or it means for ALL of your custom solutions implemented on this tenant.
I hope this is only for the solution you are disabling/enabling.
Thank you for your attention.
This is only for the solution you are disabling/enabling. 🙂
This is good news!
Thank you for your help.
Really a very useful piece of information .... thanks for sharing Stefan 🙂
I need clarification on this -
The side effects of Enabling the patch solution which you mentioned (under How does this look for customer? ) - they are valid for the tenant in which the patch is created.
If there are 2 test tenants (1 dedicated for development, other for testing) and patch is created in 1st Test tenant and uploaded to the 2nd test tenant for testing - these side effects wont be visible in 2nd test tenant.
Is this correct ?
this is correct. The switch only effects the development tenant (1st tenant), assuming you've not created a patch on the test tenant (2nd tenant).
Very well documented.
You mentioned that when we hide the original solution and unhide the patch solution - "All testdata in extension fields are gone"
Does that mean if I have standard fields present along with extension fields in a BO, the data in standard fields will persist and data in extension fields will be gone?
Kindly provide clarification.
Yes, this is exactly right. No standard fields is being changed. The extension of the original solution are being hidden and the extension fields from the patch solution are being set visible. Because they look like the same field (same label) on the front end, it looks like the data is gone (for the business user).
i need clarification this part: "Finetuning must be redone and also the integration part needs to be adapted."
Does that mean that if we redone finetuning and we adapt the integration with another system we can reupload custom data and test the patches ?
In our scenario we have only one test tennant and after the first deploy of the solution in the Production system we're not able to test patches until we deploy in production tennant.
I would highly recommend, that you move to a 3-tier landscape.
The SAP recommended lanscape for SDK development is:
DEV tenant - with the patch solution active
TEST tenant - with the original solution active
PROD tenant - with the original solution active
This give you the benifit of being able to test everything in DEV, have a proper transport test and still be able to transport reports, pagelayouts and business configuration between TEST and PROD.
I facing issue where we have not activated solution in the scoping but still the extensions that we did are visible, can you please suggest what must be wrong.
Nothing is wrong. C4C has a special mode. While you are developing in the original solution, the developments are visible on the frontend. Even when you do not have created a BACElement yet. This changes after the first deployment, where BACElement must be present.
Thanks Stefan, it's very useful and detail explanation.
Here is a case, in Dev, when I create another PES to extend custom field(BizID) to more services in patch solution. Both the backend and WSDL show BizID twice, see below.
Does that mean, there is only 1 BizID field in Prd, and the service field technical name is also the same as "BizID"?