4 Replies Latest reply on Jan 23, 2020 12:19 PM by Thad Esser

    Tracking Control-M Jobs in the CMDB

    Thad Esser
      Share This:

      Hello,

       

      I've been tasked with tracking Control-M jobs in the CMDB and I'm seeking advice on which CMDB class would be the best for extending into a new sub-class?  I am not, at this point, concerned with integrating the two systems, although that may be something we tackle down the road.  We already have the data in a bespoke application (not Remedy) and existing processes to keep the data up to date, we're just moving it into the CMDB.

       

      I've been searching the docs and communities for anything related, and the closest I've gotten is "Batch Discovery", which might have had a useful extension, but appears to have been deprecated a while ago.  Does anyone recall/know which class that extension used as its super class?  The "Mapping Your Data to CMDB" spreadsheets I could find didn't cover it.

       

      So, what would be the best class (and why) to extend for tracking Control-M jobs?

       

      Thanks in advance,

      Thad

        • 1. Re: Tracking Control-M Jobs in the CMDB
          Sateesh Kulkarni

          You could use Application Service class as is or can create subclass and name it as Jobs and use it for storing Control_M Jobs.

          The reason because, Application Service is something which is used to represent low level module of an Application. Here in your case Control-M is an Application and each Job is a Application service.

          2 of 2 people found this helpful
          • 2. Re: Tracking Control-M Jobs in the CMDB
            Thad Esser

            Sateesh Kulkarni, that makes sense, thank you.  If I may, I have two follow up questions regarding relationships.  We have most of our Applications mapped via Discovery, so I'm thinking the individual jobs should be related to the application that they support (the jobs don't support "Control-M", they support their specific application).  APPLICATIONSYSTEMCOMPONENT seems like the most fitting relationship name, is that correct?

             

            Also, these jobs have predecessor/successor relationships between them that we want to track, however they aren't technically dependent on each other. 

            For example, if Job1 is the predecessor to Job2, it's possible that Job2 could still be successful even if Job1 failed.  Would you still use the Dependency relationship and just set the HasImpact attribute to No?  Is there an existing relationship that fits better, or do I need to create a new one?

             

            Thanks again for your help,

            Thad

            • 3. Re: Tracking Control-M Jobs in the CMDB
              Sateesh Kulkarni

              The correct relationship class between Application and Application Service is BMC_ApplicationSystemServices.  Yes name can APPLICATIONSYSTEMSERVICES or APPLICATIONSYSTEMCOMPONENT.

               

              Dependency can be used to represent the flow between Jobs,no need to represent Impact and as they all are independent.

              1 of 1 people found this helpful