As per my understanding your compliance rule not even able to find/check of existence of value4 from the extended object.(rule is non-compliant with exists error)
At 1st try to check if your rule able to find the value4 existence itself and then go for checking the value of value4.
something like this.( may be I have some syntax error but when you write the rule BSA will take care of this)
"Extended Objec Entry:Patrol PH" . "Value4" exists
If above one is complaint then go for checking the value of value4. something like below must do
"Extended Objec Entry:Patrol PH//Name" . "Value4 as String (ALL OS)" contains "??NAME??"
I think changing:
"Extended Object Entry:Patrol PH"."Value4 as String (ALL OS)" contains "??NAME??"
"Extended Object Entry:Patrol PH//*"."Value4 as String (ALL OS)" contains "??NAME??"
should work for your use case.
I have tried changing the rules as requested ,but it does seem like the rule is unaware of the value of "value4".
Quite frustrating as the Discovered component does shoe values populated in value4.
Any ideas why these cant be leveraged within the ruleset??
by any chance did you get success for checking existence of value4. Does your rule able read it from the extended object ?
Also can you just give a try by creating a global EO instead of local one.
Can you check if "compliance" option is selected in the "parts" for this extended object? If not that might also cause this issue.
Just some thoughts. It looks like you're comparing two variables against each other. ??NAME?? might not necessarily mean the NAME of your EXO. You might need it in a format like ??YOUR_EXO.NAME??
Also, I've seen running tests like this vs running it against a server can, on occasion, have slightly different results.
I would recommend building and verifying your Rule at a more basic level, and slowly add complexity to it. Verify it Live browse's successfully on a target server. Review the values. Focus on getting the left side value correct. Then focus on getting the right side value correct. Etc.
I think the problem you might be experiencing is related to Value 3. In your example Value 3 contains "=" which possibly breaks the grammar interpretation. You could try to substitute the second occurrence of the "=" sign by an explicit string like "equals". That might help.
Also you might want to use a different grammar like the INI grammar. I found myself in what I believe is a similar situation (only not with the pconfig command as a data source) and I transformed my EO in a centrally executed EO, wrote a few lines of script in NSH (mainly sed and awk) to transform the output into something compatible with the INI grammar. Also I got rid of the findstr part and used those keywords as the section header in the INI structure. The advantage of doing that is that I used the same EO and therefore the same part for many compliance rules. I just built these rules against a different path in the result of that same EO.
It did turn out the = and some specail charaters was the cause of the issue.
Stripping them resolved the porblem.