3 Replies Latest reply on Feb 13, 2019 9:31 AM by Hector Vijande

    BMC_BaseLement Status field vs AST_Attribute Status field

    Mahamadou Traore

      Hi Folks,

       

      I would like to know the process of synchronizing the field status in BM.CORE Forms vs AST Forms. Some of our CI records have different value for status in BMC.CORE vs AST Forms.

       

      From my understanding, by default CI is created in BMC.CORE with the values ''0''. As soon as any join  field coming from BMC.CORE:BMC_BaseElement is updated from AST Form, the status field in BMC.CORE is update (Sync) to the value of the status in corresponding AST Forms.

       

       

      Best Regards

        • 1. Re: BMC_BaseLement Status field vs AST_Attribute Status field
          Mohammad Rehman

          Looks like you are mixing the two, Status field was moved to AST:Attributes from 8.x and no longer exist on BMC.CORE classes anymore.

          When you "by default CI is created in BMC.CORE with the values ''0'' " i believe you are mixing it with ReconciliationIdentity.

          • 2. Re: BMC_BaseLement Status field vs AST_Attribute Status field
            Mahamadou Traore

            Hi Mohammad,

             

            I am not ttalking about ReconciliationIdentity, I know this field is different that status field. Status field is in BMC_BaseElement. It is just hidden (See screentshoot)

            AST:Attributes Form has also status field (See Screenshot). When we create a new CI either from Atrium, the status is ''0''. When promoting to BMC.ASSET, the corresponding status in AST Form will have ''3'' Deployed. Then when update any field from Asset console that is from BMC.CORE, a this point the status is synch (remember it was 0 in BMC.CORE) to the status field to AST Form.

             

             

            Hope it is more clarified now.

             

            Thank you

            • 3. Re: BMC_BaseLement Status field vs AST_Attribute Status field
              Hector Vijande

              Hi @Mahamadou:

               

              Since the separation of the Asset information fields from the strictly CMDB data, in 8.x, AssetLifeCycleStatus became an asset only piece of information.

               

              We still keep the 'Status' field in CMDB, in the BMC.CORE class forms because is needed, and to avoid users creating a field with the same name.

               

              From the CMDB perspective, there are only two possible statuses for a CI: is either active or not:

              • If the CI is active (meaning any discovery tool is able to scan it ) the default status is 'Deployed', and its MarkAsDelete flag set to 'No', or $NULL$
              • If the CI is no longer found, the MarkAsDelete flag would be set to 'Yes', and workflow will change its status to 'Delete'. ( you  can test this, how the status changes just by changing the value of 'MarkAsDelete' in a test record)

              This feature allows CMDB to dispose or 'soft delete' records no longer found by a discovery in the source datasets.

               

              From the Asset Management perspective, there are many other possible statuses than just 'Deployed' or 'Delete'. A CI could be in Inventory, or being assembled, etc.

               

              Both status fields, 'AssetLifeCycleStatus' and the BMC.CORE 'Status' one are not synched bidirectionally. CMDB will synch if the record is 'Deployed' ( when MarkAsDelete is set to 'No' or is null ) or if it has been flagged to be deleted, but does not know about other statuses, like Asset does.

               

              Hope this explains a bit what you are seeing.

              4 of 4 people found this helpful