I can't solve the problem for you, but I can give some info from when I looked into this. I don't have those notes anymore or I'd just show you that.
When I and couple of colleagues looked into this a while back, we expected it to be a huge issue requiring a whole lot of changes to processes. While on one hand, there is a possibility for this to occur. But it all comes down to how often the datatype DateTime is used in your processes. I didn't end up having to finish the work on that project, but I heard that it ended up not being that big of a deal because people hardly ever use DateTimes. I'm not saying they're never used, but you may be surprised to find it's usually Dates and Times. And then even when DateTimes are used, they often aren't affected by the V6 change because it's only when they go through code stages that this issue arises.
As far as programmatically searching for this issue, I personally would just grab Notepad++ and avoid wasting time on writing a script for it. If you have someone who already has a deep understanding of the xml in Blue Prism release files, then go for it. This especially would be a good reusable tool for other organizations to use. Blue Prism really ought to have built this tool themselves, but no one is perfect.
😃 Anyway, I'd use Notepad++'s feature that can search for words across multiple files. You'll probably be searching for something like these words:
type="datetime", as you can see in the code snippet below. I'd then just make a list of those things. You may find it won't take long to make your list. Then go look at them in Blue Prism (unless you're a machine and can read XML easily) and see if any of the DateTimes are passed into a code stage. This of course includes, as that document mentions, the collection manipulation actions in the VBO. Blue Prism attempted to list all of the actions that can affect DateTimes in collections, but they missed like three actions if I remember right so it's best to go ahead and check them. If you can run in DEBUG mode for those pieces without running end to end then it'll be easy to test.
<process name="__selection__Test object"><stage stageid="b4053218-2b88-4db4-9349-a497d4755152" name="Coll1" type="Collection"><narrative></narrative><displayx>-645</displayx><displayy>-45</displayy><displaywidth>60</displaywidth><displayheight>30</displayheight><font family="Segoe UI" size="10" style="Regular" color="000000" /><datatype>collection</datatype><private /><alwaysinit /><collectioninfo><field name="Field1" type="datetime" /></collectioninfo></stage></process>
This may sound painful, but I honestly think that for many organizations it will take less time to do this manually than to develop and rely on a script to identify whether pieces will be affected by this change. (Again, unless someone made it available to the community). You'll probably know once you search for datetime in your releases.
As far as I know, there's no way to dynamically create a datetime field. Blue Prism requires that you define that data type ahead of time (unlike number and text fields which can be created dynamically in a collection). You may also want to consider any outlying scenarios where there is custom code that outputs a DateTime in a collection in a dynamic way, but here again this is very unlikely.
My guess is that you'll start looking through the processes and you'll find datetimes are uncommon. The best way to test this may just be to copy the processes over to V6 and run them in a test environment for a week and take note of the outputs and whether they match the same thing in V5.
------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris
3Ci at Southern Company
Atlanta, GA
