在SaaS平台上进行CRM二次开发的经验

　　CRM是客户关系管理系统的简称，于上个世纪90年代初逐渐形成，慢慢作为一个领域应用真正发展起来，并被国外大多数企业验证能够为企业大幅提升销量及巩固客户关系。但CRM也一直因为实施复杂，及价格昂贵而被称为“富人的游戏”。

　　随着CRM在国外如火如荼的发展，国内企业发展中也显现出对客户关系管理的迫切需求。在技术层面，互联网的广泛应用和技术的突飞猛进，把SaaS平台运营模式引入CRM的发展中，大大降低了实施CRM的成本。但国内企业层次不齐的管理水平，以及行业管理需求的差异，使得CRM应用到企业时必须要作调整。而CRM二次开发则可以使产品像虚拟主机那样快捷易用，同时又拥有无限的功能延展性。

　　日前，国内领先的SaaS平台运营商风云在线联合微软中国举办的“设计——我能 微软CRM模板设计大赛”正式拉开帷幕。大赛目的旨在激发设计人员们的设计热情，开发出大量具有高市场接受度的CRM产品，并进一步促进SaaS产业升级。

　　大赛自9月份进入产品设计征集阶段以来，得到了业内广泛支持。微软CRM4.0是一个快速的企业级应用开发平台，可以随着企业业务的发展进行软件的同步的升级，广大网友总结并汇总了在快速开发CRM方面的经验，特此汇总分享：

　　Picklist VS Lookup

　　在设计业务状态字段时建议采用Lookup(关系)类型，这样便于用户在企业业务调整的时候能够自行进行设置，而不用系统进行任何调整。

　　Javascript VS ISVConfig

　　在进行页面按钮控制的时候可以通过Javascript在From的OnLoad事件中进行控制也可以在ISVConfig文件中进行配置，这两者各有特点，但是相对而言在OnLoad中用javascript控制更加灵活，比如可以控制按钮在指定状态指定用户浏览的时候才显示(权限控制，如审核);在OnLoad事件中的Javascript脚本写起来也比在ISVConfig中相对容易而且测试也方便;而且OnLoad还可以设置事件是否生效;两者共同的特点就是方便导入导出，便于移植。

　　ISV Web Application VS Plug-in

　　有时候在CRM表单上执行一些操作需要激发后台相关操作，在这种情况下可以采用外挂网站的方式(ISV Web Application)或者采用Plug-in的方式。基于CRM模板的方便部署、维护性，建议采用Plug-in方式。(如果是传统方式部署的话建议大家采用外挂网站方式，这样开发调试都相对容易)

　　Plug-in VS Workflow

　　CRM中的工作流是异步执行的，所以所有触发工作流所做的修改不能立即生效并在界面上看到，而且如果工作流执行过程中如果产生了错误，也不能即时的通知用户，但是Plug-in可以配置为同步的方式执行，避免异步工作流的这个问题。

　　同时Workflow的工作流具有很好的可配置性，能够进行用户级的配置，但是Plug-in的逻辑却是编程时既定的，所以综合看来各有各的用武之地，需要根据业务的需要进行灵活的选择。

　　Wait/ Timeout Workflow VS Common Workflow

　　CRM的工作流提供了很多的选择条件，其中需要提到的就是等待条件和超时条件。基于等待条件可以建立等待工作流，这种工作流可以基于工作流创建的对象/任务进行判断推动工作流的执行，比较典型的例子就是销售漏斗;Timeout工作流实际上也是一种等待工作流，但是这种工作流会超时结束，可以利用这种工作流建立例行计划，如建立每天的电话销售提醒。

　　系统中如果存在太多的等待工作流有可能会造成系统资源开销增大从而导致工作流不能正常执行，但是官方并没有对此进行声明，所以本着谨慎的态度，如果系统中需要使用工作流建议采用普通的条件工作流;建议尽量少使用等待工作流，如果必须使用建议配合超时条件一起使用，这样系统的等待资源会保持在一个可控的范围内。

　　CRM Database Transaction

　　据CRM官方说明显示可以通过将Plug-in注册为Child pipeline的方式来支持数据库事物，但是测试发现如果在Plug-in中执行了多个CRM操作，在抛出异常之前执行的操作不会被回滚。如下图：

　　如果位于Child Pipeline的Plug-in在执行到步骤C的时候发生了异常，将导致位于Parent Pipeline的操作回滚，但是在Child Pipeline中的A、B步骤提交的操作将不会被回滚。所以，如果是简单的操作应该是没有问题的，如果是执行有逻辑的长过程操作，建议用户通过程序自行控制事务(通过状态标记实现)。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。