SharePoint 2013 Nintex Workflow 工作流帮助（七）

博客地址 http://blog.csdn.net/foxdave

工作流动作

11. Check out item（Libraries and lists分组）

与上一个对应，用于签出条目。如果一个库配置为需要签出进行修改，那么在工作流中，在Update Item操作前放置这个操作是必要的。

配置项同样很清晰，并且跟签入操作是一个道理，这里就不赘述了。

12. Collection Operation（Operations分组）

该操作提供了对集合变量中值的直接访问。应用此操作，首先需要创建一个集合类型的工作流变量。

我们来看一下配置项。

Target collection

该参数为必须项，指定该操作要应用于哪一个工作流集合变量。

Add

向集合变量中添加新的值，可以选择Index来指定插入到集合的哪个位置，如果不选择Index，则该值会被添加到集合的末尾。如果Index越界了，会报错。

Remove

从集合变量中移除指定Index的值，集合的大小会减一。

Count

输出集合的大小值，存储在数值类型的工作流变量中。

Get

获取集合变量中指定索引的值存储到其他变量中，注意二者必须是匹配的。

Exists

输入一个布尔类型的值到其他工作流的布尔变量中来判断指定的值是否在集合变量中存在。

Sort

对集合变量中的值进行排序并存储到另一个集合变量中，当然也可以直接覆盖当前的集合变量。

Pop

从集合的末尾取一个值存到其他变量中，集合的大小会减一。

Join

把集合变量中的值用指定的分隔符连接起来存到另一个集合变量中。

Clear

清空集合变量。

Remove duplicates

移除集合变量中的重复元素，对于文本类型的变量将匹配大小写。

Remove by value

移除集合变量中等于指定值的所有元素。

13. Commit pending changes（Logic and flow分组）

该操作强制当前批处理操作提交。批处理操作是指工作流不立即提交的动作，比如更新列表条目、以及上面所述的签入签出操作，而是等到工作流提交修改。工作流提交一个延迟操作，任务操作或者是工作流的结束，当更新列表条目操作运行运行时，它只是先进行注册而不是实际去更新。

SharePoint工作流引擎并不按照设计器显示的顺序来执行批处理操作。比如，以下顺序的操作：

设置条目的权限操作（Nintex）、更新列表条目操作（Microsoft SharePoint）、设置权限操作（Nintex）。

实际上却会按照一下的顺序执行：

设置条目的权限操作（Nintex）、设置权限操作（Nintex）、更新列表条目操作（Microsoft SharePoint）。

为什么会以这个顺序执行呢？原因是有Microsoft和Nintex两个批处理（任何第三方都有自己的批处理），Nintex不能向Microsoft中添加批处理操作，并且一个批处理中的操作只能在另一个批处理之前都执行完毕。至于先执行哪个批处理，取决于工作流的第一个动作操作，如果是Microsoft的，则就执行Microsoft的所有操作，Nintex在之后执行。

回到我们当前介绍的操作上，对上面的例子稍微修改：

设置条目的权限操作（Nintex）、更新列表条目操作（Microsoft SharePoint）、提交等待的变更、设置权限操作（Nintex）。

在这种情况下，就会按以上顺序执行了。因为当调用提交等待的变更时，Nintex是先调用的，它先执行，但是此时它的批处理中只有一个操作，所以接下来更新列表条目操作就执行了。然后最后的设置权限操作又是另外一个新的批处理了。

此操作并没有什么配置项。

14. Compile Audience（企业版才有）

此功能需要SharePoint Server版本。此操作会编译当前环境中一个已存在的听众。

关于配置项的说明：

User Profile Service Applications

选择一个用户配置服务应用程序。

Audience name

要编译的听众的名称。

Credentials

具有编译听众权限的账户。在管理中心中，该账户需要作为用户配置服务的管理员来管理听众。

Compile type

指定是执行完全编译还是增量编译。