In TSCO, the system type previously set by an ETL is being overwritten by another ETL that runs afterwards

Version 1
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    TrueSight Capacity Optimization


    COMPONENT:

    Capacity Optimization


    APPLIES TO:

    TrueSight Capacity Optimization 10.7, 10.5, 10.3



    PROBLEM:

    Scenario:

    There are two different ETLs importing data from a third party data source sharing same SYSID. So, for example you may have a Solaris Ldom machine that is also a Database server and there is an OEM ETL configured to get database metrics related to the partitions where the database instances are installed. Also, there is a VIS parser ETL collecting performance metrics from the same Solaris machine. 
    Due to this configuration, the machines lost their system type (Solaris LDOM machine) when the OEM ETL is run afterwards as it overwrites the type to Database. This caused that Solaris machines and partitions cannot be accessible from the Virtualization View as it cannot recognize the systems as a Solaris Ldom machines.

    Question:

       
    • Is there a way to maintain the system type previously set by the first ETL without allowing the second ETL to change the entity_type?

     


    CAUSE:

    The second ETL 'wins' by modifying the system_type when it runs, so it changes the type to its nature in order to pull the data into BCO


    SOLUTION:

    The reason for the above mismatch is caused due to hierarchy transaction. The name of an entity is set by OBJ-REL. OBJ-REL checks for the difference between the current transaction and all other transactions for both the entities that have been asserted and the relationships. It compares them to the previous entities that have been asserted in the relationships and if something is changed it in the entities, it applies to the hierarchy. To resolve the issue the system types A and B designated by the last ETL executed has to be retained.
     
    In order to force the system type to be retained and not overwritten by the last executed ETL, you can use the ‘Authoritative Mode’ setting in the Object relationship hierarchy rule. 

       
    1. Go to Administration >DATA WAREHOUSE >Hierarchy rules
    2.  
    3. Find the hierarchy rule associated with the ETL that you want to keep the system type and select it.
    4.  
    5. Click edit and select YES for ‘Authoritative mode’ (See image1 below)
    6.  
    7. Perform a restore relationship on this rule to restore system type for historical dataType declared by vis ETL will be forced. This closes all the object-relationships and it rebuilds the entire relationship tree based on the current and latest object-relationships that have been imported.
    8.  
    9. Execute the  ETL again to update the name of the systems. 
          
      User-added image
    Image1: Set Authoritative mode on the ETL
     
     
      
      
      For the OEM ETL there is a new parameter which needs to be added to accomplish the change for using Authoritative mode when a user wants another ETL like the BMC - TrueSight Capacity Optimization Gateway VIS files parser and have the OEM ETL not update the entity type after the hierarchy is run.   
     
    To allow this change for the OEM ETL improperly updating the entity type we have added an ETL property which the user can specify in the OEM ETL and set the value to false.   
     
          ETL property -    extract.specify.databaseserver.entity.type  
          Set the value of the property to    false.   
     
    Note:Database server type to be deprecated from 11.5 Sp2 for OEM ETL. 

     


    Article Number:

    000121181


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles