Table of Contents
< All Topics
Print

App Design Guidance

Data Modeling Guidance

Gnosis provides many options for designing your Solutions and Business Objects; sometimes, there is more than one way to skin the cat to use the clique. The following provides the methodology for determining how and when to use the different data modeling techniques.

When to Extend an Item Type

When an Item Type already exists that matches your needs, even in some other Solution, you need to augment it with additional properties.

Or it nearly matches your needs, and you need to change, “overload,” or replace, as you like, the data types for one or more of its properties.

You cannot remove inherited properties, so if the Base Item Type has additional properties not needed in the new sub-Item Type, consider separating those properties into its sub-Type.

Another reason to create sub-Item Types even when no property overloading or additional properties are required is when you need different Lifecycles. Here, the Base Type defines the properties for all the sub-types, and each sub-type defines the unique Lifecycles.

Note, however, that with conditions on Lifecycle State Transitions, depending on how different your sub-Type Lifecycles are, you may not need sub-Types. So, create sub-types for each unique Lifecycle for the Base Type if using State Transition Expressions makes the one Lifecycle overly complex to design and manage.

When to use a Link Type

When you need a Many-to-Many relationship, the Link Type is the table you’re linking if you like.

When you need information on the relationship between the Items, a Bill-of-Material “BOM” is a good example, where you have a Part-to-Part relationship, and there is data about the relationship, such as quantity and effective date.

When the Parent Item and its Relationships are removed, the Child Linked Item needs to remain.

When the Linked Item needs to be referenced by other Link Types or Reference “Pick List” Properties.

When to Extend a Relationship Type

When the relationship data is the same for more than one Relationship Type.

It is possible to convert an Extended Relationship Type to a Link Type if you later decide that the relationship data needs to be separated so that other Items may reference the Item.

When to use a Property Type

When a Property needs to be Complex, it is a composite of several fields, and you need to use the composite more than once. An Address is a good example: it has several address lines and city, State, and postal code fields.

Lifecycle Design Guidance

Lifecycles define an item’s possible states at any given moment. This section describes the recommended approach to designing your Item Type Lifecycle.

Step One: Define your States

The first step is to create all the States for the Lifecycle. This is not a requirement, but it is sometimes the most productive way to think about and design the Lifecycle.

When naming and labeling the State, use the present tense as the State Name and the verb as the State Label. For example, the State Name would be “Running,” and the Label would be “Run.”

Step Two: Add the State Transitions

The next step is to link the States together, adding the State Transitions.

Step Three: Define State View Permissions

Review each State and define the Identities with Read and Update Permissions. As necessary, create additional views that are uniquely suited to the identities.

Step Four: Define State Transition Permissions

Review each Transition and define the Identities that will have Transition Permissions. Alternatively, set the Transition Expression, and when the conditions are met, the Item will automatically Transition into the State. The Transition Priority will direct the Transition if more than one Expression is considered valid.

If the Transition has Identity Permission, it cannot be automated, and a Member of the Identity must explicitly call the service to perform the Transaction. However, if there is also an Expression, the Expression must also be valid for the Identity to be allowed to perform the Transition.

Step Five: Add State Transition Workflows

Next, define Workflow as required on the Transition to perform any necessary business processing. Send notifications, perform calculations, interface, and integrate with other systems.