Skip to Content
Technical Articles

Why you should avoid editing custom forms from UI

Hi All,

 

This blog intends to educate customers and partners about why they should avoid editing custom forms from UI or uploading custom forms downloaded from UI. This is a frequently encountered scenario and below are the relevant details related to the same.

 

You can edit a custom form in the SAP Cloud Applications Studio (Studio). You can also edit it in the Form Template Maintenance work center. However, the impact of the two cases is different. When a custom form is edited from the Studio, the changes are stored in the solution branch. Whereas when a form is edited from the UI, the changes are stored in a separate branch called customer branch.

The main problem that you might face is the loss of changes that you have made in custom form using the Form Template Maintenance work center in the UI. You will have to make the same changes again in the Studio. Therefore, we recommend that you use the Studio to edit custom forms.

 

The image below shows the Form Template Maintenance work center:

 

The image below shows the XDP file which can be edited from the Studio:

 

We recommend that you do not edit custom forms from the UI for the following reasons:

  • During activation of FTHD (form template header file) file, the corresponding XDP files are cleaned up. And the clean-up ultimately fails because of customer branch. The only way to proceed is to remove the customer branch.

There can be following possibilities:

    • Solution is in development: When this issue happens for an in-development solution, there is no way we can proceed for assembly without removing this customer branch. Removing this branch also removes changes done corresponding to it.
    • Solution is assembled or deployed: In this case, there can be an issue while creating patch. Also, every time tenant copy is triggered, manual correction must be done in target tenant every time or corrected once in source tenant.

 

  • Secondly, this increases the maintenance load. Incidents related to this issue are encountered frequently and many of them have very high priority. So, every time you make a change from the UI, a customer branch is created that stops the activation leading to incident creation.

 

We have already communicated to customer and partners to edit forms from the Studio only and not do from the UI. However, a lot of incidents are raised and we have to correct them manually. In addition, customers and partners have concerns about data loss corresponding to the files being corrected. So, it is better to avoid this behavior and consider editing forms from the Studio itself.

 

Best Regards,

Pranay

 

 

4 Comments
You must be Logged on to comment or reply to a post.
  • Hey Pranay,

    thanks for that insight. Still I am wondering if that restriction also applies to production tenants where I will never have a solution in development. So, will we run into issues when modifying a custom form on a production tenant and at some later point in time will deploy another version of the solution? Or will it then behave just as standard and there will be a new version of the form that can be actived, but not necessarily must be activated?

    Best regards,

    Daniel

    • Hi Daniel,

      The only way to do a change in forms in production tenant is to edit it from UI. Since state of a solution can only be deployed in production tenant, there will be problem only during tenant copy or move of this PROD tenant where solution is present. The suggested way of doing the same is to do changes in corresponding test tenant and then deploy it to PROD. Please note that in future, we will work on disabling editing of custom forms from UI.

      Let me know if you have any other query.

      Best Regards,

      Pranay

      • Thanks for your feedback, Pranay. This is very unsatisfying, as it makes forms in multi customer solutions (MCS) sensless. Using KUT is the only option to customize such forms to the customer’s needs. It must be possbile to add a company logo and address to a form. What is SAP’s inteded way to deal with forms in MCSs?

        But also for forms in customer specific solutions this is not very satisfying.

        Best regards,

        Daniel

        • Hi Daniel,

          I understand your concern. But consider the following situation right now which will make you understand why we intend to do this change. Till now, partner edits the forms and they do not know about the consequences until they try to activate forms again from PDI. But, general case is that partner would create patch or ask for tenant copy/move. In those cases, the process gets blocked till we do not remove the layer which has those changes. We remove them by taking partner’s permission and then partner has to ultimately do those changes from PDI.

          So, in the end, it comes down to PDI only. Since it has been already been informed to partner to not do the changes from UI, it is better to block the same from UI. This is the understanding behind this scenario.

          Best Regards,

          Pranay