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
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
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
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.
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).
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".
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
UnitOfInformatione.g.Part Identifier.idString, the stringidStringon theIdentifierIdentifier.context.idString, the stringidStringon theIdentifierContextthat is thecontexton theIdentifierIdentifier.roleQualifier, the stringroleQualifieron theIdentifierif 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.
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.
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.
