0 Replies Latest reply on May 8, 2016 11:54 PM by ben.prinsloo1

    TIP: Alternate way to extract Property/Key values from Symptom content

    ben.prinsloo1 Apprentice

      This is not a question, but rather a tip on how to extract the values for keys within the Symptom body. A few of our sites have email listeners connected to event managers, which in turn send an email in a fixed format if an event was raised. This would then create the Incident, but in some cases you might want to extract key information from the text body. The most commonly used method is by attaching an XSLT to the email listener, but that requires some knowledge on XSLT and extracting values from plain text using this method. It is very much possible to do, but there is an easier way - Regular expressions.

       

      If the email body is as follow for example, you might want to extract the GUID and EventIDs into custom fields on Incidents :

      EventID: 12345

      GUID: {1234-FFDDE-4444}

      Field1: 1234

      Field2: 44444

       

      As mentioned before this could be done using XSLT 1.0 and 2.0 (easier than 1.0). But an alternate, and probably easier way will be to apply this simple expression on the field, ie. make it a calculated field:

      $(Trim(Replace(FirstRegexMatch(Symptom,  /^GUID:\s*((?:(?!^\w+).)+)$/m),

        "GUID:",

        "")))

       

      The above will return {1234-FFDDE-4444} since the value extracted is using "GUID:" as the search string. Unfortunately it will return the FULL line by default, so we then manipulate it further by removing the GUID: from the result. This can be applied on other fields as well as a calculated field, and just change the Bold section to match the property that you need to extract.

       

      For example, to extract EventID change it as follow :

      $(Trim(Replace(FirstRegexMatch(Symptom,  /^EventID:\s*((?:(?!^\w+).)+)$/m),

        "EventID:",

        "")))

       

      The beauty is that this will not fail during Incident creation if the patterns doesn't match, which means normal incidents are unaffected.

       

      I hope this will assist someone else. The expression was actually written for multi line properties, and could be extended to look for the next property with ":" at the end. This could be normalized quite drastically, but the principle will remain the same. The same goes if the property uses "=" as delimiter instead of ":". In these cases change the : with a whitespace check before and after to ensure all cases are covered.