What's New in tSM 2.4
Version 2.4 is the largest tSM release to date. It introduces professional configuration tooling, a standardized Public API, new ways to extend the platform with scripts, and a reactive forms engine — all backed by a major dependency upgrade for security and performance.
For the full change list, breaking changes, and upgrade instructions, see Version 2.4 Release Notes.
Configuration Explorer & Packages
Managing configuration across environments has always been one of the hardest parts of running tSM at scale. Version 2.4 introduces a complete configuration lifecycle — from development through review to production.
Configuration Explorer is the new primary UI for understanding how your configuration is organized. It presents every configuration item grouped by ConfigType, enriched with package metadata and installation status.
Configuration Packages let you bundle related configuration into versioned, installable units with dependency tracking. Change Sets add story-level review on top — group changes across multiple packages for a single user story, review them, and close when done.
Installed Package records tell you exactly what is deployed to each environment, when it was installed, and whether anything has drifted since.
📖 Configuration Explorer · Change Sets · Installed Package
tSM Studio & CLI
tSM Studio is a VS Code extension that turns configuration management into a proper development workflow. Download configurations to your local filesystem, edit them with full IDE support, commit to Git, compare environments side-by-side, and push changes back to tSM.
The tSM CLI (tsm) complements the UI with a command-line tool for scripted and automated configuration workflows — package creation, deployment, and environment management from the terminal or CI/CD pipelines.
Together, they enable branching, merging, pull requests, and environment comparison for tSM configuration — the same practices software teams already use for code.
📖 tSM Studio · CLI Reference · Configuration Lifecycle
Public API V2
Public API V2 is now unified across all core domains — billing, catalog, config, customer, inventory, ordering, ticketing, and WFM. It standardizes request/response behavior, adds safer query options, and brings audit/history capabilities via JaVers to every entity.
A formal API Versioning & Lifecycle policy documents backward compatibility guarantees: within a major version, only additive changes are allowed. API V1 is now deprecated.
Task Templates
Configuring BPMN tasks used to mean manually setting topics, delegate expressions, mappings, and dozens of properties. Task Templates replace this with a form-driven approach — select a template, fill in the parameters, and the correct BPMN configuration is generated for you.
Templates support versioning: when you apply a template, both its identity and the concrete version are persisted. This prevents silent behavior drift when a template is updated later and enables future diff/reapply scenarios.
Templates are available for Service Tasks, External Tasks, Kafka Tasks, and User Tasks. They appear as favorites in the Process Designer palette.
📖 Task Templates · Kafka Task · External Task
Script Bindings — REST & MCP
SpEL scripts are no longer limited to running inside processes and events. Two entirely new binding types let you expose scripts to the outside world:
REST Bindings publish a SpEL script as an HTTP endpoint (POST /api/v2/scripts/<path>). The platform handles routing, authentication, body validation against a JSON Schema, execution, and JSON response serialization. No custom controller code, no deployment — just configuration.
MCP Bindings expose scripts as AI-callable tools via the Model Context Protocol. AI agents like GitHub Copilot, Claude, or ChatGPT can discover and invoke your tSM logic. Tools are organized into servers, each with its own endpoint.
Both build on the restructured Scripts and Bindings subsection, which also extends the existing Event Bindings and Script-to-Script Bindings.
📖 REST Bindings · MCP Bindings · Scripts and Bindings
SpEL Language — Lambdas & String Interpolation
The SpEL language itself gained two important capabilities that make scripts shorter and more readable.
Lambda expressions let you define reusable anonymous functions — assign them to variables, pass them as arguments, return them from other lambdas, or use them with collection operations like .forEach() and .filter(). Multi-expression bodies are supported via #do(...), and lambdas capture surrounding variables as live bindings so they naturally work with the rest of your script.
#double = (#x) -> #x * 2
#double(10) // 20
String interpolation makes dynamic text construction cleaner. Double-quoted strings now support #{...} syntax — any SpEL expression inside the braces is evaluated and embedded directly into the string, replacing verbose + concatenation chains.
#name = 'John'
"Hello #{#name}, you have #{#count} items"
📖 Lambda Expressions · String Interpolation
SpEL Console — Debugger
The SpEL Console now includes a full step-through debugger, bringing a professional debugging experience directly into the browser. You can pause execution at any expression, inspect all context variables and their current values, add watch expressions that evaluate live at each step, and dynamically evaluate arbitrary SpEL expressions against the current execution state.
The debugger supports Step Over and Continue controls, a Variables panel showing every variable in scope, and a Watch panel for tracking computed values as you step through the script — similar to the debugging experience in Chrome DevTools or VS Code.
Form Effects
The new Form Effects engine brings reactive behavior to tSM forms. Define side-effects that automatically respond to value changes — clear a dependent field when its driver changes, copy a value between fields, or call a server-side script whenever a specific input is modified.
Effects are configured declaratively alongside the form definition. No scripting is required for common patterns like dependent LOVs or field synchronization.
Observability & Tracing
Diagnosing problems across a distributed microservice platform used to mean correlating logs manually. Version 2.4 introduces four standard HTTP headers propagated across all services and message queues:
| Header | Purpose |
|---|---|
X-Trace-Id | End-to-end request tracking across all services |
X-Correlation-Id | User session correlation |
X-Request-Id | Individual HTTP request identification |
X-Debug-Level | Temporarily override log level for a single request |
A new frontend logger service forwards UI errors and events to Kibana, closing the gap between frontend behavior and backend logs.
AI Chat
A built-in AI assistant is now accessible directly from the top bar. It supports real-time streaming responses, conversation threads, image attachments, and context-aware integration with the SpEL Console.
Users can provide structured feedback via thumbs up/down, helping improve response quality over time.
AI in tSM is evolving in two phases. Version 2.4 focuses on developer support — AI-assisted scripting in the SpEL Console, context-aware code suggestions, and debugging help. Next steps will extend AI assistance to the Process Designer and Form Designer, helping with workflow suggestions, form generation, and validation. After that, AI will expand into the business domain — customer care, ticketing, ordering, and other modules — providing operational insights, guided resolution, and intelligent automation directly where business users work. See the AI Assisted Development roadmap for the full vision.
📖 AI Chat · AI Roadmap
tSM AI Docs
The tSM documentation is now AI-powered. The documentation portal at tsm.datalite.cz includes a built-in chatbot that lets you ask natural-language questions about the platform and get answers grounded in the official documentation.
For deeper integration, tSM AI Docs is also available as an MCP server. Connect it to your preferred AI tool — GitHub Copilot, Claude, ChatGPT, or any MCP-compatible agent — and let it talk to the tSM documentation on your behalf. This means you can query tSM docs directly from your IDE, AI chat, or automation pipeline without leaving your workflow.
Calendar & Working-Day Functions
New SpEL methods make working-day calculations straightforward. Add N working days skipping weekends and public holidays, check if a date is a working day, or compute deadlines that respect country-specific holiday calendars — all loaded from the System.Holidays register.
Key methods: .plusWorkdaysWithHolidays(n, country), .plusWorkdays(n), .isWorkingDayWithHolidays(country).
Online Collaboration
tSM now supports real-time multi-user collaboration across its configuration editors. Multiple users can work on the same artifact simultaneously — seeing each other's changes live, with automatic conflict resolution.
The flagship implementation is the SpEL Console: the script editor now supports concurrent editing by multiple users, live cursors showing what others are doing, and built-in conflict resolution — similar to the experience in Google Docs or VS Code Live Share.
Beyond scripts, the attendance indicator is available across the platform — in the Process Designer, Form Designer, and other configuration screens. The indicator is added via a configurable form component, so it can be enabled on any entity form. It shows who is currently viewing or editing the same artifact and who last made a change.
📖 SpEL Console — Online Collaboration
Process Engine Improvements
- Camunda History in Elasticsearch — process history moved from relational storage to Elasticsearch for better scalability in high-volume environments.
- Kafka Task — new first-class BPMN task type for asynchronous Kafka communication, replacing the previous receive-task workaround.
- Bulk User Task Operations — mass handover to user groups, bulk continuation, and large-scale import support.
- Optional Process Variable History — suppress selected variable storage for privacy or performance.
- Service Task Script Binding — execute stored SpEL scripts from BPMN using
tsmScriptDelegateExecutorwithout inline code.
Business Module Highlights
- Lead as Standard Entity — Lead now participates in standard configuration, API, and management flows (CRM).
- Parent/Child Order Hierarchy — clearer nested order structure for complex ordering scenarios.
- Email Communication Widget — reusable widget for embedded email interactions in any business flow.
- Stock Module Expansion — better API coverage, consistent naming, and paging for stock movements and items.
- Catalog Backup and Import — back up catalog records by filter and import them across environments.
Business Module Documentation
Version 2.4 ships with 38 new documents covering all tSM business modules for the first time:
CRM · Ordering · Catalog · Inventory · Ticketing · Billing · WFM · Stock · Service Orchestration
Each module includes an overview, entity reference, process handling, and blueprint documentation.
Security & Dependency Upgrades
API Keys
tSM now supports API Keys as a first-class authentication method for machine-to-machine integrations. Instead of managing short-lived tokens and refresh flows, external systems can authenticate with a long-lived, revocable API key.
API keys are created per user in the User Management → Users → API Keys tab. Each key is bound to that user's roles and privileges, supports an optional expiration date, and can be revoked instantly without affecting the user account. Multiple keys can be issued per user for different integrations.
Security: API keys are stored as SHA-256 hashes — the plain-text key is shown only once at creation.
On Behalf Of (Token Exchange)
Integration users can now act on behalf of end-users via the token_exchange OAuth 2.0 grant type. This is essential for scenarios where an external system (portal, orchestration layer, or partner platform) authenticates as a service account but needs to perform tSM operations under the identity of the actual end-user.
How it works:
- The integration user authenticates with
client_credentials(or API key) - Exchanges its token for one representing the target user via
POST /api/tokenwithgrant_type: token_exchange - The resulting JWT contains the target user's roles and privileges, plus an
actclaim identifying the original caller
{
"sub": "end-user-id",
"authorities": ["Support_Agent"],
"act": { "sub": "integration-user-id" }
}
All actions are logged with both identities — the target user and the acting integration user — providing a complete audit trail. The same mechanism also supports admin impersonation for troubleshooting.
Dependency Upgrades
All core dependencies have been upgraded to their latest versions. Key highlights:
- Spring Boot 4.0 with Jakarta EE 11 and virtual threads
- Angular 21 with signals-based reactivity
- Java 21 LTS as required runtime
- PostgreSQL 16+, Elasticsearch 8+, Kafka 3+ — latest versions recommended for security
For the full dependency table and deployment recommendations, see Version 2.4 Release Notes — Dependency Upgrades.