Integrating to legacy temperature monitoring device

Below is sample code of a proxy ASP.Net page that queries a TempageR 4E realtime temperature monitor and exposes the temperature to PRTG in order to report and escalate out of range values.

public partial class FetchTemp : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            System.Net.Sockets.TcpClient client = new System.Net.Sockets.TcpClient(System.Configuration.ConfigurationManager.AppSettings["ip"], 80);
            NetworkStream ns = client.GetStream();
            byte[] request = System.Text.Encoding.ASCII.GetBytes("GET /getData.htm HTTP/1.1\r\n\r\n");

            ns.Write(request, 0, request.Length);

            byte[] resp = new byte[2048];
            int bytes = -1;

            StringBuilder sb = new StringBuilder(); 

            while (bytes != 0)
            {
                bytes = ns.Read(resp, 0, resp.Length);
                sb.Append(System.Text.Encoding.ASCII.GetString(resp, 0, bytes));
            }

            dynamic obj = JsonConvert.DeserializeObject(sb.ToString());
            Response.Write("[" + obj.sensor[0].tempc + "]");
        }
    }

It calls the getData.htm page, which exposes the device info, sensors and their values as a JSON object. This gets parsed, and the value of the first sensor is written to the Response in blockquotes. The PRTG HTTP Content sensor is configured with the URL of the page (FetchTemp.aspx).

The code uses a TcpClient instance to retrieve the data. The getData.htm page does not return HTTP response headers, which causes HttpWebRequest as well as the built-in PRTG HTTP XML/REST sensor to fail with "The underlying connection was closed unexpectedly", using TcpClient solves this issue.

Using TLS 1.1, 1.2 in .Net 4.0 Application

One of our partners stopped support for SSL3.0 and TLS1.0 on a service that we connect to with a .Net 4.0 application.

Using WireShark we determined that the application was attempting connections using SSL3.0 and TLS1.0 only. Digging into this we found a link mentioning that a registry value needs to be configured for .Net4.0 to be able to use TLS1.0 and above.

Once we configured the registry value and restarted the application, it was able to connect to the remote service.

How to generate a GUID in XSLT transformations

A recent task involved migrating tens of jobs from Control M to VisualCron. I 'm never in the mood for manual repetitive tasks, so the approach was taken to do it with XSLT, since both Control M and VisualCron support XML config schemas.

VisualCron expects various Ids to be GUIDs, and XSL has no built-in functionality to generate GUIDs, so a plan had to be made. I queried Google and found that one can write extension objects in C# and use them during the translation.

The code for to generate a GUID is very simple:

    public class TransformUtils

    {

        public string GenerateGuid()

        {

            return Guid.NewGuid().ToString();

        }

    }

This is then plugged into the transformation code like this:

            string xmlPath = txtXMLSource.Text;

            string xslPath = txtXSLSource.Text;

            StringBuilder output = new StringBuilder();

            

            XsltArgumentList arguments = new XsltArgumentList();

            arguments.AddExtensionObject("EPS:TransformUtils", new TransformUtils());

            

            using (StringWriter writer = new StringWriter(output))

            {

                XslCompiledTransform transform = new XslCompiledTransform();

                transform.Load(xslPath);

                transform.Transform(xmlPath, arguments, writer);

            }

Inside the xslt stylesheet the extension function can now be called:

<xsl:value-of select="TransformUtils:GenerateGuid()" />

I found a good sample and guide here