CentraSite Documentation : Getting Started with CentraSite : Implementation Concepts : Customizing Your Asset Catalog : Issues to Consider when Customizing Your Registry
Issues to Consider when Customizing Your Registry
CentraSite provides many ways for you to customize the asset catalog. After you install CentraSite, you should customize the predefined asset types provided by CentraSite (if necessary) and create new types, taxonomies and association types as required for your site.
Note:  
Although you should do the initial customization after CentraSite is installed, you can always add additional asset types, taxonomies and association types as you develop the need for them.
When customizing the catalog for your site, keep the following points in mind:
*You can customize any of the predefined asset types installed with CentraSite by adding attributes to them and/or modifying the content and organization of the profiles associated with the type.
*If you have an asset that is not represented by one of the predefined types provided by CentraSite, you must create a custom asset type for it. If you want users to be able to generate the asset type from an input file, you must also create a custom importer for that type and register the importer in CentraSite.
*Consider using Classification attributes and Relationship attributes instead of ordinary String attributes whenever possible. Among other benefits, these attribute types enable users to more easily discover assets and understand the relationships that an asset has with other objects in the registry.
*In general, use a Classification attribute or an enumerated String instead of an ordinary String attribute when you want the attribute to be more strongly typed.
*Instead of defining multiple asset types to represent variants of the same basic type, consider creating one basic type and using a classification attribute to differentiate them. For example, instead of creating separate asset types for different kinds of Web services (for example, business services, technical services, security services), use the one basic Web service asset type and use a Classification attribute to classify its variations.
*When you are designing a new asset type, think about the design/change-time polices that you might want to apply to assets of that type. If you need to apply different policies to different sub-sets of the asset type, use a Classification attribute to differentiate the sub-sets.
*If you do not want users to be able to assign ad hoc classifiers and/or associations to instances of a particular type of asset, omit the Classifications and/or Associations profiles from that asset's type.
*If a taxonomy is designed to be used with specific types of assets, specify those types in the taxonomy's Applicable to Object Types tab. This will prevent users from using the taxonomy to classify objects with which the taxonomy was not intended to be used.
*You can define taxonomies with multiple levels of sub-categories to create very fine-grain levels of classification. When you do this, users can search for assets that are classified by a specific category or any of its sub-categories. For example, the Service Type taxonomy shown in the figure below would enable users to locate a specific type of technical service (for example, a Utility or a Network service) or all technical services (that is, all services that are classified by the Technical Services category or by any of its sub-categories).
*If you are working in a multi-stage environment, always master your custom asset types, taxonomies and association types on one stage and export them to the other stages. Do not attempt to define these objects manually on each stage.
Copyright © 2005-2015 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback