Microsoft Dynamics CRM 2011:一个部署,多种基础语言

CRM 4.0能够支持多至41种语言,如果你对这一点很满意,那么你肯定会喜欢CRM 2011的这个功能。    Microsoft Dynamics CRM 2011 Beta已经具有这个不是很明显的功能,它支持在同一个部署中来放置使用不同基础语言的组织。   在Dynamics CRM 4.0中,服务器的安装语言决定了你能够创建在这个部署上所有组织的基础语言。现在,在Microsoft Dynamics CRM 2011中,只有第一个组织的语言是与服务器安装语言绑定的,随后在同一个部署中创建的所有其他组织,都能够使用这个部署中所安装的相应的语言包,来为这些组织设置不同的基础语言。   例如,虽然Microsoft Dynamics CRM 2011 Beta版本只提供英文的服务器组件,但你能够用下列基础语言来创建组织:英语,法语,德语,希伯来语,意大利语,日语,西班牙语和简体中文。这也意味着,当产品最终发布,不管服务器是哪种安装语言,你都能够使用41种语言中的任何一种来创建组织。     它操作起来十分简单。作为创建组织的一部分,你会被要求选择一种基础语言。下拉菜单中你所看见的基础语言来自你的部署中可用的语言包。     尽管上述功能是针对On-premise版本的产品,在Microsoft Dynamics CRM Online 2011中也是可行的,你能在注册的过程中选择你的组织的基础语言。     谢谢!   原文地址: http://blogs.msdn.com/b/crm/archive/2010/09/24/microsoft-dynamics-crm-2011-many-base-languages-one-deployment.aspx   Jackie Chen(陈攀)    


简介CRM 2011 Solution

在刚发布的Microsoft Dynamics CRM 2011 beta中,在自定义扩展方面有许多有特点的功能,其中一个比较重要的就是“Solutions Management”(Solution可译为解决方案,下文中将使用原文表述)。   还记得在以前的CRM 版本中是怎么进行功能扩展的吗?让我们将之提到一个新的高度。使用CRM 2011,我们能够在几天内(一些核心组件甚至可以在几小时内完成)定义,转移,部署,维护并使用架构在CRM框架上的整个商业应用,而不像以前需要几个月的时间。仅仅点击几下鼠标,你就能够定义你的数据模型,工作流程,用户界面和分析工具。一些高级扩展,例如.Net plug-ins 和 SRS 报表,都能够包含在CRM Solution中。所有内容都能够以一个统一的模型进行转移和部署。   这绝对是一个了不起的功能。CRM 2011 允许我们将组件打包并将其视为一个“Solution”。为何说这个功能了不起呢?下面才是关键点。不仅仅因为它允许将组件打包,而是因为系统平台现在能够知道solution的边界,并执行相应的智能操作。请继续往下阅读。   开发和发布Solutions来控制客户化(unmanaged和managed) 对于大多数以前为CRM4开发人员的“新人”来说,第一件事情就是我们引入了unmanaged和managed solutions的概念。可以把unmanaged solution理解为你的系统的源代码,而把managed solutions理解为编译后的版本。当然,你不必在这点上咬文嚼字,因为CRM中的一些组件只是“定义”,不需要被编译;但尽管如此,这种类比还是十分有用的。所以,当你最初创建一个solution的时候,它总是被创建为unmanaged,你能够创建新的组件并修改其他组件。你甚至能够定义一些限制来使solution的管理更方便,例如将一些组件设置成不可自定义化。   当solution已经完成并准备最终发布使用,你可以将其导出为managed。当客户安装了一个managed solution,我们强制执行你所设定的任何限制(例如:设定某些组件为“不可客户化”来阻止对其进行客户化)。尽管solution自身不能被修改,可客户化的组件仍然可被客户化,但系统会将这些客户化视为在managed solution的“上层”所作的修改。因此,你拥有更灵活的选择,你能够限制一些组件不可被客户化,而对其他组件仍然具有内嵌的扩展功能,并且不需要写一句代码。   智能更新 如果你允许客户修改你的solution(创建在上层),将会给你将来的维护工作带来噩梦般的困难。其实并非如此,我们会帮你解决。每当你对一个managed solution进行更新时,系统架构会自动保存创建在上层的客户化。我们有2种基本的冲突解决方案(merge and preserve),这点我将在随后的帖子讲解。总之,这两种冲突解决方案的结果是让客户能够维护他们的客户化,并且你仍然能够进行更新。   自动记录依赖关系 你怎么能够记录什么组件在哪里被用到,并且没有被意外删除而影响其他组件呢?如果你允许客户进一步客户化你的solution,那么这个问题会更加严重。不需要担心,因为solutions的架构会自动地记录系统中所有的依赖关系,相当了不起的功能!   一处创建,多处部署 在CRM框架上创建的solution能够在所有的CRM部署类型(Online, Partner Hosted, On-Premises)和所有的CRM客户端(Web, Outlook, Mobile)传送。它真的越来越接近开发者所崇尚的神圣目标“code once, deploy/use everywhere”。哦,对了,我有提起过我们还可以在Outlook client上将你的solution变成“离线状态”吗?有多少构架能够提供这种功能?   Solution共存 目前为止,一切都不错,但如果一个用户安装了多个由不同的合作伙伴创建的solution,那么它们会相互影响吗?事实上并不会,solution框架自动处理让2个或多个managed solution能够共存。但是,不同的solution必须要有一定关联才能共存(在功能上,要有意义)。尽管从技术上说,在同一个组织(organization/tenant)中安装两个完全不相关的solution(例如医院管理和教育管理)是可行的,但最终结果或许对终端用户来说没有任何意义,特别是如果两个solution需要修改共同的组件(例如一个希望把客户(Account)当做医院,而另一个希望把客户(Account)当做学校)。  …


使用Microsoft Dynamics CRM 来做简单的运算

CRM工作流能够用来做简单的运算。我碰到过很多用户不了解这个功能,所以将这个话题写成博客应该比较有意义。下面将提出一个例子,使用工作流做一些简单的运算。   在建立这个工作流之前,在[商机]的页面上添加一个属性叫做[加权收益],类型为money。    下面来创建一个工作流,由[预计收入]和[可能性]来计算得到[加权收益]。在CRM中,[可能性]是整数形式,因此[加权收益]= [预计收入]* ([可能性]*0.01).   将[可能性]赋值给[加权收益]:   将[加权收益]的值乘以0.01。这是使用运算符“乘”来实现的:  现在用[加权收益]中的值乘以[预计收入]:   这是一个非常简单而且很棒的计算[加权收益]的方法。我相当喜欢这种方法。事实上,我们花了仅仅4分钟就实现了这个功能。   谢谢!   原文地址:http://blogs.msdn.com/b/crm/archive/2010/09/14/using-microsoft-dynamics-crm-to-do-simple-calculations.aspx   Jackie Chen(陈攀)    


Microsoft Dynamics CRM 2011升级场景

随着近期Microsoft Dynamics CRM 2011 beta的发布(在www.crm2011beta.com注册),如何从一个版本升级到另一个版本成为大家关注的问题。微软花了大量的时间和精力来确保从一个版本到下一个版本的升级能够很顺利,即使产品功能上有很大的改变。微软给客户充分的选择空间,为On-premises和CRM Online部署分别提供了多种升级途径。   下面来介绍一些缩写词: Release To Web (RTW): CRM Online正式发布版。 Release To Manufacturing (RTM):   CRM On-premises 发布给制造商版 Beta不用在生产环境中。   对于计划使用CRM 2011 Beta版的客户,首先必须注意的是Beta版不能用于生产环境。Beta版并不是一个能得到完全技术支持的版本,此版本中遇到的任何问题不会得到技术支持部门的直接支持。微软将使用一个微软论坛来支持所有的Beta版中的问题。   无论是Online还是On-premises版,Beta版本都是一个很好的测试环境,它让你能够测试即将发布的Microsoft Dynamics CRM版本,开始了解更多它能给你的组织带来的好处,开始创建一些新功能的样例,并开始设计CRM 2011正式发布后的工作内容。对于一些决定开始用Beta版做一些配置和客户化的客户,有升级途径可以使你们的solution从一个版本升级到下一个。下面,我来列举一些CRM 2011 Beta版中你们比较感兴趣并且比较重要的升级场景。   从 CRM Online Beta 升级至 CRM Online RTW 对于希望在生产环境中继续使用CRM Online的客户,我们将提供一种由用户决定参与的升级方式。如果客户决定要签约并继续使用CRM Online,所有被支持的客户化和配置都将从Beta升级到RTW。   从CRM 2011 Beta升级到CRM 2011 Release Candidate,然后升级到CRM 2011 RTM 对于使用On-premises的客户,产品具有这种升级的功能,但只会通过Beta支持流程(微软论坛),提供有限的技术支持服务。  …


Trust for Delegation in List Web Part for Microsoft Dynamics CRM 4.0

使用On-Premise类型部署的Microsoft Dynamics CRM 4.0 (MS CRM),如果CRM Server和SharePoint Server装在不同的物理机器上,将会遇到信任委托(Trust for Delegation,以下简称为TFD,有时也被理解为Double-Hop impersonation)的问题,这篇文章将会讨论这种情况下TFD的配置.   以下场景将不受TFD的影响: 1.      需要部署List Web Part (LWP)的MS CRM采用Internet Facing Deployment(IFD). 2.      Microsoft Dynamics CRM 和 SharePoint Server装在同一台server上. 当使用On-Premise类型部署的MS CRM和SharePoint 装在不同server上时,使用LWP的MS CRM用户在认证(authentication)时会遇到问题.如果SharePoint Server没有配置过TFD,用户的Active Directory 凭证(credentials)不会传递到MS CRM Server.部署在SharePoint上的LWP不会从SharePoint接收CRM认证票据(authentication ticket),而是显示一个使用IFD安装时的登录界面.下图为LWP的配置和登录界面.未配置TFD时,会显示这个界面.     图1:IFD部署下的配置和登录界面    什么是双跳(Double Hop)问题? 当MS CRM Server和SharePoint Server装在不同机器上时,第一条是从LWP用户的IE浏览器到SharePoint Server,然后第二跳是从SharePoint Server到MS CRM Server.由于安全问题,Windows凭证在第二跳中不能被传递.为了使SharePoint Server能够传递用户凭证,必须为SharePoint Server配置TFD.   配置Trust…


在CRM 4.0中配置工作流来实现业务数据审核

Microsoft Dynamics CRM 4.0为用户提供了一个基于WWF的强大的工作流平台。在这个配置完善的平台上用户能够在不需要编写一行代码的情况下方便地建立很多工作流。 业务数据审核(Business Data Auditing)是CRM等商业软件的一项常见需求,主要是指系统对业务数据的变更过程进行记录。这篇文章将告诉你如何为Microsoft Dynamics CRM4.0部署建立全面综合的数据审核。这个示例能够将你的解决方案中所有记录的任意一栏的变更情况全部记录下来,当然如果你的数据审核的需求相对简单也能够仅仅对某些变更事件进行记录,对于这两种情况Microsoft Dynamics CRM 4.0都能够通过简单的操作来实现。 下面介绍一下该解决方案是如何实现这一需求的: 对于每个需要进行审核的CRM实体,建立一个与之相关的自定义实体来存放CRM记录的变更情况快照。例如如果我们想审核有关联系人的数据,就建立一个叫“审核联系人”的实体,这个实体包含我们需要审核的联系人实体的所有属性。 设计“审核联系人”实体的表单,加入我们需要审核的字段,然后发布。 编辑关联视图来展示待审核的属性。 对于需要审核的实体和属性,建立由“创建”和“更改”事件触发的工作流,该工作流会建立一条新的“审核联系人”记录来记录创建或变更的“联系人”属性。 每当创建或更改“联系人”时我们都能得到一条“审核联系人”记录,这样通过关联视图就能看到完整的“联系人”记录变更历史。 创建自己的报表来打印审核记录;设置审核记录的安全性来防止它们被更改或删除。 下面通过如下步骤建立一个Dynamics CRM的联系人记录审核系统。通过示例中的方法你能够对任何实体进行审核。  步骤1:创建如下自定义实体: 步骤2:创建Contact Audit的属性: 尽管可以添加任意数量的属性,但最好只添加需要审核的属性。例如如果你不想审核Yomifirstname就不需要在Contact Audit中创建这个属性。 步骤3:在实体Contact与Contact Audit之间创建一个多对一关系。 将行为类型设置为引用,限制删除以防因记录被删除所导致的不能审核。 步骤4:设计Contact Audit的表单,在表单中显示创建的所有属性。 步骤5:配置Contact Audit实体的关联视图来在列表中显示你所感兴趣的属性。 步骤6:发布以上所有更改。 步骤7:在安全角色中设置Contact Audit实体的合适的安全属性。 步骤8:创建一个“联系人审核”的工作流。  点选已创建记录和记录属性更改的选项。 步骤9:点击选择进入属性选择界面,选择你需要关注更新情况的属性。 此处并不需要选择所有的属性,只需选择想要关注的属性。如果以后想添加或删除任意一项属性,随时可以进行更改。 步骤10:在添加步骤中点选创建记录,在创建后面的下拉菜单中选择Contact Audit并点击设置属性。 步骤11:在添加步骤中点选检查条件,以此来判断当前触发工作流的操作是创建还是更新。 如果创建时间等于修改时间则是创建操作,反之则是更新操作,最后点击保存并关闭。 步骤12:如果是创建操作则添加一个更新记录的工作流步骤用于更新名称属性来反映当前是创建操作。 步骤13:在添加步骤中点选分支条件用来处理更新操作。如上添加一个更新记录用于更新名称来反映当期是更新操作。 最后发布工作流,这样就可以审核有关“联系人”的业务数据了。参照以上方法你可以建立工作流来审核任意其他实体。 还可以通过以下方式来完善该解决方案: 创建SSRS报表来显示审核记录。 添加其他工作流触发事件以使之支持对分派和删除的审核。 由此可见,Microsoft Dynamics CRM4.0的功能是十分强大的!你不需要.NET的开发技术就可以完成很多事情,希望通过这篇文章你能够学会如何配置工作流来完成对你工作更有益的事情。 原文出处 翻译:…


如何使用Microsoft Connect站点提交对产品的建议

Microsoft Connect是微软和客户的交互站点。在Microsoft Connect中可以进行许多操作,比如下载最新的软件和文档,在论坛中做调查,交换意见等。最重要的是微软可以根据客户的反馈意见改进微软的产品,从而为客户提供更好的服务与软件。 本文将以微软的产品Dynamics CRM为例,详细阐述如何使用Microsoft Connect。 1. 注册加入Microsoft Connect 1)Microsoft Connect的网址为https://connect.microsoft.com/,需要使用你的Windows Live ID登陆。 登录Microsoft Connect后,界面如下图所示: 2)点击右边的“立即注册Connect”按钮进行注册。注册后便可以使用Connect的各项功能,注册界面如下所示:   在注册界面中“*”标注的字段为必填字段,电子邮件地址既可以是Hotmail的邮件地址也可以是别的邮件地址。 注册后需要填写一个“显示名称”:   3)注册完成后,便可以进入Connect的控制板了,这个时候,由于是第一次使用,没有提交过意见,也没有添加任何关注的内容,所以控制板上的内容为空:   2. 提交意见 1)注册Connect后,便可以对微软的产品提交意见,以Dynamics CRM为例,在给CRM提交意见之前,我们需要先将其添加到控制板中。点击Connect页面右上角的目录菜单,进入目录中:   在页面左边的类别中,选择“商业软件”,可以看到Dynamics系列的产品:   在列表中找到Microsoft Dynamics CRM,点击“申请”来将其添加到控制板中。点击“申请”后会转到对CRM提交和查看意见的界面,可以点击“CREATE NEW”来提交意见,也可以“SEARCH EXISTING”来搜索并查看意见:   2)点击“CREATE NEW”来提交反馈意见:   在“访问权限”中,如果选择public,那么所有注册了Connect的用户都可以看到和答复该意见,也可以对该意见进行投票。如果选择private,那么只有微软能够看到这条意见,并对其进行答复。 提交意见后,可以在控制板中看到这条意见(如果看不见,请将“显示项”设置为“所有项目(无论是否更新)”): 可以点击该意见进入查看:   3. 搜索和查看他人提交的意见 在图8所示的界面中点击“SEARCH EXISTING”,可以搜索并查看更多的意见:   在这里我们可以搜索自己感兴趣的内容,下图显示了搜索“CRM workflow”的结果:   我们可以点击进入一个反馈意见以查看详情。进入后将看到以下界面:   在该页面中,可以利用左边的红色和绿色箭头对该意见进行投票。点击绿色箭头表示认为该意见重要,点击红色箭头表示认为该意见不重要。 如果需要将该意见加入到监视列表,可以在右侧的监视列表处点击“添加”,将此反馈意见加入监视列表中。加入后,就在控制板就可以看到该意见的进展情况。  …


理解CRM 4.0异步服务的数据结构AsyncOperationBase ( part 2)

在理解CRM 4.0异步服务的数据结构AsyncOperationBase ( part 1)中我们有张表格介绍了异步服务更种System Job的状态。这些状态通常在界面上通过登录CRM后检查系统工作列表能够看到。大家是否注意到有些jobs被现显示为失败,有些允许手动重试resume/cancel,有些可以自动恢复执行? Gonzalo Ruiz的博客解释了背后的逻辑: Gonzalo Ruiz: When do asynchronous jobs fail, suspend or retry?   本文概要翻译一下作为参考。   当StateCode=1时候,根据错误严重级别AsyncService有如下三种逻辑决定下一步处理办法: Fail: 该错误致命的,本job将不会被继续执行或者重试 Retry: 该错误严重级别低,系统将在一定时间内自动重试执行 Suspend: 该错误严重级别中等 – 将导致job被挂起,管理人员必须通过界面手动干预重新执行激活该job   那么错误严重级别如何决定呢?可以参看下表: 注意:AsyncOperationBase表格的ErrorCode和Message列记录了详细的错误信息.表格中工作流作为一种特殊的job,由于有人机交互的机会干预更改错误,所以很多情况下系统倾向为挂起工作流job。本表格仅是示例的一部分供参考,实际代码要复杂的多。 Scenario Async job result action Workflow result action ErrorCode An SDK call fails: Infinite loop detected fail fail 80044182 An SDK call…


理解CRM 4.0异步服务的数据结构AsyncOperationBase ( part 1)

AsyncOperationBase库表随着时间和业务量增长可能会增长到很大程度,从而影响到CRM AsyncService的性能。 如果安装了CRM 4.0 Update Rollup 3 (或更高版本), AsyncOperationBase表格可以有自动清空类型为AsyncOperationType=1 和 10的记录。 – http://support.microsoft.com/kb/957871/ 自动清空AsyncOperationType=1记录 (需手动添加注册表DWORD AsyncRemoveCompletedJobs=1方能生效) – http://support.microsoft.com/kb/968755/ 自动清空已经完成的工作流中间记录 (需手动添加注册表DWORD AsyncRemoveCompletedWorkflows=1方能生效) 下面文章有手动SQL脚本定向清除某些记录。  http://support.microsoft.com/kb/968520   表1: Asyncoperationbase table – operationtype, status code and state code AsyncOperationType Name Description 1 Event    系统事件,比如WorkflowExpansion Task 2 BulkEmail     3 Parse      4 Transform      5 Import      6 ActivityPropagation…