The Regular Expression action is an extremely powerful action for splitting text, replacing text or getting data out of text. Don't be worried about not knowing how to put Regular Expressions together. There are a number of sites online that give you the basics of it. In this post, I'll give you some quick tips on how to get data that you may need.
There are times where you will be getting data from lists, from web services, databases or elsewhere, where the data comes to you in a delimited form. Either comma delimited, as in CSV files, or semi-colon delimited, as from some accounting systems or some other delimiter. If you need to get the data into a Nintex Workflow collection variable, you can use the Regular Expression action to split the data based on that delimiter.
Notice that the first data entry field to fill is in the pattern. When doing a split, this is the delimiter. The character or characters that will be used to split a piece of text. The operation is "Split" and the Input text, I've simply typed in some text with the comma separating them.
The result of this needs to be stored in a Nintex Workflow collection variable. For more information on the collection variable, take a look at these :
The interesting thing to note here, is that the pattern is a Regular Expression. Although it could be a single character, like a comma or even several characters like #!# if that is the delimiter (I used to use that), it could also be very intelligent as you could give it options.
The above example is stating that the delimiter could be a comma or a semi-colon. That really opens things up doesn't it?
To get a little more elaborate, what if your delimiter was a period (dot or full stop for non US people)? Well, in Regular Expressions, a period is a special character. So in that case, you need to escape it. You would do it like this:
Putting the backslash on it escapes it and lets the Regular Expression parser recognize that you want to deal with a period and not their special meaning of it.
Using a Regular Expression action is not the only way in Nintex Workflow to replace text. There is an inline function you can use in a Build String action, called fn-Replace. Having said that, that action only lets you replace a known piece of text with another piece of text.
The Regular Expression action allows you to build complex expressions so that not only do you replace a piece of text, but you can find any number of matching sequences of text or replace only one piece or just from the beginning or from the end. The number of expressions you can build is almost infinite.
In the screenshot above, we have some text "abc-def-ghi-123-lmn" and we cant to replace the numbers with a ###. Now if you were to use this with a Build String action (with fn-Replace), you would need to know those 3 digits. But if this was data coming in from another system, those 3 digits would be different each time. That's where the Regular Expression action is so powerful.
You can build an expression like [0-9]+. This is saying that every in my text where I find one or more digits, I want to replace them with ###.
Another expression that would do the same thing is [\d]+ . The reason I show you this, is because there may be other expressions that do the same things as what you're doing now. Some will make your expression smaller and more streamlined. Others maybe actually be faster at finding the text you need. Although I would say that for workflows that you build, you're unlikely to come up with a scenario that the performance of a Regular Expression is something to worry about.
This can be as simple as the replace above, or something more complete.
To extract the numbers from the example above "abc-def-ghi-123-lmn", you can use the same expression.
The main thing to note here, is that the Extract option will only save the results into a Collection variable, even if you know you're only getting one result back. So you should be aware of this when extracting data.
Where it gets a little more complex, is if you want to extract data between two strings.
Let's take the above text as an example. If we needed to get all the numbers, but they had to be between 3 text characters and the dash, on both sides, how would this be done?
In this case, our Regular Expression gets a lot more complex. It would look like this :
You're probably looking at this and thinking it is gibberish. That's what I thought it was when I first was learning about Regular Expressions.
It broken up into three components.
(?<=\w+-) - This is called a Positive Lookbehind . We're looking for some text that is a number of text characters followed by a dash (hypen).
\d+ - This is the data we want to extract. It is one or more numerical digits.
(?=-\w+) - This is called a Positive Lookahead. We are looking ahead to find a dash (hypen) followed by one or more text characters.
Although when you look at complex regular expressions, they look daunting, they actually aren't. You just need to spend a little time playing around with them and maybe running through some tutorials and you'll be well on your way to build awesome business solutions.
The match operation, I'm not going to talk about much, since it's similar to the others. It simply lets you know if based on your Regular Expression, there is a match in your text. A good example of this, is if you didn't have Form validation and you wanted to validate that someone had entered a valid email into an item field that the workflow is running on, you could use this functionality to match it. If it matched, you could continue with the workflow but if it didn't, you could notify the initiator to get them to fix the issue.
Regular Expressions are extremely useful in countless scenarios. Don't be afraid to play around with them and use them to make your workflows very slick. If you want to learn more, take a look at this site, which is one that I go to often to if I need a refresher - RegExr: Learn, Build, & Test RegEx
I hope this explains a little on how to use Regular Expressions in your Nintex Workflows. If you have any questions, please free to post them in the comments section.