我今天需要把大量的文件从OneDrive迁移到一个SharePoint的文档库里。这样的操作在Microsoft 365中是可以的,但是手动复制的话单次复制的文件总大小是有限制的,所以我反复遭受“File size over limit”的折磨。

最后在网上看到有人说可以用Power Automate遍历文件,再把文件分别上传。

总的来说Power Automate还是很高效的,我只花了一整个中午就做出来了一个完全不能用的文件迁移器。(更早的时候还有创建别的workflow,但是因为做太烂了就直接删了重新新建了)

图片

不能容许复杂 链接到标题

我要复制的文件夹里面是有很多层目录结构的,我首先想到的就是通过递归来把里面的所有目录、文件都拷贝过去。接下来就是Power Automate扯淡的地方了:不能定义函数、不能玩递归。

看论坛里别人说的,定义函数以复用代码已经在几年前被向微软提了很多次了,但是至今都没有做出来。

代码复用 链接到标题

那里面的代码块我就自己一层一层把循环套娃放进去吧,套了4层,第5层不能套了,因为我这里面每个循环里面都有if语句,Power Automate里面有限制说不能嵌套超过8层。反正4层基本上够用了,那就这么用吧。

顺带一提,Power Automate的新版界面上没有提供复制的按钮,我如果要复制“代码块”我还要保存然后切换回老版本。

调试 链接到标题

遂继续尝试,跑了许久,也没见文件上传成功,就一直在那里转圈圈。随后我把任务取消运行,然后我又把这些“代码”块拆开,然后搞了个文件进行测试,因为这个东西在循环里面取消之后循环里面的运行情况是看不到的,我也没有找到这个东西有提供断点之类的功能。最后发现原来是我SharePoint的路径填错了,没写Shared Library那段。

遂补上然后继续尝试,结果发现这玩意儿大文件上传可以从OneDrive读取到但是不能上传到OneDrive,至于返回的内容是什么我就不知道了,我没有闲工夫把我的下午的时光也搭进去研究微软拉的这坨屎。

应该是文件太大然后不允许上传了,不过有一说一Power Automate的每个“代码块”的文档都蛮厉害的,居然能让我在看到每个动作的名称就知道这个动作是干什么的,比如“列出文件夹中的文件”这个动作我看一眼就知道它做的事情是列出文件夹中的文件。它传进去的参数的名字叫做“文件夹”,想必是文件夹的路径吧,毕竟Power Automate的主要目标用户就是不会写代码的人,普通人若不额外说明的话定位一个文件夹首先想到的就是文件夹路径,我也不例外,所以就把文件夹的路径传进去了。于是我得到了Bad request,因为这玩意儿要传进去的是Item ID。

图片

表达式 链接到标题

做这个的中途有用到表达式。因为我定义了变量,我要把文件路径的格式稍作调整然后存进去。

这个表达式的编辑器在新版界面里应该是复用了VSCode的编辑器的代码,旧版界面里就只是一个输入框。

表达式的写法要看官方文档,我一开始以为这里面写的是js,然后发现这玩意儿只是一坨连四则运算还要调用函数的、不知道叫什么的东西。

我一开始把里面的字符串当js里面的字符串然后调用字符串的一些方法去操作字符串,在表达式编辑这里是可以通过检查的,但是保存workflow的时候是会报错的,而且它只告诉我说有地方报错,丝毫没有提到是哪里有报错,检查流程里面显示没有问题。

另外有个涉及到生产效率的问题,就是现在大家已经开始用AI协助办公了,那我应该怎么给Copilot描述说我要写一个Power Automate的表达式呢?我尝试过直接这样说,但是Copilot给我的是Java Script。

你就吹吧 链接到标题

知乎上有关于Power Automate的评价,我看到的是一边倒的支持Power Automate。

如果只是涉及到本地的文件处理,我还是觉得不能说Power Automate是无可替代的,只能说用啥写脚本都比Power Automate好。

唯一一个Power Automate擅长一些的领域就是处理Microsoft 365里的东西,因为这玩意儿不需要我去看文档就可以轻松地调用微软的API。进行一些简单的操作,比如让它在发生什么事情之后自动在outlook里提醒一下,这种事情用Power Automate是很方便的。但是如果要求稍微复杂一点,那是否使用Power Automate还是值得商榷的。