Skip to content

Configuration Best Practices

Configuration is one of the ways in which a customer solution can be tailored. Configuration can be used on its own, or in combination with extending on the outside or extending on the inside (customizing).

Before deciding to implement a certain tailoring requirement using configuration, make sure you are familiar with the guidance for choosing the right type and level of tailoring as well as the key principles when combining tailoring types.

IFS Cloud Projection Configurations

Best Practices for Projection Configuration

For Entity Associations:

  • Try to use an Association Name that clearly indicates the parent/child relationship of the association.

Application Configuration Packages

It is important to understand that the ACP is just a set of pointers to custom objects. It is not a snapshot of what the custom objects were at some point in time. However, when we export the ACP to file, we are exporting the custom objects as they are at that moment.

It a good idea to put all custom objects into an ACP. This provides overall organization, and helps to ensure no custom objects get “left behind”.

One suggestion is to create an ACP per block of functionality – perhaps encapsulating some custom fields, and custom events that are linked together to solve a particular gap. This can lead to a large number of ACPs over the course of a project. Once the custom objects are stable it might make sense to consolidate into a few, larger ACPs – but in practice this will require coordination between the people who developed them.

Prefix the ACP Name with “IFS”, or the Partner Name (if it was created by one of those parties), or the name of the consultant/user who created the objects for easy tracing.

It is recommended to check the ACP into the Customer Solution Repository so that Impact analysis of updates can be performed.

Custom Events

With the deprecation of Execute Online SQL event actions in IFS Cloud, the recommendation is to use BPA Workflows to solve more advanced requirements whenever possible.

For those customers that have used Execute Online SQL event actions in their existing solution, IFS recommends the phasing out (replacement) of these elements, during or after the process of upgrading to the latest version of IFS Cloud. This will require analysis to determine which can be replaced using another approach such as a Workflow, Extend on the Outside or Extend on the Inside; and which can be removed, perhaps because new features in IFS Cloud render them redundant.

Please also read about Custom Utility Packages and Views, which is closely linked to the Execute Online SQL action type; there are more details in that section on the alternatives recommended by IFS.

Custom Utility Packages and Views Guidance

Customization and Configuration Guidance

There is a clear separation between the Customization layer and the Configuration layer. This is important for several reasons, but chiefly because deployment issues are likely to occur if Customizations are built on top of Configurations, that is to say, if a custom object in the Configuration layer is a prerequisite for code in the Customization layer.

The simplest and most likely example of this would be a Customization that reads (or sets) the value of a Custom Attribute. Equally, a Customization in IFS must not use a Custom Enumeration, Custom Entity or Custom Event.

(Note that it is common and perfectly acceptable to build Configurations on top of Customizations).

While there is not yet a barrier in IFS Cloud that prevents Customizations being built on top of Configurations, this is likely to be added in a future update.

What are Custom Utility Packages and Views?

IFS Developer Studio allows the creation of Utility models. These can be thought of as code that does not tie to a particular database table. They are generally used to provide supporting functionality and methods in a particular area. Utility models can be used to create database packages and views.

Issues caused by the use of Custom Utility Packages with Configuration Objects

Some IFS customers have used Utility Packages and Views to create customizations with the goal of manipulating the values of Custom Attributes. A typical usage was to define a Custom Event (or Custom Command, previously a Custom Menu in IFS Enterprise Explorer) with some embedded PL/SQL code that called a method in the Custom Utility Package; and that method performed a series of actions, reading, inserting and modifying data, including Custom Attributes.

The Custom Utility Package would often be developed “informally” i.e. by a consultant or super-user and without detailed specification and hence was sometimes incorrectly thought of as Configuration. This kind of development is a Customization because it changes the codeline.

Likewise, some IFS customers have used Developer Studio utility models to implement custom views that include (are dependent upon) custom attributes or custom entities.

The problem with these usages is that they break the layering rule, because they create Customizations that are dependent on Configurations.

This approach will likely lead to difficulties in the deployment of updates, problems with Support, and generally make it harder for the Customer to have an Evergreen experience with IFS.

To be clear: there is nothing wrong with developing Utility packages (or views) in Developer Studio following the proper development processes. The problem is when the Utility package is made dependent on Configuration objects (including Custom Attributes, Custom Enumerations and Custom Events).

What are the intentions of IFS in this area?

IFS intends to deprecate the ability to use PL/SQL code blocks via Configurations, in order to make the product more supportable. This means that the Execute Online SQL custom event action type will be deprecated.

In the future IFS may also make it impossible to deploy a Customization that is dependent upon Configurations.

Advice for Upgrading and New IFS Customers

For upgrading customers that have used Custom Utility Packages in this way in their existing solution, IFS now recommends the phasing out (replacement) of these elements, during or after the process of upgrading to the latest version of IFS Cloud. This will require analysis to determine which can be replaced using another approach such as a Workflow, Extend on the Outside or Extend on the Inside; and which can be removed, perhaps because new features in IFS Cloud render them redundant. Some of the options are summarized below.

Execute Online SQL event actions are deprecated in IFS Cloud. For customers performing new implementations, IFS strongly recommends not using Execute Online SQL event actions or Custom Utility Packages that are dependent on configurations. The alternatives below are recommended instead.

Workflows

With the deprecation of Execute Online SQL event actions in IFS Cloud, one of the main alternatives is the Workflow functionality. Workflows exist in the Configuration layer, so we can use them to read and manipulate both standard attributes and Custom Attributes, without contravening the layering rule.

In fact, Workflow capabilities surpass what could be achieved with Execute Online SQL event actions in several ways.

Workflows are the recommended approach for requirements such as

  • Data Enrichment i.e. updating fields/creating data records based on a database event or projection action
  • Data Validation, and notifications to the user via warning and error messages
  • User Interaction, gathering additional inputs from the user via dialog windows

Query Designer

IFS Cloud Query Designer is the tool to use for development of new data sources for functionalities such as

  • Page Configurations
  • Lobbies
  • Integrations

Query Designer is a tool in the Configuration layer and therefore it can be used to query standard and Custom Attributes without breaking the layering rule.