|
A service that runs at regular intervals is a much wanted feature in any web application. It is more so if it is one that can be managed with user configured parameters and without having to reboot etc. JIRA offers a mechanism to add new services on to it that runs at regular intervals after every start-up. It lets us do things related to JIRA and things independent of it. It lets us integrate with third party applications. It lets us do wonders!
There are built-in services in JIRA. Export Service, POP Service etc to name a few. Here we are going to see how we can add a custom service on to JIRA
26 Comments
I thought I would attack this topic next given its growing popularity in the forums !. So why is this so popular? The context is pretty much given in the earlier tutorial for creating a SOAP client. There are at least a couple of ways for extending the given, out of the box SOAP capabilities of JIRA. Those will be writing an RPC plugin (thanks to JIRA for giving that option) and re-building the RPC plugin.
There are so many user stories for this one! How do you override some of the JIRA built in actions? How do you do some additional stuff in the JIRA built in action? Like doing some crazy things immediately after creation before the page return to the user? Or doing some innovative validations on some of those actions? Or do what is asked in this thread ?
Here is the simple answer to all those questions. Extends the JIRA actions using the webwork plugin module. There could be some alternatives in few cases (like handling it in a listener) but not always.
We have seen how to write a custom field in one of the previous tutorials. Writing the field is one thing but making it available to one of the JIRA's most powerful functionality, i.e. Search, is another!
So how do we do that? In most cases, you wouldn't need a custom searcher. Instead you can use the built in custom field searchers in JIRA itself. The list includes, but not restricted to, Text Field Searcher, Date Searcher, Number Searcher, User Searcher etc.
Creating an Issue in JIRA from other applications, like custom built UI for instance, is a common behaviour. It is pretty easy because JIRA provides us with the SOAP or XML/RPC interfaces. SOAP is recommended as it supports more operations which you might be using along with the Create!
Creating a JIRA SOAP client is pretty easy and is detailed in my previous tutorial. I am going to assume that you have the client created and a sample test done to ensure you are connected to your JIRA.
It is very obvious! If you are reading this, you must be knowing how important it is to have an external interface for JIRA and how Atlassian helps by providing a SOAP interface. In an enterprise, or even in small companies for that matter, we often end up integrating JIRA with multiple systems. Creating a SOAP Client is a recommended and easy solution in such scenarios.
In fact, JIRA enables remote access through both SOAP and XML-RPC. SOAP is recommended because it covers more operations!
In this tutorial, let us have a look at workflow validators. If you have gone through our workflow post function and condition tutorials, this should be damn easy!
Workflow validators are specific validators that checks whether some pre-defined constraints are satisfied or not while progressing on a workflow.The constraints are configured in the workflow and the user will get an error if the same is not satisfied. A typical example would be to check if a particular field is present or not before the status of the issue is moved to a different status.
In this tutorial, We attempt to take you through creating workflow conditions. If you have gone through our workflow post function tutorial, it going to be a breeze!
So what are workflow conditions? They determine whether a workflow action is available or not. Considering the importance of workflow in installations and how there is a need to restrict the actions either to a set of people, roles etc or based on some criteria (Eg: the field is not empty!), writing workflow conditions is inevitable.
Hope you all enjoyed the custom field tutorial! If you haven't got a chance and is interested, have a look here.
Let us now look at workflow post functions. Workflow post functions are very effective and heavily used. They allow you to do a lot of things when you progress on the workflow on an issue. Lot of customizations and work arounds take this route! And hence I am hoping this tutorial will help you wee bit in getting there!!
Well, I have chosen this as the first topic because of the most obvious reason. This is what most of the people will start with. That is one reason why there are lot of customfield plug-ins around! No matter how many are there, you will need a new type. You always do!
Given the context, let me make a huge assumption - You know how to create a skeleton plugin! If not, go to here and do it before you continue! |
AuthorJobin Kuruvilla - Works in Adaptavist as Head of DevOps Professional Services. Categories
All
Archives
October 2016
|
RSS Feed