Please could you provide detail on it ?
Please could you provide some details on it.
It totally depends on what you want to achieve through the integration ie. if Incident Created/updated in Remedy it also needs to be created/updated in SNOW or vice versa. You can use web services.as we know Remedy supports SOAP web service and Rest (from 9.x onward and only allow to publish) but there are some third party tools and with those you can even consume Rest services in remedy. as far as I know service supports both Rest and Soap.
Check below link it has some additional info as well
Thanks Sharvan for your kind response.
We are on remedy 8.1 & requirement is regarding bidirectional integration with service now so its REST API only via web service.
If possible please could you provide high level approach to achieve it.
Also i have already traversed through the links you provided but not much helpful.
Early response will be highly appreciated.
1 of 1 people found this helpful
In remedy 8.1 you wont be able to publish Rest though you can consume Rest in remedy through Restful API Plugin – A Programming Legacy
So let experts confirm if there is any other way around may be some sort of connector or building a middleware which can use remedy SOAP web service and convert it to Rest for SNOW to consume
Thanks Sharvan for your kind response.
i believe we can achieve the bidirectional Service Now integration with Remedy 8.1 via SOAP Web Service.
If anyone any provide high level approach to achieve it , please suggest?
3 of 3 people found this helpful
I am not a SNOW experts but i will try to help. from remedy point of view below are the details
Before starting with this you need to know what operation you would be performing. Lets take an example if requirement is
1. create a ticket in SNOW when a ticket is created in Remedy and update when remedy ticket updated.
2. Create a ticket in Remedy when a ticket is created in SNOW and update when SNOW ticket update.
You may prefer to create a staging form for the integration. below is high level design
for use case 1 mentioned above
1. Publish a SNOW web service and then consume that web service using Set field(web service) Filter in remedy. so in case of staging form when a ticket is created you would be pushing required fields which you want to pass to SNOW on your staging form. then from your staging form write filters which will call SNOW WS and pass details. you will need SNOW ticket number in return which will be used as identifier for update or other approach could be create a new field on SNOW side which will hold remedy incident number and you can use that field in qualification for update
2. For update you need to decide when an update will be sent to SNOW lets say when status is changed or in some other condition. accordingly you can push fields on your staging form and from there you will call SNOW update WS(assuming you would be using 2 Web services, one for creation and second for update) to pass necessary details to update SNOW ticket.
3. You will need a temp field on your staging form lets say z1D_Action and you would be pushing CREATE when you are creating a new ticket and UPDATE when you are updating an existing ticket. this field can be used as qualification in filters which are calling SNOW web service.
For second use case:
1. You can create WSDLs on your staging form for CREATE and SET operations and SNOW would be consuming these web services
2. you have to write workflows on your staging form to push(create/update) a record to respective Interface forms (ex. HPD:IncidentInterface_Create or HPD:IncidentInterface) according to CREATE or SET operations
Thanks a ton Sharvan for your detail info.
For sure I will work out on it also PFB query on it:-
1. How to check that both the system’s requests should be in sync i.e there should not be parallel update on Incident at a time from both the systems like if remedy already closed, it should not allow Snow to send further update & status transition should be in sync in both the systems.
2. According to you which one is the most feasible solution ….a. To Publish remedy WS which can be consumed by SN or b. To consume SN WS to be consumed by Remedy.
3. Also how to maintain the status transition in Remedy & SN.
4. Also we are trying to achieve it for all requests via SR so how to approach for the same as SR can raise INC, WO as well as Request at the backend in remedy.
2 of 2 people found this helpful
1. This is something you need to agree upon. Both systems can technically update ticket at the same time. I would suggest using custom fields as flags.
2. Publish and consumption of WS are fairly easy inside Remedy, I do not know how it is inside ServiceNow. Consumption of SN WS would take out some resources from Remedy to process requests.
3. You need to map all the necessary info for status change inside Remedy and SN and send them with the new status
As I understand, you are mirroring two systems (Remedy and SN both need to have the same information at all time).
Thanks for your kind update Igor.
Please could you address Point 4 as well & will be highly grateful.
For point 4, I am not that familiar with ServiceNow. I presume that if there is SR, INC, WO and RF inside ServiceNow, then you should create separate transitions (one for INC, second for SR ... ) for each.
Thanks for your kind response.
We are discussing only from remedy point of view.
My query here is that the requirement is to trigger the integration only for remedy Incidnents but the Incidents are getting created only SR & SR also create WOs.
So how to classify that the bidirectional integration should work only for those SRs in remedy which is creating Incidents & not WOs?
If you only need to pass the Incidents, then the trigger should be the creation of the incident in HPD:Help Desk form.
Thanks Igor for your kind update.
I will try it & will update shortly.