不同的BPM流程可以有多种启动方式，如管理者平台的手动触发、Web服务启动，API调用的方式启动等方式。通过流程控制台手工启动流程适用于对基础流程的场景测试，而后两种则是从开发的角度发起流程实例，如图7-14所示。

图7-14 BPM启动事件触发器的配置

比较开发端两种启动流程的方式，Web服务的方式从接口的角度来讲更通用也更规范。对于其他系统来讲，通过调用流程的Web服务就可以发起BPM流程，但客户端调用的过程却较为烦琐。对于每一个Web服务都要有一个生成客户端代理并调用服务的过程，而且如果是Web Dynpro调用Web服务，当流程的启动接口结构发变化时，往往要重新导入模型，使因为接口结构的变化带来了客户端程序的调整，同时由于BPM发布后生成的Web服务本身是异步的机制，不能通过服务返回的参数来判断或获取流程相关的信息（如标准流程ID），这些数据对于标准的流程处理（如取消流程等操作）都是必须的，因此通过WS启动流程的种种弊端让大部分实施者在后期实施中采用API的方式来启动流程。比较前者相对于规范化的启动接口来讲，API的启动方法可以适用于所有流程，接口结构的变动不会对方法带来太大的影响。另外，API具有返回参数，参数中包含了URI形式的标准流程ID，这些都会让最终的调用过程变得高效，而且功能更加全面。总的来讲，对于系统间的服务调用来发起流程，采用WS是比较好的一种方式，对于系统本身的流程启动更多的是倾向于标准API。

1.手动触发

使用管理员账号登录NWA平台，在菜单中选择“Configuration”，随后单击“Processes and Tasks”就能打开流程和任务的管理界面，如图7-15所示。

在清单中列出了所有成功部署至服务器的流程，单击选中任一流程，在下方任务清单中选中开始事件，随后单击“Start Process”按钮，就能从服务器端手动发起指定流程。但由于这种方式不够灵活，且必须由管理员手动进行操作，因此在实际项目应用中较少使用。

2.Web服务启动

一般在定制流程模型、开始事件时，都会关联对应的服务接口（Service Interface），即流程的启动服务接口（也是流程发布服务器后Web服务的访问接口），对应于Web服务的WSDL地址，如图7-16所示。

图7-15 流程中的任务清单

图7-16 项目目录结构

从服务定义的角度来说，BPM在部署到服务器后都会产生一个对应的Web服务，其中包含发起流程的方法以及必要参数，通过调用该Web服务触发相应的事件就能启动流程，并传入必要参数的值。

开发实例：

1）通过服务接口的关键参数在管理员平台的“WS Navigator”进行测试，以保证在使用时可以正常运行。进入NWA页面的“SingleService”服务，并输入关键字进行搜索，如图7-17所示。

图7-17 搜索服务界面

2）查找到对应服务后，单击下方的“WS⁃DLs”页签，并单击“Test”按钮，如图7-18所示。

图7-18 WSDL界面(www.daowen.com)

3）随后跳转至Web服务测试页面“WS Navigator”，单击“下一步”按钮，如图7-19所示。

4）输入必要的执行方法参数，单击“下一步”按钮，如图7-20所示。

图7-19 选择对应操作

图7-20 输入参数值

5）执行完成后，通过执行返回消息确认服务执行成功，如图7-21所示。

6）接下来通过在Web Dynpro工程中模型导入Web服务，并创建对应的执行方法或生成自定义控制器进行执行，便能达到代码端启动流程的目的，如图7-22所示。

图7-21 测试结果

图7-22 导入模型

3.流程API启动

通过API启动流程是在NetWeaver 7.2及更新版本中提供的更受开发人员欢迎的一种方式，因为它相对于Web服务的定义和使用来说，更加地简洁和直接。值得一提的是，在新版本中SAP不仅公开了BPM启动流程的API，还提供了对操作任务的API以及操作流程的API等内容的支持，这些API使开发者实现各种各样的增强（包括对流程的动态控制）成为了可能，有时通过API的使用也能达到一些意想不到的效果。

使用API启动流程的代码示例：

注：这段Web Dynpro中的代码只有添加对“tc/bpem/facade/ear”与“tc/je/sdo21/api”两个标准软件组件的依赖才能编译通过。