Thanks Jason,

I have another file that contains more detailed information for 
installation/configuration as well as the create_incident script and sample 
rule/config files and the directory structure for implementation. It's pretty 
close to a drop in install. You would just need the box to put it on. I won't 
be officially supporting the package but I'll help as much as I can since it 
benefits me to have more than just my eyes on it. I'd be interested in finding 
out what, if any, changes are necessary for the version.

Thanks,
Ron

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Friday, March 01, 2013 10:59 PM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy Integration with other Ticketing systems

**
Very cool!  I really like the approach you detail.  Today we build all of the 
rules and processing in AR workflow.  I think we need to look into using 
Procmail since we haven't started to (re)build email integration with our new 
out of the box system.

Jason

On Fri, Mar 1, 2013 at 9:35 AM, Peters, Ron 
<rpet...@columbia.com<mailto:rpet...@columbia.com>> wrote:
**
Fortunately I already had our system pretty much documented for support 
purposes. I did some cleanup and posted it. The document posted is an overall 
design with use cases.

Thanks,
Ron

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Jason 
Miller
Sent: Thursday, February 28, 2013 11:21 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: OT: Remedy Integration with other Ticketing systems

**
Hi Ron,

It sounds like you have some great knowledge and experience with email 
integration and using Procmail.  I know time is an issue for many of us but it 
would be great if you would be able to create a 
document<https://communities.bmc.com/communities/community/bmcdn/bmc_atrium_and_foundation_technologies/choose-container!input.jspa?contentType=102&containerType=14&container=2002>
 in the in AR System section of the BMC Communities.  This topic sounds like 
something many people would benefit from having a document to follow and some 
sample use cases.

Jason


On Thu, Feb 28, 2013 at 8:20 AM, Peters, Ron 
<rpet...@columbia.com<mailto:rpet...@columbia.com>> wrote:
**
I'd echo everything said below for the pros and cons. We heavily use email 
integration and the OOTB email engine primarily for incident creation and 
routing. I moved all the email decision making and ticket creation logic out of 
Remedy and use Procmail which is designed for the task. I have a single script 
that is used to generate a ticket though the ticket can be fully customized and 
assigned directly based on the variables used when the script is called. I have 
dozens and dozens of rule sets that are used for many different reasons and 
implementing new ones is fairly trivial. The system processes through ~5000 
messages a week.

Automated messages from UPS's around the company can auto create tickets for 
their support team if the right message comes in or simply ignore and drop the 
message. Monitoring systems send messages that are routed to other groups. 
Messages from end users sent through special distribution lists auto-route to 
the proper support group (Asia, Europe etc.). Tickets are created for specific 
customers or a faceless default account depending on the need. Any message that 
shows up and doesn't have a specific rule that applies generates a ticket for 
my team to investigate. I don't want to miss anything. I've eliminated (so far) 
all the mail loops through a set of system rules (drop messages coming from 
Remedy etc.). All this from primarily a single script that is tightly 
controlled. The business has become very aware of what we can do and I commonly 
get requests for more integration in other areas.

Hope that helps and if you're interested, let me know.

$.02

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Brittain, 
Mark
Sent: Thursday, February 28, 2013 7:21 AM

To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: Re: Remedy Integration with other Ticketing systems

**
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<mailto: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.
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

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

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

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

Reply via email to