Add more advanced string handling functions to the String Builder data reference
I would like to use some more advanced string functions such as Split, Len (string length), and even regex filtering to allow more fine grained control of how some input strings (such as attribute values or substitution parameters) are manipulated to create a new string output.
Luke Yarnall commented
An additional capability that would be good is the ability to parse a string by delimiters. This would be helpful when tracking alarms and events from the Interface for OPC AE. OPC AE messages are sent as a pipe (|) delimited string and stored as string PI tags.
For alarm and event tracking with event frames, it is useful to split the pipe delimited string and store each alarm attribute as an AF child attribute.
Currently this must be done in asset analytics using the InStr function, which is not available in String Builder.
I've attached a relevant tech support case to this enhancement request.
In response to Stephen Kwan, "John, What are you trying to do? Are yo..."
That wasn't my original use case, but these would probably be easier to parse with some of these kind of functions. I'm more looking at parsing various string elements for PI tag name resolution - some of my customers (and one in particular where I have a couple of current projects) use some very nicely consistent naming conventions, and being able to dynamically resolve tag names from asset string data would be easier with some of these functions.
In response to John Messinger, "Hi David, Some of the additional funct..."
What are you trying to do? Are you parsing alarms and events?
In response to David Moler, "We are evaluating what features we shoul..."
Some of the additional functionality I would like to see includes the following standard .Net String methods:
Clone()Insert()LengthPadLeft() & PadRight()Remove()Split()
I'd also like to see the following string methods from Analyses as additional functionality in the StringBuilder:
Char()Len() - pretty much same as above Length() function
I also agree with Kevin Fisk that being able to use substitution parameters in all the arguments of the Replace() function would be useful.
Not covered in the above two lists is an IsNumeric() method. More on this later.
Also, it would be great if some regex functionality could be included, where I can extract a specific matching substring from a larger string based on a regular expression.
Lastly, a simple If..Then..Else function to be able able to make a decision on how to extract part of a string would be really useful. For example, I might like to extract a substring at the beginning or end of another string, but only the numeric component (or maybe only the non-numeric component). An example of the envisioned usage would be:
If IsNumeric(Right(%Element%, 3)) Then Right(%Element%, 3) Else Right(%Element%, 2)
This is particularly useful when dealing with assets that are alphanumerically named with the number at the end of the string (such as one of our customer's gas wells) and we want to extract either the numeric or non-numeric component from a well that may have either two or three numbers at the end (ie, Well99 or Well208).
AdminDavid Moler (Admin, OSIsoft) commented
We are evaluating what features we should prioritize for StringBuilder. We want to make sure that we are addressing use cases that are current pain points. Would anyone interested in this feature be willing to share (here or over email) examples? Specifically we are looking for:
* Input sources and example values (e.g. %Element% is "Well 123" or 'attribute' is "Active")
* The logic that needs to be applied to those inputs and the expected output (based on the example inputs)
Simply adding the string functions available in the analysis menu would be a great improve for the attribute string builder. It would also be nice to be able to use substitution parameters in any argument for string builder functions and not just the first argument. For example, using the replace function in string builder I can use %Element% for the first argument but not the second or third.
John has proposed some functionality that would solve some very real world issues for us. If we can chop up some strings, we will be able to improve the quality of integration we have to our systems, for Well and Compressor Work Management System.
Right now, we have to maintain a set of tables for Table Lookup to be able to provide the strings that are already encoded within a string attribute we already have.