如何实现让对方上传数据到webservice然后自己读取数据并插入到数据库

相逢错过天意 2013-08-08 03:13:35

如题！急~~~~~~~~~~~~~~~~~~

...全文

667 10 打赏收藏转发到动态举报

写回复

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

掌握永恒需控制现在 2013-08-09

打赏
举报

回复

引用楼主 u010587407 的回复:

如题！急~~~~~~~~~~~~~~~~~~

webservice在服务端写好处理的方法客户端直接调用这个web引用然后调用你写的方法 (可以带参数的)就可以直接存到数据库啊

chuting1 2013-08-09

打赏
举报

回复

WEB SERVICE 做接口再好不过了

相逢错过天意 2013-08-09

打赏
举报

回复

有代码吗？不懂关于发送和接收

我真的不是菜鸟 2013-08-08

打赏
举报

回复

使用Xml或者Json做接口、把数据都放到Xml里面，服务器解析数据并插入数据库

终點-起點 2013-08-08

打赏
举报

回复

可以让对方通过ftp上传excel到ftp服务器，然后你写一个服务遍历ftp服务器的目录依次解析excel文件导入数据到数据库，操作成功了的excel要么删除，要么移动到其他目录备份

qls_0 2013-08-08

打赏
举报

回复

首先要看对方上传的是什么数据,webservice不是文件夹,不能直接放数据.如果数据直接是文件,你可以用webservice读取文件,然后写入数据库.如果是上传的数据流,那么你可以直接读取数据流写入数据库。如果你不是直接在对方调用webservice上传数据后立马写入你需要的数据库，那么你可以先放个中间数据库在网上，用户上传以后先写入中间数据库里面，然后你自己在想要取数据的时候再从中间数据库拿出来写入你自己要操作的数据库中

相逢错过天意 2013-08-08

打赏
举报

回复

别沉啊！！！！！！！！！！！

相逢错过天意 2013-08-08

打赏
举报

回复

顶下！！！！！！！！！！！！！

相逢错过天意 2013-08-08

打赏
举报

回复

好吧我是个小白。我就想得到对方网站上传来的数据然后将它插入到自己的数据库中，这个方面我不懂

CqCoder 2013-08-08

打赏
举报

回复

上传数据到webservice？？哥！webservice是一种服务不是磁盘文件夹

奥哲 H3 BPM 系统演示环境操作说明书深圳市奥哲科技有限公司二〇一四年十月目录 1 业务集成 4 1.1 适配器 4 1.2 业务数据库连接 4 1.3 业务服务 4 2 流程模型（流程功能展示） 5 2.1 主数据 5 2.2 表单和控件 6 2.2.1 模版子表 6 2.2.2 表单设计流程 7 2.2.3 显示所有的数据项 9 2.3 办公流程 10 2.3.1 请假流程 10 2.3.2 会议通知 & 通知办理 12 2.4 流程功能 15 2.4.1 流程演示 15 2.4.2 竣工报告审批 17 2.4.3 多人活动 20 2.4.4 出差报销（父子流程） 22 2.4.5 微信通知 24 2.5 业务集成 28 2.5.1 供应商入库/供应商获取 28 2.5.2 审核后创建（WS和DB）/从WebService和DB获取 31 2.5.3 监控并在BPM操作 35 2.5.4 监控业务系统自动发起 35 2.6 外部表单 35 2.6.1 访问WS接口 35 2.6.2 访问API接口 37 2.7 业务规则（选择、排序、脚本） 38 3 业务规则 42 1 演示环境概述 H3 Cloud演示环境分为两部分：  门户： http://120.25.238.237/Portal 登录名 / 密码：administrator@authine.com / h3authine  后台管理：http://120.25.238.237/Portal/admin ，或在Portal页面的右上角，点击用户图标（管理员），选择“后台管理” 登录名 / 密码：administrator@authine.com / h3authine 2 业务集成 2.1 适配器 H3默认提供的适配器列表，并可支持拓展开发适配器，并注册到H3系统中； 2.2 业务数据库连接目前演示环境中使用到的数据库连接配置 2.3 业务服务业务服务列表管理中，支持以下几种应用： 1．新建文件夹：支持把同一个业务所使用的业务服务进行归类管理； 2．新建业务服务； 3．上传业务服务；那么，在本演示环境中使用到的业务服务类型有：Data Table、WebService、Data Sql，详细的业务服务的使用，请参考《H3实施开发手册》。 3 流程模型（流程功能展示） 3.1 主数据功能展示  主数据的维护和查询。  主数据可以有以下两个来源：  来源于业务系统，通过业务服务来读写业务系统的数据；  存储于H3系统，通过H3的表单进行维护数据；  主数据被流程表单中字段的开窗使用；业务场景在实际业务中，会涉及到业务表单使用的公共基础数据，如简单的省份、城市、学历等等数据，以及跟生产相关的物料名称、供应商信息等来自于第三方的数据；设计过程  来源于第三方的业务系统：通过绑定业务方法，读写第三方数据库；  来源于本地系统的基础数据维护：演示过程 1. 主数据可以【绑定业务服务】和【绑定业务规则】 2. 主数据中定义的【查询列表】，供流程包中的表单调用 3.2 表单和控件 3.2.1 模版子表功能展示这个流程是自定义表单，展现的是基于子表控件自定义开发的个性化子表，子表类型SheetGridView的使用；业务场景使用子表数据项的场合，使用子表控件来呈现自定义的效果。设计过程使用自定义表单实现；演示过程在Portal门户的流程中心中发起【表单和控件->模版子表】流程，在表单中点击子表的添加按钮，查看新增行的子表效果； 3.2.2 表单设计流程功能展示  展示开窗查询；  展示联动查询；  字段的自动运算；  字段的显示/隐藏控制；  子表的开窗查询和自动计算；  子表的联动查询；  字段的正则表达式的验证；业务场景根据实际业务需求，部分数据来源与主数据信息，用户可以根据选择的项目，并把对应项目的详细信息加载到表单相应字段中；设计过程以下功能都是基于默认表单配置实现，请在在Portal/admin中查看【表单和控件->表单设计流程->默认表单】，点击每个控件，观察每个控件设置的属性值 1. 开窗查询：字段【编码】说明：SchemaCode的值来源于“主数据”，QueryCode来源于“主数据”中定义的查询列表；OutputMappingString的值是要加载的表单字段信息来源； 2. 联动查询：字段【省份】、【城市】、【区县】 3. 字段运算：字段【营业额】的设置 4. 字段隐藏控制：“类型”字段，当选择“其它”时，可以显示“其它”文本框； 5. 子表中同样可以实现“开窗查询”、“字段运算”；子表中同样可以实现“联动查询”； 6. 字段正则表达式的验证；演示过程 1. 演示开窗查询在表单中选择字段【编码】，可以弹出查询窗口，选择值后，且可以自动带出相关字段的值； 2. 联动查询选择不同的【省份..城市..区县】，观察选择不同数据项时的区别； 3. 字段的计算【利润】=【营业额】-【成本】； 4. 字段隐藏控制：【类型】字段，当选择【其它】时，可以显示【其它】文本框； 5. 子表中同样可以实现“开窗查询”、“字段运算”；子表中同样可以实现“联动查询”； 6. 字段正则表达式的验证； 3.2.3 显示所有的数据项功能展示展示H3表单控件的使用。业务场景使用H3表单控件实现默认表单的显示效果。设计过程以下功能都是基于默认表单配置实现，请在在Portal/admin中查看【表单和控件->显示所有数据项->默认表单】，点击每个控件，观察每个控件设置的属性值演示过程在Portal门户的流程中心中发起【表单和控件->显示所有数据项】流程，在表单中，展示各个H3表单控件的使用，如：整数&数值型，输入字符的自动验证； 3.3 办公流程 3.3.1 请假流程功能展示 1. 表单：字段的控制：  当请假类型选择“病假”的时候，必须提交“附件”才能提交流程；  请假开始时间的选择，只能选择当前日期之后的日期；  请假时间可以自动计算出结果； 2. 流程：路由控制根据员工级别&请假天数判断路由；如：普通员工并且请假天数大于2天时，需要总监审批； 3. 数据字典的应用：表单中的【假期类型】信息，来源于数据字典；业务场景典型的请假流程的控制；数据项、流程路由设计过程在Portal/admin中查看【办公流程->请假流程->默认表单】，点击每个控件，观察每个控件设置的属性值，如：请假类型的属性请假时间的属性演示过程 1. 字段【请假类型】，选择“病假”，点击提交，注意弹出的窗口提示信息。 2. 字段【请假开始时间】，只能选择今天或今天以后的日期；以及【请假天数】的自动计算； 3. 请选择不同的请假时间，观察流程的审批参与者变化； 3.3.2 会议通知 & 通知办理功能展示  典型的父子流程，且两个流程分别在不同的流程包中。另外一种父子流程的展现方式，请参考【流程功能->出差报销】的父子流程；  【会议通知】中已选择的“参会单位”，才能在子流程【通知办理】中接收消息；  【会议通知】的表单字段“会议时间”类型，该控件精细到时分；  自动启动子流程【通知办理】，并可通过日志中，钻取子流程的流程监控图。业务场景在流程设计中，子流程可能需要用到父流程的数据，设计流程时可以设置数据项来源于父流程。如【通知办理】子流程的“会议内容”来源于父流程【会议通知】的“会议内容”数据项，可以对数据项的来源进行配置。设计过程  子流程分属于不同的流程包，2条流程如需建立关系，需通过“数据映射”建立父子流程的联系；  参与者函数：获取指定组织所在组织架构的指定名称的用户组，如：查找查找表单中已选择的部门下面的“联络员”；演示过程 1. 在Portal门户的流程中心中发起【办公流程->会议通知】流程，请注意（目前DEMO中，生产一部&生产二部 >> 联络员组）才有具体联络人，因此，需要展示效果，请至少选择一个部门； 2. 继续提交流程，并观察流程监控图中的信息，找到子流程【通知办理】的接收人； 3. 以【会议通知办理】中的参与者用户名登录Portal门户，在【待办任务】中找到由父流程触发的待办任务信息，查看表单中由父流程带过来的内容； 3.4 流程功能 3.4.1 流程演示功能展示流程设计的各个流程节点的控件、以及流程逻辑中的常用功能展示；业务场景常用的流程条件路由、传阅、等待、消息等场景应用；设计过程 1. 流程的路由：根据表单中是否勾选Checkbox来选择流程路由，如果存在条件路由的情况，是用“虚线”来连接； 2. 传阅的功能：流程执行到“传阅”节点时，使用参与者函数{AllParticipants}，传阅到之前参与流程的所有参与者。 3. 等待：检查条件，采用时分秒格式设置，如："00:01:00" 4. 消息通知：可以选择通知方式，以及设置通知的“消息标题”&“消息内容”。演示过程在Portal门户的流程中心中发起【演示功能->流程演示】流程，根据【表单】中的数据项不同，观察流程的路由情况，并且观察各流程节点所使用控件的功能； 3.4.2 电力倒闸流程功能展示展示表单的特殊打印效果：打印的表单与流程表单是单独的一个文件；一个表单可以有多个打印页面；业务场景业务审批完成之后，需要打印表单，但是表单需要按固定格式打印的场景。设计过程扩展设计&制作一个表单格式：演示过程在Portal门户的流程中心中发起【业务流程->电力倒闸流程】流程，在表单中可以选择【打印】，输出打印表单的设计格式：流程表单打印效果 3.4.3 多人活动功能展示在审批环节，在多人会签任务场景时，各种串签、并签的审批效果：业务场景实际业务中，在会签、并签、串签、加签等具体的场景中应用；设计过程 1. 多人串签（可加签）除流程设计阶段预设的参与者外，还允许在表单中选择更多的参与者，参与者全部通过时，该节点通过；其中有1人不通过，则驳回至上一节点。 2. 多人并签（全部通过）在流程设计阶段预设的参与者，执行并签（参与者互不影响），只要有1个参与者选择驳回，则系统自动取消其它未审批的流程，直接驳回至上一节点。 3. 多人并签（1人通过）在流程设计阶段预设的参与者，执行并签（参与者互不影响），只要有1个参与者选择提交（同意），其它参与者可以不用再审批，直接流转至下一节点。演示过程在Portal门户的流程中心中发起【演示功能->多人活动】流程，结合【流程监控图】，观察流程的执行情况。 3.4.4 出差报销（父子流程）功能展示  不需要建立数据映射关系，也实现父子流程的目的；  子表中的日期控件，只能选择日期；  子表中默认的下拉菜单列表；业务场景在流程设计中，父子流程的数据是来源于同一数据源，且属于同一条业务流程。子流程可能需要用到父流程的数据，设计流程时可以设置数据项来源于父流程。如“机票预定”流程的“申请人”来源于父流程的“申请人”数据项，可以对数据项的来源进行配置。设计过程  在同一个流程包中有唯一的数据模型，但是可以新增多个流程&表单；  在设计流程时，可以使用同一个流程包下面的流程，作为子流程；  表单控件，在默认表单页面中，即可配置出来；演示过程 1. 在Portal门户的流程中心中发起【演示功能->出差申请】流程； 2. 审批环节流转至【子流程：报销流程】时，自动发起【报销流程】，并可看到【出差申请】中填写的数据； 3.4.5 微信通知功能展示在Portal中发起流程，“微信”能够收到H3系统通过微信的公司企业号推送的通知消息，发起流程后，可以在手机中收到通知，并可以在微信中实现审批功能。业务场景业务表单绑定微信号的消息通知；设计过程演示说明：请使用各自的用户名登录Portal发起流程；演示过程 1. 设置Portal登录用户名及微信号设置，并用自己的帐号登录（每个账户绑定一个微信号）； 2. Portal中发起流程用自己的用户名登录Portal，在Portal门户的流程中心中发起【演示功能->微信通知】流程，点击发起后。如图： 3. 填写【微信通知】表单，并提交，可以在自己的微信中，收到H3系统推送的任务消息； 4. 手机上的微信收到的消息推送界面，并可操作【驳回】、【提交】等操作。 3.5 业务集成 3.5.1 供应商入库/供应商获取功能展示  通过业务服务（Data Table Adapter），写入、读取、更新第三方数据库（ERP）中的数据表：Vendor 和Material；  通过【数据模型】的【关联关系】，通过1：1或1：N的对应关系把多个【数据模型】关联起来，如：建立Vendor表和Material表的1：N的关系。业务场景需要操作数据库表，数据库可以是H3的数据库，或者是第三方的数据；设计过程 1. 在【业务集成->业务服务】中，建立【供应商信息表】和【Material信息表】的业务服务； 2. 在【流程模型->主数据】中，建立【物料主数据】和【供应商主数据】； 3. 新建流程包【供应商入库】，【数据模型】中需要用到的【业务方法】分别绑定相应的业务服务，如Create、Load、Update、Remove；并新建主从表的【关联关系】； 4. 新建流程包【供应商获取】，【数据模型】中需要用到的【业务方法】分别绑定相应的业务服务，只有Load、Update；并建立主从表的【关联关系】；演示过程 1. 【供应商入库】： a) 在Portal门户的流程中心中发起【业务集成->供应商入库】流程，在表单上录入表单信息&物料信息，其中Code为关键字（必填项）。 b) 查询确认：打开【供应商入库】流程，在IE地址栏的URL中加上参数Code的值，如：&Code=ORC，就可以查询到刚才录入的Code值是ORC的记录，以及相关的物料信息子表。 2. 【供应商入库】 a) 从Portal门户的流程中心中打开【供应商获取】流程，在字段Code中输入【供应商入库】中填写的Code值，如ORC，点击保存后，即可查到ID是Code值的表单信息。 b) 此时，可以修改表单的值，提交流程后，可以将新值更新到数据库表； c) 同【供应商入库】的查询确认，可以在URL中加上Code的参数值，可查询最新数据信息； 3.5.2 审核后创建（WS和DB）/从WebService和DB获取功能展示  流程包中建立方法，在流程中调用；  采用DB的方法（PRHeader）向第三方数据库插入PR值；  采用WS的方法（PRCreate），更新业务系统的值；业务场景业务数据存储在业务系统，在H3系统中创建表单和执行业务审批，审批完成之后，将业务数据回写到业务系统的情况；例如：有些第三方业务系统没有审批流程时。设计过程  【审核后创建（WS和DB）】的流程包中，定义【创建采购申请】的方法，该方法分别引用：  PRHeader的Create方法，来自于业务服务的【PRHeader表】，属于Date Table的适配器创建；  WS的PRCreate方法，来自于业务服务的【业务系统WS服务】，属于WebService的适配器创建；  【从WebService和DB获取】的流程中，业务方法Load和Update方法，分别绑定PRHeader的Load方法，和【业务系统WS服务】的PRGet方法。  校验PRNumber是否存在的校验：在默认表单中字段【PRNumber】的OnChangeScript属性控制【if(sheet.executeService('ERPSql','ExistsPRNumber',{'PRNumber':'PRNumber'}) == 1){alert('该编号已经存在！');this.value='';}】，来源于业务服务【业务系统SQL服务】的ExistsPRNumber方法。演示过程 1. 在Portal门户的流程中心中发起【业务集成->审核后创建】流程，填写表单信息后提交，可以在【已办任务】中找到表单，此时，表单中的【Return】的值是“False”。 *如果表单信息【PRNunber】录入的编码已经存在相同的编码，点击提交时将会提示： *此时，从Portal门户的流程中心中发起【业务集成->从WebService和DB获取】流程，录入PRNumber=【】并保存，则查不到相关数据。查看流程监控图可知，未执行【审批】和【PR入库】操作。 2. 在【待办任务】中，继续执行流程的【提交】审批操作后，已经【审核】通过，并且执行了【PR入库】操作。此时，从Portal门户的流程中心中发起【业务集成->从WebService和DB获取】流程，录入PRNumber=【】并保存，则可查到刚刚录入的【PR】信息； 3. 在刚刚打开的【业务集成->从WebService和DB获取】流程中，可以新增一条PRItems记录，并【提交】。 4. 在【已办任务】列表中，找出刚刚更改的流程任务，打开表单后可确认【Return】的值为“True”： 5. 从Portal门户的流程中心中发起【业务集成->从WebService和DB获取】流程，录入PRNumber=【】并保存，可以查询得到，新增记录已经记录。 3.5.3 监控并在BPM操作功能展示在业务系统创建表单，在H3中审核 1.创建采购单->自动触发H3 BPM的PO流程； 2.在H3中审核当前表单，每次操作后，可以在这里查看业务表单数据状态。业务场景 H3与第三方业务系统的深度集成，业务系统中有业务表单来触发H3的流程引擎，流程执行在H3系统中，并将每一次的流程状态结果体现在业务系统表单相应的状态中。演示过程打开模拟的第三方业务系统的表单； http://120.25.238.237//ERP/ 【业务系统流程，操作在BPM】，或直接打开http://120.25.238.237/ERP/POProcess.aspx 1. 录入【显示名称】、【预算金额】，点击【保存】，自动生成【PO编号】。 2. 通过H3系统【定时作业】定义【监控业务系统启动流程】来监控业务系统，每30秒轮询一次，如果有新记录，则执行【启动流程公有云版】的方法； 3. 后续的流程审批操作都在H3系统中执行，H3每个审批节点都会执行【更新状态】的方法来更新业务系统的状态值； 4. 业务系统中可以查看订单流程状态，并可通过【查看流程】打开H3的流程监控图； 3.5.4 监控业务系统自动发起功能展示所有的操作都在业务系统中完成 1.创建采购单->自动触发H3 BPM的PO流程； 2.将采购单依次改为->询价、比价、议价、订单下达4个状态，可以将流程触发到不同的环节至结束。 3.议价可以保存至询价环节，将流程驳回询价。业务场景第三方业务系统与H3流程引擎的深度集成，流程表单和业务操作都在第三方业务系统中，流程运转使用的是H3的流程引擎。在业务系统中没一个操作步骤，能够在H3的流程监控图中都能体现；演示过程打开模拟的第三方业务系统的表单： http:// 120.25.238.237/ERP/ 【业务系统流程，操作在业务系统】或，直接打开：http:// 120.25.238.237/ERP/POProcess.aspx 1. 录入【显示名称】和【预算金额】，点击【保存】，会自动生成一个【PO编号】。 2. 随后，H3系统的【定时作业】，会监控ERP数据库中的PO表，新增记录自动触发流程启动； 3. 点击【查看流程】，可看到流程监控图中，流程已经启动； 4. 继续在ERP表单中，采购单依次改为->询价、比价、议价、订单下达4个状态，可以将流程触发到不同的环节至结束，说明：可以通过ERP表单中的【查看流程】或H3 BPM中【流程监控>>进行中的流程】，查看流程流程监控图的变化。 5. 3.6 外部表单 3.6.1 访问WS接口功能展示  表单在第三方系统，调用H3的提供的Web Service启动、处理流程；  在第三方系统中的【查看流程】，可以直接调阅H3系统的中流程信息页面；业务场景在实际的业务应用场景，客户在现有的系统中已经有表单了，不想在H3中再重做表单，但是没有流程功能而需要应用H3的流程逻辑（或者已经有流程功能但功能不够强大，需要应用H3强大的流程逻辑来辅助业务执行），那么，H3可以提供Web Service的流程操作接口，供第三方系统调用，实现流程功能。设计过程在第三方系统中，通过调用H3提供的Web Service服务，执行流程的启动、提交、驳回、查看流程等操作。演示过程通过2种途径进入流程表单页面： 1. 在Portal门户的流程中心中发起【外部表单->访问WS接口】流程，点击发起后，打开的页面是第三方表单； 2. 进入第三方系统： a) http:// 120.25.238.237/ERP/ 后选择【Web Service模拟表单】打开： b) 直接进入表单页面； http:// 120.25.238.237/ERP/SheetWS.aspx?Mode=Originate&WorkflowCode=PRWS 3. 第三方系统中【提交】流程后，可以在Portal门户首页的【待办任务】和流程中心的【已办任务】列表中，分别看到刚刚从第三方系统发起的流程待办和已办。 4. 在H3中打开任务链接，直接跳转至第三方系统的表单页面中操作，可以执行【提交】、【驳回】和【查看流程】。 3.6.2 访问API接口功能展示  表单在第三方系统，调用H3系统接口(DLL)启动、处理流程  在第三方系统中的【查看流程】，可以直接调阅H3系统的中流程信息页面；业务场景在实际的业务应用场景，客户在现有的系统中已经有表单了，不想在H3中再重做表单，但是没有流程功能而需要应用H3的流程逻辑（或者已经有流程功能但功能不够强大，需要应用H3强大的流程逻辑来辅助业务执行），那么，H3可以提供API接口的流程操作接口，供第三方系统调用，实现流程功能。设计过程在第三方系统中，通过调用H3提供的API接口服务，执行流程的启动、提交、驳回、查看流程等操作。演示过程通过2种途径进入流程表单页面： 1. 在Portal门户的流程中心中发起【外部表单->访问API接口】流程，点击发起后，打开的页面是第三方表单； 2. 进入第三方系统： a) http:// 120.25.238.237/ERP/ 后选择【API模拟表单】打开： b) 直接进入表单页面； http:// 120.25.238.237/ERP//SheetDLL.aspx?Mode=Originate&WorkflowCode=PRDll 3. 第三方系统中【提交】流程后，可以在Portal门户首页的【待办任务】和流程中心的【已办任务】列表中，分别看到刚刚从第三方系统发起的流程待办和已办。 4. 在H3中打开任务链接，直接跳转至第三方系统的表单页面中操作，可以执行【提交】、【驳回】和【查看流程】。 3.7 业务规则（选择、排序、脚本）功能展示业务规则可以自定义词汇表和规则，实现矩阵式的规则管理。例如以下采购申请审核矩阵：参与者办公用品生产设备采购金额<2000 采购金额>=2000 采购金额<10000 采购金额>=10000 业务主管 √ √ √ 　部门总监 √ 　 √ √ 财务总监　 √ 　 √ 总经理　 √ 　 √ 该矩阵中，根据【采购类型】、【金额】，需要不同的人员进行审核，如果在流程设计中实现，流程逻辑会复杂化。此时可以使用业务规则进行定义该规则，将业务逻辑在业务规则中进行图形化定义实现，更符合业务角度进行理解。业务场景在实际业务中，流程本身并不复杂，审批层级就是4级，但因为业务逻辑关系影响到流程需要非常多的分支来判断，如采购单会根据【采购类型】和【金额】的不同，分别有不同的人来审批；休假申请会根据【假期类型】和【请假天数】的不同，分别会有不同的人来审批。通过H3的业务规则引擎，可以实现业务与流程的耦合，从而达到简化流程的目的，以及方便流程的维护，当公司业务逻辑或公司制度发生异动时，不需要重新来制作流程，只需要维护业务规则表即可，极大的节省了后期的维护成本。设计过程详见《H3 BPM实施开发手册》的第10章：业务规则的详细介绍。演示过程业务规则的演示流程有3条：【采购（排序）】、【采购（选择）】和【采购（脚本）】，分别对应【业务规则->演示规则】中预设的【排序规则】、【选择规则】和【脚本规则】。 1. 选择规则：选择规则是将需要执行的单元格按照选中状态进行串联起来，将参与者最终赋值给指定的参与者类型词汇，例如以下表示涵义为：  当采购类型是办公用品时  金额小于2000，需要主管审核；  金额大于等于2000，需要主管、财务总监审核；  当采购类型是生产设备时  金额小于5000，需要主管、采购总监审核；  金额大于等于5000时，需要主管、采购总监、财务总监和分管副总审核； 2. 排序规则：排序规则是将所有需要执行的单元格将连续的数值连接起来，将参与者最终赋值给指定的参与者类型词汇，例如以下表格：表示涵义为：  当采购类型是办公用品时  金额小于2000，需要主管审核；  金额大于等于2000，需要主管、财务总监审核；  当采购类型是生产设备时  金额小于5000，需要主管、采购总监审核；  金额大于等于5000时，需要主管、采购总监、财务总监和分管副总审核； 3. 脚本规则：脚本规则是执行所有满足条件的单元格的脚本，对词汇直接进行赋值。 4. 在Portal门户的流程中心中发起【业务规则】目录下的3条流程：分别输入不同的【采购类型】和【总金额】，观看流程流转的变化。提示：发起流程页面，审核人不用选择，流程提交之后，系统会自动根据设定的业务规则，列出需要参与的审批人，按顺序排序，详见下图。说明：流程的审批顺序按【审核人】的顺序执行【串签】，直至最后一人审核后到流程结束。 4 业务规则业务规则的使用，请参考《H3 实施开发手册》演示环境中已实现的【演示规则】，详细请参考本手册【流程模型】章节的【业务规则（选择、排序、脚本）】的应用；

Webservice是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

Excel POI读取封装(文件+示范代码) package org.excel.service; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.FileWriter; import java.io.IOException; import java.lang.reflect.Field; import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.text.DateFormat; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.*; import javax.jws.WebService; import org.apache.poi.hssf.usermodel.*; import org.excel.data.DataType; import org.excel.data.DealForeign; import org.excel.data.ExcelImport; import org.excel.data.impl.StInStatusImpl; import org.excel.data.impl.StuClassImportImpl; import org.excel.data.impl.StuEducationImpl; import org.excel.data.impl.StuImprotDataImpl; import org.excel.data.impl.StuInClassImportImpl; import org.excel.data.impl.StuWorkStatusImpl; import org.excel.manager.Util; import org.excel.model.ExcelMap; import org.excel.xml.ExcelXmlParse; import net.sourceforge.jtds.jdbcx.JtdsDataSource; @WebService public class ExcelServiceImpl implements IExcelService { String tableName = ""; public static Integer suc = 0; public static Integer fail = 0; StringBuilder insert = new StringBuilder( " insert into {tableName} {column} values {values}"); /** 读取Excel表格数据 */ public List readExcel(String excelName, Integer sheetIndex, String startPoint, String endPoint) throws Exception { FileInputStream inputStream = null; inputStream = new FileInputStream(excelName); HSSFWorkbook workbook = new HSSFWorkbook(inputStream); HSSFSheet sheet = workbook.getSheetAt(sheetIndex); String[] sc = null;// 开始坐标 String[] ec = null;// 结束坐标 int startRow = 0;// 默认开始行数 int endRoe = sheet.getPhysicalNumberOfRows();// 默认结束行 int startLine = 0;// 默认开始列 int endLine = 0;// 结束列 if (startPoint != null && endPoint != null) { sc = startPoint.

我们今天以企业用户常用的CRM系统，来看一看标准的SaaSCRM应该是一个什么样子。　　实际上，很多用户对于CRM并不陌生，早在2000年的时候，有一些企业就已经开始尝试CRM系统。在很多人眼中，CRM就是一套C/S或者B/S的应用系统。　　而当CRM进入了SaaS，他在架构上会是一个什么样子呢?我们以361CRM为例，来看一下SaaSCRM的架构。　　361CRM系统采用分布式架构。采用企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分主要为四层，根据调用关系依次为应用层、缓冲层、服务层以及存储层，如下图所示：　　应用层　　从浏览器发送过来的请求，直接由应用层来进行直接响应; 　　平台是多租赁用户的在线多应用来实现的，由于每个用户的具体业务需求不同，因此每个租赁用户的应用是相互隔离的，但应用层的结构却都是相同，从上到下主要分为业务展现层、业务逻辑层、业务模型层、实体访问层; 　　业务展现层主要为用户数据的不同视图表现，为用户呈现各种易于浏览、便于理解的各种数据表现方式，如表单、表格、报表、图表等; 　　业务逻辑层主要是业务逻辑的具体实现层，对于用户动作、触发事件以及工作流程等由业务逻辑层来实现业务的处理以及响应，通过业务逻辑层对下层业务模型的访问来实现具体的逻辑处理; 　　业务模型层主要是业务对象的具体定义与封装，是对于现实中业务在平台中的最直接的映射; 　　实体访问层是对于业务逻辑层对于业务模型操作的封装，业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。　　缓冲层　　缓冲层主要对于静态资源以及动态数据的缓存。静态资源主要是指应用层中展现层中所要使用到的静态资源文件，以及由用户在业务操作中产生的文件等，如图片、上传的文件等; 　　而动态数据是指用户在使用平台的过程中所产生的业务数据，在实现业务中，这部分数据大部分都是读操作比较多，而写操作比较少，因此可以针对这部分数据根据特定的缓存失效策略机制来进行相应的缓存; 　　缓冲层的缓存针对应用层是透明的，而且针对多应用也是透明的，因此缓冲层具有更大的弹性与灵活性。　　服务层　　服务主要是指平台的核心服务，核心服务分为业务共通服务以及平台共通服务，平台共通服务是指与业务无关且是平台最基础的服务，如任务调度、消息队列、邮件服务、图片处　　理、工作流引擎等;而业务共通服务指基于平台共通服务，而对于所有业务具有共通性的服务，如日志审核、操作回滚、数据安全、全文检索、权限角色等; 　　服务层是对于平台运营、维护最核心的服务实现，是平台正常运行的基础。　　存储层　　存储主要分为两部分：分布式文件存储以及分布式的数据存储; 　　由于是多应用的平台，因此随着平台的运营，会产生海量的业务数据以及资源文件，因此伴随着海量的数据而来的问题就是存储、检索、分析以及统计等问题; 　　针对上述问题，361CRM平台采用了分布式的存储系统，基于Map-Reduce来进行相应的检索、分析以及统计，实现了对于海量数据的统一操作。　　这种结构能做到真正的分布式网络计算，有效降低网络流量，减轻客户端负担，还能安全、方便地与互联网接口。另外公司员工或客户分布或行走于全国各地，通常都有移动办公需求。　　REST 架构　　REST是基于HTTP的，因此天生就有在互联网上穿透防火墙的能力，REST可以简单地认为它是轻量级的WebService，但是它具有自己的一些显著特点：　　所有的资源通过统一的接口访问(HTTP/HTTPSGET、POST、PUT、ELETE)，而且接口比较统一，便于与第三方的集成; 　　因为是基于HTTP/HTTPS的，因此可以将资源(响应)分为可缓存的和不可缓存的，以及采用浏览器的标准压缩方式，有效地提升网络效能。也可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等; 　　因为是基于HTTP/HTTPS的资源请求，因此本次连接和下一次到服务器的连接之间没有状态。由于361CRM平台采用了REST架构，因此也就决定了361CRM平台天然就具备以下几方面的优势：　　由于REST本身无状态的特性，361CRM平台天然就是分布式的，决定了后台通过根据业务量而弹性地增加服务器就可以实现平台计算能力的线性增加; 　　所有的请求都是统一通过RESTAPI进行相应的资源与服务的请求，这样就能够保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性，同时也能够根据业务进行相应统一且透明的内存缓存　　客户端浏览器能够轻松通过Ajax实现REST资源的异步调用处理，同时也可以有效地减少应用服务器地压力　　通过提供开放的RESTAPI，能够轻松实现与第三方的集成　　平台服务　　平台服务层的调用是通过RESTAPI进行的，由于REST的特点，通过在URI中添加资源路径以及版本信息，很方便地能够实现平台的平滑升级以及数据兼容性问题。　　平台服务层实现的都是共通的服务，服务之间是独立的，而且是插件式的方式来实现的，平台选用了面向分布式计算的Erlang语言来实现的，因此保证了这些插件式的服务能够热拔插地部署，实现真正地不宕机地部署与更新。　　平台服务层的插件式架构，决定了平台的无限扩展能力，能够根据不断变化地用户需求而进行平台的不断地在线迭代与更新，与用户的需求形成一个良性的循环。配置定制平台通过服务器(Apache)的自定义开发，实现了企业用户应用的透明隔离，因此平台具有面向不同企业用户根据不同需求进行个性化定制的能力。不同的企业用户，一般主要有几方面的自定义需求：业务对象、工作流程、报表、布局等，而361CRM平台的平台框架就决定着能够很好地满足用户的自定义需求，主要分为以下几个方面：　　由于用户使用的是文档数据库，有着松散的数据结构，因此用户根据需求，而可以随意自定义自己的业务对象; 　　361CRM平台后台的平台服务层，有相应的实时的工作流引擎，提供给用户强大的自定义工作流程功能; 　　361CRM平台有业内是丰富的报表模板，用户只需要根据自己的需要来选择即可，针对一些自定义的动态数据，还提供模板的再定义功能，能够很好地满足用户的报表需求; 　　由于平台是应用隔离的，因此针对着页面的布局，可以很容易地实现个性化地定制; 　　361CRM平台的配置功能的强大，并不以损失平台应用的易用性为基础，361CRM平台在操作上采用引导式操作，以及提供方便易用的在线帮助，大大地降低了系统使用的复杂度，使系统更加地人性化、简易化。　　实时即时　　361CRM平台的平台服务层与通常的应用服务不同，它是实时运行的服务，平台服务层有相应的任务调度机制，邮件服务、消息队列以及实时的工作流引擎等，这些服务都是实时运行的，因此当企业用户的业务对象或者业务流程发生变化时，通过这些平台服务就可以把即时的状态消息(通过邮件、短信或者其它的IM工具)推送给用户，让用户真正了解到业务的即时与实时的状态信息。　　而通常的应用服务是静态的，只有当用户登录时，才会进行相应的业务状态的检查，这样就严重影响了业务处理的速度，对于即时性业务，就会带来很大的损失。　　多级负载　　平台是一个多租赁用户的在线SaaS系统，因此会给平台带来大量的高并发的请求，361CRM平台是一个多层次的结构，而且采用了REST架构，REST天生就是分布式，因此通过物理部署就可以实现高并发带的负载均衡。　　四层负载在链路层解决来自互联网的并发请求压力，使用LVS+Heartbeat的主从双备的架构，保证不会出现单点故障; 　　Web应用的大部分压力都来自于资源的请求，如图片，静态文件，样式表等文件的请求，服务器压力的70%都来自于这些资源的请求，因此对于这些静态资源的请求，通过静态资源缓冲层就能够很好解决这些请求对于后台造成的压力; 　　经过实测，经过一段时间稳定运行之后，静态资源缓冲层能够命中前台请求的80%以上，有效地缓解了应用服务器的压力; 　　七层负载层主要是做业务、以及资源的请求分流，把负载均衡到多台文件服务器以及应用服务器上; 　　文件服务器与应用服务器是分布式的，通过Map-Reduce进行任务的拆分与结果的合并，充分利用多台服务器的并行计算能力，提升整体平台的运行性能; 　　文件缓存采用多级缓存策略，解决命中率高的文件的频繁请求。而数据缓存则通过业务标签以及时效性策略进行数据的缓存，并且进行缓存的增量更新，有效地解决了对于后台的　　数据读写压力; 　　分布式的存储系统有效地解决了海量数据的存储、检索、分析以及统计等问题。　　可见，当传统的CRM系统转换为SaaS服务后，其架构方面还是发生了不少的变动的，也只有这样的变动，才使得CRM能够在SaaS平台上更好的为客户所服务。　　附：什么是REST架构　　REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术，同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网，这种网络将会使得搜索更加智能化。　　REST与HTTP协议　　REST软件架构是由RoyThomasFielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构，或者更进一步把REST和HTTP看作为等同的概念。　　今天，HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位，而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现，才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导，才能避免在软件开发的实际工作过程中少走弯路。　　REST与URI(资源定位) 　　REST软件架构之所以是一个超媒体系统，是因为它可以把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word还是视频文件，也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。　　REST与CRUD原则　　REST软件架构遵循了CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建、获取(Read)、更新和销毁就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作：(生)、select(见)、(变)和(灭)，所以有时候CRUD也写作为RUDI，其中的I就是，这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。　　REST与网络服务　　尽管在Java语言世界中网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议，而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作，它们完全独立于HTTP协议来进行的，这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题：如何实现网络服务才能充分利用现有的HTTP协议?该问题给出了四个答案：去问微软;WSDL2.0/SOAP1.2;WS-Transfer;根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议，而是一个聪明的会表现自己的协议，这也许是REST=RepresentationalStateTransfer的真正含义。　　实际上目前很多大公司已经采用了REST技术作为网络服务，如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是ApacheCXF和Axis2.Java语言也制定关于REST网络服务规范：JAX-RS：JavaAPIforRESTfulWebServices(JSR311)。相信还会出现更多与REST相关的激动人心的信息。　　REST与AJAX技术　　尽管AJAX技术的出现才不到两年时间，但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人员，就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构，凡是采用AJAX技术的页面简洁而又丰富，一个页面表现了丰富多彩的形态。　　AJAX技术还使用了一种不同于XML格式的JSON文件格式，这个意义在哪里呢?在REST软件架构下我们不能对于XML文件进行序列化处理，这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可，它被认为能以远比XML更好的方式来序列化和传输简单数据结构，而且它更简洁。这对REST是一个极大贡献和补充。　　当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态，客户端的状态自己来管理，这是AJAX技术的应用之地。通过AJAX技术，可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。　　REST与Rails框架　　RubyonRails框架(简称Rails或者Rails框架)是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持，也是当今应用REST最成功的一个软件开发框架。Rails框架(从版本1.2.x起)成为了第一个引入REST作为核心思想的主流网络软件开发框架。在Rails框架的充分利用了REST软件架构之后，人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST，它是网络服务最理想的手段，但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃，让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。　　REST安全性　　我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻，前者是一种传统的寄信方式，而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话，传统的寄信被送到对方就很危险，而电子邮件是开发的，电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒，而是说明HTTP是无法处理SOAP信息包究竟好不好，需要额外的软件工具解决这一问题，包括防火墙也用不上和管不了。　　REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包，如你可以规定从外部来的只能读取(GET操作)自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证(BasicundDigestAuthentication)。除了这些REST自身的安全性功能外，还可以利用像基于信息的WebServicesSecurity(JSR155)作为REST不错的补充。　　我曾经遇到一个求职者，他的简历看起来不错，基本上没有大问题，但他就是没有收到任何回复。一天我半开玩笑似的问他是不是电话写错了，我一检查，果不其然。他改正后，立即收到了他所期望去的公司的面试电话。从这个故事中我们得到一点教训：哪怕只剩最后一秒钟，也要检查你的联系方式两遍。这是理所当然应该做到的细节，早做比晚做好。

12,162

社区成员

16,328

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章