Regex multiple line text parsing

Avatar
  • updated
  • Under review

Hi,


I have issued a basic http command that retrieves multiple lines, effectively we cannot get the values of the 7 groups that are returned under a specific matching. The question is how does COmfortClik handle the groups within regex text to be able to handle the group values, remember this is a text regex not a JSON or XML regex, so there are no tokens!!


Image 3398


Image 3402

The REGEX listener I have created is for a string (it has been validated as it works in any regex tester) ^\#>(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})(?[0-9]{2})$/gm

Image 3399

However, Comfortclick does not seem to handle the groups within a Text REGEX, despite multiple lines are coming in the system response

Image 3400

When executed through a host connection this is the same code returned

Image 3401

Avatar
Paul G

The receiver set-up where the text REGEX waits for the multiple line response

Avatar
Paul G

Ok, after further investigation, the issue is looking bad, even when the remote device sends a single line, 24 characters, BOS splits the response into teo lines, hence the RegEx is deemed useless, because BOS processes the response as if two strings were sent, when actually is only one long line of 24 characters, as the telnet screen shows.

@Comfortclick team any thoughts on why BOS processes the device response as two separate strings responses?

Avatar
Paul G

a single command executed to get a single line response made of 24 characters, is split in two

Avatar
Paul G

Any thoughts team on how to solve the BOS string split? I have tried multiple things but it is not possible to parse a text whose structure you do not know how it will be received. I´d expect someone has dealt with RegEx parsing of strings longer than 24 characters

Avatar
Paul G

@Comfortclick team any thoughts on why BOS processes the device response as two separate strings responses despite one single response being generated (or two if the command is accepted as a line based on the hex codes 00-0A

Avatar
ComfortClick Support
  • Under review

Hello,

thank you for reporting this issue. Values are being treated differently depending on the connection type, end of line is missing in tcp and other connection types, which we will add it and the values should be coming trough correctly.

You can expect this fix in the future release.

Best regards.

Avatar
Paul G

Thanks guys, Can we please clarify what is the current behaviour, as I have an external TCP device with RS232 commands that I cannot handle because of this situation. Regardless of the multiple line processing

a) Currently BOS is splitting the response message at will, with random logic, as per the logs shared. Is the bug you call out addressing this symptom?

b) Currently there seems to be a limit on the response length, accepting a maximum of 24 characters, even if there is a single line response BOS is dropping anything beyond 24th character. Is the bug you call out addressing this symptom?

c) Multiple line response processing is the third item in this bug


None, except the last, of the items mentioned, require multiple line response processing with carriage return coded in the message, BOS is quite powerful so I´d struggle to believe it cannot handle a simple TCP response with more than 24 characters, even that no one has reported similar scenario before in so many years. 


Currently craving to get an answer, happy to test a Beta, because as of now I cannot control with BOS an external music device via TCP/RS232 from a well known brand. Any thoughts? 

Avatar
ComfortClick Support

Hello,

hard to say how the current parsing works as it spit out different info here. The programming team was already able to implement the end of line function in our TCP connection type, so you should be able to see this in the next beta release.

Best regards.

Avatar
Paul G

Great, looking forward for that Beta.

Avatar
Paul G

Hi team, any thoughts when that Beta might be released? THanks.