# Documentation on Strolch

https://strolch.li/documentation/ Recent content in Documentation on Strolch Hugo -- gohugo.io en-us

# Architecture

https://strolch.li/documentation/architecture/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/architecture/Architecture Birds View A Strolch agent&rsquo;s architecture can be seen as a simple three-tier architecture. The presentation layer is mostly a web frontend, where the communication with the agent is done via REST API calls. The agent itself implements the business logic using Services, Commands, Queries etc. The agent can communicate with other 3rd systems using any API, where it is preferred to use JSON over REST. The agent can use a standard RDBMS as a storage system, where currently DAOs have been implemented only for PostgreSQL.

# Model

https://strolch.li/documentation/model/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/model/Model Before we dive into the entire model, let&rsquo;s show an example and how it would be modelled in Strolch and use in Strolch: The model has four entities, which will be modelled using 3 Resources and 1 Order object. The objects have numerous fields and the following relationships: Bidirectional between Article &lt;-&gt; Product Unidirectional from Order -&gt; Article Unidirectional from Order -&gt; Customer A possible model would look as follows:

# Do and Don't

https://strolch.li/documentation/do-and-donts/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/do-and-donts/This page discusses things you should and shouldn&rsquo;t do when using Strolch The following is a simple list of do&rsquo;s and don&rsquo;ts: 1 Service per use-case, should mostly delegate to Commands. Commands implement use-cases or parts of it, and are thus reusable. Subclass ResourceSearch, OrderSearch and ActivitySearch when implementing use-case specific search - this allows privilege checking. One Transaction at a time - no TX inside of another TX.

# Runtime Configuration

https://strolch.li/documentation/runtime-configuration/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/runtime-configuration/Runtime Configuration A Strolch runtime configuration comprises two parts: a configuration part, and a model part. The configuration are files located in the ..config/ folder, and the model are files located in the ../data folder. In an absolute minimal configuration, the Strolch runtime requires the following folder structure: ../config/ ../StrolchConfiguration.xml → configures the Strolch agent ../PrivilegeConfig.xml → configures user management ../PrivilegeUsers.xml → contains the users in an XML based user management file .

# Realms

https://strolch.li/documentation/realms/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/realms/Realms Realms implement multi-tenant capabilities. A Strolch agent can have an arbitrary number of realms configured and each realm has its own persistence configuration, allowing to separate mandates completely. A realm can run in one of the following modes: EMPTY This is a transient data store mode, where no model changes are persisted - they are only kept in memory. When the Strolch agent is started, this realm is empty as no data is loaded.

# Components

https://strolch.li/documentation/components/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/components/Components A Strolch agent can be easily extended with arbitrary components. An agent is basically a container for classes extending StrolchComponent with a life cycle. These classes mostly implement an interface which describes the operations that are supported by the component. The following represents a list of the most used components: RealmHandler: li.strolch.agent.impl.DefaultRealmHandler PrivilegeHandler: li.strolch.runtime.privilege.DefaultStrolchPrivilegeHandler EnumHandler: li.strolch.runtime.query.enums.DefaultEnumHandler PolicyHandler: li.strolch.policy.DefaultPolicyHandler ServiceHandler: li.strolch.service.api.DefaultServiceHandler StrolchSessionHandler: li.strolch.rest.DefaultStrolchSessionHandler PersistenceHandler: multiple implementations PostInitializer: project specific implementation MailHandler: li.

# Services and Commands

https://strolch.li/documentation/services-and-commands/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/services-and-commands/Services and Commands Services are written to implement a specific use-case. Commands are written to implement re-usable parts of a use-case. The use-case can be abstract e.g., AddResourceService or very specific e.g. CreatePatientService. Should the use-case be re-usable in different scenarios, then commands should implement the logic, and the services should then execute the commands. E.g. The CreatePatientService would use a CreatePatientResourceCommand and then use an AddResourceCommand in a single transaction, so that the task of creating the actual Patient Resource can be re-used somewhere else.

# Searches

https://strolch.li/documentation/searches/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/searches/Searches As is custom for every framework, querying, or searching, the model must be possible. Strolch searches are implemented using the StrolchSearch class and one of its concrete implementations: ResourceSearch, OrderSearch, ActivitySearch. A Strolch element always has two identifiers: Type and Id. The type is important as it classifies an element. So if a car and a house would be modelled in Strolch, then those would both be a Resource, but one of type Car and the other of type House.

# Queries

https://strolch.li/documentation/queries/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/queries/Queries The Query API is deprecated and the search API should be used instead. As is custom for every framework, querying the model must be possible. Strolch queries are implemented using the StrolchQuery interface and one of its concrete implementations: ResourceQuery, OrderQuery, ActivityQuery. A Strolch element always has two identifiers: Type and Id. The type is important as it classifies an element. So if a car and a house would be modelled in Strolch, then those would both be a Resource, but one of type Car and the other of type House.

# Transactions

https://strolch.li/documentation/transactions/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/transactions/Transactions Strolch Transactions play a central role in a Strolch agent. A transaction is opened for a realm, and grants access to the model of the agent. Transactions are implemented as a Java try-with-resources by implementing the AutoCloseable interface. This makes it trivial to understand the scope of a transaction. Transactions handle the following: Opening and closing database connections Releasing locks to strolch elements, if tx.lock(StrolchRootElement) or tx.lock(Locator) was called Performing Commands by executing them in the added order, and validating them first.

# Policies

https://strolch.li/documentation/policies/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/policies/Policies Policies are an integral part when writing business logic in Strolch. In many cases it would suffice to write all such logic in Services and Commands, but as soon as behaviour can change, depending on the element being accessed, then this would quickly lead to many if/else blocks. Since writing large if/else blocks is not maintanable in the long run, Strolch offers a different approach. All Strolch elements can store Policy definitions.

# Observers

https://strolch.li/documentation/observers/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/observers/Observers All changes done in a Strolch transaction are recorded and then propagated to any registered observers. The observer feature is opt-in and is configured for each realm. In the StrolchConfiguration.xml file enable observers by adding the enableObserverUpdates property per realm: &lt;StrolchConfiguration&gt; &lt;env id=&#34;dev&#34;&gt; ... &lt;Component&gt; &lt;name&gt;RealmHandler&lt;/name&gt; &lt;api&gt;li.strolch.agent.api.RealmHandler&lt;/api&gt; &lt;impl&gt;li.strolch.agent.impl.DefaultRealmHandler&lt;/impl&gt; &lt;depends&gt;PrivilegeHandler&lt;/depends&gt; &lt;Properties&gt; &lt;realms&gt;defaultRealm, otherRealm&lt;/realms&gt; &lt;enableObserverUpdates&gt;true&lt;/enableObserverUpdates&gt; &lt;dataStoreMode&gt;TRANSIENT&lt;/dataStoreMode&gt; &lt;dataStoreFile&gt;StrolchModel.xml&lt;/dataStoreFile&gt; &lt;enableObserverUpdates.otherRealm&gt;true&lt;/enableObserverUpdates.otherRealm&gt; &lt;dataStoreMode.otherRealm&gt;TRANSIENT&lt;/dataStoreMode.otherRealm&gt; &lt;dataStoreFile.otherRealm&gt;StrolchModel.xml&lt;/dataStoreFile.otherRealm&gt; &lt;/Properties&gt; &lt;/Component&gt; &lt;/env&gt; ... &lt;/StrolchConfiguration&gt; Registering for updates is done by registering an Observer on the ObserverHandler of the realm itself:

# Versioning

https://strolch.li/documentation/versioning/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/versioning/Versioning One of Strolch&rsquo;s features that sets it apart from other frameworks, is that versioning is baked into Strolch&rsquo;s fabric. The feature is opt-in, as it is not required in all projects, but it only needs enabling, for all modifications to objects to be versioned, so that rollbacks can be done when needed. The feature is enabled for each realm. In the StrolchConfiguration.xml file enable it by adding the enableVersioning propery per realm:

# Reports

https://strolch.li/documentation/reports/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/reports/Reports Since Strolch has a generic model, it was rather straight forward to create a simple API for writing reports. In Strolch a report is defined by using its own model, i.e. a Report is a Resource of type Report. A report consists of the following parts: policy definition, thus allowing extensions basic configuration like base object type, order direction, etc. column definitions joins ordering definition filters An example of a report is as follows:

# Privileges

https://strolch.li/documentation/priviles/ Mon, 01 Jan 0001 00:00:00 +0000 https://strolch.li/documentation/priviles/Privileges No framework is complete without user management and privilege validation. The basic form would be Users and Roles, and then validating that an authenticated user has a given role. In Strolch we go a step further: A User has roles assigned, and each role has a set of Privileges. The privileges can overlap, a validation is performed to make sure that the one role doesn&rsquo;t deny and another role allows a specific action.