I hope this blog helps you.
Please comment on it in case you have any questions so that there will be more information when someone looks out for that blog.
2 of 2 people found this helpful
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.
Hope this helps.
2 of 2 people found this helpful
although a little older, the concepts are the same in the later versions of SRM:
This document will show how the CAI is designed and fits together.
3 of 3 people found this helpful
BMC Service Request Management uses CAI to integrate with backend applications, such as BMC Incident Management and BMC Change Management. CAI is a subcomponent that is used to run commands on external systems. CAI uses a command definition (a type of template) to construct commands using the parameters sent to it by BMC Remedy ITSM.
The CAI plug-in is a filter API plug-in which is triggered when entries are created on the CAI:Events form.
Used to communicate between SRMS and backend applications (e.g. Incident and Change Management).
CAI Application Registry (CAI:AppRegistry) - defines backend application connection information (server, login, interface forms, template forms, etc)
CAI Commands and Parameters (CAI:Commands, CAI:CommandParams) – defines commands and command parameters; there is a 1-many relationship between commands and command parameters
CAI Command Parameter Mappings (CAI:CommandParamMapping) – defines mapping between command parameters and backend applications
CAI Plug-in Registry (CAI:PluginRegistry) – specifies the number of threads and the private server queue to be used for the CAI Plug-in.
Run time CAI Forms:
CAI Events (CAI:Events) – specifies the event to be processed
Inputs needed by CAI plug-in:
EventType – Create, Get, Update or Decrypt Password
Execution Mode – Asynchronous or Synchronous
Target Server, Login, Password, Port # – connection info for backend application; if not specified the Remedy Application Service account is used
Protocol = AR (must be set to AR to use CAI plug-in); other options are URL, Webservices, Command Line, Plug-in, Other
App Interface Form – name of backend application form
Access Mode – Local or Remote
Max Retries – number of times to retry event if there is an error
Direction – Outbound or Inbound (outbound is from SRM App, Inbound is the reverse)
Event GUID – GUID used to tie Event to Event parameters
Return Code – “Warning”; used with SYS:Action form to ensure all data is committed before calling plug-in
Outputs from CAI plug-in:
Return Code – OK, Warning, Error, Running, Start (OK = success, Running = plug-in is processing event, Error = an error was received during processing, Start = used to retry event, Warning –not used as an output)
Return Message Code – Error code returned (can be AR error number or Application message number)
Return Message – Error message text received from either AR or application
Example: Creating a fulfillment request from SRM
SRM-->AOI-->CAI-->CHG,HPD Interface forms-->CHG:Infrastructure Change, HPD:Help Desk