LSPS documentation logo
LSPS Documentation
Data Type Model

A data type model comprises the hierarchy of all Records–user-defined data types with an inner data-type structure–with their relationships and inheritance in a Model.

They are defined in data type definition files of Modules using a graphical editor, the Data Type Editor.

Since a record holds your business data, you want to make sure that the data is valid. You can do so by defining constraints for your record.

Note: Further information on Records, Relationships, and related elements and mechanisms is available in BPMN Modeling Language Guide. The instantiation of Records, accessing a Record instance Fields, and related mechanism are documented in the Expression Language Guide.

Creating a Record

To create a Record, do the following:

  1. Open a data type definition file for editing or create one:
    • To create a data type definition file, right-click a Module and go to New > Data Type Definition.
    • To open an existing definition file, double-click the definition in the GO-BPMN Explorer.
  2. Right-click into the canvas and in the context menu, select Record.
  3. Select the inserted Record and define its basic properties on the Detail tab of the Properties view:
    • Name: name unique within the Module
    • Supertype: supertype Record of the Record
    • Monitoring: displays an icon to indicate that the Record is involved in Monitoring
    • Shared: shared record has its data persisted and hence is not dependent on the existence of its model instance
    • Abstract: An abstract record cannot be instantiated, but can be used as a supertype record of another Record.
    • Read-only: if true, all Fields of the Record are read-only: The Record instance is initialized on model instantiation and can be deleted during runtime; however, neither the Record instance nor instances of its subtype can be modified during runtime.

      Read-only Records can only be targets of data relationships, but not their sources. This prevents a possible inconsistency of data.

    • System: if true, the Record is read-only for the user

      A model instance cannot create instances of a system Record or calculate its Field values. However, it can be instantiated from your Application with the createRecord() on your context, possibly from a custom task or function implementation.

    • Final: if true, the Record cannot be a supertype
    • Deprecated: flag to denote a deprecated Record

      If the attribute is true, the validation displays an information message that the Record is deprecated.

  4. Insert fields into the Record and define Relationships and their properties if applicable.
  5. Optionally, define Metadata as key-value pairs on the Metadata tab.
  6. Optionally, define XML Mapping.

Creating a Record Field

To create a Record Field in a Record, do the following:

  1. Select the Record or its Field and press the Insert key to add a new Field.
  2. On the canvas, select the Field and define its properties in the Properties view.
    • Name: name unique within the Record
    • Type: data type of the record field
    • Read-only: if true, the field is read-only (instantiated on model instance instantiation; not modifiable after that)
    • Deprecated: flag to denote a deprecated Record field

      If the attribute is true, the validation displays an information message that the Field is deprecated.

    • Used for equals: if true, the field value is used as a comparison criterion. You can find further details in Using Fields in Record Comparisons
definingcomplexrecordfield.png
The additional tabs with properties serve for the following:

  • Metadata define additional data as a map
  • XML Mapping define the mapping used on export to XML when creating webservices, and by the convertToXML() and parseXML() functions.

Creating a Record Subtype

To define a Record's supertype, open its Properties view and on the Detail tab enter the name of the supertype Record. Alternatively, select the Inheritance connector in the palette and draw the connection on the canvas.

For more information on the inheritance mechanism, refer to the GO-BPMN Modeling Language Guide.

recordinheritancehierarchy.png
Hierarchy of Records with multiple subtypes

Creating a Record Relationship

A Relationship serves to establish logical relation between Records. In the case of shared Records, it translates to relation between the Record database tables.

It is symmetrical, that is, set on both ends of the relationship. Therefore it is not necessary to make one of the Record the owner of the relationship.

Further information on the mechanisms, related elements, comparing of records and record properties is available in the GO-BPMN Modeling Language Guide.

To create a Relationship between two Records, do the following:

  1. In the Data Type Editor, click the quicklinker icon and pull the link towards the target Record.
    creatingRecordRelationship.png
    Creating Record Relationship
  2. Select the Relationship and open its Properties view:
    1. Define general properties of the Relationship on the Detail, Metadata, and Appearance tabs.
    2. Define the properties of the Relationship ends on the Target and Source tabs.

      The ends that represent the Target and Source ends depend on the way you dragged the Relationship line: the Record you started from is considered the source. Information on the Relationship direction is at the top of the Properties view. Define the required properties of individual ends:

      • Name: name of the Relationship end used to navigate through to the target record
        settingNavigability.png
        Setting the target name
      • Visibility: visibility of the navigation

        If set to Public, the relationship direction is accessible from the entire model; if you unselect the option, it is private and accessible only from within its module.

      • Multiplicity: cardinality of the relationship end
      • Composition: establishes a "fixed" relationship direction of records
      • Used for equals: when comparing instances of the records, the given relationship is included
      • Lazy: whether loading of the related shared records is lazy or eager (refer to Fetching)
      • Exclude from optimistic lock: if selected the version of the entity in the database remains unchanged when the relationship changes; hence, the entity will be changed by all commits without collision. If not selected, and the relationship end entity is changed by multiple users at once, the system returns a "Conflict on entity" error.
      • Ends of Shared Records define in addition the following:
        • Excluded from auditing: if true, the relationship end is excluded from revision history keeping of shared Records.
        • Cache Region: name of the cache region of the relationship
        • Foreign keys (for each end): If such a name corresponds to the name of a primary key Field of that shared Record, the foreign key is used as primary key. The types of the primary key and of the foreign key have to match.
      • Ends leading to a non-shared Record from a shared Record define the BLOB size.

        This is the space reserved for the non-shared Record value since the entire tree of the non-shared Record is serialized and stored as a database entry of the BLOB type.

    3. Optionally, define the XML Mapping properties of the Relationship ends on the Target XML Mapping and Source XML Mapping tabs.

XML Mapping in a Data Type Model

XML mapping of a data model is used on export to XML when creating webservices, and by the convertToXML() and parseXML() functions, which make use of xml mapping properties defined on the pertinent records, record fields, and relationships.

  • To define the XML mapping of a record, open the XML Mapping tab in its Properties view and define the relevant properties:
    • XSD type: XSD type of the record
    • Node name: name of the record node in the namespace
    • Namespace: XML namespace used for the record node
    • Use xsi:nil flag: make the record schema nillable so if the instance is null its XML instance node is generated with the xsi:nil="true" attribute.
    • Order of fields: the order of XML nodes generated for the record fields
  • To define the XML mapping of a record field or a relationship direction, open the XML Mapping on a field and Source/Target XML Mapping on a relationship Properties view and define the relevant properties:

    • XML Transient: exclude the field from the XML
    • XSD type: XSD type of the field
    • Node name: name of the record node in the namespace
    • Namespace: XML namespace use for the record node
    • Use xsi:nil flag: make the field schema nillable so when the field is null, its XML instance node is generated with the xsi:nil="true" attribute.
    • Attribute: the field is the attribute of the record element
    • Optional: the field is left out when null
    • Use as content: the field value is used as the record node content

    This setting is ignored if the Attribute property is selected.

Creating a Record Composition

Compositions establish a "fixed" data relationship between records in a direction, where the target record represents a part of the other record. The part cannot exist by itself and must hence always define its source value. It represents a "has-a" relationship.

To define a relationship end as a composition end, select the composition attribute of the data relationship end in its tab of the Properties view. For further information on composition, refer to the GO-BPMN Modeling Language Guide

compositionSetting.png
Composition setting

Comparing Records

A Record instance is resolved into an object identity: when you compare records, the system compares the object identities, not the Record field values. If you want to compare Records based on the values of some Fields, you will need to define, which Fields should be used.

Defining Fields Used in Record Comparisons

Consider two instances r1 and r2 of a Record, which has a String field.

def Record2 r1 := new Record2(property -> "string");
def Record2 r2 := new Record2(property -> "string");
r1 == r2

The code returns false by default since it checks whether r1 and r2 are the same record instances, which they are not.

On the other hand, if you compare fields of a basic data type, the system compares the field values to check if the records equal: Hence r1.property == r2.property returns true.

To compare one or multiple properties when comparing record instances instead of the record identities, set the relevant record fields to Used for equals. If you set the flag on the Record String property,r1 == r2 would compare the strings and return true.

If a record has multiple properties with the Used for equals flag, all properties must be evaluated as equal for the record comparison to return true.

Note that the flag is inherited by fields of child records. For records with relationships to other records, you need to set the Used for equals flag on the navigation to allow inheritance of the equals flags.

Important: The Used for equals flag applies only to non-shared records.

Comparing Records with Fields on Related Records

To use a Field of a related Record when comparing instance of a Record, select the Used for equals flag on the Relationship end.

Presentation of Record Diagrams

Displaying and Hiding Record Compartments

To display or hide additional compartments in Record views, such as,

Fields and inherited Fields, right-click the Record view in the Diagram, go to Compartments and select or unselect the compartments.

Viewing Record Hierarchy

You can view the record hierarchy of the entire workspace in a tree structure in the Record Hierarchy view. The view provides an overview of all data types and their inheritance relationships.

The view is not displayed by default: to display it, go to to Window > Show View, or call the view from the context menu of a data type (either in the GO-BPMN Explorer or the Data Type Editor). Alternatively, right-click a Record view in a diagram and select Open Type Hierarchy.

ShowingRecordHierarchyView.png
Displaying a data type in the Record Hierarchy view (using the context menu) with the Record Hierarchy view on the left
When you select a Record in the tree, its fields are displayed in the lower section. From the context menu of a Record, you can do the following:

  • Open the Data Type Editor with the data type focused
  • Show the Data Type in the GO-BPMN Explorer or Properties view
  • Show Full Type Names for all displayed Data Types
  • Focus On the selected Data Type to show only the particular Data Type and its hierarchy

Importing Data Types from an XSD File

To import the data type definitions from an XSD file as Records, do the following:

  1. In the GO-BPMN Explorer view, right-click the GO-BPMN module.
  2. Click Generate Data Types from Xsd.
  3. In the Generate Types from Xsd dialog box, select the Xsd file from the file system.

    Some mechanisms of the XSD file, such as, reducing the set of the permitted values or allowing a choice of values for several types, are not supported.