By: Dave Theodore, Atlassian Team Manager
In our recent webinar, I received a number of questions around nFeed and how I set up the integration. In the interest of security, I decided not to demonstrate nFeed with Coyote Creek’s internal systems. Rather, I set up a database to simulate the type of integrations that we commonly perform with nFeed. This is a brief article on how I set things up and the configuration of nFeed.
Note: the webinar and the content of this article pertain to nFeed version 5.12.4 and Jira 7.7.1, which are the current versions as of this writing. As new versions come out, this process may change.
I created a database instance in MySQL and added some fake data to it. The schema consisted of one table with three columns: username, location and phone. I then populated some data to use for the demo.
I then was able to create some simple SQL statements in order to fetch data that I needed. For the use case in the webinar, I needed a “Location” and “Phone Number” field. That meant one query for each field. Here’s an example of the query I based the “Location” field query on.
When you do this, you’ll need to identify the tables, columns, relationships, etc in order to design your queries. The process is similar for querying a directory service, such as Active Directory, but you will use AD Filters in order to obtain the data you intend to populate in the nFeed fields. You can also query remote APIs and even text files, such as CSV files. If you use text files, just be aware that you have no ability to query, since there is no technology to support querying or filtering, like you have in a database. Now that our data is in place and I know how to query it, I move on to the configuration of nFeed and its fields.
nFeed comes with number of built-in custom fields. You simply add the ones you intend to use as Custom Fields and then add them to the appropriate Screens in your Screen Schemes and Workflow Transitions. (related Atlassian documentation for this process.)
In my example in the webinar, I chose the “nFeed” field type, as it provided the function that I needed. Once I had the “Location” and “Phone Number” fields created, I moved on to setting up the Data Source. The rest of the nFeed configuration is done in the Add-ons section of the Jira Administration interface under the “NFEED CONFIGURATION” section. Since I’m connecting to a MySQL database, I needed to install the MySQL JDBC driver in Jira and restart. This is the identical process you follow if you are using MySQL as your Jira database. With that in place, we can configure our database. We just need to add the information about the database, such as host, username/password and instance name.
Once that is done, we can move on to configure the fields themselves. You will see that there are fields to configure when you open the “Configure Fields” panel in the nFeed configuration interface. Click “Configure” and the select the MySQL data source that we just added.
In my example from the webinar, I wanted to take advantage of nFeed’s built-in variables to perform a query based on the person opening the JSD Request. In Jira, this is called the “Reporter,” and the nFeed variable that corresponds is “$issue.reporter” We don’t want to risk someone changing the database or users experiencing errors, so I made the “Editor” option “Read Only.” I made no other configuration changes. I simply saved the configuration and tested the results.
The way this configuration will work is that the nFeed “Location” and “Phone Number” fields will now use the “$issue.reporter” variable to pull in the username of the person opening the request (shown as the “Reporter” in the Jira Issue) to execute the query. For example, if Jennifer Evans, username “jevans,” opens a request, the nFeed field will run the following query:
select location from details where username = 'jevans';
The result is that the Location and Phone Number for Jennifer are displayed in JSD requests that she makes, and this will help our Desktop Technicians resolve her requests faster!
nFeed is a very powerful App for Jira. We work with it quite often to pull data in from a variety of types of systems. This example is fairly simple, but very often these integrations are quite complicated. I recommend that you develop your configuration in a test environment first! Once you have everything working the way you like, then migrate the changes to your production Jira.
If you would like to view a recording of our recent Jira Service Desk Webinar, you can view it here.