In this blog post, I would like to clarify the question about which kind of custom fields we recommend to use.
In C4C, we support different kinds of extension fields which can be added to a standard business object screen.
- Extension fields created in Silverlight (Adaption Mode)
- Extension fields created in HTML5 via Page Layout
- Extension fields created using the SAP Cloud Applications Studio (SAP SDK)
The good news is, the first two are the same type of fields created on different user interfaces. So we only have to differentiate between two types of extension fields:
- Frontend generated extension fields via KUT or Page Layout
- Extension fields created via Cloud Applications Studio
Both types of extension fields can be used in parallel, however there is best practice depending on the usecase.
Usecase 1: Cloud for Customer without any planned custom development
In this case, you do not have any SDK development. Therefore all extension fields should be created on the frontend.
Usecase 2: Cloud for Customer with (planned) custom development
If you already know that custom development via the SAP SDK is planned, you should think about creating all extension fields from the SAP SDK instead of mixing technology.
There are different aspects in a project that play a role in this decision.
- Social aspect: If you have people creating fields on the frontend and developers enhancing the system, you never clearly know where to look first, when the system is not behaving correctly. If fields are behaving not as expected, you always need to find out what kind of field it is in order to find the responsible person to look at and correct the behavior. You can completely avoid this confusion by sticking to one technology.
- Technical aspect: Frontend generated fields are not (easily) accessible with the SAP SDK. If you need business logic on frontend generated extension fields, that has to be programmed with the SAP SDK, the developer is very limited in accessing these fields. In early days, it was not possible to access these fields with SDK logic at all. Later we made this possible, but certain limitations apply.
- The datatypes are limited, frontend fields cannot be defined as well as fields created with the SAP SDK.
- They are not getting transported with the SDK deployment and must be created manually in all tenants. (Update: With Release 1511 the SDK deployment logic creates the fields automatically).
- They can not be accessed from the SDK UI designer.
- The SDK access to frontend extension fields was developed as “rescue” option, not as feature to use regularly.
- Livecycle issues with frontend field access are a bit more likely.
- Future aspect: In various projects it happened, that there was a clear differentiation between fields that will never need any logic and can be created on the frontend and some fields that must contain logic which were created via SDK. In most cases it happened that in a later stage of the project access to one or more frontend fields from the SDK was required.
If you understood the details above, you can make a well informed decision about how you want to proceed in your project. The safest way is to stick to one technology, which is the reason why our best practice advice is to not mix up the extension field technologies and create all of them with the SAP SDK in case custom development is used or planned anyway.
I hope this blog post helps you to understand the motivation behind this best practice.