8.使用UFLO最佳实践
我们知道，UFLO包含uflo-core、uflo-console与uflo-client三个主要模块，uflo-core主要负责流程的核心流转控制;uflo-console则是采用dor ado7做为表现层，以网页形式为我们提供了流程模版在在线监控与测试;而uflo-client则提供给我们的程序员使用，程序员通过uflo-client模块中 提供的ProcessClient与TaskClient实现业务系统与流程引擎的绑定。
在实际的使用当中，我们推荐将UFLO与BDF2一起使用，这样有了BDF2框架后，UFLO的使用就变得非常的简单，所以这里的最佳实践以将以在 BDF2上使用UFLO为基础来进行介绍。将UFLO与BDF2结合使用，可以通过bdf2-uflo模块实现，关于bdf2-uflo模块，之前已经有过详细介绍，这里就不再赘述了。在结合BDF2使用U FLO时，一定要加上bdf2-uflo模块，因为bdf2-uflo模块的运行依赖于uflo-core与uflo-console两模块，所以如果您的项目是Maven结构，那么 在添加好bdf2-uflo模块后，Maven会为我们自动加载uflo-core与uflo-console两模块及他们所依赖的其它第三方jar文件。但如果您是普通的Dy namic web project项目，那么在添加好bdf2-uflo对应的jar后，还需要手工添加uflo-core与uflo-console两模块jar及他们所依赖的其它第三方jar文件。
值得注意的是，我们程序员要使用的uflo-client模块并没有被bdf2-uflo模块所依赖，所以在添加完bdf2-uflo模块后，我们还需要手添加到uflo-cli ent模块(如果是Dynamic web project项目，需要手工添加uflo-client对应的jar)。所以一个在bdf2中使用uflo，需要包含以下表格所示的四模块。
我们知道，UFLO使用有两种部署模式，也就是普通的嵌入式模式和独立服务运行模式。在实际项目开发当中，无论是哪种部署模式，在结合bdf2使用uflo时都需要上述表格中所描述的四个模块，对于我们的程序员而言，只需要去调用uflo-client中的ProcessClient与TaskClient实现业务与流程的结合就行，而不用去关注将来使用UFLO的部署模式，因为我们采用UFLO开发的业务系统在运行时是否采用独立服务运行模式，完全由uflo.restAccessBaseUrl属性决定，它的值为远程独立部署的UFLO Server所在应用的地址，该属性默认值为空，也就是说不定义访问远程的UFlo Server，这样当该属性值为空时，应用中的UFLO将以嵌入式模式运行，而不会去访问远程的UFLOServer;一旦我们配置了该属性，那么UFLO中所有事关流程流转的动作将全部通过访问这个uflo.restAccessBaseUrl属性指定的独立部署的UFLo Server完成，从而实现独立服务运行模式;uflo.restAccessBaseUrl属性值定义的格式如下:
uflo.restAccessBaseUrl属性定义格式http://localhost:8080/uflo-test-server/dorado
从上述定义的格式来看，就是指定远程UFLO Server应用地址，值得注意的时，地址一定要以dorado结尾，这是因为UFLOServer暴露给外部可访问的REST风格的服务是通过Dorado7提供的Servlet完成的，所以这里要求一定要以dorado结尾。
采用独立服务模式下，我们除了要为客户端指定UFLO Server所在应用地址外，还需要告诉我们的UFLOServer，当前有多少个客户端，它们的地址又分别是多少，所以我们还需要为UFLO Server定义一上属性，以告诉UFLOServer当前有哪些客户端在调用当前Server上的UFLO暴露的服务，该属性名称为uflo.clients，属性值定义格式如下:
uflo.clients属性值定义格式http://localhost:8080/uflo-test-client1
可以看到，定义格式比较简单，我们只需要指定客户端应用所在地址就行，同时如果有多个客户端，那么该属性直接定义多个客户端URL，中间用“;”分隔，如:
多个客户端地址URL定义http://localhost:8080/uflo-test-client1;http://localhost:8080/uflo-test-client2;http://localhost:8080/uflo-test-client3
有了这个地址，当我们采用我们的流程模版在线设计器修改已有的流程模版，在将修改好的流程模版部署的UFLO Server时或者在UFLOServer上删除某个流程模版时，我们的Server会利用这里定义的客户端地址，通知所有客户端立即更新对应的流程模版，从而实现流程模版数据的同步。
前面的我们提过，UFLO的独立服务模式，不是一种纯粹的独立服务模式，而是一种混合嵌入式模式的独立运行，所以在独立服务模式下，我们的客户端应用中同样要包含uflo-core、uflo-console模块。实际上，在UFLO独立服务模式下，作为客户端的业务系统，其中的流程引擎只会将一些可能会影响流程流转的操作发送到远程UFloServer上完成，而对于普通的流程信息查询，则直接调用系统内嵌入的UFLO引擎实现，这样做的即保证了大并发下流程引擎运行的完整性，也大幅提升了系统的运行效率。下图向我们展示的UFLO的嵌入式运行模式。
与嵌入式运行模式相对应，一旦我们设置了uflo.restAccessBaseUrl属性，那么我们的包含uflo的BDF2应用，将自动从嵌入式模式转换为独立服务与嵌入式混合模式，如下图所示。
从上面的独立服务部署模式的示意图中可以看到，UFloServer也是一个普通的Web应用，在这个应用当中只需要包含uflo-core、uflo-console及bdf2-uflo三个模块即可，而不需要像我们的客户端应用那样包含uflo-client模块。可以看到，与嵌入式不同的地方就是uflo.restAccessBaseUrl属性从空值变成了UFloServer地址，这样就完成了我们的业务系统从嵌入式运行模式到独立服务模式的转换。
在独立服务部署模式下，因为我们的客户端应用当中也包含uflo-console模块，所以我们的客户端可直接访问uflo-console模块当中包含的流程监控与测试中心页面com.bstek.uflo.console.view.ProcessMaintain.d，但我们的UFloServer上也有这个页面，那我们究竟应该采用哪个呢?回答是UFloServer上的。因为有了Server，我们肯定不能再用各个客户端中包含的监控测试页面了，而应该用UFloServer上的这个页面。除了这个页面之外，其它的诸如待办任务列表页面com.bstek.uflo.console.view.TodoTaskMaintain.d，以及节假日配置页面com.bstek.uflo.console.view.CalendarMaintain.d，都可以采用各个应用uflo-console中自带的页面即可，因为这些页面都只是数据的简单查看与维护，不会影响流程的流转，所以不用使用UFlo Server上的。
在我们项目上线的时候，无论是我们的UFLO Server还是UFLO Client，都需要调整uflo.idBlockSize属性，在安装与配置一节点我们就解释过这个属性，我们知道它的作用是用于定义UFLO中所有表数据主键中的缓冲区大小的，缓存区越小，用完的速度就越快，这个属性默认值为10，比较便于我们开发测试，正式部署到生产环境一定要修改该属性值，一般情况下，可以修改该属性值为5000，这样可为系统提供一个比较大的ID缓存区，提供给UFLO流程引擎使用，从而提高系统运行效率。
对于采用UFLO Server运行流程的UFLO的客户端应用来说，还需要添加一个名为uflo.disableScheduler的属性，该属性默认值为false，用于标明是否禁用当前应用中用于周期性扫描任务提醒功能的JOB，对于采用UFLOServer的UFLO的客户端应用来说，需要将该属性值设置为true，表示禁用UFLO客户端中周期性扫描任务提醒功能的JOB，这样，所有扫描的工作都交由UFLO Server来完成。
更多建议：