VMware Cloud Community
NemesisSaints
Contributor
Contributor

Regular Expressions: must have "su" in field

I am new to Regular Expressions. I am working with vRealize Automation 7.6 and would like to set a constraint on one of the fields to make it mandatory to use the letters "su" at the end of the field. It must match this format: "firstname.lastname.su"

How would I write that?

19 Replies
daphnissov
Immortal
Immortal

I would suggest you look at some regex tutorials online because there is nothing special about the format that vrealize automation accepts. A regex is a regex for the most part.

NemesisSaints
Contributor
Contributor

This appears like it would work, but it does not:

.*[s][u].*

https://regex101.com/r/71gifh/1

It fails the regular expression edit with an "Invalid format" error when using both su and non-su.

Some different variations were also tried:

[s][u]

Both su and non-su: Invalid format.

*[s][u]*

Allows both su and non-su.

.*

Allows both su and non-su.

^.*$

Allows both su and non-su.

^.*[s][u].*$

Both su and non-su: Invalid format.

^^.*[s][u].*$$

Both su and non-su: Invalid format.

^[^su<]+$

Allows both su and non-su.

^^[^su<]+$$

Allows both su and non-su.

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

I am starting to think it could be a vRealize issue.

.*[Ss][Uu].*

Matches test string using firstname.lastname.su on regex101.com.

Both su and non-su: Invalid format. Failed regular expression edit.

[Ss][Uu]

Matches test string using firstname.lastname.su on regex101.com.

Both su and non-su: Invalid format. Failed regular expression edit.

.*

Matches test string using firstname.lastname.su on regex101.com.

Allows both su and non-su.

^.*$

Matches test string using firstname.lastname.su on regex101.com.

Allows both su and non-su.

^^.*[Ss][Uu].*$$

Matches test string using firstname.lastname.su on regex101.com.

Both su and non-su: Invalid format. Failed regular expression edit.

^.*?[Ss][Uu].*$

Matches test string using firstname.lastname.su on regex101.com.

Both su and non-su: Invalid format. Failed regular expression edit.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

I just tested this under 7.5 and it works fine.  I used your first example  .*[Ss][Uu].*

Can you maybe supply a screenshot of your test so we can see how you have everything defined?

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

I believe you. I am starting to suspect part of the problem is that from vRealize Orchestrator the field makes a call to the top level of Active Directory for the pull down user list instead of manually typing in the information. Do you happen to know how to tell VRO what specific OU to look in?

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

Expression_Example.JPG

Allowing_Non_SU.JPG

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

Whats_Been_Tried.JPG

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

Screen Shot 2019-08-01 at 3.31.43 PM.pngI don't have 7.6 to test in... here is a screenshot from 7.5 .  I'd open a support ticket or maybe someone else on here with 7.6 can verify maybe?

Reply
0 Kudos
daphnissov
Immortal
Immortal

Works fine here in 7.6.

pastedImage_0.png

pastedImage_0.png

pastedImage_1.png

NemesisSaints
Contributor
Contributor

No matter what regular expression I try, it does not work. I have opened a support case and have not gotten far; the same regular expressions do work in the VMware support lab on their end. They are saying since there is no error, it becomes and SDK support issue. However, we do not have SDK support.

I think it has to do with the how the Notify workflow ties into Active Directory in vRealize Orchestrator, in particular the on_behalf_of input field. Please see URLs below. Yes, we do have the plugin installed. It sounds like it is possible for it to call to a sub OU in the Active Directory inventory. It appears as though it is currently calling from the top level of Active Directory. Our non-SU and SU accounts are in different OUs. My thinking is if we specify only the OU with the SU accounts, then the field in VRA will not be able to select non-SU accounts.

I need help to figure our where to go in VRO to make the changes; we are at version 7.6.0. This is the AD path: OU=AdminAccounts,OU=Admin,DC=GD-MS,DC=US

I have attached screenshots.

https://code.vmware.com/forums/3055/vrealize-orchestrator#537777 and https://communities.vmware.com/people/igaydajiev/blog/2016/07/18/active-directory-plugin-300-new-and...

Reply
0 Kudos
xian_
Expert
Expert

You are using the vRO web client. Did you try with the Java client if it makes any difference?

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

Relevant release notes on vRA 7.6

  • [IMPORTANT] The Java-based Orchestrator Legacy Client is deprecated and is scheduled for removal for future releases of vRealize Orchestrator.
  • [IMPORTANT] Workflows created and edited in the new HTML5-based vRealize Orchestrator Client are not compatible with the Java-based Orchestrator Legacy Client. 
  • [IMPORTANT] Avoid using the vRealize Orchestrator Client to edit workflows created in the Orchestrator Legacy Client, if you plan to continue using these workflows in the legacy environment.

So once a workflow is touched in HTML5 client it is not advised to edit it in legacy client, we will use the HTML5 client only going forward to be sure that we comply with this requirement and to avoid having a shared list of workflows that have or have not been touched by the new HTML5 client.

https://docs.vmware.com/en/vRealize-Orchestrator/7.6/com.vmware.vrealize.orchestrator-using-ops-clie... and https://docs.vmware.com/en/vRealize-Orchestrator/7.6/rn/VMware-vRealize-Orchestrator-76-Release-Note...

Reply
0 Kudos
xian_
Expert
Expert

I'd still try it (by copying the WF). I've seen some issues specific to the web client here in the forum...

Reply
0 Kudos
daphnissov
Immortal
Immortal

Just don't use the HTML5 client in vRO. Forget that it exists because there are too many issues and too many caveats. Just steer clear.

NemesisSaints
Contributor
Contributor

I am not completely convinced because it works in the VMware lab environment with the HTML5 client. I believe one of the others in this thread was also using the HTML5 client and it worked for them.

Reply
0 Kudos
daphnissov
Immortal
Immortal

It "works" in some situations and creates compatibility issues for things like XaaS. That feature is a 1.0 feature, which means it's going to be buggy and incomplete. It's best to continue using the legacy client until things stabilize. My advice is to not even touch the HTML5 client in 7.6.

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

The problem is we adopted the HTML5 client 2 months ago and have created several newer workflows since. In fact, the Java client has a warning on the current workflow stating "this workflow can be edited only in the web-client as it has newer format." Everything about the workflow is greyed out in the Java client and it will not let me copy it.

Reply
0 Kudos
daphnissov
Immortal
Immortal

So yes, this is one of the side effects of adopting the HTML5 client, hence my advice of not using it.

Reply
0 Kudos
NemesisSaints
Contributor
Contributor

The regular expression of “.su$” does work on another field, but does not work on the field I am working on, leading to my conclusion it is because the field is an Active Directory lookup.

I created a new Active Directory policy with the sub-OU of the SU accounts that points to our existing AD endpoint.

I think the next step may be to try adding the configuration to a Blueprint in VRA or in VRO try adjusting the workflow input parameter. Everything I am reading so far talks about placing a new machine in a specific OU with VRA done at the vSphere portion of the blueprint, and is not available in the portion I am working which appears to be a VRO section of the blueprint. So at this point, we might have to get rid of the AD drop down and let them type in manually and force the SU at the end that way.

Reply
0 Kudos