Table of Contents
Last updated: 10/9/2024

SoftTypes


The ability to configure ShareAspace to manage specific data is based on the concept of SoftTypes. This part of the documentation will go through the concept and usage of SoftTypes.

Warning

If the out of the box excel mapper will be used for import or export remember this: The combined length of a SoftType id and SoftType schema id can not exceed 30 characters. This is because the maximum length of an excel sheet name is 31 characters.

Introduction


Before we dive in to the details of SoftTypes, let us begin with a simple scenario.

Say we want to represent a very simple Part "Box Part" with the attributes Name, Length, Width, Height, and Price. If we build a system from scratch a simple way would be to model one class with the five different string attributes.

Modeled as

Modeled as

An instantiation of a Part modeled as above could then look like this. Here, the values of the attributes are concatenated strings of the value and the unit.

Instantiated as

Instantiated as

A simple way to persist instances of this Part object would be to have a very simple database table like this.

Persisted as - Part table

Id Name Length Width Height Price
001 My Part 10 cm 5 cm 20 cm 50 SEK

When working with ShareAspace, we know that the model is likely to be more complex than that. First of all the ShareAspace model does not have a fixed set of attributes defined, instead the model itself handles the definition of these attributes. A simplified model could look like this.

Representing a Part

Representing a Part

We also know that the modeling constructs for a Part are more complex than just a Part Class. The Part is in fact represented by a Part, one or more Part Versions each having one or more Part View Definitions.

Representing a Part Complex

This brings us in to the reason for the SoftTypes. In fact SoftType is a mechanism for defining multiple features or solving multiple problems for us. First of all, it is common that we in one space might want to handle different specific variations on a Part, e.g. we could use Part to represent a Box as in the example above. But we might also in the same space use Part to represent a "Design Part". To separate the two we might classify them with two different classes, thus we can store them and disttinguish between the two types of Part.

But we might also want different definitions for our different parts, we might want to be able to state rules for the allowed values of attributes, we might want to present the parts differently, we might want to have the different parts go through different maturity states, etc.

In earlier versions of ShareAspace most of this support required customization's based on code. The concept of SoftTypes is introduced to be able to do all of what is described above by just using configurations. We can use want the SoftTypes to define our Business Objects and the rules for data on those objects. At the same time we also want the user interface do be driven by the SoftType definitions.

So far we have only talked about attributes as in Properties but in fact SoftTypes can do more than that (more details below). In fact SoftTypes can actually treat ObjectNamings (i.e. identifiers, names, etc.) as "attributes".

As an example, we could have a Part with multiple identifiers. In the ShareAspace model both identifiers will be represented as Identifier. Instantiated, those identifiers might have different Organization instances as their id contexts. But in the User Interface we might not want the end-user to have to remember to add two identifiers and picking the correct id contexts for the two when instantiating a part, instead we want the end-user to be presented with a friendly user interface stating that here is where you type in id one and here is where you type in id two. We might also want to call our two identifiers something different than just "Identifier". For example, "Id" and "Supplier Id".

The fact that those two identifiers created might have different id context might be of little interest to the end-user creating the Part. More likely the different id context will probably be of more use in other scenarios. Therefore we would like the SoftTypes to help simplify the presentation and UI functionality of ShareAspace so that end users will not have to be concerned with how the ShareAspace model works.

So the SoftTypes will help with all of this, but what can we actually do?

SoftType definition


A SoftType has a name and is defined for one type of Business Object (e.g. Part or Case).

SoftType Dependencies

Data

When defining a SoftType the first step is to define a ShareAspace model instantiation template i.e. a template describing the intended model scope for the SoftType. This template configuration is done within the data section of the SoftType definition. When defining a SoftType it is possible to define rules on top of the ShareAspace model rules (i.e. it is possible to define stricter rules than what is in the ShareAspace model, but it is not possible to break the ShareAspace model rules).

All SoftType definitions can be setup with default values. These default values are not just limited to simple types such as strings. We also have the possibility to define the usage of default SoftTypes instances. Any default SoftTypes instance (like setting a default Id Context Organization for an Identifier) requires that SoftType to have a defined instance in the space template.

Data going in to or out from a SoftType is defined by ports in the data section.

All SoftTypes will have a set of basic non configurable metadata that is always available when loading a SoftType. These attributes are Business Object database id and the SoftType id.

To help explain the SoftTypes we will be using an example SoftType of Document called "Document".

Document Create

Input schemas

The Input Schemas are used to define a simplified input object for the SoftType. The input schema can expose ports defined in the data section. The input schema forms the data contract used by the REST API when creating or updating a SoftType. The input schema can use a subset of the available `ports´ in the data section as long as all the required values are included. The input schemas can define "soft" rules for the SoftType to be used for user input validation in views.

Output schemas

The Output schemas define what data from the SoftType data definition should be loaded when getting an instantiated SoftType. As with the Input Schemas the Output Schemas can expose the ports in the data section of the SoftType.

Settings

The settings control the icons, labels, and default presentation (both single and table) for the SoftType.

Views

Views are used to define SoftType presentation and SoftType Create/Edit forms. It is possible to have multiple views defined for one SoftType. A presentation view requires an Output Schema to bind its presentation to. A Create form View requires an Input Schema to bind the user input to. An Edit view requires both an Input Schema and an Output Schema; the Output Schema is used to populate the form with current values and the Input Schema is used to bind the user input of the values.

A view will allow for the configuration of the UI presentation of the create and update forms. Within the view it is possible to group attributes and relations freely (i.e. independent of the ShareAspace model mapping). Within the view definition it is possible to define labels, helper texts, and UI controls to be used when fetching data from the end-user.

For the Web Framework there is a predefined set of View names to use in order for the SoftType View to be enabled within some of the Web Framework components.

Maturity systems

The Maturity System section is used to define the different states that a SoftType can have. It is also used to define the relation between the different states and the paths that a SoftType can navigate between the states. The configuration also includes the possibility to define a Role required to be able to approve a state transition.

In the data section it is possible to further extend the data validation rules for a SoftType for each defined state. A typical rule could be to set one of the attributes that was not required when first instantiating the SoftType to be required in order for the SoftType to move to the next State.

Space template


All defined SoftTypes are setup as part of the Space Templates. This way it is possible to reuse a defined SoftType in any number of Space Instances. It is also possible to start from an existing Space Template and reconfigure already existing SoftTypes. Different space instances can use completely different SoftTypes as well as using the same setup of SoftTypes. It is however important to know that any changes made to a SoftType in a running space will only affect the SoftType definition for that space instance.

For a running space it is possible to add new SoftTypes, add attributes and relations to existing SoftTypes. It is also possible to change the input / output schemas and views. It is however not possible to remove anything defined within the data section of a SoftType.

Id context pattern


The IdentifyingContext object and the roleQualifier attribute on the Identifier is a new construct to solve a problem when there are two SoftTypes that are based on the same model type and the SoftTypes can have identifiers that are equal i.e. SoftType DesignPart based on Part can have an id 001 in context OEM and SoftType ReferencePart also based on Part might also have an id 001 in context OEM.

The global uniqueness for identifiable objects (Unit of Information's) have changed. A Unit of Information that is unique by identifiers will be unique by a combination of:

  • The type of the UnitOfInformation e.g. Part
  • Identifier.idString, the string idString on the Identifier
  • Identifier.context.idString, the string idString on the IdentifierContext that is the context on the Identifier
  • Identifier.roleQualifier, the string roleQualifier on the Identifier if it is set (it is optional)

A identifying context has an attribute contextObject that is optional. The contextObject points to a select, IdentifyingContextSelect, where only Organization is available at this time. The contextObject is NOT part of the uniqueness but it can be seen as the overall context for the identifier.

Two SoftTypes with same base type


In the case where there are two SoftTypes that have the same base type there is a pattern to make sure there is no id collision.

Role on the identifier

It is easiest to use the roleQualifier i.e. NOT the role. In the configuration of the SoftType the role can be specified differently for the two SoftTypes and then an id collision can be avoided.

Unique Identifier By Role

Different context with same context object

Another way is to use different IdentifyingContext for identifiers of the different SoftTypes but letting the IdentifyingContext point to same contextObject. This way it is possible to display the contextObject as the context of the identifier but still be able to have unique ids for the different SoftTypes.

Unique Identifier By Context

Role on identifier and different context with same context object

Certain scenarios demand that there are no identifier collisions even within a SoftType and also against other SoftTypes based on same type. Combining the pattern with roleQualifier and IdentifyingContext.contextObject gives a powerful way to create global uniqueness for identifiers.

Unique Identifier By Role And Context