Virtual Hierarchical Subject Areas / Virtual Applications

Note: this page is available to everyone, but the actual implementation details have been omitted.  If you are a RoAccess customer or are in the process or Evaluating RoAccess, click here to get the FULL details.

This page addresses:

  • What is a Hierarchical Subject Area (HSA)? Click here.
  • What is a Virtual Hierarchical Subject Area (VHSA)  (Virtual Hierarchical Application)? Click here.
  • Limitations of Hierarchical Subject Areas. Click here.
  • What is the Theory Behind RoAccess Virtual Hierarchical Subject Areas? Click here.
  • How Do I configure a VHSA? Click here.
  • Runtime considerations? Click here.
    • Once you understand the underlying fundamentals of standard Rochade Item Versioning coupled with the ease of RoAccess Virtual Hierarchical Subject Areas, you will be able to do things you never dreamed of being able to do with your Rochade Repository.
     

    What is a Hierarchical Subject Area?

    The Rochade Repository has "Item Versioning" as a basic part of the database engine.  If you create a Hierarchical Subject Area, you can create a "search order" for requests for those Items.   The Subject Areas and Projects (Applications) are "stacked" on top of each other.  The "highest" application is searched first, then the second, all the way to the last application.  The Item that gets returned is from the first application in which it is found.  (Actually Projects now have much less value, because a Project for most purposes is basically a two level HSA.)

    Autopilot allows you to define the "application hierarchy", that is which applications to search and in what order.   In Rochade terms, it provides a method to specify the "configuration path", which is the ordered list of all Applications to search and in what order.

    The implementation of Rochade Hierarchical Subject Areas is a creation solely of Autopilot.  They are NOT a basic part of the database engine.  Actually, the Rochade database engine does not know what a HSA is!  Autopilot is merely an application that has decided to use the basic Item Versioning capability of the database engine in a very structured and somewhat overly complicated way, and they call them Hierarchical Subject Areas..  It also has a number of limitations that may make life cycle administration costs prohibitive.  If you don't understand versioning, you then might like to use a HSA just because Autopilot offers it or you might find that HSAs the way Autopilot implements them is just what you need.

    But once you start using HSAs, you may well find that it may be overly complicated for you needs and the potential administration needs way beyond your ability or time/financial constraints     But it seems that in most cases it is overkill and more involved that you would like.  You will start wanting more flexibility and control over your applications.

    The nice thing is that you do not have to use Hierarchical Subject Areas at all to do Item Versioning.  Since Item Versioning is a basic feature of the database engine, you can create your own Item Versioning mechanisms or approach.  Hence, RoAccess' Virtual Hierarchical Subject Areas.

    What is a Virtual Hierarchical Subject Area (VHSA)  (Virtual Hierarchical Application)?

    A HSA, as Autopilot defines them,  is basically a way to specify the configuration path for each application.  But you need to use Autopilot, and sometimes it's a bit tricky or non-intuitive.  What you would like is to be able to define the various application hierarchy trees via the WEB using a standard browser by merely updating Items as usual.  This way, you don't have to learn anything new or different to configure and manage the Virtual Hierarchical Subject Areas.  Easy to learn, easy to administer, and easy on your support budget.
     

    Limitations of Hierarchical Subject Areas

    The names of all the applications must be the same.  Only the application version can be different.  This means the application name becomes almost irrelevant, which is a shame.  You would like to be able to us any arbitrary application name and version.

    Once an application is in the middle of a HSA, you cannot delete it.  That means it must stay there, even if you no longer have a use for it.  If you have hundreds of Applications, you don't want old, "dead" applications lying around taking up disk space.  You want to get rid of them.

    Suppose you frequently create Subject Area named like "Current_Metadata_03/04/2002" and so on, based on the date.  But you always want your users to be able to open the most current Subject Area always using the same name.  (That is, their book marks would never change.)   Interesting problem for a Rochade HSA.   But it's easy for RoAccess.

    Any time you want to change the hierarchy, you have to use Autopilot.  Using Autopilot from home over a modem to access a repository at work is really slow, and you certainly don't want to be disconnected in the middle of a HSA structure change!

    Suppose you have a multi-level tree with lots of branches and branches that have branches.  Suppose you would like to move an entire node (sub-tree) from one node to another?  With Autopilot HSAs, you can't do it.
     

    What is the Theory Behind RoAccess Virtual Hierarchical Subject Areas?

    When you send a query to Rochade, if you specify the order of Applications search (configuration path), then that is the same that Autopilot uses when querying a HSA.

    RoAccess Virtual HSAs use only simple Subject Areas and Projects.  You do not need to use Autopilot HSAs.  That is part of the beauty and simplicity of this approach.

    RoAccess allows you to specify the configuration path for each Subject Area and Project. This differs from Autopilot because in Autopilot each simple Subject Area only has a "work configuration", whereas in RoAccess it can also have a configuration path! You merely use a standard RoAccess screen to enter the configuration path into a "system ItemType" that you want to be in force for each application.   That's it!  You merely type in the order of applications to search, and its done.

    When RoAccess subsequently opens that Application, it looks to see if you have specified the configuration path to use, and if so, that is the configuration path that is used.  It's that easy.

    How Do I configure a VHSA?

     (sections deleted for general viewing...)

    Example:

    Suppose you have 4 Applications:
  • Metadata_2/4/2002  (configuration 1034)
  • Metadata_2/7/2002  (configuration 1055)
  • Monthly_Maintenance_3/1/2002  (configuration 1061)
  • Emergency_Maintenance 3/3/2002  (configuration 1065)
    • Subject Area Metadata_2/4/2002 is the production metadata as of 2/4
    Metadata_2/7/2002 is the production metadata as of 2/7 because a scanner was run in the background and automatically imported
    Monthly_Maintenance_3/1/2002 Has the metadata for applications, scripts, copybooks, procs, libraries that are being changed as part of monthly scheduled maintenance.
    Emergency_Maintenance 3/3/2002 was created to handle a serious bug that needed to be corrected immediately, and could not wait to be part of the Monthly_Maintenance_3/1/2002 set of enhancements/bug fixes

    You want to be able to view the metadata from Emergency, but you need to take into account any changes that Monthly Maintenance may be doing as well as what the metadata was in 2/7 and finally 2/4 if Items were deleted in 2/7 in error and need to be picked up from the 2/4 Subject Area.

    How to you create this Virtual Hierarchical Subject Area?  Easy.

     (sections deleted for general viewing...)

    You have in effect created a Hierarchical Subject Area, but in seconds.  You can also change it just as fast.

    Suppose the emergency change takes longer than a month, Monthly_Maintenance_3/1/2002 is over and empty, and the results are transferred to a new Subject Area Metadata_4/1/2002  (configuration 1121), and a NEW Monthly_Maintenance_4/1/2002 (configuration 1170) is being used.   If you were using standard Autopilot Hierarchical Subject Areas, it would be a problem.  But in RoAccess, you now merely only change entries in the USE_CP text attribute which Subject Areas are in the path, and you are done.  Easy!
      

     (sections deleted for general viewing...)
    You have done what would be considered a restructuring in seconds!  Simple, easy, clean.

    Suppose now that you have hundreds of Subject Areas, for test, production and development, for various dates, for separate data loading, separate data validation, and such.  How can you reconfigure to handle this changing environment?  Easy.  Merely use these same steps above.  It takes only seconds to configure and test your Virtual Hierarchies.  This will save you time and money, plus make everything self documenting.


    Gateway Applications

    Suppose you want to have a Subject Area named CURRENT_PRODUCTION_METADATA INITIAL, and you always want your customers and users to only open that Subject Area but always get the latest metadata, when the REAL current metadata is stored in different Subject Areas that change over time?  It's easy:

     (sections deleted for general viewing...)

    Subject Area CURRENT_PRODUCTION_METADATA INITIAL has become  a "gateway application" re-directing you to where you are supposed to go.
     

    Note: this page is available to everyone, but the actual implementation details have been omitted.  If you are a RoAccess customer or are in the process or Evaluating RoAccess, click here to get the FULL details.