08-Backend-dev-part2.pptx

Training

Backend Dev

Part 2

Forms overview

In Solings, a form method is the backend entry point that builds and manages the user interface form required by a service when it needs user input. Whenever a user opens a service that cannot run blindly Solings invokes the service’s declared formMethod to construct the initial form and to refine it as the user interacts. The form method signature always contains the following parameters and only the first parameter changes depending on service type :

• Runtime component (Workspace/Container)
• List of selected UIDs
• Aspect name
• Aspect class name
• SolForm

Forms : A deeper look

In Solings, a form is a structured runtime object responsible for presenting the fields, sections, and interactions that compose the user interface of a service. A form is built from form parameters and may also contain sub‑forms, which act as nested groups of fields and often appear in the UI as tabs or secondary sections. Every form parameter has a visibility setting that determines whether it is shown to the user, sent to the frontend, or kept entirely on the backend. It can be directly set via the corresponding constructor or changed via the setter. In addition, forms in Solings supports the reload mechanism is what allows forms to react dynamically to user interaction. Certain form parameters can be marked as reload triggers, meaning that whenever the user changes their value, the frontend performs a lightweight update cycle: it sends the modified field values to the backend, and Solings calls the service’s getForm() method again to regenerate any parts of the form that depend on what was changed. This mechanism is essential for building responsive, context‑aware interfaces.

Solings engine: A snippet

The Solings Engine acts as the “bridge” that determines which plugin provider must be invoked, based entirely on the data source(s) and archetype(s) selected by the user. It effectively resolves a routing problem: from generic service call ➜ to implementation in the correct connector plugin. To perform this routing, the engine needs four essential inputs: the feature name, the service name, the selected data source, and the associated archetype. These elements form a unique pair that identifies the correct implementation rule. Implementation rules are defined in Solings to describe which provider class is responsible for a feature/service pair for a given data source/archetype.

Providers: Technical approach

Providers are backend classes implemented inside plugins (Optegra, Windchill, Teamcenter, VPM…). They contain the actual business logic that is specific to a given PLM system. They act as the endpoints selected by the Solings engine based on the selected data source, and the corresponding archetype. In addition, the engine checks if the required connectors set by the provider is linked to the selected data source and is running. Moreover, not all providers are bound to a single service. If a provider is marked as reusable (reusable = true), it can be executed for multiple services as a cross-service logic.

Providers : Implementation hierarchy

In Solings, providers rarely extend the base abstract provider directly; instead, developers rely on pre‑defined inheritance patterns that encapsulate recurring behaviors and simplify implementation. For instance, in the Optegra connector plugin, the first level is the OptegraRestProvider, which offers convenient methods for calling Optegra REST services and executing SQL or PL/SQL queries through the Optegra connector. Above it, the RestProviderPattern, designed for services that operate on a single object: it standardizes typical steps such as preparing the REST call, formatting the outgoing container, and processing the returned result. For multi‑object operations, the Optegra connector plugin offers the MultiRowRestProviderPattern, an equivalent abstraction for batch actions. These patterns enforce consistent service behavior across plugins, and help developers focus on custom logic

Exceptions

Solings defines two main exception types: technical exceptions (SolingsException) and user exceptions (SolUserException). Technical exceptions represent internal, unexpected errors that users cannot fix. In contrast, user exceptions signal problems caused by incorrect user actions—missing fields, invalid operations, or disconnected agents—and are displayed through localized messages SolingsException extends RuntimeException to keep code clean, uncluttered, and correctly layered. By making it unchecked, Solings allows technical errors to bubble up naturally to the framework’s global handler, where they can be logged once with full context and converted to a safe, localized user message when appropriate. This approach discourages bad try/catch patterns and preserves the root cause and stack trace for diagnostics. When a technical exception (SolingsException or any unexpected runtime error) reaches the top of the Solings execution stack without being handled, the framework automatically converts it into a generic SolUserException to avoid exposing internal details to the user. This means that even if the underlying issue is a low‑level problem the user will only see a safe, localized message such as “A technical error occurred, please contact support.” Meanwhile, the full stack trace and technical context are kept in the logs for developers and support teams.

Localization overview

The Solings localization framework ensures that every user‑visible string (form labels, column names, service names, user messages, or enum values) is resolved dynamically according to both the user’s language and the current implementation context (Core, PLM, or a specific plugin such as Optegra or Windchill). This enables the same feature to adapt its vocabulary depending on the backend system it interacts with, while allowing each plugin to override labels or messages defined in parent layers. To keep translations organized and maintainable, Solings splits text into multiple resource bundle categories, each stored in its own .properties file: enumerations, form labels, service and service‑aspect labels, user‑facing messages and errors, and a miscellaneous “free text” category for anything that does not fit the others. Each plugin contains its own version of these bundles, following the implementation hierarchy, which allows a plugin such as Optegra to override only what it needs while still inheriting default values from PLM or Core. The engine is also tightly linked to the localization mechanism and execution stack. When the engine selects a provider, it also switches the localization context so that messages, labels, and exceptions inside the provider resolve using the resource bundles associated with that specific plugin

Localization : Context & Resolution

In Solings, a LocalizedString object does not immediately resolve into the final text when it is created. Instead, resolution happens only when the .build() method is called. This delay allows the system to apply the correct localization context at the precise moment the message is needed. Because the localization context can shift throughout execution (for example, when switching from a feature to a provider), building the string too early might use the wrong resource bundle. In the feature layer, if the form contains a data‑source selector, Solings computes the first common implementation across all selected data sources and uses that as the active localization context. When execution enters a provider, however, the context switches to the specific plugin or data source implementation (e.g., Optegra or Windchill), allowing that plugin’s resource bundles to override PLM or Core text. This is why the same KeySpec can produce different results depending on where .build() is invoked. Solings resolves form and column labels using a three‑level fallback strategy to give developers flexibility while avoiding unnecessary duplication :

Thank you