Automated request fulfillment overview

Service Desk and Asset Manager provide extensive integration between themselves and Ivanti Endpoint Manager (LDMS) through Ivanti Process Manager (LPM). Together, these applications enable you to include features such as automated request fulfillment and software deployment as part of your standard service delivery:

To enable this integration, you add a behavior to an object so that each time an instance of that object is created, updated, or deleted, a call is made to a web service that includes a set of configurable parameters taken from your database. This web service is then read by LPM, which processes the data and acts on the information provided. When LPM has completed its workflow, it sends a set of values back to Event Manager that include data to identify the original process, so that it can progress the original process appropriately.

Alternatively, if you are integrating with a process tool that cannot interface with a web service, you can add a behavior to an object so that each time an instance of that object is created, updated, or deleted, an entry is added to a Queue table (tps_event_queue). This table can then be read by your process tool, which processes this data and acts on the information provided. When your process tool has completed its workflow, it returns a set of values to the inbound Events table (ev_event). These values include data to identify the original process, so that Event Manager can progress the original process appropriately.

In the previous chapter (Configuring Event Manager), you learned how to configure Event Manager to integrate with external applications (such as the SolarWinds Orion network management tool) to create and then progress processes. In this chapter, you learn how to configure Event Manager to progress processes that it had not created itself by creating an Integration Process Source that identifies and processes values in the inbound Events table that originate from LPM.

1 – in Service Desk or Asset Manager, a user clicks an action that creates an object with the behavior Web Service. This automatically calls a web service method that includes an identifier for the specific process instance and other configurable information that can be used to direct LPM.

2 – an LPM web service listener reads the web service call.

Alternatively, a user creates an object with the behavior Event Generator, which adds an entry into the tps_event_queue queue table that can then be read by an LPM database listener in a similar manner.

3 – LPM fulfills the service request using the data sent to it, either using Active Directory actions or by using other products that have LPM web interfaces, such as Ivanti Endpoint Manager.

4 – LPM calls the Event Manager web service's SendIntegrationEvent command, which identifies the original process instance and provides other appropriate data that Event Manager can interpret and act on.

5 – Service Desk or Asset Manager reads the SendIntegrationEvent command and processes the data returned by LPM.

6 – the process continues according to the information passed back by LPM. For example, you could design the process to proceed via different paths depending on whether the LPM actions succeeded or not.

There are four steps to integrating with LPM:

  1. Create and configure the object and action that will be used to initiate the service request. For more information, see Linking to Ivanti Process Manager using a web service, or Sending information without using a web service as appropriate.
  2. Design the process that you want to use with the above object. For more information, see Process Designer.
  3. Set up LPM to have the required web service listener, workflows and integrations with Ivanti Endpoint Manager. For more information, see Designing the LPM workflow and refer to the documentation provided with LPM and Ivanti Endpoint Manager.
  4. Set up the Integration Process Source in Event Manager. For more information, see Creating the Integration Process Source.

Request Management processes and queries that incorporate examples of much of this functionality are described in the Prebuilt Content document; the rest of this section describes how to implement request functionality in the Request Management module.

For more information about the Web Service behavior, see Linking objects to Web Services.