How CAI plugin works in server group?

Version 2
    Share This:

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


    Remedy IT Service Management Suite


    BMC Remedy IT Service Management Suite


       How CAIevent plugin works in server group?  
       BMC Remedy Action Request System  
       Solaris 10, ARS 7.5 , ITSM 7.6  



    Legacy ID:KA325419

      The CAI events form is used by the CAIFilterPlugin which is mainly used by SRM. It is mainly used to integrate the ITSM apps with SRM. When you create an SRM request, entries will be pushed to CAI:Events/Eventsparams to tell the CAI plugin to do some work. The CAI plugin is then pinged to tell it there is work there and to action the entries. It then uses HPD:incidentInterface to update or create an Incident if it is an SRM:Request that should cause an Incident to be created based on the rules defined for Incident Management.  
          So it is a way to farm off work to this filter plugin to tell it to create Incidents, Change records etc. based on SRM requests.  It also works other way around too, If you create an Incident, the ITSM rules might say it should create an SRM:Request and CAIPlugin will do that work too.  
    If someone updates the worklog on either the SRM:Request or on Incident/Change etc then the update is pushed to the other related record (to SRM:Request or to Incident/Change and vice versa).  
    So it's really a way to keep two sets of records in-step based on the ITSM rules.  
        The activity by the CAIFilterPlugin will show up in the server logs as 'Remedy Application Service'.  
    So, if you have a system configured where creating an Incident causes an SRM:Request to be created then turn on full server-side logging and submit an Incident. You'll see the push entries to CAI:events form and then 'Remedy Application Service' kick in and update the records accordingly.  
          In general, plugins are not part of the failover and should not be. Each arserver in server group has one or more companion plugin servers (C and Java) running on it. The plugins that run in these plugin servers typically do work that is tied to the local arserver. For example,  for AREA plugins,  when a user logs into an arserver, it should connect to the local plugin server rather than connecting over the network to a shared pluging server,  for efficiency.  
    Same goes with ARDBC plugins.  It is more efficient for each ARDBC plugin to reside on the same system as the arserver so they the data involved doesn’t make an extra trip or 2 over the network.  
          CAI PLugin is an ARF plugin that runs in a filter.  Again, it’s important for it to run efficiently by running on the same system as ARServer and not on remove arserver. And therefore, the plugin server is not a managed operation in the Server Groups setup. This does make sense when you recall that managed operations are not failed over unless the owning ARServer fails to update the intervalCount in the servgrp_board table;  that it is evidently down.   We would never failover simply because the plugin server is down.  
          As far as workload distribution is concerned, the work is distributed by virtue of the User load distribution.Plugins can do work other than that which is triggered by user activities, such as Escalations, AIE, etc.   But again, those activities can be manually distributed. 
           Also, since threading on the plugin servers can be controlled hence load can be dirstributed across multiple threads in a single server. The design of the Plugin server allows a Plugin server to reside on a remote system. It also allows multiple arserver to connect to a  shared plugin server.But these setups are not generally useful and do not help with stated goal.  And also are not a part of the Server Group design. 


    Article Number:


    Article Type:


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