Query Configuration For National Weather Service

For the sample National Weather Service Connector project, review the query code generated by the Integration Framework Wizard.

Using Query is the first place where the actual structure of the data becomes important. If you have an example of a response, you can use some tools to generate classes to help serialize and describe the structure of the data.

Start with the code generated by the Wizard.

 protected override IList<HttpQueryRegistration> ConfigureQueries()

      var weather = this.Queries.EnumerateResponseAs<Weather, Rootobject>

            ("/xml/sample_products/browser_interface/ndfdBrowserClientByDay.php", r => r.Items.Cast<Weather>());

       return new List<HttpQueryRegistration> { weather };

The Wizard created a query configuration that expects a Rootobject as the response and enumerates Weather. This is an easy way to deal with the data. However, when we look at the actual data that is returned and use some tools to get serializations built for that data, we see that this particular data example is not ideally suited for the generated code.

Instead, we can generate classes in Visual Studio using the XML response displayed in Analyzing The National Weather Service Connection.

Take the XML response returned when you were Analyzing The National Weather Service Connection and copy it to the clipboard.
In Visual Studio, navigate to the Models folder and open the Root.cs file.
Use the Edit -> Paste Special -> Paste XML as Classes command to paste these classes underneath the ones that were generated in the Root.cs file.

After pasting the classes, we can see that the format of the data that is returned is not going to be that helpful. The main problem is that the data is returned in an array of simple values. TIBCO Scribe® expects the values in a simple flat structure with a name for each value. Another problem is that the Weather data should be combined with other sections of the data. For example, the time-layout section is referenced in the temperature section, and the minimums are in a different section than the maximums. A better structure for TIBCO Scribe®, in XML, would be something similar to the following:

 <?xml version="1.0" encoding="utf-8"?>

 <WeatherResponse>

   <Weather>

     <Start>2015-10-27T06:00:00-04:00</Start>

     <End>2015-10-28T06:00:00-04:00</End>

     <High>53</High>

     <Low>34</Low>

     <Summary>Partly Sunny</Summary>

   </Weather>

 </WeatherResponse>

This is a very small example and is not complete, but it is a simpler structure for us to work with, and the Integration Framework is designed to work with simple things.

Based on the data presented, you could determine that the Fast Connector Framework would not be the best fit for this project. The data is a little too complex and it takes effort to make it workable. Using the regular Connector Development Kit might be a better option for this project, though the data is difficult enough that it will be challenging in general. This is an example that can provide some insight into ways that we can extend the Integration Framework Framework.

The key problem is that the data returned in the Response body is too complex for the built in serializers to get into a good structure for TIBCO Scribe®. However, we can provide our own implementation of a serializer, as shown in the following:

The type signature for this is:

 public interface ISerializer

   string Serialize<T>(T typeToSerialize);

   T Deserialize<T>(string s);

This is a flexible signature that we can use to compose the things that we want to do.

The first part, string Serialize<T>(T typeToSerialize);, is not something we are concerned with in this case because we are not implementing any target operations, such as Create or Update. If we did need it, the way to think about this is to say that given some .NET type T, return a string that is the serialized payload that represents that data.

T Deserialize<T>(string s);, is the important section for this example. It requires us to take a string, in this case the XML in the Response Body, and turn that into an instance of a .NET type. For the sample project that .NET type is the WeatherResponse type that we want. We can leverage the built in XML serializer to automatically deserialize the response into the dwml type generated by the Paste XML as Classes. Then, we can write some custom code to translate that into the type we want.

We have provided some sample working code, however it is not a robust solution. It is simply a quick solution. The serializer provides you with some ability to write custom code while still taking advantage of the Integration Framework. When writing your own serializer, you need to override the default serializer. This can be done on the WeatherConnectInfo section of the code, as follows:

 public class WeatherConnectionInfo : XmlHttpConnectionInfoBase<WeatherConnectionInfo>

     protected override ISerializer Serializer { get { return new WeatherSerializer(); } }

…

See Sample ISerializer Implementation to review the sample working code.