To register a new item (such as a tag) for progress, it is necessary to first create a new class definition (or identify an existing class definition) and then map to the hierarchy.
-
Identify the class to make progressable (or create a new class if one does not exist).
-
Ensure that the class definition realizes the following interfaces:
-
ISPFPrgProgressItem
-
Either ISPFPrgDesignItem or ISPFPrgActivityitem
-
ISPFPrgRegisteredItem
-
-
Ensure that the class definition has access to all objects that constitute a progress hierarchy level, for example, DevTagContract new relationship definition.
-
Ensure that the forms for the class definition expose display items for Progress Weighting and all the properties and relationships that make up the hierarchy. See also How to Configure the GUI Model.
-
To retrieve the values for the hierarchy levels of the item registered, create mapping relationships between the properties that represent the hierarchy levels and the relationship definitions or properties that can be used to get the information.
Example
If a tag is not progressable and we wish to make it so, we need to create a route to all its hierarchy values by either:
-
Creating a relationship definition between the tag and each hierarchy level.
-
Creating a mapping relationship between the hierarchy properties and the properties on the object being registered.
If Tag has no relationships to Contract, Area and Unit; however, Unit DOES exist on the Tag object as a mandatory property, UnitForTag:
-
A new relationship definition between Tag and Contract would need to be created (DevTagContract).
-
A new relationship definition between Tag and Area would need to be created (DevTagArea).
When Tags get created, the user can specify a Contract, Area, and Unit for the Tag.
To enable Progress to know which Workpack a Tag would be registered to, it must be told how to obtain the Tag's values for Contract, Area, and Unit at the point that the Tag is registered. This is achieved through mapping relationships.
The Hierarchy Interface (in this case, ISPFPrgHierarchyH1) has exposed properties that correspond to each of the hierarchy levels - SPFPrgHierarchyContract, SPFPrgHierarchyArea, SPFPrgHierarchyUnit.
-
To enable the system to obtain the value of the Tag's Contract, the SPFPrgHierarchyContract property must be mapped to the new DevTagContract RelDef, by creating an instance of the SPFPrgPropertyDefMapsToRelDef relation between the SPFPrgHierarchyContract property (end1) and the DevTagContract RelDef (end2). The SPFPrgPropertyDefMapsToRelDef relationship definition has a link interface on which the direction of the expansion from the tag being registered to its contract must be set.
-
To enable the system to obtain the value of the Tag's Area, the SPFPrgHierarchyArea property must be mapped to the new DevTagArea RelDef, by creating an instance of the SPFPrgPropertyDefMapsToRelDef relation between the SPFPrgHierarchyArea property (end1) and the DevTagArea RelDef (end2). The SPFPrgPropertyDefMapsToRelDef relationship definition has a link interface on which the direction of the expansion from the tag being registered to its Area must be set.
-
To enable the system to obtain the value for the Tag's Unit (which exists as a property on the Tag), the SPFPrgHierarchyUnit property must be mapped to the UnitForTag property by creating an instance of the SPFPrgPropertyDefMapsToPropertyDef relation between the SPFPrgHierarchyUnit property (end1) and the UnitForTag property (end2).
Since it is likely that more than one class definition will be registerable, different relationship definitions would be needed to expand from the registered item to get the hierarchy values. For example, where a Tag gets its contract by expanding the DevTagContract relationship definition, a Design Document would get its contract by expanding the DesignDocumentContract relationship definition.
Therefore, each of the hierarchy properties may well be mapped to a number of relationship definitions or properties. In order that the correct relationship definition is found, the system analyzes each of the mapping relationship that it finds from a hierarchy property and checks which way the expansion is configured. If the expansion is end1-end2, then each relationship definition at the other end of a mapping relationship is interrogated to see if the end1 interface appears on the item being registered. If it does, then this is deemed to be the correct relationship to expand to find this particular hierarchy level. If not, then the next mapping relationship definition is analyzed in the same way. If the expansion is end2-end1, then the process is the same except that the end2 interface on the relationship definition is used for the comparison.
Therefore, one relationship definition or property definition should be found for each hierarchy level.
If a relationship definition is found for a hierarchy level, this is expanded from the item being registered in the specified direction, and the name of the object at the other end is considered to be the value for that particular hierarchy level.
If a property definition is found for a hierarchy level, the value for it is retrieved from the item being registered. This value is then considered to be the value for that particular hierarchy level.
Register a tag summary
-
Find hierarchy properties.
-
Expand mapping relationships from properties.
-
Obtain correct mapping relationship by checking if the appropriate interface indicated as UID1 or UID2 on the relationship definition appears on the item being registered.
-
Expand retrieved relationship definition from the item being registered in the given direction.
-
Add the value for the name of the object on the other end of the relationship to the workpack query.
-
If no mapped relationship definitions are found, check to see if any mapped property definitions are found.
-
If so, AND if the retrieved property exists on the item being registered, get the value and add it to the workpack query for the hierarchy level.
Creating a new activity class
An Activity is represented by an interface definition, which can therefore be realized by any class definitions (such as purchase order, supplier activity, and so forth) that represent activities whose progress must be monitored.