...

...

Resources

Remarks

...

Introduction

The Forms tile is available on the dashboard for users with the YUUVIS_TENANT_ADMIN or YUUVIS_SYSTEM_INTEGRATOR roles.

You can model the Metadata aspect area in CREATE and EDIT forms that are offered in your client to view and edit metadata. It also possible to combine the form modeling with situation-specific scripts. To check the current layout during modeling, yuuvis® architect provides a form preview presenting the modeled metadata form as it will appear in your client.

...

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 the 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 role YUUVIS_SYSTEM_INTEGRATOR.
• 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 role YUUVIS_SYSTEM_INTEGRATOR.
• A tenant schema contains object types for one specific tenant. A user cannot use objects types defined in a tenant schema not belonging to the own tenant.
  → yuuvis® architect: Modeling of metadata forms is possible only with the role YUUVIS_TENANT_ADMIN.

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

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 its 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 are abstract object types. No business objects can be instantiated from secondary object types. However, they act as groups of properties that can be referenced in multiple document and folder object type definitions. Thus, the properties for secondary object types can be available also for the referencing object types. These additional properties are included in the search as well.

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

• The properties of static secondary object types 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 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 on the creation process.

Floating secondary object types in the yuuvis® architect

In contrast to static secondary object types, floating secondary object types 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  floating secondary object types 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 floating secondary object types 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 a floating secondary object type, it has to be referenced as floating in the corresponding document (or folder) object type definition.

Note: A floating secondary object type must not be referenced by more than one object type to assure the form modeling.

The operating principle of the yuuvis® Momentum architect is based on a classification of the secondary object types. Floating secondary object types referenced in a document or folder object type definition can be given a classification tag 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 a floating secondary object type. Here, the choice is between primary-classified floating secondary object types, characterized by the appClient:primary classification tag. 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 secondary object types 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 secondary object type with this classification can be assigned to an instantiated object.

Whenever one of the referenced primary-classified floating secondary object type is assigned, all required-classified floating secondary object types referenced in the same object type definition are assigned at the same time.

Classification 'required'

...

Extending Types without Classification

...

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 static secondary object types. 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 static secondary object type.

The assignment of a primary-classified floating secondary object type makes an object appearing with a specific business pseudo-type determined by the properties of the primary-classified floating secondary object type.  Since all referenced required-classified floating secondary object types are assigned at the same time, the object has now a fixed set of metadata containing the properties of the original general object type from the creation, the assigned primary-classified floating secondary object type and from the assigned required-classified floating secondary object types. This set of metadata will be the same for any object to which the corresponding primary-classified floating secondary object type 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 primary-classified floating secondary object types.

...

Introduction

The Forms tile is available on the dashboard for users with the YUUVIS_TENANT_ADMIN or YUUVIS_SYSTEM_INTEGRATOR roles.

You can model the Metadata aspect area in CREATE and EDIT forms that are offered in your client to view and edit metadata. It also possible to combine the form modeling with situation-specific scripts. To check the current layout during modeling, yuuvis® architect provides a form preview presenting the modeled metadata form as it will appear in your client.

The labels displayed in the metadata forms for the client can not be customized in the form modeler, but by means of the Localization sub-tool of the yuuvis® architect.

...

...