07-Backend-dev-part1.pptx

Training

Backend Dev

Part 1

Containers overview

A Container is a powerful in-memory table tailored for Solings’ data model and designed to manage large sets of PLM objects seamlessly. It acts like a custom collection containing multiple Container rows along with a fully defined header, primary and secondary indexes, and behavioral mechanisms such as conflict policies, recorder transactions, selection management, and delta tracking. Containers mirror many capabilities found in database tables while remaining completely in memory, optimized for speed, and tightly integrated into the Solings service–frontend workflow. Each container defines its header, configured through the Configurator, listing every column it will store. A column includes an internal name, a data type (enum SolType), and flags indicating whether it belongs to the primary key, should be localized, or remains internal (backend-only). A ContainerRow is the model representing a single PLM object or metadata entry. It functions like a lightweight Map, holding value pairs for each column defined in its container (e.g., name, revision, state). They are intentionally simple and contain no business logic: their job is strictly to store metadata efficiently. In addition, each row maintains a link back to its parent container.

Containers : A deeper look

• Primary indexes : Defines how each row's UID is computed. By default, Solings uses an auto-incrementing integer (0, 1, 2…), but PLM-oriented containers override this with business key-based identification. For example, Optegra objects may use (name, revision) while Windchill may rely on (number, version).

• Secondary indexes : Defined on one or more columns to enable fast and direct lookup of rows. Instead of iterating through all rows to find an object with a specific combination of fields, Solings can query the relevant index instantly. Developers configure secondary indexes via the header which provides SQL‑like performance inside Solings’ in‑memory model.

• Conflict policies : When adding a row with a UID already present in the container, Solings uses conflict policies to determine how to handle the situation with a default value set to override, covering most cases in all container types.

• Delta : A change log that records all modifications made to a container, including added rows, removed rows, and updated fields. Instead of sending the entire container back to the frontend after an operation, Solings sends only the delta, dramatically improving performance and user experience.

• Recorder: Provide a transaction-like mechanism for managing a sequence of modifications on a container. When a recorder is activated, all changes are captured. If the operation completes successfully, the Recorder is stopped (commit). If a business rule fails or an exception occurs, the recorder can be undone, rolling back all recorded changes (rollback).

• Selected UIDs : Stored in a ThreadLocal variable ensuring that each web request thread has its own isolated selection state, preventing interference between parallel actions. Solings extends Java’s ThreadLocal with its own “SolRequestObjectLocal” to guarantee automatic cleanup after each request.

Container configurator

The container configurator is the pre‑execution setup phase used to define a container’s structure before any data is inserted. By calling container.configure(), developers access a dedicated API to declare columns, types, primary key rules, indexes and special behaviors like unique row handler containers. A unique row handler container is a specialized container type that is designed to hold exactly one row and used when the PLM metadata represented is single-valued for a business object. This behavior can be declared via the configurator method setAsUniqueRowHandler(). The configuration process is also thread‑safe and synchronized to prevent multiple threads from modifying the schema at the same time. It guarantees that containers are built with a consistent, validated schema before being used.

Container types

A Container is Solings’ in‑memory table for representing data from PLM and related systems. A container type is a specialized subclass of this base container that pre‑configures columns, indexes, and behaviors for a particular use case (search results, data structure, file exchange, batch processing, lifecycle, ownership, etc.). Solings introduces separate container types to match data shape to different behaviors following the business and technical needs.

DataContainer

The DataContainer is the central and most frequently used container type in Solings, designed to store PLM business objects. It acts as an in‑memory table tailored for PLM data and comes with a predefined structure that includes core technical columns like provider and external reference used internally to track the origin and routing of each object. Moreover, the DataContainer embeds the business identity : archetype, dataSource, and sourceType, which, together with the PLM system’s own key fields (such as name + revision in Optegra or number+ version in Windchill), form the primary UID of each row. This ensures that objects never conflict and that identity is consistent across refreshes, merges, and multi-selection actions. In addition to, the DataContainer can include subcontainers such as the MaturityContainer (lifecycle information) and OwnershipContainer (checkout/reservation status), each stored as a dedicated column and containing a unique row. They allow Solings to handle lifecycle transitions, availability of actions, and ownership validation directly from search results without extra backend calls.

Core configuration objects

Together, the Data source, archetype, and Sourcetype form the core identity of every PLM object in Solings. They directly influences how unique identifiers (UIDs) are built in data containers, ensuring that objects from different systems never collide and that values like name, number, or revision are interpreted correctly based on the originating system. In practice, they provide the essential context Solings needs to process PLM data consistently across multiple environments.

DataSource

A Data source represents any external system that Solings communicates with to read or manipulate data. It can be a PLM system (Optegra, Windchill), an ERP, or even the user’s local desktop through Solings Agent. Each Data Source defines how Solings interacts with that system by specifying its connectors, communication protocols, supported archetypes/sourcetypes, and system‑specific logic. All data sources are declared in load files and stored as Hibernate entities. In practice, the Data Source acts as a bridge between Solings and the external environment. It stores essential configuration elements such as:

• Connectors, which define how to execute searches, transactions, file operations, or SQL queries.
• Source Model, a backend component containing system‑specific behaviors (e.g., how identities are constructed).
• Supported Archetypes and Sourcetypes, which indicate which types of business objects can be manipulated from this system.

Archetypes & Sourcetypes

An Archetype represents a high‑level business object family in Solings, such as Part, Document, or Change. It defines the broad category an object belongs to, independently of any specific PLM system. Archetypes are created once during installation and serve as universal reference types across all Data Sources. While they contain only simple configuration elements (name, display label, icon…) they are essential for classifying PLM entities and determining which object families each Data Source supports. This makes Archetypes the foundational layer for organizing and interpreting business data consistently across multiple external systems. A Source Type is a precise subtype of an object within a given Data Source. It describes the exact kind of object used inside each external system such as Design Solution, Equipment, or Standard Part. Because every PLM system has its own internal taxonomy, Source Types are defined per Data Source, even when different systems share similar names. Both archetypes and sourcetypes are declared in JSON files loaded during installation and persisted as Hibernate entities in the Solings database. Their relationships are also stored through the junction entity Archetype-DataSource, and each Source Type is explicitly tied to both a specific Data Source and its corresponding Archetype. These connections ensure that Solings can correctly understand the nature of each PLM object, apply the right behaviors and identity rules for the system it comes from, and consistently manage data coming from different PLM environments.

Feature / Service

Features & rest controllers

A Feature in Solings is a Java class that extends AbstractFeature and is annotated with @SolingsFeature. Features provide a structured way to organize services by functionality—such as data source management, queue administration, authentication, or container operations. Each feature defines metadata like its name (the feature key), technical profile (permissions required), visibility settings, and whether REST endpoints should be automatically generated. At server startup, Solings scans the class path, detects all features, and stores them as Hibernate entities for reference in permission checks and internal routing.

For each Feature, Solings can automatically generate the corresponding REST controller containing one endpoint per service. This generation happens during server startup inside the Solings master workspace under /restControllerSource/. The generated code includes routing, request parsing, and execution logic that delegates to the underlying Service via the SolServiceExecution mechanism. Developers do not need to manually create controllers: Solings creates them as long as generateRestEntryPoint = true in the annotation. The generated Java files must be copied into the plugin project so they can be built and delivered with the server.

Services

In Solings, some services, especially those executed on multiple selected UIDs (like bulk sign out or lifecycle changes), are marked as asynchronous. In this mode, the server immediately returns control to the UI while the actual operation continues in the background. Solings then uses a Process Container to track progress. The front-end polls at intervals (e.g., every 2 seconds) to retrieve delta updates, allowing users to see real‑time progress and results. Asynchronous services are essential for operations on large datasets and ensure smooth UI responsiveness.

Thank you