might be a possibility depending on what your 3rd party tool is capable of.
If you can hand back some details to store in your 3rd party system after the web service call, you want so hand over the GUID of your ticket. Then you will be able to use the Integration Source in Event Manager for updating any ticket you want using your 3rd party tool, as long as you tell Service Desk the GUID of the ticket that you want to update. But I don't think that your 3rd party tool is capable of storing the GUID, otherwise you might not have asked???
The second best option:
Using a Network Source in your Event Manager with multiple actions to fire can work, but it is prone to some problems and errors if you're firing a rapid succession of web service calls to your Service Desk.
You can define more than one action, but you have to identify them using an attribute, that needs to come from your 3rd party tool.
For example we're using a monitoring tool that fires web service calls every time a Server, VM or network device is down and it will fire again if the system is recovered. Therefore we're using three attributes to identify what to do:
- Event Source - it's always the same value "MONITORING" that comes from our tool, so Event Manager (EM) will know it is from our monitoring.
- Event Type - it states if a system is down ("DOWN") or if it has recovered ("RECOVERY"), so we can distinguish between New Process (ticket) for DOWN or Add Note for RECOVERY
- Config Item - our monitoring tells us the name of the system causing the problems
So if there is no open ticket and a new event with type DOWN comes in, then Service Desk will open a new Incident in our case. If the action "Add Note" is still available in the status the ticket is waiting, then the type "RECOVERY" will add a note to the existing ticket. If there is no open ticket or the action "Add Note" is not available at the current status, then the action in EM will fail.
So as you can see, there is plenty of room for errors...
I'd normally recommend using the PostEvent method but as the EM will only poll every minute at minimum, this will not work properly if there are more than one event to the same Config Item and with the same Event Type. This will cause duplicate errors. I guess you will have to use the SendEvent because it does not depend on the polling interval and will send the event directly into the Service Desk. Just check on the current PDF for administering the EM, there you will find a description how to set up your EM for distinguishing between two or more actions. You'll find it in the documentation (help.landesk.com).
I hope I could help you understanding the EM a little bit better and to set you on the right track to get your web service calls up and running.
Many thanks for responding this.
Let me comment in order the 2 options that you have explained :
First option: Yes, The 3rd party tool is able to store the GUID or at least the reference number of the created ticket on LDSD. What should I provide for the 3rd party to be able to
retrieve this information? Is there a way to call a web service that returns the GUID for the last created ticket for example ?
For me, all the question is here : How to provide the 3rd party this unique identifier of the incident created by the first call (web service for creation)
Second option : Actually I use an integration source on EM to allow creation of ticket by the 3rd party tool.
When the 3rd party tool call the WS it specifies theses parameters (not all the list because i pass some other parameters)
- Source ="Monitoring"
- Type = "CREATION"
- Title = "Title of incident in the 3rd party tool"
- External ID = the Id of ticket on in the 3rd party
I added a new action (Add note) and my idea is to propose another call based on Type ="UPDATE" to add a note on the concerning ticket. But I need to set on Mapping the Id of the created incident (here is my problem)
In the example that you mentioned, if you have 2 or more open tickets with type "RECOVERY" and then you call WS with type "DOWN" which ticket is updated in this case?
I agree with you that SendMessage is better for real time treatment but this will impact perhaps performance (in the official EM document, PostEvent method is more recommended)
as for the first option:
Yes, there is an option to call a webservice from within the Service Desk.
If you have a test environment, I'd recommend that you add a new collection to the Incidents and add the behavior "WebService" to the new object. With that behavior the object will be able to call a web service using SOAP. For a more thorough explanation see the current designer guide PDF (page 40). You can find it at help.landesk.com
If your tool is capable of distinguishing between new and update information, you'll be able to set the Type to "UPDATE" for example. Then you'll only need to configure a second action using the same attributes, but recognize the type "UPDATE". Then you add a new note to your Incident. In addition you have to make sure, that the action Add Note is available in every status, in that you like to get notes added.
So in the end you'll have one integration source and two actions (New Process and Add Note), being distinguished by the type.
Hope it helps!
Curious as to what you came up with for this. We are in the same boat.. Can create tickets from 3rd party via WS but looking to pass back the ID for ticket updates Thanks
1 of 1 people found this helpful
I have found that the solution is based on understanding the behavior of EM (Event Manager) when parsing the ev_event table.Let me explain :
When EM is parsing the ev_event it will looks for all events where ev_is_procedded =0. then For each entrie EM will looks for parameters configured into the event Source that identifies the unique entrie
For example, in my case I have set as unique-identifier theses parameters :
- Event type
- External 3rd party Incident Reference.
With this manner, EM will found each time (When Conditions matchs event created under action) the matching ticket created on Service Desk A unique one will be updated !)
be sure to save the 3rd party Incident Reference on an event parameter on ticket creation
I hope that this post will be helpful and sorry for my french screenshots -;)
1 of 1 people found this helpful
Sorry for the long reply. I hope it helps.
As you will already know there are 2 types of Event Manager source
Integration Process Source will only let you update tickets. You cannot create them.
This identifies the ticket to update by its GUID.
The external system MUST know the GUID of the ticket you are trying to update. The guid can be sent using a collection object with the ‘Web Service’ behaviour added. This can be configured as an automatic action in your process which sends a Web Service Call to the external application. The external app will need to be configured to receive the web service call and accept the GUID.
Network Source will let you create tickets.
It can also update tickets it has created, but not any ticket in the system.
This identifies the ticket to update using a combination of ticket attributes which make it unique from any other ticket in the system.
For example, as mentioned in a reply above, this could use
The creation event creates a ticket and sets the CI.
You now have an open ticket for the CI.
An update event can then be sent with a different Event Type and the same CI.
Event Manager will check if there is a current open ticket for that CI and this is the ticket it will update.
In your case, it sounds like you could use the Network Source with the following being the attributes which define the Incident to update.
- Create the Network Source.
Parameter 1 will contain the reference number of the external app and be mapped onto the ticket so that it can be used to identify the ticket to update later.
The external app must be configured to send its ref number as Parameter 1
2. Define the Event
3. Setup the Mapping (Parameter 1 into External Ref)
Event Source = External App
Event Type = Create
External Ref = 1234
This will create the ticket. Make sure you map External Ref to an attribute on the ticket.
4. Now setup a Process Action in the Network Source. Here I have created Add Note
5. And the mapping
Event Source = External App
Event Type = Update
External Ref = 1234
This will look for a ticket with External Ref = 1234 and if it is not Closed, it will Add Note on the ticket if that is the action you have configured it to do.
You must make sure that the Add Note action is available in the Process at the status
the ticket is at.
Thanks for the reply but let me back up a little bit. Basically we are looking for a 2 way street. We have a 3rd party company that monitors our network after hours and create tickets based on issues that may pop up. They use Service Now. We gave them access to our WS to create tickets in our SD system from their system.
Basically how this works
1- The third party creates the ticket in their Service Now environment
2 - The workflow in their service now creates a Ticket in our SD via Event Manager This works flawlessly Now we want to be able to pass info back when needed from Service Desk to the 3rd party system. They provided us with a access to their WS((https://xxxxxxxxxxxx.service-now.com/incident.do?WSDL) In following the documentation in designer( page 40)
so this is as far as we have gotten. Are we on the right track? How do i get the parameters for the WS listed? is this even possible?
I am not a Web Service expert but as far as I know there are 2 types. Simple and Complex.
Simple Web Service have all of their parameters defined at the top level. So for example as soon as you connect you can see the parameters.
Complex have their attributes grouped into folders. In this case, you would need to navigate into a folder to see some of the attributes. Navigate into another folder to see more attributes. Kind of like windows explorer.
Service Desk can only send data to 'Simple' web services.
So if ServiceNow has a 'Complex' web service, you will not be able to see its parameters from within the Service Desk web service business object.
Yep, had the same problem. The LanDesk salesman told us that they integrate with ServiceNow all the time. Then when we hired them to develop the integration process. 2 months later, they said it couldn't be done.
I ended up creating a web service that LanDesk could talk to. LanDesk consumes it and passes in all the parameters needed. The service then packages it up into the format that ServiceNow understands and sends it to them.
It is an extra step, but it works.