There are two main groups that perform development using the IFS Cloud platform.
- IFS RnD software engineers that develop the Core application of IFS Cloud itself.
- Software engineers anywhere in the larger IFS eco system (e.g. working in IFS consulting, for an implementation partner, or directly with a customer using IFS Cloud) that develop Customizations (extend on the inside tailoring) for a customer solution.
Regardless of which group you belong to it is important that you are familiar with the fundamental concepts and principles described on this overview before you go ahead and undertake any development.
The development stack for IFS Cloud consists of a set of programming languages, libraries, tools, runtimes etc. used to develop the Core application of IFS Cloud as well as the Customization layer of IFS Cloud customer solutions.
The development stack together with the IFS Cloud platform itself provide for rapid development of business functionality whist at the same time providing a consistent and high quality experience for the eventual users of the customer solution.
Key elements of the development stack consist of:
- IFS Developer Studio as the main Integrated Development Environment (IDE) for development of the presentation, api, business logic, and storage tiers.
- Marble Domain Specific Language (DSL) used to model and describe the complete presentation tier as well as the bulk of the API and storage tiers. Marble is used to model and entities, APIs, pages in the user interface, information sources and much more.
- PLSQL as the main programming language for the business logic tier.
- Java as an alternative programming language for the business logic tier.
Alternative Development Stack¶
Many services and capabilities inside the IFS Cloud platform itself, and some highly specialized capabilities in the core application, are developed using some alternative development stack (e.g. other programming language, other tool).
Services and capabilities built using an alternative development stack still "slot in" to IFS Cloud as good citiizens using prescribed architectural principles in terms of how they are deployed/monitored/managed, adhere to the IFS Design System for any UI included etc. Or they leverage specifically provided extension mechanisms such as the plug-in concept of IFS Cloud Web.
Use of alternative development stacks is is not allowed for Customizations.
IFS Cloud development is an interative process where developers model, code, deploy, test, and repeat to iteratively refine the solution. The innermost development cycle has been designed to be as fast as possible in order to facilitate this iterative way of working. Source code is manged in Git based repositories providing the means to develop and test new features in isolation before pulling to the master branch and including them in the next update or delivery.
Model Driven Development¶
Development of IFS Cloud is highly model driven where developers express as much as possible of the application design and behavior in the form of models. These models can be visual (like an entity model diagram, a state diagram) as well as textual using the low-code Marble domain specific language. The model driven approach combined with the fact that the complete development stack is handed in one and the same tool means that a common skill set can be used for development across all tiers (presentation, api, business logic, storage).
While some models are simply deployed to an environment and interpreted by the IFS Cloud Platform at runtime, many of the models go through a transformation step of "code generation" to create deployable and executable artifacts. For example when an entiy model goes through the code generation step multiple deployable artifacts are created including database table, indexes, and a PLSQL package . For other models the code generation step only involves some light weight tansformation to a model or meta-data format more suitable for runtime use. The code generation has been designed to leave the manually written code (e.g. PLSQL code, Java code) virtually unchanged which makes it easier for developers to regognize the code they wrote when debugging. Biolerplate code is typically generated into seprate files and also based on templates for high consistency and making it easy to make generic changes.
Customizations developed for a customer solution are kept in the separate customization layer, and thus will also be kept in separate files (applies to models files as well as code files). This makes for a clear separation of the core application and customization layers and makes it easier to apply updates to the core application layer without needing to revisit customizations.
When developing a customization (extending on the inside) as part of tailoring the customer solution, it is generally possible to use the customization layer to add new as well as override existing code artifacts such as entity, projection, and page definitions.
There are however a few items that are not possible to override.
- Operational report definitions (RDF files) - new ones can be added, but it is not possible to override report definitions in the Core application layer.
- Translations (LNG and TRS files)
The merging of the core application and customization layers into the complete customer solution happen either in runtime, by the platform services themselves, or during the code generation step. Hence, in order to apply changes to a customization a solution build must be performed and susequent delivery applied. This in difference to configurations which do not require a solution build, as they apply immediately when published or imported into an environment.