Own SOAP endpoint in Jira 6.x?

[Karol Kleibl]

For integration purposes i'd need to create a SOAP webservice to create and update JIRA issues.

Since the SOAP support was dropped in JIRA, i'm thinking about creating a plugin that exposes such interface. What kind of plugin module should i create (since the RPC endpoint plugin module is deprecated)?

Or should i take completely different approach?

Thank you for your answer.

Karol

[Volodymyr Krupach]

I would start with JIRA rest plugin module https://developer.atlassian.com/docs/atlassian-platform-common-components/rest-api-development/rest-plugin-module and pack SOAP calls there. Just a guess, you need to try .

[Jobin Kuruvilla [Adaptavist]]

I agree. SOAP is gone from 7.x

[Nic Brough -Adaptavist-]

I wouldn't even try wrapping SOAP calls into it. Use REST, and create a REST module to cover any functions not (yet) exposed by Atlassian's REST implementation.

[Karol Kleibl]

hi thanx for the responses. the SOAP interface is a requirement for the integration scenario and i can't change it to REST. my first idea was to create an external adapter application exposing the required SOAP interface and translate it to Jira REST calls. but i wanted to investigate also the possibility to run that adapter as a Jira plugin, so that it can benefit from the same URL (protected by the same SSL certificate) and the same runtime.

[Nic Brough -Adaptavist-]

SOAP is a method of doing something. When you say "it is a requirement", that's wrong because it's never a requirement. A requirement is "we need to do X". Never "we need to do X using Y". SOAP is the wrong way to do this. Do it with REST, even if you have to write a translator to take SOAP calls from your other application and issue REST ones, that way, you won't have to bin everything and start all over again on the next upgrade. And you'll be supported.

[Karol Kleibl]

sometimes it is a requirement. for instance now. ;-) i have a paying customer that requires to integrate his issue tracking/helpdesk system with our jira in the same way as he did it before with other partners. he requires us to implement the interface he gave us and it is SOAP. if there would be some room for discussion about it, i'd deffinitely propose to use s REST interface myself. unfortunately this is not possible and therefore i'm looking for the easiest way how to implement the custom SOAP <> REST adapter. thanks for your responses so far

[Nic Brough -Adaptavist-]

Nope, it's still not a "requirement", it's a "constraint". Your "requirement" here is "integrate the issue tracking/helpdesk system". You are now constraining yourself by saying you want to stick to the old deprecated way of meeting the requirement. That's fine, but whenever you see a constraint like this, you should ALWAYS question it. It's absolutely not a requirement, but something that forces you into doing more work that you really shouldn't have to. The right, and best approach is to make the systems work properly with REST. A less good variation on that would be to write an intermediate wrapper, where your old systems can issue their deprecated calls and it translates them into supported REST calls for JIRA. A second right approach is to provide something in JIRA that will enable the old interface to work - to do that, write your own SOAP addon to provide it. But I wouldn't do this. Although this is still a "right" approach, it's definitely not a good approach because it requires significant development time, introduces massive dependencies for ALL systems which will kick you on any upgrade, and it's not supported by your application vendors.