Hi all,
I have a requirement to integrate JIRA with BMC Remedy. The basic requirement would be when a remedy ticket is created, a new JIRA ticket is created. No further integration is required at this stage (eg amends/cancels etc do not need to be done).
Has anyone had any experience with doing this? Or does anyone have any pointers on how to achieve this?
Community moderators have prevented the ability to post new answers.
Thanks Dieter - that definitely sounds like something to investigate. Would it be easy to write a script which could extract parts of the automated emails into custom JIRA fields (eg the Remedy ID into a field in JIRA, the Remedy ticket contents into the description field etc)?
Apologies for the questions, I am a newbie to scripting using the JIRA API.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The built-in email processing is simple, it only really handles new issues and commenting on existing ones. You'll need to do some coding to do anything more complex, although I'd highly recommend a look at the advanced email handler (JEMH) which can handle parsing into fields, updating status and so-on.
https://marketplace.atlassian.com/plugins/com.javahollic.jira.jemh-ui
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The Jira email handler already does a basic job and puts the subject of the email in the summary system field and the mail body in the description.
To process this information further, i recommend the Groovy script runner plugin. Just add a groovy post function to the create transition which parses the raw issue information in summary and description and initializes the fields you need. This create transition is automatically executed when a new issue is created no matter how you create the issue (using the user interface or by the mail handler).
There are some general hints in this question https://answers.atlassian.com/questions/14326/groovy-post-function-on-create-transition-can-t-set-custom-field</p<>>
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks all for your help - We have the Groovy script running installed already, so i'll probably start experimenting with that one before looking at JEMH. First step is to get our MS Exchange administrators to enable POP/IMAP for a new mailbox on the exchange server - that sounds like a more difficult task than the scripting ;)
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Simone, I am interested in the same process as you described in your post. Issues will be created in Remedy & we want them to then automatically create a JIRA ticket. Then once the JIRA ticket is updated, for it to then go back into Remedy & update the status there as well. Any info that anyone has woudl be greatly appreciated.
Thanks!
Amanda
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have there been any updates on this? I need Jira to create/update tickets in Remedy...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No real change. I've not seen any new add ons or software that would do it.
I suspect it's mainly because Remedy is now "legacy" software - there's little money to be made writing niche software to push data into systems that are on their way to the scrapheap.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Nic, tell us how you really feel about Remedy ;-) Actually, for use cases of 50K tickets/day I can see people still using Remedy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd better not... Well, in public.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Nic,
I am currently investigating Remedy and already have JIRA.
I understand that without my own integration implementation it is not possible.
I am wondering about your statement of remedy being legacy, could you hint me to a few topics?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In the last five years, I have seen around 30 sites using Remedy. All are moving away from it. I don't know of any development or support sites considering adopting it, it's ruled out at the first hurdle. Even the large corporates that are pretty much wedded to it consider it "legacy" even though it's deeply embedded and in use - although most of them are keeping it for assorted reasons, no-one is expanding their use, they're prefering more appropriate tools and a bit of light integration.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
can anyone explain how to use the email solution from Remedy smartIT to Jira? I dont see a email console in Remedy to use so emails can be transitioned to Jira tasks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Remedy has an inbound email engine that can create an incident automatically. Once an incident is created you can use the solution below as an OOTB integration w/ Jira.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would like folks interested in such flows between Remedy and Jira to checkout- BMC Multi_Cloud Service Management for OOTB flow to create an issue in Jira from a Remedy incident (synch comment or status) and create a change in Remedy from a Jira issue. Plase check out-
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Wow, that's complex. Wouldn't it be easier to just move to Jira Service Desk?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There are a tremendous set of ITSM capabilities that are available in Remedy. Even for service desk, theres huge capability gap that exist.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Still easier and cheaper to move off a legacy system than spend time on this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Absolutely, it can create a Remedy ticker from a JIRA issue. It is a cloud based service that is as simple as a plug-in with UI driven contorls to modify the OOTB behavior.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not a developer, but I found these APIs
Has anyone tried to use these for integration?
http://remedylegacy.com/tools/restful-api-plugin/
https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, there's thousands using JIRA's REST API for "integration". It works very well once the "integration" is clearly defined.
For Remedy, less so. It's being abandoned in favour of, well, um, software that actually works...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm working on this same problem but have chosen a different approach; since one of my goals is to spread usage of JIRA within my company, I figured that if Remedy would want to talk with JIRA, other apps might want to as well.
Rather than a point-to-point integration, I'm using web services as the conduit.
Our needs are as follows:
We are using WSO2 ESB to expose the web services, and because it can handle JSON natively, it turns out to be a nice fit. I'm sure other ESB products like Mule would work just fine as well. It turns out that there are some limitations in our current production version of WSO2 ESB (4.6.0) in handling JSON that have been addressed in the latest version (4.8.x).
To create an issue, Remedy will post a SOAP message to a service endpoint, and the ESB will translate this to the proper JSON message and submit to JIRA's REST API endpoints. The response is translated to a SOAP message and then posted to an endpoint exposed by Remedy.
The list of JIRA projects is done through a GET call to JIRA. Because the top level of the response is a JsonArray, we had problems with WSO2 ESB 4.6.0 (it can't handle such messages). Remedy calls this service as needed.
As for JIRA notifying Remedy, I am using EventListeners in a JIRA plugin. Because the ESB and/or Remedy can be down from time to time, the listeners simply get the required information and store the data using ActiveObjects, and then a custom service will pick up the data and post to the ESB and mark as sent (or delete) when complete.
Now this last bit is causing me some grief, and I posted a question about it.
As for why we chose the ESB approach which, at first, seems like more work, take the above needs and replace the word Remedy with any system you want., as many times as you want ... I already have another use case in mind that will add a lot of value to this work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I can see the argument for having a common interface for other systems. My experience of using Remedy SOAP directly with a JIRA service a few years ago was pretty ugly - hard to change, hard to debug, not fully documented. I hear things have got somewhat better since.
One painful part is when admins change the name of JIRA custom fields or the options in a select custom field without realizing what this does to the integration. Another tricky part is notifying JIRA admins when there is a problem with the integration that needs attention. It can all be done, just needs careful planning and lots of work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Thomas,
Please let me know whether your Remedy to JIRA integration is completed successfully. I am a Tibco ESB guy looking for integrating Remedy and JIRA...do you have any inputs/suggestions/documents for me to start with it. Thanks in Advance
Thanks
Abdul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Thomas,
I'm very interested in your solution as well, mind to elaborate on the result of the project? How did it go? Did you hit any obstacles?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi guys.
I am on the same problem: having JIRA and Remedy to talk.
As of now I have found this document that summaries all the application programming interfaces available to developers to access Remedy. Between them, Java is recommended. However, also Ruby is present and might be an alternative good for JIRA.
https://communities.bmc.com/communities/docs/DOC-17512
Given this open "breach" into Remedy, I am now wondering what would be the best way to "lead" bidirectional communication, needed "just" for tickets created from Remedy (i.e. once the ticket gets updated from Remedy, then notify JIRA; when the corresponding JIRA ticket is updated/moved over the workflow within JIRA, then update Remedy).
Any idea/best practice? Thanks a lot.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.