Custom Fields is a Custom Objects concept that lets you extend existing IFS Application pages with custom information. The extension is taking place in the server layer where Custom Attributes extend the Logical Unit. Custom Fields is then enabled from the client pages that is designed for the given LU. This way the fields can be persisted or read only, e.g., calculated values. The Custom Fields are enabled and positioned on a page using Customizable Screen Layout (CSL). Once enabled and positioned on a page, a Custom Field will have the same look as any other field. In the picture below the Customer Address and Market Code are both Custom Fields added to the standard Custom Order page. In addition to Custom Fields where the fields are merged into the standard layout, there is also Information Cards where the added information is located on a separate floating page.
Custom Fields are the client representations of a server Custom Attributes . The administrator configures Custom Attributes that extends a Logical Unit. When the extension is published Custom Fields bound to the attributes can be enabled and positioned onto Application pages. There are tree main types of attributes supported.
It is not possible to add business logic directly to a Custom Field, e.g., validations. It is possible to achieve some logic and flow by referencing Custom Fields from Custom Defined Events or Custom Menus. Referencing Custom Fields from static source code is however not supported. See more about this in the restrictions section.
Custom Fields can also be used in the following features/concepts:
The architecture of Custom Fields works as follows. A shadow LU is created for every LU that has a Custom Attribute. This shadow LU consists of one or more database objects, a table, a package, one or more views.
When deploying a Custom Field configuration several new database objects are created. Note: Not all objects listed will always be created, it is dependant upon the type of the attributes.
24DE63531ACB492685897482934EB7F2 that is unique. The master table and the
custom table has a constraint that removes the custom record if the master
record is deleted.
In runtime, the framework will automatically choose the database object to access depending on if a page have enabled Custom Fields or not. When fetching data either standard or the custom _CFV view will be used. When data is updated the framework will keep track of if a persistent Custom Field is updated. If needed the custom _CFP package is called for after the standard save method is called.
The configurations are persisted in the server. This Meta data is when administrating and creating database objects. The Meta data is also fetched to the client in runtime where it is used by the framework to handle Custom Fields. The Meta data fetched in runtime is cached in process memory. If the Administrator is making changes to the configuration while users is working, the cache needs to be manually refreshed to get the updated configuration.
Since Custom Fields is implemented as a "shadow" LU, with similar database objects as the master LU, the Custom Field LU can be administrated the same way as a normal LU. This means that security is applied in the same way on a Custom Fields LU as any normal LU, meaning that if you are not granted a view you can't use that view in a query from a client. In the same way any method in a Custom Fields package, if you not are granted a method you can't use it to save the data. In order to avoid such security runtime errors we check if the User is granted to any Custom Fields database objects before delivering the Meta data to the client.
Upon deployment of a Custom Field LU we create a Presentation Object (PO) called cfX (where X is the LU name, for LU SalesPart we create a Custom Field PO called cfSalesPart). This PO can be used to grant this functionality to the roles that should have this database objects grants.
The Custom Fields PO is always automatically granted to all roles that is granted to the views you have added for this Custom Fields LU at that moment. When we deploy the Custom Field LU we also grants all necessary grants to the privileged users IFSSYS and IFSWEBCONFIG.
The client side of Custom Fields, i.e., where a field is enabled and located on a form, is stored in the profile. This means that a centralized client configuration can be done for a group of users by taking advantage of the Base Profile functionality. Read more About Profiles and Profile Repository.
The Base View of the Logical Unit where Custom Field is deployed must not be defined as a Union.
A read-only Custom Field must be able to create against the Logical Unit's base view. This means that your expression or your select statement must be possible to validate against the base view.
The excluded logical units are LU's that have been chosen not to be available for custom object extensions. All Logical Units in the framework components FNDBAS and FNDCOB are excluded, and can not be extended with Custom Attributes.
When managing many of IFS Applications business objects (like Customer Order, Product structures and so on) you commonly want to copy one business object when you create another new business object. This can be done in two ways:
Custom_Objects_SYS.Copy_Cf_Instance.The Custom Fields copy API is dependent on that the names of the Custom Fields is exactly the same if copying between different LU’s (e.g. between Active Work Orders and Historical Work Orders). So only if it exist two attributes with the same name in both of the LU’s a copy of the Custom Fields will be done. If an error occurs when copying Custom Fields the whole transaction is rolled back.
Custom Defined Events can be used as a means to add some minor business logic to custom fields, e.g., validations. For this to work it is important to place the event on the generated Custom Fields table. If the event is attached to the standard logical unit table the value of the custom field attribute will not be updated. This is because the insert on the standard table is done before the Custom Fields table, hence when a trigger is executed for the standard table the value of the Custom Field attribute is null. Same thing happens on an update, when the standard table fires the update trigger, the value of the Custom Field attribute is not yet updated and contains the previous value.
New development or customizations of application source code should never make use of a Custom Attribute or Custom Field. There are technical limitations as well as maintenance issues with such an approach. Writing business logic including a custom field is not supported by IFS or IFS Development and Deployment tools. In other words, writing static code that references configured objects is not supported.
Use this parameter to enable or disable custom field functionality system wide. If this parameter is set to OFF no custom field will be available in any page. Also note, that related concepts that build upon custom fields, e.g., information cards, will also be disabled.
Tablespace where tables generated for Custom Objects should be created.
Tablespace where indexes generated for Custom Objects should be created.
Tablespace where Custom Objects, Large Objects should be stored.
Default values for the Custom Objects tablespace parameters are the same as the
application installation. The administrator should change these values if there
is a need to separate custom and application storage.
Configure Custom Fields
Administrate Custom
Fields
Custom Field Examples