Re: Remedy Integration with other Ticketing systems
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.commailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Thursday, February 28, 2013 11:21 AM To: arslist@ARSLIST.ORGmailto: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 documenthttps://communities.bmc.com/communities/community/bmcdn/bmc_atrium_and_foundation_technologies/choose-container!input.jspa?contentType=102containerType=14container=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.commailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark Sent: Thursday, February 28, 2013 7:21 AM To: arslist@ARSLIST.ORGmailto: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
Re: Remedy Integration with other Ticketing systems
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 documenthttps://communities.bmc.com/communities/community/bmcdn/bmc_atrium_and_foundation_technologies/choose-container!input.jspa?contentType=102containerType=14container=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.commailto: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.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark Sent: Thursday, February 28, 2013 7:21 AM To: arslist@ARSLIST.ORGmailto: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
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 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 documenthttps://communities.bmc.com/communities/community/bmcdn/bmc_atrium_and_foundation_technologies/choose-container!input.jspa?contentType=102containerType=14container=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
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 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 Pentahohttp://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.commailto: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
Re: Remedy Integration with other Ticketing systems
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] On Behalf Of Steve Kallestad Sent: Wednesday, February 27, 2013 11:58 PM To: arslist@ARSLIST.ORGmailto: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
Re: Remedy Integration with other Ticketing systems
A lot depends on the requirements of the integration. 1.How does the other system keep track of their open incidents in Remedy 2. How do they add notes to the incident? 3. Can they close or cancel a incident? You can assume they use e-mail but when integrating with another system you have the Email Loop problem you have to solve. I.e. you send an e-mail to create a ticket ... their system responds with a Thank you email which generates another ticket in your system. Gratefully your system responds which creates a ticket in their system Web Services or using direct java api can provide a better interface. You also may want to consider a publish/subscribe solution like webMethods. I would only do that if it is not a point to point integration and multiple systems have to integrate with Remedy. Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org] On Behalf Of Christine Milton Hall Sent: Wednesday, February 27, 2013 10:25 AM To: arslist@arslist.org Subject: Remedy Integration with other Ticketing systems ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
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 documenthttps://communities.bmc.com/communities/community/bmcdn/bmc_atrium_and_foundation_technologies/choose-container!input.jspa?contentType=102containerType=14container=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
Remedy Integration with other Ticketing systems
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. * ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Remedy Integration with other Ticketing systems
Like anything with Remedy, there a bunch of ways to approach it. From email integrations (clunky) to Web Services. First question, Are the 2 systems on the same network? If not, will the 2 networks be able to talk? What version of Remedy? What is the other system? Warren On Wed, Feb 27, 2013 at 10: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_ -- Warren R. Baltimore II Remedy Developer 410-533-5367 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Remedy Integration with other Ticketing systems
1 Webservices is general best, assumes ability to connect which is not always a given 2 how long is a piece of string, if can be simple or complex depending on your requirements. Incidents are much easier then changes/service requests. 3 2-3 weeks to 6 months 4 different statuses flows, differing classifications methodologies esp. Remedy to other ITSM systems, are you sending or receiving, is this an create, update or a resolution. Are there SLA's involved. Are approvals involved, are tasks involved (v complex then). Do you use middleware - I strongly recommend you do on both sides to buffer ITSM apps and comms. Are you a third party, first level or second level desk? Are CI's required if so are they integrated? For BMC use Atrium Orchestrator, other ITSM suites have their equivalent. Even if its Remedy to Remedy I would not recommend a direct interface, especially if it makes API calls - this is not suitable long term as it is very easy to break and hard to upgrade. I have managed heaps of integrations generally there is always a gotcha, with mapping of classifications as the biggest bugbear. Generally this needs to be done on the instigators side but could depending on the design be on the other side. Stuart Schon Service Desk Systems - Manager From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Christine Milton Hall Sent: Thursday, 28 February 2013 2:25 AM To: arslist@ARSLIST.ORG Subject: Remedy Integration with other Ticketing systems ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
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 Pentahohttp://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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Remedy Integration with other Ticketing systems
I prefer to not use email or web services, because at any significant volume, throughput becomes an issue. I prefer to use either the Integrator app or the API calls in a Perl or Java script. Rick On Feb 27, 2013 8:59 PM, Steve Kallestad st...@tabtonic.com wrote: ** 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 Pentahohttp://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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
