Email is the easiest to implement and troubleshoot. Polling can be an issue if 
you are doing a hot handoff where your customer is tier 1, you are tier 2 and 
the their end user's phone call will be transferred to you. Even if polling is 
1 minute on each end that can seem like eternity.  The other advantage of email 
is simulation. Typically in a  web services approach you are not going to have 
access/control end to end. You can send the email from your desktop mimicking 
the customer/process, see any error messages and verify any custom workflow. 
Email is also better if you are having periods of downtime. The incoming email 
will be in the mailbox until the Remedy server comes back up. In the case of a 
web service the SOAP call fails and the request is gone. The down side is the 
polling and security. Also there is the perception that email is low tech, and 
not reliable (AKA not cool).

The biggest shortcoming is going to be the other ticket system. I have worked 
with Remedy, NimSoft, Service Desk Manager, and Service-Now and each has its 
own challenge.  If they are using a shared/on-demand version then 
customizations on their end are difficult to impossible. Attachments can be 
tricky. Data lengths can be an issue where your fields are shorter than their 
fields. If you have data length or required field conflicts you might want to 
consider a staging form where you take their request, massage it and push to a 
new ticket. If you use a staging form have workflow push the ticket number back 
to the staging form because your response back to the customer is from the 
staging form.

If an incoming email can update your ticket, and you send email updates to 
their tickets, beware of auto-replies. My biggest fear is a email loop. I 
handle this two ways, outgoing updates are from a bogus email address so it 
won't come back at me and incoming update workflow includes $USER$ != "Remedy 
Application Service" in the qualilfication.

Hope this helps

Mark


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Steve Kallestad
Sent: Wednesday, February 27, 2013 11:58 PM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy Integration with other Ticketing systems

** There's no best-practice that's globally correct across all potential 
applications.

If there's a canned solution for a particular vendor, then that's the one to 
use 9 times out of 10.

Email is good because it has built in store-and-forward and failover 
mechanisms.  Email is bad because it introduces points of failure that may not 
be in your control and it can be slow.

There are several options, but the most utilized would be geared towards either 
Web Services or API level integration - ensuring that server side workflow 
processing, permissions structures, etc. are all handled.

Between remedy servers, DSO (Distributed Server Option) is most frequently 
used.  On occasion, people just use custom designed workflow.

It's always good practice to utilize an abstraction layer so that an upgrade on 
one side of the integration does not necessarily mean an upgrade on the other 
side of the integration.

Integrator is based on 
Pentaho<http://www.pentaho.com/explore/pentaho-data-integration/> so that can 
be used as an integration mechanism as well - although I haven't played with 
integrator a whole heck of a lot just yet.

On Wed, Feb 27, 2013 at 7:24 AM, Christine Milton Hall 
<christine_milton_h...@pepperidgefarm.com<mailto:christine_milton_h...@pepperidgefarm.com>>
 wrote:
**
Hi everyone - It is has been a while...

Looking for some feedback on integrating external ticketing systems with our 
Remedy Environment. (currently 7.5.1, windows platform)


1.       What is the most common and best practice method?  Right now the most 
requests seem to be requesting the utilization of email notifications with 
other external systems.

2.       How difficult is it integrate with another non-Remedy environment?

3.       What would be the worst case and best case in work effort/duration?

4.       Is there any pitfalls that I should be aware of if we move towards 
this type of solution?

Any guidance or thoughts would be greatly appreciated!

Thanks!
c

*************************************************************************************************

This e-mail and any files transmitted with it may contain confidential 
information and is intended solely for use by the individual to whom it is 
addressed. If you received this e-mail in error, please notify the sender, do 
not disclose its contents to others and delete it from your system.

*************************************************************************************************
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

________________________________
This e-mail is the property of NaviSite, Inc. It is intended only for the 
person or entity to which it is addressed and may contain information that is 
privileged, confidential, or otherwise protected from disclosure. Distribution 
or copying of this e-mail, or the information contained herein, to anyone other 
than the intended recipient is prohibited.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to