Project 31-A

One of my current projects is getting data out of Jira into a DataMart to allow fast (and easy) analysis. A library such as TechTalk.JiraRestClient  provides a basic foundation but there is a nasty gotcha. Jira can be heavily customized, often with different projects having dozen of different and unique custom fields. So how can you do one size fits all? You could go down path of modifying the above code to enumerate all of the custom fields (and then have continuous work keeping them in sync) or try something like what I do below: exploiting that JSON and XML are interchangeable and XML in a SQL Server database can actually be real sweet to use. Modifying JiraRestClient The first step requires downloading the code from GitHub and modifying it. In JiraClient.cs method   EnumerateIssuesByQueryInternal add the following code.                 var issues = data.issues ?? Enumerable .Empty< Issue >();       ...

One of the pains with using REST is getting the data from JSON into something usable. There is a very simple solution:  Take the JSON, pass it to a magic black box and get a dataset back that has foreign keys and other joys.   That sounds very nice -- Make the JSON REST call and then Query or filter data tables to do future processing. No need to define classes to deserialize the JSON into..... The code is horrible and shown below... using System; using System.Linq; using System.Data; using System.Xml; using Newtonsoft.Json; namespace Avalara.AvaTax.JsonUtilities { public static class Utility { public static DataSet ConvertJsonToDataSet(string jsonText, string rootElementName) { var xd1 = new XmlDocument(); xd1 =JsonConvert.DeserializeXmlNode( jsonText,rootElementName); var result = new DataSet(); result.ReadXml(new XmlNodeReader(xd1)); return result; } } } To put this...

A while back I was contacted to solve a quasi-nasty issue. An existing REST implementation had been updated with an extra field being added to the response. This worked fine for 99% of the consumers, but for one consumer it broke. This consumer wrote a package that they sold on to others and their customers were screaming. The reason it broke was that it was not coded to handled additional fields. Technically, REST is an architectural pattern without standards . Robustness in handling extra fields and data is what most developers would expect -- but that is not a requirement of REST. It is hopeful thinking. If the REST was well versioned, this issue would not have arisen. It did arise. While this consumer can patch their code, getting the patch to all of their customers was problematic hence there was a need to do an immediate fix, somehow. Fortunately, their package allows the REST Url to be specified and that allow a simple quick solution. Create a "Relay Website" up ...