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> 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] *On Behalf Of *Brittain, Mark > *Sent:* Thursday, February 28, 2013 7:21 AM > > *To:* 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 <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> 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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
