Skip to content

Customization Best Practices

Extending on the inside refers to customization of the solution using the IFS Cloud platform and IFS Developer Studio to make additions or changes. This involves editing models, low-code development in the Marble domain specific language, as well as coding in other languages such as SQL, PLSQL, Java.

Extending on the inside is a powerful capability and is the only way certain things, such as overriding or changing business logic in the standard application, can be done. It is also the most invasive and spans a broad range from smaller additions that are easy to carry forward to future releases, to invasive changes that will result in additional work to analyze impact, uplift code etc. when applying future releases. Hence use the power of extending on the inside wisely, following the key principles and be mindful of the advice.

Key principles for extending on the inside:

  • Customizations are initially done / created in DEV environment in the build place, committed to the customer solution repository, and propagated to other environments in the build place through build pipelines.
  • Propagation of customizations from the build place to the use place is always through the creation of a delivery, which is then installed in a use place environment.
  • Never make customizations dependent on configurations as this risk causing deployment and installation failures. For example, do not make a customization containing business logic dependent on a custom attribute added using configuration. Instead add that attribute as part of the customization.
  • Never customize anything in a platform component (see list here) as this could impair the appropriate function of IFS Cloud.
  • Never mark a projection added or modified as part of a customization as being a premium API. The use of Premium API class is reserved for IFS. Future release may automatically remove premium API classification.

Important advice regarding extending on the inside:

  • Place any added objects (entities, projections, pages, …) inside a new component dedicated for this purpose.
  • Follow naming guidelines regarding things (components, pages, entities, attributes etc.) added as part of extending on the inside.
  • Use @overtake as a last resort only since when you do this you effectively branch the standard code, creating your own copy of it inside your customization and taking responsibility for keeping this code updated with regards to any changes in the standard code in future releases or even service updates. If at all possible, use @override instead.

The IFS Customization Project can be used to create Customization projects by consulting organizations. In IFS Cloud we use the solution set file located in customer repository to load the enable components for the customer.

NOTE: For projects which support layered architecture the layer is set to 'Cust'

Aurena client naming and syntax

Usage of correct naming syntax for Projection and Client elements

Make sure correct naming syntax for Projection and Client elements

Projection element :

Entityset - CSet

Entity - C< EntityName>

Query - C< QueryName>Query

Attribute - C

Reference- CReference

Array- CArray

Enumeration - C Enum

Structure - CStructure

Virtual - CVirtual

Singleton - CSingleton

Summary - CSummary

Client element :

Navigator entry- CNavEntry

Selector - CSelector

Dialog- CDialog

Group - CGroup

Card - CCard

List - CList

Command - CCommand

Command Group - CCmdGroup

Advanced LOV List- CLovList

Chart- CChart

Singleton - CSingleton

Variable- CVar

File Naming:

​ Client: C.client

​ Projection: CHandling.projection

​ Fragment: C.fragment