Learn in this article about the definition and composition of the objects types in your yuuvis® architect and yuuvis® client.

Introduction

Any business object handled in your client has an object type. The available object types are defined in the yuuvis® Momentum schema as document, folder or secondary object type. This article gives an introduction into the basics of the yuuvis® Momentum schema and the particularities for yuuvis® Momentum client and yuuvis® architect.

The yuuvis® Momentum Schema

All work with yuuvis® Momentum begins with a data model – the yuuvis® Momentum schema. The schema is used to define object types via which users create and manage business objects. It is part of yuuvis® Momentum core and can be accessed or modeled only via the corresponding core endpoints.
>> Schema - Defining Object Types

The schema is divided in three parts that can be customized independently by means of separate endpoints. Thus, permissions can be set for customizing the individual parts.

• The system schema is a global part. The object types defined in here can be used by all tenants and applications.
  → yuuvis® architect: Modeling of metadata forms is possible only with the YUUVIS_SYSTEM_INTEGRATOR role.
• An app schema contains object types for one specific application. If necessary, multiple application schemata can be defined. The object types defined in the application schemata can be used by all tenants.
  → yuuvis® architect: Modeling of metadata forms is possible only with the YUUVIS_SYSTEM_INTEGRATOR role.
• A tenant schema contains object types for one specific tenant. Users cannot use objects types defined in a tenant schema not belonging to their own tenant.
  → yuuvis® architect: Modeling of metadata forms is possible only with the YUUVIS_TENANT_ADMIN role.

Note: The roles used by yuuvis® architect are not defined in the schema but in a tool-specific role set. This role set is also required for yuuvis® Momentum client. However, yuuvis® Momentum allows you to define your own roleset. If you do so, you will not be able to use yuuvis® architect or yuuvis® Momentum client.

Idea of Object Types

An object type identifies a business object by means of specific metadata which can be used to find and identify the object. Metadata describes the properties of a business object. For example, an invoice document is defined by its invoice date, invoice number, and vendor/customer. The properties are defined and assigned to the object types in the schema.

The object types are defined in the schema as one of those three basic object types: document, folder and secondary object type. A business object can be instantiated only from a document object type or a folder object type, but not from a secondary object type.

Document and Folder Object Types

From document and folder object types defined in the schema, document and folder objects (short documents and folders) can be instantiated. Those objects have the properties that are assigned to the object type in the schema from which they are instantiated. Documents and folders in the system can be found via their metadata.

Document object types enable the instantiated documents to include a document file in addition to metadata. Document files can be text files, e-mails, image files, etc. Documents can reference a folder to be their parent.

Folder object types enable the instantiated folders to be the parent of multiple documents in the system. Each document can be contained in one parent folder only.

In a document or folder object type definition, multiple secondary object types can be referenced.

Secondary Object Types

Secondary object types (SOT) are abstract object types. No business objects can be instantiated from SOTs. However, they act as groups of properties that can be referenced in multiple document and folder object type definitions. Thus, the properties for SOTs can be available also for the referencing object types. These additional properties are included in the search as well.

The reference on an SOT in a document or folder object type definition can be either static or floating.

• The properties of static secondary object types (SSOT) are automatically assigned during the creation of any instance of the referencing document or folder object type. They are available for the instantiated objects for their whole lifetime.
• The properties of floating secondary object types (FSOT) are assigned to an instance of the referencing document or folder object type only on request. They can be added to an object or removed at runtime independently of the creation process.

Floating Secondary Object Types in yuuvis® architect

In contrast to SSOTs, FSOTs can be handled in a flexible way during the import or at runtime for already existing documents or folders with an update. The concept of FSOTs fits the import behavior where files are imported as documents of a general document object type with no or only a few defined metadata properties. After creation, a classification job analyses the document and assigns specific FSOTs to that document providing the typical properties of a specific business object like an invoice, a delivery note, an order, etc.

In order to be able to assign an FSOT, it has to be referenced as floating in the corresponding document (or folder) object type definition.

Note: An FSOT must not be referenced by more than one object type to assure valid form modeling.

The operating principle of yuuvis® architect is based on a classification of the SOTs. FSOTs referenced in a document or folder object type definition can be given a classification appClient:primary or appClient:required.

Classification 'primary'

With respect to the above-mentioned import process, the user can specify business types for an object manually by means of assigning an FSOT. Here, you can only choose a primary-classified floating secondary object type (PFSOT), characterized by the appClient:primary classification. All of them need to be referenced as floating in the corresponding object type definition in the schema. After importing an object with the general object type, exactly one of those PFSOTs can be selected. Thus, the business type of the object will be determined by assigning its metadata: a specific business type name like invoice, order, etc. and a corresponding description.

During runtime, only one PFSOT can be assigned to an instantiated object.

Whenever one of the referenced PFSOTs is assigned, all RFSOTs referenced in the same object type definition are assigned at the same time.

Classification 'required'

Business objects may need more metadata properties than provided by the initial general object type together with the user-selected PFSOT. With the classification appClient:required, the required-classified floating secondary object types (RFSOTs) are defined. Their metadata properties are assigned automatically together with the assignment of any PFSOT if they are referenced in the same document or folder object type definition. The assignment of multiple RFSOTs is allowed.

Extending Types without Classification

In the schema, SOTs can be defined without any classification appClient:primary or appClient:required. Nevertheless, they can be referenced as FSOTs in an object type definition. Thus, they allow for the user to assign additional metadata independently of other SOTs. They can also be assigned or removed later on if necessary. Examples are general address data, e-mail address data, and approval process attributes.

Types for Business Objects

Any business object in the yuuvis® system needs an object type – either a document or a folder object type. The document or folder object type can reference SSOTs. Thus, any instance of the document or folder object type is provided with a set of metadata coming from the final object type definition and a set of metadata coming from the referenced SSOT.

The assignment of a PFSOT makes an object appear with a specific business pseudo-type determined by the properties of the PFSOT.  Since all referenced RFSOTs are assigned at the same time, the object now has a fixed set of metadata containing the properties of the original general object type from the creation, of the assigned PFSOT and of the assigned RFSOTs. This set of metadata will be the same for any object to which the corresponding PFSOT is assigned. Thus, you can consider them as pseudo-types you can choose for your business objects. They are identified by the title property of the PFSOTs.

Instantiated documents or folders of both categories can be extended at runtime by assigning extending FSOTs.

Tags

Tags make it possible to flag the current state of an instantiated object within a process chain in the backend.
>> Tagging

In order to display their values in your client, they need to be introduced into your schema as well. Indeed, they are introduced in a specific object type definition. Their names and expected values are set in this definition.

So once introduced, the name and expected values of a tag will appear as technical names in the localization view for users who have the permission to manage the comprising object type.

Summary

Object types are defined in the schema as document, folder or secondary object types. Secondary object types cannot be used to instantiate objects, but referenced in document and folder object type definitions. Thus, their properties may be available for instances of the corresponding document or folder object type.