IFS Marble Language: A Practical Field Guide

Marble is the declarative modelling language used by IFS Developer Studio for IFS Cloud Web and projection development. It is where you describe the shape of a projection, the client pages that consume it, and the customisation layer changes that should be merged with the underlying application model.

It is not JavaScript, XML, or PL/SQL. Marble describes models; the IFS toolchain parses those models and generates the runtime artefacts that IFS Cloud uses.

Where Marble Appears

The most common files are:

• .projection files: define projection models, entity sets, queries, virtuals, actions, functions, complex types, enumerations, and related API structure
• .client files: define IFS Cloud Web client pages, lists, groups, commands, dialogs, assistants, cards, navigator entries, and other UI model elements
• .fragment files: hold reusable sections shared by models

IFS Developer Studio is the authoritative editor and validator for these files. VS Code can be useful for searching and reviewing them, but Developer Studio should be used for creation, validation, generation, and deployment.

Projection Files

A projection is the API-facing model. IFS documentation describes a projection as a self-contained web API that implements a defined business function. It defines data types, data sources, functions, and actions, and it is also a main point for permission-set grants.

A projection file normally starts with header information such as:

It then defines entry points, for example entity sets:

Projection details can include entities, queries, virtuals, enumerations, complex types, functions, actions, and other model sections depending on the target IFS release. Always check the syntax reference for the version you are working against, because Marble evolves across releases.

Client Files

A client model defines the visible IFS Cloud Web experience. It is connected to a projection and can contain:

• Navigator entries
• Pages
• Lists and groups
• Commands
• Dialogs and assistants
• Cards, charts, maps, calendars, timelines, and other controls supported by the target release

The syntax is not HTML. You describe the client model and let the IFS framework render the UI.

Layers Matter

IFS customisation depends heavily on layers. When you customise an existing IFS Cloud model, you normally work in the Cust layer rather than editing core files directly.

That layer concept is what allows IFS to merge customer changes over the product model during generation and update uplift. The layer is also why you should keep customisation changes narrow: a small override is easier to survive than a copied page or command that silently diverges from the product.

Override vs Overtake

Two words show up constantly in IFS Cloud customisation work:

Override adds or amends selected properties while preserving the underlying model. Use it when you only need to add a field, adjust a property, or make a focused change that can merge cleanly with future product updates.

Overtake replaces the targeted model section. Use it when the thing you need to change is atomic or cannot be safely adjusted with an override. Commands are a common example where overtaking may be required.

The practical rule is simple: override when you can, overtake when you must. Overtakes are more powerful, but they increase update risk because the customer layer owns a larger copy of behaviour.

What Belongs in Marble

Good Marble changes describe the model cleanly:

• A projection entry point that exposes the right business resource
• A client page that presents the right fields and commands
• A command wired to a supported projection action
• A visible or enabled expression that reflects UI behaviour
• A small customisation layered over the product model

Bad Marble changes try to solve the wrong problem:

• Large business algorithms embedded in UI definitions
• Repeated copied model sections where a focused override would do
• Hard-coded customer assumptions that belong in configuration or server-side logic
• Workarounds for missing permission or data modelling decisions

Keep business rules in the right layer. Marble should describe the API and UI model; PL/SQL, Java projection implementation, configuration, workflow, or integration middleware may be the better home for actual business processing.

Security and Grants

Projection grants are central to IFS Cloud security. Granting a projection controls whether users can access the API and client pages that depend on it. Access can be read-only, full, custom, or none, with action-level details depending on the projection.

That means new client pages and commands are not just a UI concern. They must be reviewed with the permission-set model in mind.

Questions to ask before shipping:

• Which projection does this page use?
• Which permission sets need access?
• Are read-only users accidentally granted actions?
• Are sensitive fields exposed through a projection used by broader roles?
• Does the change rely on a projection action that needs explicit grant review?

Version Awareness

Marble syntax changes over time. IFS publishes syntax references from Developer Studio, and the developer portal records language changes. Do not assume an example from one release is valid in another without checking the target version.

This is especially important when a customer is preparing for a service update or release update. A model that parses cleanly in one version can still need review when underlying product models change.

Review Checklist

Before merging a Marble change:

• It opens and validates in the target Developer Studio version.
• The layer is correct for the change.
• Overrides and overtakes are as small as practical.
• The projection grants and permission sets have been reviewed.
• Any generated or deployed artefacts are understood by the team.
• The change has been tested in IFS Cloud Web after generation and deployment.
• Update Analyzer or Configuration Analyzer has been used where the change or release process requires it.

Key Takeaways

• Marble is IFS's declarative modelling language for projections and client models.
• Use Developer Studio as the authoritative tool for Marble validation and generation.
• .projection files define API models; .client files define the IFS Cloud Web client model.
• Work in the right layer, and keep overrides/overtakes narrow.
• Projection security is part of the design, not an afterthought.
• Always validate examples against the exact IFS Cloud release you are targeting.

References

• IFS Developer Portal
• IFS Developer Studio projection syntax reference
• IFS Developer Studio client syntax reference
• IFS Cloud projection permission documentation