VS Code and Marble: A Practical IFS Development Setup

IFS Cloud development still centres on IFS Developer Studio. It is the supported environment for Marble model editing, validation, code generation, deployment to a connected development database, and tools such as Update Analyzer.

VS Code is useful, but it should be treated as a companion editor rather than the source of truth. Use it for Git workflows, fast text editing, code review, scripts, REST calls, and notes around the customer solution repository. Use Developer Studio when you need IFS-aware validation, generation, deployment, or model navigation.

The Correct Mental Model

Marble is not XML. It is IFS's declarative modelling language used in files such as:

• .projection files for service/API models and projection actions/functions
• .client files for IFS Cloud Web client pages, commands, lists, groups, dialogs, assistants, and other UI models
• .fragment files for reusable model sections

Those files are plain text, so VS Code can edit them. But generic XML extensions, XPath tools, and XML schema validation do not understand Marble syntax and will give the wrong impression of how the language works.

Recommended Tool Split

Use IFS Developer Studio for:

• Creating and customising .projection and .client models
• Using the official Marble parser, autocomplete, and validation
• Generating and deploying customisation code
• Debugging projection Java implementations where supported
• Running Update Analyzer and reviewing customisation impact

Use VS Code for:

• Git diff and review workflows
• Searching across the customer solution repository
• Editing supporting SQL, PL/SQL, shell, PowerShell, TypeScript, or documentation files
• Running local scripts and quality checks
• Testing OData endpoints with REST Client or Thunder Client
• Managing workspace notes, snippets, and repeatable commands

IFS has also previewed an IFS Cloud Development Kit for VS Code, but the developer portal describes it as an early preview rather than the recommended daily production tool. For production application development, Developer Studio remains the dependable option.

VS Code Extensions That Actually Help

GitLens

GitLens is valuable on IFS customisation projects because Marble changes are often small but high impact. It helps answer:

• Who changed this projection action?
• Which branch introduced this overtake?
• Why did a field or command change?
• Which commits need to be reviewed before an update uplift?

REST Client or Thunder Client

IFS projections expose OData APIs. A lightweight REST client in VS Code is useful for:

• Testing GET, POST, PATCH, and DELETE calls
• Calling projection actions and functions
• Capturing repeatable examples for support and handover
• Comparing responses between DEV, TEST, and PROD

Keep authentication values in local environment files or a secret manager. Do not commit bearer tokens, client secrets, session cookies, or customer URLs that should stay private.

Code Spell Checker

Marble models contain labels, descriptions, command names, and comments. Spell checking catches small quality issues before they reach users.

Add project-specific words such as Aurena, projection, entityset, overtake, and customer terminology to the workspace dictionary.

Prettier and ESLint

Use these for JavaScript, TypeScript, JSON, Markdown, and other supporting project files. Do not force generic formatters over Marble files unless your team has tested the result against Developer Studio. A formatter that does not understand Marble can damage structure or spacing in subtle ways.

Useful Workspace Settings

Treat Marble files as their own file association so they are easy to identify:

If your team has a mature custom TextMate grammar for Marble, use that instead of plaintext. The important point is that .projection and .client files should not be treated as XML.

Snippets That Are Safe

Snippets are useful for repeated scaffolding, but they should mirror real Marble examples from your target IFS Cloud release. Keep them small and boring.

Example snippet for a release-note comment block:

Avoid large snippets that generate full projections or clients unless you have validated them in Developer Studio and versioned them with the project.

REST Client Example

A simple .http file is often more useful than a complex Postman collection during development:

The exact service path depends on the environment and projection. Pull it from the projection metadata or browser network traffic in your own tenant rather than guessing.

A Good Daily Workflow

1. Pull the latest customer solution repository.
2. Use VS Code to review the branch, search the codebase, and update notes.
3. Open the project in Developer Studio for Marble edits, validation, generation, and deployment.
4. Use VS Code's diff view to inspect generated and hand-edited changes before commit.
5. Test projection endpoints with REST Client or Postman.
6. Run Update Analyzer or Configuration Analyzer where the change or update demands it.
7. Commit only intentional source files, not local credentials, generated clutter, or tool caches.

Key Takeaways

• VS Code is a strong companion for IFS work, but it does not replace Developer Studio.
• Marble is a declarative IFS modelling language, not XML.
• .projection, .client, and .fragment files should be validated with IFS-aware tooling.
• REST clients, Git tools, spell checking, and project search are where VS Code adds the most value.
• Treat any VS Code-only Marble workflow as experimental unless it has been validated against your IFS target version.

References

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