Model Builder

Windows

Inorigo Launcher is used to Launch the Model Builder and Application Builder Modules. Upon first use, download and install the inorigo Launcher. User Menu  > Help > Download Launcher

Once the Launcher has been installed, access Model Builder through the workbench. Inorigo Launcher will automatically download and install the necessary Java files to your computer.

Troubleshooting

– Nothing happens when I click the Model/Application Builder icon in Workbench

Ensure that your browser and operating system permits inorigo Launcher to start from your browser.

Other Operating Systems

Java Webstart is used for all other operating systems.

Information units that relate to each other are grouped into information domains.

The information domains to be used are Generic Model, Process (only for methods) and Basic Data. The ones visible in the application may vary depending on installation.

In all domains but one, there are two kinds of information units, definition units and individual units. Setting up specific information models is done by creating instances of the units. The definition unit defines the behavior (attributes, possible relations and associations) of individual units with that definition. The definition unit may be viewed as a template for the individual unit.

The Generic Model domain has two definition units; Generic Type and Generic Unit. Both units work as definition units. Generic Type is the definition for Generic Unit and Generic Unit is definition for Specific Unit. Thus, behavior defined on type level must be followed on Generic Unit level. Behavior defined on Generic Unit level must be followed on Specific Unit level.

Generic Model

The following units resides within the Generic Model

 Generic Type

A generic type is a categorization of different kinds of generic units.

A Generic Type:

• Can not have a definition
• Can, but is not required to have super-classes (Generic Type)
• Can, but is not required to have sub-classes (Generic Type)
• Can, but is not required to have instances (Generic Unit)

 Generic Unit

A generic unit is a well defined, well recognized and delimited unit with a specific function and physical and/or logical features.

A Generic Unit:

• Can, but is not required to have a definition (Generic Type)
• Can, but is not required to have super-classes (Generic Unit)
• Can, but is not required to have sub-classes (Generic Unit)
• Can, but is not required to have instances (Specific Unit)

 Specific Unit

A specific unit is a fully specified unit. It is used to simplify communication through a given denotation (code) to secure a given form, feature specification and function. An example: the ISBN code is the denotation for a certain book, where the code is an identifier for the binding, publisher, date of publishing etc. Commonly used synonyms are product item, product code, part number and article number.

A Specific Unit:

• Must have a definition (Generic Unit)
• Can not have sub-classes
• Can not have instances

 Association Definition

An Association associates other units; Generic- and Specifc Units as well as other Associations. It is a nameless unit, identified only by the units it associates.

The Association Definition defines its instances, Associations. The definition allows you to specify how the instance should be presented based on perspective. If you for instance have created a definition that contains two attributes, Company (Organization) and Employee (Person) and you name the definition Employment, you can specify that from the person’s point of view, the association instance should be presented as Working at  while from the organization’s point of view it is  is employed. See  Associations for details. Association Definitions may be marked as abstract (on the general tab) in which case it is not possible to instantiate them. You may also define constraints for your associations, e.g. a certain number of attributes that constitutes a unique key.

An Association Definition:

• Can not have a definition
• Can, but is not required to have super-classes (Association Definition)
• Can, but is not required to have sub-classes (Association Definition)
• Can, but is not required to have instances (Association)

 Association

An Association is an instance based on an Association Definition. The instance is a nameless unit with the unique ability to changes appearance depending on the perspective it is viewed from. See Associations for details.

An Association:

• Must have a definition (Association Definition)
• Can not have sub-classes
• Can not have instances

 Resource

An object stored in digital format.

A Resource:

• Can not have sub-classes
• Can not have instances

 Knowledge Set

The Knowledge Set Builder is a web based module through which you join multiple search queries to create a flat subset of the knowledge in the Model Builder. The subsets are called Knowledge Sets and are in many ways similar to flat tables. Knowledge Sets can be reached via the APIs and integrated in inorigo Applications or other similar tools.

Process

A process is a change of entity states.

 Process Unit Definition

A process unit definition is a definition of well delimited units of change that can be used to create Methods.

 Method

Methods is a visual programming language that can be used in inorigo® to manipulate data where Expressions does not suffice. Method can be used for a variety of purposes; integration, import or export, calculations, validation, messaging and so on.

Geography

Geography is a division of the surface of planet Earth. This is usually done on geopolitical basis.

 Geographical Area Definition

A geographical area definition is a categorization of the different kind of surface divisions, for example country, city, district, province and state.

 Geographical Area

A geographical area is defined by a geographical area definition, for example Sweden, Stockholm city and Stockholm municipality.

Attributes comes in two different flavors, the ones identified by the arrow icon  and the diamond icon . The first kind is unit specific, defined in the database and fundamental to the unit. It is not possible to change their behavior in the application. Examples of attributes are Name, Code and Unit Id.

The other kind of attributes is configurable and defines the unit further. These attributes may be set up by the user in the application. An attribute may for example be a simple string or integer (primitives), but may also point to other information units.

The difference between an attribute pointing at another unit and a relation between two units is that the attribute defines the unit, whilst the relation is just that, a relation between the two. A person is defined by its birth date, height and hair color, but not by its children, with whom the person has the relation parent to (and the child has the relation child of).

Attributes are set up on the Information domains and units. When an individual unit is created, a definition unit is chosen to give the individual unit its behavior.

An example: A Generic Unit is created and named Company. An attribute, Organisation Number, is defined on the definition unit. Then an individual unit, defined as a Company, is created and named Ortelius Management AB. Ortelius Management AB inherits the attribute Organisation Number and is prompted to set a value to it.

The navigator icon for an attribute value is a diamond .

References

When an attribute points at another information unit (rather than a primitive), a link is created to enable search and navigation. The object being pointed at (i.e. referenced) also gets a link, a Reference (previously known as Attribute Reference), to enable search and navigation to all objects pointing to it with attributes.
The navigator icon for aReference is the Attribute diamond complemented with left arrow .

Information exists in relation to other information. The relation between two units is a Relation unit. The relation may hold attributes, such as a sequence, but no attributes. A relation is either directed or undirected. A directed relation may be viewed from two directions, up or down, and is named accordingly, for example Consist of (down) / Is a part of (up), Parent to (down) / Child of (up), Followed by (down) / Preceded by (up). An undirected relation is bidirectional and is named regardless of point-of-view, for example the Has borders to-relation between countries and the Cooperates with-relation between companies.

Some relations have a predefined behavior in the application. The specific behaviors of these relations are explained below.

Can NOT be combined with

The relation Can NOT be combined with is bidirectional. It has a predefined behavior in the inorigo® Product Configurator only. First, units with this relation are shown in the Illegals-palette in the Product Configurator. Secondly, the product generator does not generate combinations of units that have this relation.

Classifies / Is a kind of

The relation Classifies / Is a kind of can only be used between units of the same kind. The resulting structure is called a classification structure and it enables attributes to be inherited from one unit to another. In the generic model domain it also enables the composition structure to be inherited. This is a very powerful tool when similar information models form patterns that may be abstracted and reused instead of redefined and duplicated.

For example, both Car and Motorcycle are a kind of Vehicle (Vehicle classifies both Car and Motorcycle) and as such, they have common behavior. They both have an engine and wheels for example. To avoid defining the same information in many units, the information common to both Car and Motorcycle is defined in the abstracted unit Vehicle and reused. This way, only information specific to a Car or Motorcycle is defined on the specific vehicle, such as steering wheel or sidecar.

Consist of / Is a part of & Contains / Included in

The relations Consist of / Is a part of and Contains / Included in has a predefined behavior in the generic model domain only. Using any of the relations in the other domains does not result in any specific behavior.

The relations are composition relations, relations describing how a unit is composed. Generic and Specific Units have the additional tabs Product Composition and Product Configurator . Both tabs are based on unit composition. The Product Composition tab shows what the unit consists of and contains, i.e. the units the unit has the relation Consist of and Contains to. The Product Configurator uses the composition relations to decide what configurator palettes to show. To generate Specific Units the generator also bases its functionality in the composition structure.

Implements / Implemented by

The predefined behavior of the relation Implements / Implemented by controls an interface mechanism. It is a mechanism for attribute inheritance outside the classification structure and it gives the ability to apply unit characteristics that do not conceptually fit in the classification structure. This feature is applied in the generic model domain only.

An example of good use of this relation is the definition of a price. Let’s say it is essential to hold the price for many, but maybe not for all, of the functional units of a cabinet. It is not conceptually logical to let all functional units, that a price is relevant for, reside in the same classification structure; they simply are not of the same kind. A cabinet door is not of the same kind as the cabinet body. To be able to give those two units the same attribute without having to define it twice, the use of interface is applied.

It is important to remember that an interface should only be used when the attribute inherited truly is an attribute, and not a relation. And that it should only be used when that attribute is conceptually wrong in a classification structure.

Varies / Varied by

The relation Varies / Varied by is used to let units act as an aspect on other units in certain contexts. An aspect is a phenomenon where one unit may affect the attribute values of another unit. No unit is an aspect per definition, but may act as one.

For example if a cabinet is manufactured in different widths, the width concepts (named for example 600 and 800) specify the width attribute of some of the cabinet parts. The width of a cabinet body for example is 599 mm in the 600 concept and 799 mm in the 800 concept, whereas the cabinet front only is 596 mm / 796 mm.
This could be accomplished in an ordinary classification structure, where concepts Cabin 600 and Cabin 800 are classified by generic unit cabinet, and the attribute values are set appropriately. What the classification structure can’t accomplish is to define the width of a front in a 600 concept more generally, so that all fronts, regardless of what furniture (or otherwise) they are manufactured for, have a certain width. With aspects, the drawer unit front automatically gets the right width for the 600 and 800 concepts, without having to create the concept Drawer 600 and Drawer 800.

Validated by

This relation is specific to the Product Configurator which uses this relation that is connected to the Generic Unit to find a method and validate the generated specific unit (product). The method in question gets the list of specific units that constitutes the new product and is required to return a VALIDATION_RESULT as output. See Validate Bike by for details.

Price List / Price List for

This relation is dedicated to the Product Configurator as it uses it to retrieve the different price lists that are attached to this Generic Unit. For instance if you attach 5 units with the relation Price List, the generator will try and retrieve prices for each item in the BOM from every linked price list. This relation is intimately related to the #Find using -relation.

Find using

The Find using-relation is dedicated for the Product Configurator in a similar manner as the #Validated by -relation. This relation however is used to invoke the method which retrieves the price for a Specific Unit.

The basic functionality of concurrency in inorigo® Model Builder is; when changes are saved in one place in inorigo® Model Builder, it is instantly available for all users.

Temporary Matrix

The changes in the matrix will be visible for all users after the data has been saved.

In the scenario above none of the data entered will be visible for the user until it has been saved.

If the Child 1 is changed and saved it will not prompt an update of the entire matrix but just the object that has changed. I.e. if the user to the left changes the Child 1, Child 2 won’t be updated for the user to the right.

If the user to the left and to the right both make changes in Child 1 and the user to the left saves, the changes made by the user to the right will be lost and updated with the changes made by the user to the left.

Navigator

All changes are instant in the navigator, there is no need to save when making a change. When working in the navigator and someone else is making a change you can instantly see your navigator being updated with the new data.

For example someone adds Child 3 to the structure below.

There is no need to make an update to see the changes made.

Product composition

The product composition tab has a slightly different functionality regarding concurrency. If you have the structure as shown in the picture above and open Parent, Child 1 and Child 2 next to each other in inorigo® Model Builder:

The rules are as follows:

• If you add a multiplicity to Parent it is visible for Child 1 and Child 2 at the moment you save Parent. The multiplicity is written in italic for Child 1 and Child 2 and bold for Parent meaning that the children’s value is inherited from the parent.
• If you already have set a multiplicity for Child 1 and set a new for Parent, the multiplicity for Child 1 doesn’t change. The value for Child 1 is written in bold, to denote that it is not an inherited value. If you remove the value for Child 1 it is replaced with the inherited value from Parent.
• If you changed the value for Child 1 and don’t save, and then change the value for Parent and save, the value entered for Child 1 is updated with the new value inherited from Parent.
• If you make a change in Child 1 or Child 2 no changes should be visible for any of the other two.

Model Builder General

Temporary Matrix

Navigator/Search Panel

The Generic Model-domain is a bit different than the other information domains in the sense that this has three-level architecture, i.e. Generic Type, Generic Unit and Specific Unit. The modeling rules apply for this domain as well, i.e. if you specify an attribute on a Generic Type it can be used on its instances, i.e. a Generic Unit. The same rule applies to Generic Unit and Specific Unit.

The Generic Model-domain was originally the Product-domain and is especially suited for product configuration needs. The best way to effectively define, maintain and evolve business products is to start defining very generic products on a high abstraction level. Work through the levels of specification and let the Product Generator produce variants from which to create low level items; Specific Units. If you want to use the Product Configurator it is recommended that you study the example inorigo® Product Configurator. This document is a walkthrough of all the major functionality in the Product Configurator including Product Composition and Product Generator functionality.

The Generic Model-domain is suitable for all information and you should not restrict the use of this domain to only contain product definitions and instances. The Generic Model-domain also contains the Association-object which can associate (or link) any type of inorigo® entities (even from other information domains) and be able to change appearance depending on the view perspective. This feature allows you to create powerful information models that are able to resolve and refine information directly presented to the user of inorigo® Model Builder.

There is a need to be able to create a unit that may relate, or associate, two or more other units. The nature of such an object is that it does not have a name (it is nameless), but that instead it is possible to show the object, a.k.a. association, in the inorigo® Model Builder depending on the perspective of the association’s unit. An Association is in essence a nameless object which has one or several attributes.

This chapter will cover all of the aspects of the Association Definition and its instances. This chapter will use an example to describe and visualize the behavior and functionality associated with Associations. The example will use the Employment example, where there are three main attributes involved: Person, Organisation and Role.

An Association Definition is not that different from any other inorigo® unit definition. It has a few extra attribute properties, but is in general the same. An Association is an instance of an Association Definition in the same manner as a Specific Unit is an instance of a Generic Unit.

Create a new Association Definition from the File-menu and name it Employment.

Set the attribute Name (Plural) to Employments and leave the attribute Abstract unchecked; these attributes will be explained later.

Go to the Attributes tab-tab and add five attributes: Employee, Date, Company, City and Employment Type

If you are following the example you may have noticed that there are additional attribute properties to set on an association attribute; these will all be covered in the chapter Association Attribute Properties.
Create a few Employees, Employment Types and Companies in order to be able to create an Association. If you right click on one of these entities in the navigator you will get the option to create an Association (instance).

Through the connections panel we can choose from all available connections from the selected association unit. Since we are attempting to connect an instance, all abstract units are disabled in this connections menu.

Notice that the menu item (Employment, Employee) is assembled by the name of the definition and the name of the attribute, i.e. if you select this option the new object will already have the attribute Person set to the one you have selected.

Select an City, Date, Company and an Employment Type and save the object.

By default an association is presented by concatenating all of the attributes.

However, this is not very intuitive nor informative, so you need to define a default presentation expression. Open the Connections-tab for the definition Employment and select the Association-node in the tree on the left hand side.

Enter the following expression in the Presentation-text field – @Employee + ” works at ” + @Company

Save the definition and the presentation of the association will change, i.e. Wright Owen is employed as Consultant at McLee Insurance.

The attribute Name (Plural) is used as the default presentation for a bundle of associations, i.e. Attribute References.

This name also appears in the navigator when you see the attribute reference.

The name is constructed by the definition’s plural name and the attribute’s name.

The attribute Abstract makes it possible to control instansiation of association definitions. A definition marked as abstract can not be instantiated. This promotes data accuracy in that it prevents users from creating instances of definitions that are only meant to act as classification parents.

When a definition is abstract, association (instance) is not an available connection on the Connections-tab. Nor does the definition appear in the context menu of the associated units. This will make the context menu faster to load and much shorter, only showing the associations that are supposed to be used.

An Association (instance) is no more than an ordinary inorigo® object with the difference that it has no name, i.e. you need to specify how it should be presented depending on the viewer’s perspective. The object can be used as any other inorigo® instance, e.g. Specific Unit, but an association it has extended capabilities.

Opening an association in the matrix has the same behavior as any other inorigo® object; it displays its attributes and relations.

However, when you display an object that is part of an association, the behavior changes slightly.

The matrix displays the Person-object which is part of an Employment-association. You cannot modify the association since that is an entirely different object, you are only able to see the association(s) that this Person is a part of.

The attribute definitions for an Association Definition has been extended with the following properties.

To exemplify the Instance of-property you should create a new Generic Unit and name it Company. Link some of your Organisations to the newly created definition.

In this example the organisations McLee Insurance and Yucca Palms Ltd. is now an instance of Company. The remaining organisation Fringe Intl. Ltd. has no definition. Open the Association Definition Employment and change the Instance of-property to use Company as search criterion.

If you now try and create an Employment-association based on an organisation that is not an instance of Company, the option will no longer be applicable.

In the same manner only organisations which is an instance of Company are now available when editing the association.

The property Is a kind of is only applicable for types and the only Inorigo® entity that is applicable for both is Generic Unit, i.e. a Generic Unit can be an instance of Generic Type and a Generic Unit can be a kind of another Generic Unit. If you decide to specify both properties for a Generic Unit the criteria is interpreted as both needs to be true, i.e. only entities which is a kind of and is an instance of are valid.

The properties Singular and Plural Name are used to present the association from the attribute’s point of view. Open the Employment-attribute definition panel open the Company-attribute and modify the properties to Employee and Employees respectively and save the modification.

The Plural Name is now replacing the default presentation defined by the Association Definition‘s attribute Name (Plural). So from the Organisation’s point of view the association Employments is now presented as Employees.

Similarly when you want to create a new association from the organisation’s point of view, it is called Employee.

The Instance Presentation-expression defines how the association should be presented. From the organisation’s point of view we would like to present it as follows:

The presentation now changes in the navigator into Pippi Longstocking works as Hourly Employed.

The Instance Presentation is also used on the web when deleting units that have Nested Units.

The association-object is specifically designed to change its appearance depending on the perspective. If we continue with the association example Employment with the attributes Person, Role and Organisation, you can imagine that from a particular perspective the association information has different levels of relevance.

If you for instance see Employment-associations from the organisation’s point of view, you are not interested in displaying the organisation; you already know that. The image below tries to visualize how the association is intended to work.

1. Association Definition – default presentation
   • You specify a default presentation on the association’s definition, i.e. if no other is defined, this one will be used.
2. Person’s point of view
   • From the person’s point of view there is no need to display the person, since that is already known. It is only relevant to display the organisation and the role.
3. Role’s point of view
   • In this example there is no real interest in viewing the association object with a particular perspective. If none is defined the default one is used.
4. Organisation’s point of view
   • Similarly there is no need to display the organisation, since this is already known. The only relevant information is person and role.

The association itself is no more than an object with a set of defined attributes.

In the same manner the references are displayed differently.

1. Association Definition – default presentation
   • When you look for Employment-associations you use the Name (Plural) attribute, i.e. Employments. When you want to create a new one you use the Name-attribute, i.e. Employment.
2. Person’s point of view
   • When a person looks for employments it is called Jobs, and when you get hired, a new Job is created.
3. Role’s point of view
   • The role has not specified a particular presentation, i.e. the default one is used.
4. Organisation’s point of view
   • From the organisation’s point of view it has a list of Employees and a new association results in a new Employee.

When you expect more than one, e.g. “look for” in particular, the attribute property Plural Name is used and when you expect one, e.g. “create new”, the attribute property Singular Name is used.

An Association Definition may be inherited, i.e. you are able to create new definitions which is a kind of the original one. This behavior is the same as for all definitions in inorigo®. Make sure you are able to create a Classifies / Is a kind of-relation between Association Definitions; add the relation in the Relation Specifier / Admin-tab.

Create a new Association Definition which is a kind of Employment.

Assign the name Permanent Employment and Permanent Employments for the plural name and save the definition.

Go to the Attribute-tab on the new definition object and you will notice that the existing attribute properties are in italic, which means that they are inherited.

Add a new attribute called Employment ID and make it an Integer. The new attribute is only available for instances that are defined by this definition.

We also need to override a couple of presentation rules in order to distinguish the association instances from one another. Open the Company-attribute and override the properties as follows:

The difference between an Employment– and Permanent Employment-instance is that a) it has a new attribute – Employment ID and b) the presentation from an organisation’s point of view has changed, i.e. the ID is displayed first.

If you create a few new associations based on the Permanent Employment-definition you will see that the presentation changes and that the new instances are grouped in a separate bundle.

You have the opportunity to add constraints to an association definition. In particular you want to be able to prevent duplicate records, i.e. an association with exactly the same values are identical and therefore is a duplicate. The example constraint below depicts a constraint where you’ve added all of the attributes to the constraint: Employee and Company.

1. Name
   • A description of the constraint. Mainly used to inform the user of which constraint that has been violated.
2. Attributes
   • A list of attributes that is part of the constraint. Only attributes which have the multiplicity equal to 1 are allowed to be part of the key.
3. Crosswise Unique
   • If you have two attributes of the same class, you can specify that the attribute values are evaluated crosswise. Assume that you have the association definition Collaborates with, which contains two attributes of the class Company. If you check the Crosswise Unique-checkbox the constraint will check for the reversed relation as well, i.e. if A collaborates with B, the reversed relation (B collaborates with A) is considered to be equal to the first one.
4. Enforce
   • If the Enforce-option is disabled, you will be able to override the constraint, i.e. you will get a warning when you add a new association that violates the constraints, but you have the possibility to create it anyways.

     Warning!

     Allowing duplicate entries is in most cases a mistake, i.e. you invite the user to add duplicate entries.

If you try to add a new association which already exist, you will get the following error message.

If you uncheck the Enforce-option, you will only get a warning.

You may not override constraints in sub-classes, i.e. the association definition Permanent Employment may not alter the All-constraint. However, the sub-class is allowed to add constraints to the definition.

Since the Permanent Employment adds the attribute Employment ID, the new (unique) constraint checks that the combination of Company and Employment ID is unique. Please note that the inherited constraint is not editable.

You can also change the sequence of the constraints to make sure that one constraint is evaluated before another one. However, all constraints which have the Enforce-option set to true, will be evaluated first, i.e. there is no need to evaluate any warnings since validation will fail anyway. You should also bear in mind that the sequence may become difficult to predict if you have several levels of inherited constraints.

Building a product model is done in three steps:

1. Compose the product on a functional level (with functional units).
2. Define the product concepts (with concept units), based on the functional model.
3. Generate and configure the specific units.

The strength in separating the general function of things from the more organisation specific function of things is that it enables reuse of basic functions at the same time as it enables an extremely competent comparison between in-house and/or competitor products, as they both point into the same basic functions.

The functional unit model represents the general function of things and should only contain just that – general functions. No trademarks or brand specific names should be present. The conceptual model, on the other hand, is where the trademarks, proper nouns and brand- and organisation specific terms belong. It is here, that organisation specific behaviors and compositions are defined.
Steps 1 and 2 are most effectively carried out in the product composition tab, whereas the last step may be carried out in the product configurator.

The product composition tab shows unit compositions. With composition we mean the unit and all the other units it consists of or contains (i.e. has the relation Consist of or Contains).
The composition tab is different from the navigation tab in its ability to show inherited compositions, define more complex models with replaced nodes and work with aspects. It doesn’t, on the other hand, show any other relations than the composition relations.

The values in italic are inherited values, while the ones in bold are specified in the current composition. The item column in the grid shows the compound unit in a tree structure.

The position column allows the user to specify the position of the unit in the model. If a Car has several wheels, for example, it may be interesting to specify left and right wheel, as they may be manufactured differently. The multiplicity column allows the user to specify how many units the composition should have.

The value column is only editable for attributes and allows the user to set a fixed attribute value valid in the current composition only. The exception to that rule is if the composition itself is inherited (through classification). Then the values are inherited as well. This is the equivalent of modifying the attribute definition in the [Attributes tab].

To see the unit attributes, check the setting Show Attributes in the Filter menu to the left.

The subsequent columns to the right of the value column show aspects categorized by aspect type. The aspects shown are defined in the Aspects menu to the left. It has some basic filtering options, with the supplement of choosing which aspects to show.

The Aspects menu show the aspects, categorized by type, which may act as aspects on the current composition. Only those generic units that the unit is Varied by are shown.

To show all aspects of a certain type, click the checkbox in front of the type. To show only assorted aspects within a type, click the plus button (  ) to expand the aspects and click the checkbox in front of the aspects to show.

Filter out aspects by writing any part of their name in the text field above the list. All aspects that does not contain the characters written, will be hidden.

Product configurator using templates

Templates what are they?

Templates are previously generated Specific Units (Products). The Product generator can use Specific Units as templates for generating new variants.

Finding and selecting Templates

In Product Configurator show and pin the Templates panel (as shown below). A standard search panel is loaded, prepared for finding Specific Units for your current definition. Enter search criteria, press the Search button and select one or several Units in the result list.

Creating variants

As the user selects the desired template(s), below as blue bikes, the configurator automatically marks and selects the corresponding definitions.

Select new aspects to be used for creating variants, below the Touring bike. When started the Generator will calculate what aspects were used to create each template Unit and replace the corresponding aspects by the aspects selected by the user. As shown below, the new attributes are applied in the BOM when the Generator has executed.

The application menu shows at the top of the application. It allows managing fundamental features in the application, such as creating a new unit and saving it. Further functions are for example the ability to change context, language and handle the application windows.

The file menu consists of the following menu items:

The view menu consists of the following menu items:

Icon	Name	Shortcut	Description
	Current Users		Opens a window listing all users (and the engine) running that same instance, together with the context the user is logged into.
	Menu		Slides open the application menu tab. To close it again, click somewhere outside the menu or click the minimize icon in the menu header.
	Search	Ctrl + F	Slides open the application search tab. To close it again, click somewhere outside the menu or click the minimize icon in the menu header.
	Bookmarks		Slides open the application bookmarks tab. To close it again, click somewhere outside the menu or click the minimize icon in the menu header.

The tools menu consists of the following menu items:

Administrate Contexts…

Opens the Administrate Contexts window.

1. To create a new context, press the New-button and fill in the New Context-dialog. 
2. To delete a context, select the context to delete and press the Delete-button. 
3. To edit a context, select the context to edit and press the Edit-button. 
4. To change context, select the context and press the Go To-button.

Send Message…

Any user may send a message to any one or all of the other logged on users. Receiving a message, a user may choose to reply the sender only or reply all users. 
A message sent back and forth will appear almost like a mail correspondence, but will not be saved. The moment the message window is closed, the message information is lost.

The modules menu consists of inorigo® modules, stand-alone applications that may be started without inorigo® Model Builder. The modules are:

The inorigo® PLM submenu consists of:

The window menu consists of the following menu items:

The options menu consists of the following menu items:

Icon	Name	Shortcut	Description
	Context		Shows a submenu with contexts to enable changing current context.
	Navigator		Sets the navigator filter for the current user. The settings are stored as a user preference and will remain between sessions. Since v2.2
	Preferences…		Opens a window with the current user as a shortcut to changing current user preferences.
	System Settings…		Shows the settings for the context, client, system, computer and server.

The help menu consists of the following menu items:

The Report Error-function requires that you have access to the internet since you will be presented with the Ortelius Issues Tracking system.

Each inorigo® installation comes with either a default user or a user provided by Ortelius. The user is set in the Issue Tracking settings section. You also have the opportunity to login with personal credentials, in order to do so, you have to select the Manual Login for Bug Reporting-flag on the inorigo® user. You will then be presented with a login page instead of the automatic one.

The Issue Tracking System is intended to facilitate the communication with inorigo® users and to be able to track and monitor progress of bugs and assorted issues.

The list below describes the different fields available in the Issue Tracking System.

Name	Description	Mandatory
Tab: Quick info
Summary	A summary describing the ticket.
Severity – Urgency	A status describing how urgent the matter is. None No severity, is applicable to enquires and alike Showstopper Blocks production work Critical The application crashes or data is lost Major Major loss of function Minor Minor loss of function a workaround exists Trivial Cosmetic problem
	In addition to the severity there is also a status requesting how soon the problem needs to be fixed.
	None In a later release ASAP As soon as possible Within a day or two The problem needs to be corrected in the next few days Within a week The problem needs to be corrected within a week Within a month The problem needs to be corrected within a month
	The general process for bugs, if the severity is high enough, is that they will be fixed in the next maintenance release, e.g. 2.6.5. A maintenance release can be issued within a short period of time (days), unless any unforeseen circumstances. If a bug is deemed to be minor, it will be applied to the next release of inorigo, e.g. 2.7, which is released 3 times a year. The problem may also be considered to be an enhancement and / or change, and if this is the case, it will be applied in a future release.
Reproducible	How often the problem occurs. Always The problem occurs every time you perform a certain sequence of operations Sometimes The problem occurs on occasion without any apparent reason First time this happened This is the first time the problem occurred
Steps to reproduce	A description on how to reproduce the problem. It is vital to describe the problem in detail, otherwise the helpdesk officer may not be able to reproduce the problem and needs to request addition information which in turn leads to longer lead time.
Actual result / error message	A description of the actual result and an (optional) expected result.
Additional info	Additional information not directly related to the issue detected in inorigo®. It may concern external circumstances such as network problems or other relevant information.
User Email	Can be provided if the reporter wants to be contacted directly by email and reports the error as a system user. If reporting with personal credentials this information is superfluous.
Full name	Can be provided if the reporter wants to be contacted directly. The user name automatically provided from inorigo can sometimes be cryptic. If reporting with personal credentials this information is superfluous.
Tab: Application info	This tab is automatically populated with data if you report the bug from inorigo® Model Builder. However, if you login to the tracking system manually, you have to supply the information.
Communication Host	The URL to the inorigo® Server.
Application Name	The name of the inorigo® application. This is important if you have more than one inorigo® Server installation on the same sever.
Application Version	The inorigo® version, e.g. 2.6.5. This is vital in order to be able to reproduce the problem. This can found on the inorigo® start page or under the Help-menu.
Application Build	The build id, e.g. 8564. This can found on the inorigo® start page or under the Help-menu.
Application Context	The inorigo® Context where the problem occurred.
Application Database	The name and host of the inorigo® database. This can be found on the About-dialog.
Client Java Version	The Java version used by the client. This information is useful to detect compatibility issues between JVM-versions.
inorigo® User Name	The inorigo® user name. This is important if the issue concerns authorization or inorigo® credentials.
Error Message	An error message or stacktrace provided by the inorigo® application.
Additional info	For Ortelius Support internal use only

Preferences-tab

The Preferences-tab allows the user change settings for the client application, such as language and locale. The table below describes the different settings.

The Preferences-tab inherits Client-settings which is available in the System Settings-dialog. Not all settings will be modifiable in the preferences dialog, since they are applied before the user is known. User settings, i.e. preferences, will by default override values set in Client-settings.

General-tab

The General-tab allows the user change other user settings depending on the  System User Role.

The table below describes the different Settings.

Connections tab

Adding Context(s) to a user in Connections tab will prevent the ability to connect to other contexts.

The main purpose with this setting is to protect data and/or Applications from un-authorized access.

The settings applied to the application has a hierarchical type and is structured as follows:

• System
  • Server
  • Client
    • Context
      • User

In short if you set a property on System-level, it is inherited by Server and Client. The User-settings (same as Preferences) inherits the settings from the Context-settings, i.e. you are able to override settings on user level whereas default values are set on Context, Client or System-level.

The table below explains the different settings and how they are used. The Preferences-page describes which settings can be used by the individual user, while these settings are applied on a higher level. An  -icon means that it is applicable, otherwise the setting is not applicable or for information only.

Name	Applies to	Description	System	Client	Context	Server
Icon	See Preferences	See Preferences
ownerGID	See Preferences	See Preferences
controlsetGID	See Preferences	See Preferences
Helpdesk username	Bug reporting	See Issue Tracking settings
Helpdesk password	Bug reporting	See Issue Tracking settings
Log Level	Change Log	See Change log tab#Application for details
Suggest username at login	User login	Defaults inorigo® login username to computer login username
Search Qualifier	See Preferences	See Preferences
Language	See Preferences	See Preferences
Locale	See Preferences	See Preferences
Max items in drop down	See Preferences	See Preferences
Concatenate code and name	See Preferences	See Preferences
Show method tab	See Preferences	See Preferences
Import and Export	See Preferences	See Preferences
Check for duplicates	Unit save	Specifies if the client gives a warning when a unit, with the same name as an existing unit, is being saved. If attributes code- & unit id (applicable for Specific Units) are used, the duplicates check is made on those separately.
Graph text colour	See Preferences	See Preferences
Graph background colour	See Preferences	See Preferences
Graph background image	See Preferences	See Preferences
Show specific unit ID on top	See Preferences	See Preferences
Check integration channels	Integration	Specifies how many seconds the server should use between checking integration channels.
Look for new integration messages	Integration	Specifies how many seconds the server should use between checking for new integration messages
for failed integration messages	Integration	Specifies how many seconds the server should use between checking for failed integration messages
Generator Max Variants	Product Generator	The Product Generator will only generate items with this many variants per definition.This prevents a too extensive/time consuming generation of items.If there are more variants than specified, the generator will complete with an error.If this setting is not specified, the value 300 will be used.

The Computer-tab is for informational purposes only. It can provide helpful troubleshooting information.

Background and concept

In order to provide a high quality Helpdesk service the Ortelius Helpdesk service uses an advanced Issue tracking system, ITS. As of version 2.7 all bug reporting functions will be linked to the ITS. The ITS application requires a registered user to report an issue and this is the reason for the System settings Helpdesk username and password fields.

Settings

Basically there are three use cases when reporting errors from within inorigo®.

Report by the default system user

• Each inorigo® installation comes with a default user and password and is used unless the Helpdesk username and password settings are filled in.
• Since this is a general user no notifications will be sent either to the reporter of the error or the organization utilizing inorigo®

Report by the provided Issue tracking user (Helpdesk username)

• In some cases the organization utilizing the inorigo® platform is provided with an ITS username ans password.
• An email address can then be added to the ITS user preferred by the organization. This way the organization can keep track of any Issue status notifications.

Report error as an ITS registered user.

• The above settings can be overridden by setting the inorigo® user attribute Manual Login for Bug Reporting to TRUE, which enables a user to report issues as a different ITS user than the server settings.
• In this case the reporter can have mail sent directly or login in the ITS system to monitor any reported issues.

The table below provides a list of the different set of combinations.

Below the application menu there is a toolbar. 

The buttons on the toolbar have the same functionality as the corresponding functions in the file menu. The new button is special though: If there are tab units open, the button shows the same icon as the current tab unit to show that pressing the icon part of the button automatically creates a new instance of that same unit. Pressing the arrow part of the button shows a submenu with all information domains and their units. Choose one to create a new instance of that unit. If no tab unit has been opened, pressing anywhere on the button will show the

Along the left side of the main window there are three application panel tabs; Menu, Search and Bookmarks. Hovering the cursor over any of the tabs makes the panel slide open. Move the cursor outside the panel again to make it slide back. Press the thumb tack ( ) in the upper right corner of the panel to nail it so it stays open ( ).

The application menu panel (  ) shows the domains and units. Which domains that appear and the order they appear in, are dependant of application configuration and may differ between installations.

The arrow icon ( ) to the right of the domains indicates that the menu may be expanded. Press the icon to do this and press it again to collapse. As a menu item is chosen the menu will close, unless it has been thumb tacked.

The example below requires you to have a simple structure where you can apply your search criteria. The examples only cover a small portion of the different combinations you can create, however, it is intended to be an introduction to what you can and can’t do. The data and structure below is very basic and is intended to be as simple as possible not to cloud the intent of the exercise.

Create the Generic Type A, which in turn classifies B, C and D. Create a Generic Unit for each type, i.e. A:1, B:1, C:1 and D:1.

Create an attribute with the type String for each type and name them Attribute A, B, C and D.

Attribute are inherited by the Classifies-relation so the type D should have four attributes as depicted in the navigator below.

For every Generic Unit you’ve created assign a value to each attribute, i.e. for the unit A:1 set the value A:A, for unit B:1 set the value B in the attributes Attribute A and Attribute B etc.

If you open the generic units in the Temporary Matrix the values should be distributed as depicted above.

The most basic and perhaps frequently used search criteria are to search on the information unit’s attributes. A (non-configurable) attribute is static and cannot be altered dynamically. In essence it is the same as a database column. The advantage is that the query is fairly simple and fast and is used to narrow down the result where you finally pick the desired entity to open for editing.In order to be able to search for anything at all you first have to decide what to search for. Select Generic Type under the Information Domain combobox.

When you have selected the information unit you want to look for the available attributes is added to the search panel as possible search criteria.

As you can see the attributes Name and Data Owner becomes available. If you perform the search without any criteria, all generic types will be present in the result. If you add a search criterion in the Name-field, e.g. A, the result will only contain generic types where the Name Starts with A.

In order to be able to use a configurable attribute as search criterion you have to select the type which defines it. Select Generic Unit as information unit and select the type A.

When you do so the attribute A becomes available in the search panel. If you select the type D, all of the attribute defined by D and its super classes, i.e. the types that classifies D becomes available. In this example Attribute A, B, C and D.

Similarly if you perform a search all generic units that are defined by the selected type, and its sub-classes, will appear in the result.

In this example all generic units in the result is of the type A, although their inheritance spans over several types, e.g. A to B to C and D.

If you add the search criterion _ (underscore) which means “any character” into the attribute D, only the generic unit that has the attribute and matches the criterion is included in the result, i.e. the generic unit D:1.

Change the values of the attribute B to B for all applicable units.

Select the type B and enter the search criterion B into the field for attribute B.

All generic units which is of the type B and matches the search criteria is present in the result, i.e. B:1, C:1 and D:1.

Using relations as search criteria is very powerful although sometimes tricky to make viable combinations and to comprehend the result.In our simple structure we only have one relation to make use of and that is the Classifies / Is a kind of-relation. If you select the information unit Generic Type and navigate to the relation drop down box called Is a kind of. Select the type B and perform the search.

All generic types that is of the type B is present in the result, i.e. C and D.

Add a consist of-relation between the generic units B:1, C:1 and D:1 according to the image below.

Change the information unit to Generic Unit and navigate to the relation search criterion Is a part of.

If you perform the search the units that is a part of B:1 is included in the result. You can reverse the relation to search for units which consist of B:1, however, in our example there are no units that consist of B:1, so the result will be empty. If you select the unit D:1, the result will be C:1, i.e. C:1 consist of D:1.

The drop down box available for each search criterion enables you to set the search qualifier. There are a set of options depending on the type of the attribute. For instance the qualifiers More than and Less than are only applicable for numeric values while Before and After only for dates. However, the qualifiers Any value and No value allows you to search for objects which lack a specific value and or relation. In the previous example, Search by Relation , you specified a unit that was contained in another one. If you change the search qualifier to Any value, you would get all units that are contained in another one.

Similarly you can set the qualifier to No value, i.e. the result will contain units that is not contained in another one.

This feature allows you to retrieve units where an attribute value or relation exists or not. This is very handy if you want to get groups of units which are missing a value or relation, or the opposite.

In addition to selecting existing attributes, attributes and relations, you can use a sub-query for specific field. Select the information unit Generic Unit and select the Search… option in the Attribute Control field. You will be presented with a new search dialog where you can enter arbitrary search criteria, including other sub-queries.

This example is trivial, i.e. look for all generic types that starts with the letter A, however, all features are available in this search dialog as well. Please note that certain options are locked, i.e. when looking for attribute controls for a generic unit you can only look for generic types. Press the Search Query-button and you will be returned to the original search panel.

 Bookmarks are shortcuts to units and search queries.
To add a bookmark, press the bookmark button in the toolbar, right click any unit and choose Bookmark this or simply drag the unit from any navigator (search result or unit navigator) to the desired folder and row in the bookmark tree. To re-sequence a bookmark, just drag it to its right position in the tree.
To open a bookmark, just double click on it.
Renaming or deleting a shortcut does not affect the unit itself. The shortcut is renamed by clicking anywhere on it to select it and then either clicking on it again, this time on the text, or by pressing F2 on the keyboard, to set the text in edit mode. To save the new name, press enter. Leaving the edit mode by clicking somewhere else reverts the name. Removing the entire name from a shortcut gives the shortcut the unit name again.
It is also possible to bookmark a search. Define the search in the search tab and press the button Bookmark… Name the search and press the Ok-button and the search appear in the bookmarks tab with a search icon.

All units, persons for example, are shown in unit tabs in the main area of the window.

A unit tab consists of several sub tabs, for example General, Navigator, Connections, Graph and Change Log. Different types of units may have different sub tabs.
The bottom right part of the tab shows information about the kind of unit the instance is of, the context it is created in, the date and time when it was created, and if it is deleted, the date and time of deletion.

If the tab unit has been changed, but not saved, this is indicated by a asterisk (*) in the tab header . If such a tab is closed, the user is prompted to save or discard the changes before it is closed.

Units may be opened simultaneously and grouped at the users will through the Tab menu. It is also possible to change the order of the unit tabs by dragging and dropping the tabs to the left or right of adjacent tabs.

Right clicking a unit tab or any of the sub tabs opens a tab menu. The tab menu alternatives are described below.

It is possible to specify icon heritage in a elaborate manner, and the rules are as follows.

1. If no icon has been specified the default rule is to use the icon set for the class, i.e. the type, e.g. Generic Unit, Specific Unit, Association Definition etc. All units that are of that class will get that icon unless anything else has been specified.
2. The next rule is to use the first icon that is found on an inorigo® entity that classifies this unit. For example if the Association Definition Project Portfolio is a kind of Portfolio and Other Unit, the algorithm will use the first icon that has been set on any of the Association Definitions that classifies Project Portfolio.

Modify the Portfolio unit to have a different icon. The icon for the Project Portfolio will now change.

Use the icon which is set by the defining entity to be used by its instances, i.e. you specify on the definition what icon would be used by the instances. For example a Generic Type defines a Generic Unit (top down) and a Specific Unit instantiates a Generic Unit (bottom up).

Create an Association with the type My Project Portfolio as depicted below.

As you can see the newly created unit’s icon does not get the definition’s icon by default, you will have to specify it. Open the Project Portfolio object and go to the Connections-tab. Select Instances in the drop down Connection (under Applicable Properties) and specify the instances icon by pressing the lookup button. This way all instances of Project Portfolio will have the specified icon.

Change the icon into something meaningful as in image above.

The icon for the unit has now changed.

3. If none of the above rules apply, the application will look for any implemented by-relations attached to the unit. If such a relation exists, it will check if the partner object has specified its implementers to use a particular icon, i.e. the same algorithm as for the classifies-relation. Create a new Vehicle Sedan and a new (unattached) Generic Unit Drivetrain.

Create an implemented by-relation between Drivetrain and Sedan and specify an icon for units that implement Drivetrain, e.g. .

If there are no rules set on the Car-object, the implemented by-relation will set the icon on the Sedan-unit.

The Drivetrain-icon is probably not the best illustration for a Sedan, so we decide to specify that all objects that are classified by Car should get the car-icon. Open the Connections-tab and select the connection Classifies and pick the appropriate icon.

The icon for the Sedan-unit will now change since the classifies-relation overrides the implements-relation.

As a consequence of the icon inheritance you are required to set the order of a unit’s parent relations, i.e. if a unit is a kind of A and B, you have to set which should be first. This is done in the Connections-tab of the unit in question.

When the algorithm for determining the icon checks for any classifies, instantiates or implements-relations it will use the first found, i.e. the type of the relation is used to determine precedence, not the order of the relation. If for instance unit B is a kind of A and C and A has set the classifies-relation to have a specific icon. B implements C, which has set a specific icon for units that implements C. In this scenario the icon set by A (classifies) will override the icon set by C (implements), regardless if B‘s is a kind of-relation sets unit C before A.

The search algorithm for looking up the nearest icon specification looks as follows, i.e. 1 has highest priority and falling and it is assumed that the left most unit (or relation) has the highest priority (lowest parent sequence).

A unit’s heritage is displayed at the bottom of the edit-panel.

The icons displayed are defined as follows.

Attribute properties

The attribute properties window consists of the following fields.

A more detailed dependency overview has been added as a tab to unit when viewed in model builder, to supplement the usages functionality in the web interface.

Dependencies is a powerful governance tool to trace where and how objects are used throughout inorigo, to understand the impact changes will have on that unit.

Collateral displays the most critical dependents for an unit, listed under the following classes

• Applications
• Data Sources
• Knowledge Sets
• Methods
• Process Unit Definitions
• Resources

The object SWOT Statement has dependencies to three Applications and one Knowledge Set

Details displays all dependents for a unit in a recursive structure that can be traversed to view the whole dependency chain.

Tabs

Toggle the dependency warnings on and off under the options menu

Example on how to read the dependencies tab

Person is an association definition (the unit is dependent on itself)

Person is the definition in a search query named “Person”

The Query “Person” is a query in the Valueset “Addressee_Valueset”

Addressee_Valueset is defined for the attribute Addressee, on the object Address.

Email Address is a subclass of Address, (and thus it has inherited the attribute)

Postal Address is also a subclass of Address.

Person KS is a Knowledge Set where Person is used as a criterion, to set the definition in a query.

Person Application uses the Knowledge Set in the filter component p0

Criteria for an Application or a Knowledge Set to flag a dependency with a unit

If a Knowledge Set or an Application use a unit to define a search query, that unit will display the KS/Application as a dependent.

Example: A filter component content or initial base query is defined as:

Associations defined by Person.

The KS/Application will then be displayed as a dependent to the Person definition unit (e.g. Association Definition), but not to any of the person instance units (e.g. Association).

At the bottom of the application window there is a status bar.

It shows (from left to right):

	The logged on user
	Current Context
	Current application language with the locale within parenthesis
	Name of the application server: port number
	Client version and build number (a number derived from the versioning of the development environment)
	Memory available/Memory currently reserved for inorigo®/Maximum amount of memory that can be reserved.
	Today’s date and current time.

As the client is waiting for a reply from the server, a blue square is displayed around the server symbol .

The temporary matrix is a tool to provide a quick and easy way to handle large bits of information in no time. The look and feel is similar to common spreadsheet-applications with which it also shares much of its controls for operations like copy, fill-down, cut, paste and delete data in multiple cells in one go. It also supports copy and paste data to and from spreadsheets. But beware – this is not a spreadsheet application. The content of the cells are richer, i.e. they may contain one or several inorigo® entities which may in turn control the behavior of other objects displayed in the matrix. So – there is a lot more under the surface than in an ordinary spreadsheet application.

The matrix is about offering the ability to handle units of information of different kinds, from numbers, text and images to geopolitical units or user defined objects with complex relationships to the world around them. Besides supporting rapid editing of large quantities of data, the matrix also gives the user the option of sorting the data and hiding or rearranging columns to increase overview.

Row Selection

As the user selects entire rows by clicking (and dragging) in the row header part of the Matrix component, the row header will render as a blue pressed button. The data area will render a selection border around the outer perimeter of the selected cells.

Cell Selection

As the user selects individual cells by clicking (and dragging) in the data area part of the Matrix component, the row header will render as a gray pressed button. The data area will render a selection border around the outer perimeter of the selected cells. Also there will be a bold border around the last cell selected, this indicates the focused cell (which is not applicable during row selection).

Row Deletion

To delete an entire row, the row must be selected (it is not enough to select all cells in the row). If the row is selected, deletion of it is enabled both via the delete button on the keyboard and the delete button underneath the matrix (  ). If the row unit may not be deleted (due to links to other units) the delete button underneath the matrix is disabled and pressing the keyboard delete button has no effect.

Deleted rows are not immediately deleted, but only marked for deletion until the matrix is saved (see the image below). The exception to this is if a row is added, but not yet saved, and then deleted. In that case the row will be immediately removed.

To undo (not yet saved) deleted rows, select the rows marked for deletion and press the delete button again. This will remove the row deletion marks. It is also possible to reload the entire matrix (  ), but then all changes are lost.

Cell Content Deletion

When cells are selected (as opposed to rows) the delete button underneath the matrix is disabled and the delete key on the keyboard can be used to clear cell content.

Note that any change in the matrix will mark the Temporary matrix* with  an asterix.

There are three different ways to set how and what data is shown in the matrix: filters, column-setup and sorting.

Applying a filter

Applying a filter to the data in the matrix is an easy way to find and view only the rows matching a certain text typed criteria. This can be done straight away by typing in the filter box.

For more advanced filtering, press the magnifier icon to reach filter settings. The first section of these settings set which columns the filter applies to. The second section sets whether the filter should differentiate between upper- or lowercase letters. The third concerns whether filter should permit the use of joker characters (like % and *) and the forth is how the filter will match your filter string: from the start, exact match or everywhere match.

Adjusting columns setup

To rearrange the order of a column just hover the mouse pointer above its header, hold the left mouse button down and move the column to wherever you like.
To set the width of a column just let the mouse pointer hover a bit to the right or left of the border connecting two columns. The pointer will change into a double-sided arrow and you are ready to adjust the width. To auto resize any or all columns, hover above its header and right click to get a menu with these options present.
In this right click-menu you also find options of hiding current column, showing/hiding all columns and all relation columns. At the top is the option More… which brings up a dialog box containing the column names and checkboxes, making it easier to set the visibility status for many columns at the same time.

Add calculated column…

The option “Add calculated column…” available from the context menu, allows you to insert a new column right on the spot where command was issued (context menu). The expression field make use of the input object (@Y_Object) and can invoke any epxression function available in inorigo®. The example below shows where you have an object which has the attributes Amount and Tax and I’m interested in showing the tax percentage, i.e. 100 * (Tax / Amount).

The option “Remove this column” available from the context menu in Edit mode, allows you to delete a calculated column right on the spot where command was issued (context menu).
It is not possible to remove any non-calculated column, i.e. columns with data from definitions (  ) when applicable, inherent attributes (  ), defined attributes (  ) and relations (   and / or   ).

Web rendering enables other interpretation than default; Link and Html.

The example matrix below shows how you can add dynamically calculated cell values to the matrix.

Sorting the data

To sort the data, click the column heading you want to order by. The first click will set up a sort of ascending type. A second click on the same header will change the sort to descending and a third ends the sort on that column.
To sort rows based on many columns at the same time, hold down CTRL and click as described above. There is no limit to how many additional sorts you can apply.
Note that the sorting you set up wont effect coming changes to cells and rows. The way to reenact the sorting is simply to redo the clicking of column headers you want to order by.

In inorigo® Model Builder it is possible for multiple users to be logged in and work simultaneously with the same or connected sets of data. This becomes even more important when it comes to working with data through the matrix. Whenever any changes has been made from outside to the data you are currently working with, the matrix will automatically update the concerned cells and rows. The only exception to this is if a user is currently in edit mode in a cell with data that is updated from somewhere else. In this case the matrix will report unsaved changes to the cell, even if the user hasn’t made any changes, because the value in the cell differs from the saved value. If the user saves his value will be saved, if the user reloads the value in his cell will be as consistent as the rest of the cells with the current “real” data.

There are a couple of known limitations of the matrix:

• It is not possible to view/edit objects from different information domains within the same matrix. This is a consciously set limitation and exist for a couple of reasons. First off this paves the way for a use of the matrix which encourages a cleaner look and overview of the information being worked with in the matrix. With just a couple of objects from different information domains the matrix would be quite stretched horizontally and the user would need to, either do a lot of scrolling, or showing/hiding of attributes (or relations) as they moved down and up their rows of different data. Another reason is that a limitation like this makes the matrix more maintainable behind the scenes and thus easier to improve both in the areas of functionality and performance.

• For this version of the matrix the handling of complex attributes is no longer supported. Legacy still support the existing complex attributes to avoid inorigo® upgrade issues. It should be considered to remove complex attributes at customer sites.

• Beware when deleting many units at the same time. Since the matrix performs a single delete for every unit, the operation may be time-consuming, i.e. although the application seems to hang, the operation continues in the background. Currently there is no “bulk”-delete, if this functionality is deemed to be important it may also be implemented in future version of inorigo®.

The Resource unit (previously “Image”) is used for storing images and any other type of documents. A pre-requisite is that the resource type exists in inorigo® since it is used to determine the usage of the resource, i.e. if the resource is an image, it will be used to represent the object, otherwise the resource type’s image will be used by default. The “Resource type” unit can be accessed in the “Basic Data”-menu and the following are available in the base installation.

You can add any number of resource types; however, there are some special rules associated with some of them.

1. MIME-types starting with “image/” are considered to be an image and thus used to render icons and images in inorigo®.
2. The resource types for text (txt) and Excel (xls) can be used for input data to Application Builder.

To add a new resource type, choose New -> Basic Data -> Resource type. Specify the File extension (for example the image file extension tiff) and find the Content type for tiff on for example Wikipedia. Give the resource type an appropriate icon (if the resource type is an image, use the mime_img_64 resource). Once saved, it is possible to upload resources of that type.

It is not recommended to remove any of the pre-defined resource types from inorigo® sine it may limit or damage existing functionality.

Resource Update

An update of a resource will immediately refresh the display of the resource throughout the application. There is one exception though; static icons & images in user interface elements (such as buttons, menus and toolbars) are NOT guaranteed to be refreshed directly as a resource is updated. If the icon is located within a document tab or an Application a mere reopen of the tab or Application will show the new icon. In other cases it may even require a restart of the entire application in order to refresh certain elements.

Specifies the expression to use to fetch content data.

Expression Editor

Variables – Verso View will give the list of available default variables, user defined variables and dataset(s) as input to new Expression Variables in view;

Example that shows the available items defined in view

While configuring the World Map, additional options are available – the fields that was fetched from the Layer URL;

Example showing the available fields from Layer to be used in an expression

and also the items that are referenced by the Source setting for World Map;

Example that shows the available items to be used in an expression, in this case a filter box that list Countries from the Geographical Area domain.

The status bar at the bottom of Expression Editor will provide a possible cause of error in expression. The expression will also be marked with red color as seen in the examples below;

Example 1, missing parenthesis

Example 2, wrong symbol in front of expression function

Example 3, no error, and as one can see the parenthesis is being paired for better readability