3. General Information

This section covers information about the concepts and core functions of RepoPro.

3.1. Basic Concepts

RepoPro allows users to define an information model, which sets up the groundwork to manage, classify and discover information. The figure below gives a conceptual overview of the Information Modeling system used in RepoPro:

Information Modeling

Fig. 3.1 Information Modeling

Basic concepts used in RepoPro are explained below:

3.1.1. Asset Types

An Asset Type is like the “class” in object-oriented languages. It defines the blueprint. The user can define metadata for each Asset Type as Properties with the Properties grouped under appropriate Categories.

3.1.2. Asset Instances

An Asset Instance is like the “object” in object-oriented languages and bases itself on the blueprint defined for the Asset Type. Each Asset Instance has different values for each Property. Based on the Relationships defined between Asset Types, the concerned Asset Instances can instantiate the Relationships.

3.1.3. Properties

Properties are the metadata for each Asset Type, which the user can group under Categories. Asset Instances under each Asset Type share the Properties defined for that Asset Type.

3.1.4. Taxonomies

Taxonomy is the practice of classifying content with the intent of easy retrieval of information from the Repository. One of the ways Taxonomies are represented in RepoPro is visually using a Taxonomy Tree, which is a tree-like structure used in RepoPro for creating and editing Taxonomies for Asset Types; and the other way is using tables.

3.1.5. Tags

Tags allow the users of RepoPro to tag Assets with built-in metadata for ease of discovery.

3.2. Asset Relationships

A Relationship identifies a dependency or connectivity between two Asset Types. Asset Types can be related to each other in a hierarchical or non-hierarchical way. If two Asset Types are related to each other in a non-hierarchical way, they can have an Association or Classification type of Relationship. On the other hand, hierarchical Relationships exist when Relationships create a hierarchical, parent-child Relationship between Asset Types to represent products and services comprising multiple components. Hierarchical Relationships can have an Aggregation or Composition type of Relationship.

RepoPro allows users to define Relationships of the following types:

  • Classification
  • Association
  • Aggregation
  • Composition

To find more information about Relationships, visit: Relationships.

Note

Repopro does not ship with any predefined Asset Types and Relationships.

3.3. Asset Visualization

RepoPro allows users to define the way they want to visualize their assets within an organization. Users can display the assets in the right form that is visually appealing and easy to understand. This will help to comprehend information about the asset faster, and better, since it has been customized to suit user’s preference.

3.4. Properties and Parameter Types

RepoPro supports the following Parameter Types:

  • Text

    Use Text Parameter Types for text-based values. The user can specify the maximum length for a Text Parameter type. A Text Parameter Type can also hold array values.

  • Rich Text

    Use Rich Text Parameter Types for text-based values. A Rich Text Parameter Type can also hold array values.

  • File

    Use File Parameter Type to attach files to the Asset Instances

  • Date

    Use Date Parameter Type for date values

  • List

    There are four types of lists:

    • Custom List - where the user provides the list values (max 5000 characters). Do not use the characters ~,`,#,^,& ,+ and comma in the list values
    • Asset List - RepoPro allows the user to map the parameter to any of the Asset Types. For each Asset Instance, this parameter is populated with the names of all the Asset Instances of the mapped Asset type. For e.g., let us take an instance of two Asset Types, i.e., “Service” and “Consumer”. If we were to edit the Asset Type named “Consumer”, which has a parameter of type Asset List mapped to “Service”, each Asset Instance of “Consumer” lists out the names of all Instances of “Service” for this parameter. If there is only one Asset Type in the Repository and it has a parameter of type Asset list, it is automatically mapped to the only existing Asset Type, i.e., itself.
    • Native User List - where the list is populated with the names of native users
    • LDAP User List - where the list is populated with the names of LDAP users

  • Derived Attribute

    A Derived Attribute allows the user to extract the value of an attribute using the attribute names, or the Overview, Asset Instance version ID, Asset Instance name using macros from a related Asset Instance. The user can define a rule using IF, ELSE IF, ELSE pattern to get different values for different cases.

    The available macros are:

    • #ASSETINSTVERSIONID# - for getting the Asset Instance version ID
    • #OVERVIEW#- for getting the Asset Instance version overview
    • #ASSETINSTNAME#- for getting the Asset Instance name

    The user can traverse Relationships, starting from the current Asset Type in both forward and reverse directions. When RepoPro finds a defined Relationship name in a rule, it intelligently figures out the direction of the Relationship based on the Relationship definition. In cases where the same Asset Type is on both sides of a Relationship, the rule must explicitly show the reverse direction with a caret symbol.

    Different rule patterns to be followed for Derived Attributes:

    1. When the rule is without any condition:
    <asset name>[relationship name]<asset name>{Parameter name / Macro}

    Example: An Asset Type with name “services” has a Relationship name “association”, and another

    IF[<asset name1>.<parameter name1> == <value to be matched1>] <asset name1>[relationship name]<asset name2>{Parameter name}
ELSE IF
[<asset name1>.<parameter name2> == <value to be matched2>]<asset name1>[relation
ELSE IF
[<asset name1>.<parameter name3> == <value to be matched3>]<asset name1>[relation services[association]project{date}

    Asset Type named “project” has a Relationship with “services”, and has a parameter name, “date”.

    The rule for the Derived Attribute field for finding the value of “date” is:

    The rule to get the Asset Instance name for project is:

    services[association]project{#ASSETINSTNAME#}
    1. When the rule has only one condition:
    IF[<asset1 name>.<parameter name> == <value to be matched> <asset1 name>[relation

    Example: An Asset Type name is “services”, Relationship name is “composition”, and another Asset Type named “project” has a Relationship with “services” and has a parameter named “date”. The user needs to derive value of “date” based on one of the “services” Parameters named “customerid”. The rule for the Derived Attribute field is:

    IF[services.customerid==1]services[composition]project{date}
    1. When there are more than one condition use IF, ELSE IF, ELSE, like so:
    ELSE <asset nameN>[relationship name]<asset nameN>{Parameter name}

    Example: An Asset Type name is “services”, Relationship name is “association”, and another Asset Type named “project” has a Relationship with “services” and has a parameter named “date”. The user needs to use Derived Attribute based on the “services” parameter named “customerid” and find values for “project” Parameters: “date”, “date1” and “date2”. The rule for the Derived Attribute field is as below:

    IF [services.customerid==1]services[association]project{date}
ELSE IF
[services.date==26/12/2017]services[association]project{date1} ELSE
services[association]project{date2}

  • Derived Computation

    Derived Computation allows the user to find the count of Relationships based on the Relationship chain. Derived Computation parameter type allows the user to use the IF, ELSE IF, ELSE pattern to derive different computed values. The user can traverse through Relationships, starting from the current Asset Type; in both forward and reverse directions. On finding the defined Relationship names in the rule, RepoPro intelligently figures out the direction of the Relationship based on the Relationship definition. In cases where the same asset is on both sides of a Relationship, the rule must explicitly show the reverse direction with a caret symbol.

    Follow the rule pattern below for the Derived Computation parameter type:

    • When the rule is without any condition:
    <asset name>[relationship name]<asset name>.count

    Example: An Asset Type name is “services”, Relationship name is ” association”, and another Asset Type named “project” has a Relationship with “services”. The rule in this case for the Derived Computation field:

    services[association]project.count
    • When the rule has only one condition:
    IF[<asset1 name>.<parameter name> == <value to be matched>
<asset1 name>[relationship name]<asset2 name>.count

    Example: An Asset Type name is “services”, Relationship name is “composition”, and another Asset Type named “project” has a Relationship with “services”. The user needs to derive value from one of the “services” Parameters named “customerid”. The rule for the Derived Computation field:

    IF[services.customerid==1]services[composition]project.count
    • When there are more than one condition, use IF, ELSE IF, ELSE, like so:
    IF[<asset name1>.<parameter name1> == <value to be matched1>]
<asset name1>[relationship name]<asset name2>.count
ELSE IF [<asset name1>.<parameter name2> == <value to be matched2>]<asset name1>[relation
ELSE IF [<asset name1>.<parameter name3> == <value to be matched3>]<asset name1>[relation .........
ELSE <asset nameN>[relationship name]<asset nameN>.count

    Example: An Asset Type name is “services”, Relationship name is “association”, and another Asset Type named “project” has a Relationship with “services”. The user needs to use Derived Computation based on the “services” Parameters named “customerid” and “date”. The rule for the Derived Computation field is as below:

    IF [services.customerid==1]services[association]project.count
ELSE IF
[services.date==26/12/2017]services[association]project.count
ELSE services[association]project.count

    To learn about the implications of Access Control on Derived Values, refer: Implications of Access Control on Derived Values.

  • Derived Attribute for Asset List

    Derived Attributes based on Asset List allows the user to retrieve the attribute value for a particular Asset Instance traversing through the Asset List parameter. A new parameter type ‘Derived Attribute for asset list’ is included to the available list of parameters.

    When the rule is without any condition, the semantics is of the form as shown below.

    Rule for single level

    <asset name> [assetlist type Parameter name] <asset name> {Parameter name}

    Example: An Asset name “Services” has an Asset List Parameter named “List” which is mapped to an Asset name “Project” which has a parameter name named “Text”

    The rule for the Derived Attribute for Asset List for single level

    Services[List]Project{Text}

    Rule for multiple levels

    <asset name> [assetlist type Parameter name] <asset name> [assetlist type Parameter name] <asset name> {Parameter name}

    Example: An Asset name “Services” has an Asset List Parameter name “List” which is mapped to Asset name “Project” and the asset named “Project” has an asset list parameter named “List1” which is mapped to an Asset named “Application” which has a parameter named “Status”

    The rule for the Derived Attribute for Asset List for multi-level

    Services[List]project[List1]project1[List2]Project2{Text}

    Note

    The above rule applies

    • If the Asset list has a link to the next defined Asset Type.
    • For values through n-levels.

  • LDAP attribute Mapping Parameters

    RepoPro allows the users to create a new parameter LDAP attribute Mapping at Asset Level. The parameter is aligned to ldap attribute mapping and values for this parameter can be defined at the instance level.

    LDAP attribute parameters can be configured for Single and Multiple users. Ldap attribute mapping parameter values will be displayed in table format in the Asset Instance Version page.

    The LDAP attribute mapping allows the users to retrieve and display the data in table format. The parameter can be mapped to different attributes. The combinations of the attribute are First Name, Last Name, Email ID, and User Id etc.

    Parameter value can be imported and exported via excel.

3.5. Versioning

Asset Types can be versionable or non-versionable. With a versionable Asset, users can create new versions of the Asset’s Instances. Users can clone a version of an existing Asset Instance or create a new one. They can compare any two versions of an Instance. If an Asset is set as non-versionable, all its Instances also become non-versionable.

3.6. Access Control

RepoPro allows access to information in the registry for logged-in users as well as Guest users (or non-logged-in users). To manage access permissions for logged-in, RepoPro makes use of User Roles, User Groups and User types.

3.6.1. User Roles, Groups and User Types

As part of its user management, RepoPro allows its users to:

  • Add and map Roles to pre-defined functions - functions that can be performed by the Roles are predefined in the product.
  • Add Groups and assign Groups to Roles - the user can select the Roles that a Group can be associated with. Role-admin is predefined in the product.
  • Add Users and assign Users to Groups - the user can select the Groups that a User can be associated with. Group-admin is predefined in the product.

After creating and mapping User Roles, User Groups and Users, the user can control access at two levels:

  1. Asset-level

    • Default Access for newly created Instances - the user can define the default Add-Edit-View-Delete permissions that is applicable to an Asset Instance created under this Asset.
    • Guest Access - the user can define whether a Guest User can access the Instances created under the Asset.
    • Category-wise Access - after defining a Category for an Asset, the access to the Category can be controlled using the Category-wise Access.

  2. Asset-Instance-level

    The user can manage View-Edit-Delete permissions for Groups that can access an Asset Instance from the View/Edit Asset Instance screen.

To better understand Access Control for basic User types: guest, admin and non-admin users, take a look at the table below:

Table 3.1 Access Control over User Types
User type Guest-level access Asset Instance-level access Asset-wise access
Guest user (non logged-in user) Manage Guest Access screen Block public Access from Asset Instance screen Category-wise Access from Manage Assets screen
Logged-in user with Admin role Not Applicable Not Available Category-wise Access from Manage Assets screen
Logged-in user with Non-admin role Not Applicable Multiple Asset Instance Access from Browse grid screen, Asset Instance Access Rights from Asset Instance screen Category-wise Access from Manage Assets screen

The user can use Access Control at the following places in RepoPro:

  • Block access to Assets for Guest users – blocks the Asset and all its Instances from non-logged-in users
  • Block access to Asset Instances for Guest users – blocks individual Asset Instances from non-logged-in users. This includes browse and search results.
  • Individual Access Control based on User Groups for each Asset Instance version – the user can configure individual Asset Instance version to make it visible or invisible to different groups, and access control per Asset Instance for non-logged-in users. This includes browse and search results
  • Control visibility of Categories and Parameters based on Groups

The table below shows the Access functions for Logged-in and Guest users:

Table 3.2 Access functions for Logged-in and Guest users
Function Access
Logged-in user - access to view Asset Instance versions Based on access control settings
Logged-in user - access to edit and delete Asset Instance versions Based on access control settings
Logged-in user - access to add Asset Instance versions Based on access control settings
Logged-in user - admin options Based on roles assigned
Guest User - view Asset Instance Based on access control settings
Guest user - browse Asset Types Based on access control settings
Guest user - add or edit or delete Asset Instances Not allowed
Guest user - admin options Not allowed
Guest user - Search Based on access control settings

3.6.2. Implications of Access Control on Derived Values

Since Derived Attributes and Computations traverse Relationships, the access permissions for the traversed Asset Instances become important.

Find the implications of access control on the values of Parameter Types: Derived Attribute and Derived Computation in the table below:

Table 3.3 Derived Values and Access Control
Relationship Scenario Derived Attribute Derived Computation
When there is a Destination Asset Type(s) that the user does not have access to Derived Attribute value of the parameter for which the Asset Type is inaccessible is blanked out Count of all Destination Asset Types that have a Relationship (including the inaccessible Asset Type) is displayed
When there is a Destination Asset Type(s) that the user has access to Derived Attribute value of the parameter for the Asset Type(s) is displayed Count of all Destination Asset Types that have a Relationship is displayed

3.6.3. Implications of Access Control on Derived Attributes based on Asset List

Since Derived Attributes on asset list traverses based on parameters, the access permissions for the traversed Asset Instances becomes important.

Find the implications of access control on the values of Parameter Types: Derived Attribute based on Asset List.

Table 3.4 Derived Values and Access Control
Scenario Derived Attribute for Asset List
When there is a Destination Asset Type(s) that the user does not have access to Derived Attribute for asset list value of the parameter for which the Asset Type is inaccessible is blanked out
When there is a Destination Asset Type(s) that the user has access to Derived Attribute for asset list value of the parameter for the Asset Type(s) is displayed

3.7. Authentication

RepoPro provides facility for user Authentication through:

  • Its native database
  • Integration with corporate LDAP
  • SAML

3.8. Discover Repository Information

The user can discover information stored in the Repository through the features below:

  • Browse
  • Search

3.9. Subscriptions

RepoPro allows users to subscribe to allow them to get email notifications about changes to the Repository. The email notification is sent to the email address provided in the user profile. The user can view/edit their Subscriptions using the Subscriptions option in the user widget. There are other options to subscribe/unsubscribe, as mentioned below:

Asset Type Subscriptions

On subscribing to an Asset Type, all the changes made to the subscribed Asset (including creation of an Asset Instance, changes to Categories, Parameters, renaming the Asset Type, deleting the Asset Type) are notified by mail to the user.

Asset Instance Subscriptions

On activating notifications to an Asset Instance, RepoPro sends email notifications to the user about all the changes made to the subscribed Asset Instance (including changes to Overview information, Parameter values, and Relationships, renaming the Instance, deleting the Instance, adding a version, editing versions, or deleting a version). The user can change subscription status (by enabling or disabling notifications) for an Asset Instance from its View/Edit <Asset> Instance screen.

Taxonomy Subscriptions

When a user subscribes to a Taxonomy node, the user receives notification for the following changes to the Taxonomy nodes by email:

  • Whenever the Taxonomy node is assigned or unassigned to Asset Instances
  • Renaming or deleting Taxonomy nodes

For instructions on Subscriptions, visit: Subscriptions.

3.10. Gamification

RepoPro includes gamification elements to increase user involvement, which ensures an up-to-date Repository for the enterprise. The system awards points to users for specific actions, and these display in a leader board on the Home Screen as shown below:

Table 3.5 Gamification Point System
Action Points
Creating a new Asset Instance 5
Creating a new version of an Asset Instance 5
Providing values to an important parameter (first time or update existing value) 1
Providing values for Overview Description (first time or update existing value) 1

3.11. Export and Import

3.11.1. Export

RepoPro allows the user to export data to an Excel workbook. The entire information stored in the Repository can be exported in the form of an Excel workbook. The Export happens as a download to a file with .xlsx extension.

3.11.2. Import

RepoPro supports updating of information in the Repository through its Import Excel feature, which uses the data in an Excel workbook to do the import.

Users can use the following three methods for importing data:

  • Full Import: the Excel file content is updated into the Repository by updating those records that are in the Excel sheet and exist in the Repository, deleting those records missing in the Excel sheet, and creating those records present in the Excel sheet but not in Repository
  • Incremental Update: for a selected set of records in the Repository, updates are performed. Neither new records are inserted nor existing ones deleted
  • Incremental Insert: a set of new records is inserted in the Repository without disturbing other existing records

The workbook should, however, be in the same template and format (i.e., with .xlsx extension) as was obtained through the Export Excel option discussed earlier. RepoPro sends the Import status via email to the user that did the Import. RepoPro validates the entire Excel file uploaded as per the rules described below, and updates the database only if the entire file is valid in all respects. In addition, all the updates are made as a single transaction. Once an Import is triggered, another Import cannot be taken up until the first one is complete.

The below general rules apply to the Import Excel feature (for all the three Import options: Full Import, Incremental update and Incremental Insert):

  • The file uploaded should be an Excel workbook with an .xlsx extension.

  • When the XLSX file refers to “File” type Parameter with files to be uploaded, the actual files and the XLSX file can be zipped together and uploaded.

  • Parameters cannot be added or deleted for an Asset Type through Import Excel.

  • Users are allowed to modify only the Parameter values for Asset Instances.

  • Relationship definitions cannot be added or deleted through Import Excel.

  • Relationship names used in the Excel file must match the Relationship defined in the Repository.

  • For non-versionable Asset Types, Version name column must be “NA” in Asset Attribute sheet.

  • For versionable Asset Types, version name column must be in the “x.y” format in the Asset Attribute sheet.

  • Asset Instance Name, Version Name, and Overview column can have maximum lengths of 100, 10, 10000 characters respectively.

  • Versions cannot be added through the Excel Import feature.

  • Parameter values in Asset attribute sheet must have valid parameter values, like so:

    • Date type: in DD/MM/YYYY format and Year Range in 1900-2999 range with leap year validation.
    • File: a file with the name provided must be uploaded, zipped together with the Excel file.
    • List: must be one of the valid list elements applicable for the Parameter.
    • Text: must match size restrictions.

  • Derived Attribute, Derived Computation and Derived attributes for Asset List values are excluded from the Import procedure.

  • LDAP attribute mapping parameter is included for an import procedure.

  • Taxonomies: provide the list of Taxonomies for the Asset Instance, separated by commas. Ensure that all Taxonomies are assigned. If it is an existing Asset Instance, the assigned Taxonomies prior to Import are over-written with the one provided in the imported Excel file. The Taxonomies assigned to the Asset Instance mentioned in the Excel file are validated against the Asset-level settings. Provide the path starting from root and ending with node name to be assigned: e.g., country/India, type/paid. The Taxonomies must match with those defined in the Repository.

  • Tags: provide as a comma separated list not exceeding 50 characters. If the Asset Instance is an existing one, the Tags assigned prior to Import are overwritten by those provided in the imported Excel file.

  • LDAP userlist: The LDAP userlist can be imported via spreadsheet. The format FirstName (UserName) / String can be specified in a new column during the data import. If the search data retrieves no result or more than one result, it is considered as an invalid search. If the search data retrieves exact one result, the same value is updated.

  • Asset Instances cannot be renamed through Import Excel.

  • Duplicate records are not allowed, both in the Attributes sheet and Relationships sheet.

  • Source Asset name, Source Asset Instance name, Source Asset Instance Version name, Target Asset name, Target Asset Instance name, Target Asset Instance Version name must have max length of 30,100,10,30,100,10 respectively in the Asset Relationship sheet.

  • Source and Destination cannot be same Asset Instance for Association and Classification Type in Asset Relationship sheet.

  • Relationships between Asset Instances can be created through the Excel Import feature by adding a row with the correct details, subject to the below:

    • Destination Asset Instance must not exist in the Repository for Composition or Aggregation Relation.
    • Destination Asset Instance must exist in the Repository for Classification and Association Relations.
    • Source Asset Instance must exist in the Repository. It could be a new Instance added through the Attributes sheet also.
    • If Relationship Type is Composition or Aggregation, the Destination Asset Instance version name must be 1.0.

For method-specific rules and instructions on Export and Import, visit: Import/Export Excel.