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> 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] *On Behalf Of *Jason Miller > *Sent:* Thursday, February 28, 2013 11:21 AM > *To:* 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> 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_ **** > > ** ** > > _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"
