3 Replies Latest reply on Feb 7, 2020 2:00 AM by Jason Miller

    How to represent bots within the CMDB?

    Shawn Pierson
      Share This:

      We're developing greater detail within our CMDB, focused on things like integrations between Application CIs and other types of dependencies we might need to track for our various processes.  One newer area that we developed a lot of questions about is how to represent RPA (Robotic Process Automation) bots within the CMDB.  My understanding is that these "bots" are similar to a form of integration, but less formalized and rather than going through APIs, simply do what an end user would be doing.  I'll give a high level example that should make sense to Remedy people below:


      Use case:  Monitor an Exchange mailbox, and when an email with a specific subject line is received, approve a Service Request in Remedy.


      Manual Process:  User checks their email, and when they receive one that meets the criteria they open their browser, log into Remedy, and click "Approve" in Approval Central.


      Traditional Remedy Integration:  Use AR Email with RBE in Remedy (or write code to run and monitor the Exchange inbox) that will periodically pull emails into Remedy and if they meet the criteria a Filter updates the approval record appropriately.


      RPA Process:  The bot opens the Outlook client and detects an email that meets the predefined criteria, then opens a browser window and logs into Remedy then simulates clicking "Approve" in Approval Central.  This is similar to how we used macros in Remedy back in 3.x but more advanced.


      From my perspective, this is essentially fulfilling the same function as an integration, so I would have a CI representing "Exchange" and a CI representing "Remedy" (probably both in the Application class for this purpose, rather than Service or Software Server.)  This bot, and any other form of middleware integration, would sit in the middle as some other CI class with relationships showing how the data flows.


      Since this is a fairly new area for me I wanted to reach out to you all and ask these questions:


      1. How do you track bots in your environment?

      2. What class or classes do you use to track bots, as well as other integrations?

      3. If you didn't create a new class, did you add new properties to any existing CI (or relationship) classes?


      Any assistance with this would be appreciated.

        • 1. Re: How to represent bots within the CMDB?
          Ganesh Gore

          I never thought about this or came across anything like this but as a CMDB implementer, I would create Business Service (Logical entity) for each bot. e.g : AutoLoginRemedy will be the Business Serice representing bot in your case and having relationships with other CIs like "Exchange" and "Remedy".

          if bot is performing important number of processes (complex bot) then I would create multiple Business Services for each process.

          I am not sure about the best practice, this is just a thought,

          • 2. Re: How to represent bots within the CMDB?
            Shawn Pierson

            What gets a little more tricky for us is that we don't really consider the bots as a Business Service.  They're closer to being a form of integration, which is the approach I want to take because we use them generally to perform actions based on events in one or more existing Applications that are in support of a Business Service.


            One of the main business drivers for us to track these and other forms of integrations is that we have a highly dynamic environment, and we've identified that one of our biggest areas of risk is around the boundaries of where various systems interact with each other.  In the example I provided of a bot that updates Remedy approvals, imagine if as a part of a Remedy upgrade we forced our users to use Digital Workplace to perform approvals instead of Approval Central in the Mid-Tier.  The back-end integration would likely continue working, and even if not it's something we'd have represented within our CMDB that could be looked at within Change Management.  However, the bot would fail, because the UI changed paths (e.g. it could no longer navigate to midtier/arsys/forms/arserver/Approval+Central/ and would have to go to dwpserver/dwp/app/#/activity and the UI and controls would require rebuilding that bot from scratch.

            • 3. Re: How to represent bots within the CMDB?
              Jason Miller

              The first thing that came to my mind was a Technical Service, which is stored in the BMC_BusinessService class just with a different flag set.


              My next thought is to store them in BMC_ApplicationService since it is some application that is running the bot/integration/daemon/etc and there is a "service" component of that application doing the work.


              This could be the best diagram I have seen of an integration or in your example bot.



              I think Business and technical services models - Documentation for BMC CMDB 19.08 - BMC Documentation is the best documentation on the topic if you are looking to stay in the boundaries provided OOTB.


              Digging a little further I found a previous discussion that also touches on using BMC_ApplicationService as well as creating custom sub classes: Modelling Integrations in the CMDB


              Making my search a bit more broad, I found people on the competitor's website asking the same question: Where do folks see integration and broker service offerings fitting into the CSDM? - Common Service Data Model - Service…


              The conversation on that website doesn't look that different from the one Christian Smerz  and Carey Walker has back in 2016 (Application Service and creating new classes). It amazes me that between two large product install bases, how to model integrations is still a mystery after all these years.


              Looking some more at the CDM you could even go with BMC_Activity or BMC_BusinessProcess

              4 of 4 people found this helpful