创建microft Dynamic CRM图形报表的几种方法.docx
- 文档编号:4147530
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:41
- 大小:384.12KB
创建microft Dynamic CRM图形报表的几种方法.docx
《创建microft Dynamic CRM图形报表的几种方法.docx》由会员分享,可在线阅读,更多相关《创建microft Dynamic CRM图形报表的几种方法.docx(41页珍藏版)》请在冰点文库上搜索。
创建microftDynamicCRM图形报表的几种方法
创建microftDynamicCRM图形报表的几种方法
crm技术及管理2009-07-2214:
40:
33阅读6评论0字号:
大中小
创建CRM图形报表的几种方法
关于把图形报表整合到CRM的应用比较普遍,也是大家比较感兴趣的问题。
我总结了一下自己在项目中用到的一些方法:
1.WindowsSharepointService(WSS3.0)+Officewebpart
在WSS2.0里有一个免费的webpart:
Office2003Add-in:
WebPartsandComponents,但是3.0不可以直接安装了(可以手工安装),这个webpart的好处是简单易用,但不是很灵活。
而且如果你想看到它产生的图形报表,你的机器必须安装MicrosoftOffice2003/2007,所以还是有局限性的。
1.WindowsSharepointService(WSS3.0)+ReportingServicewebpart
你还可以在WSS3.0里用SQL报表的webpartReportingServicesAdd-in,方法是先写好Report,然后用ReportViewerwebpart把Report添加在WSS的页面上,由于这种方法其根本是调用SQLReportingService,所以很灵活。
但这种方法对性能上有一定的影响。
1.ASP.Net+FusionCharts
FusionCharts是专业的生成图形报表的软件,它其实是Flash文件,通过接受XML数据来显示图形。
FusionCharts有一个免费的版本可以非常好的实现图形报表了。
这种发式其实是使用ASP.Net+FusionCharts开发报表了,所以更加灵活,可以很方便的支持多组织,效果也很漂亮。
类似的报表软件还有:
Visifire(使用Silverlight),AnyChart(使用Flash),Dundas(SharePointwebpart)
1.CRMAnalyticsAccelerator
这个呼之欲出的CRM4.0Addon也可以很好地实现CRMDashboard,更多信息参见:
CRMAccelerators–PartI–AnalyticsAccelerator
在WindowsSharePointService平台上构建协作式应用--
作者:
JasonMasterman、TedPattison
难度:
★★☆☆☆
读者对象:
Office开发人员,企业信息工作者
相关技术:
WSS、SPS、OfficeSystem
[摘要]在过去的几年中,微软在协作技术方面做出了巨大的投资。
而WindowsSharePointServices(WSS)andSharePointPortalServer(SPS)是此领域中两种旗舰性产品。
本文分为两部分。
在本期中,我们将介绍SharePoint的基本结构,并且讨论SharePoint所提供给使用微软.NET框架开发者的机遇。
在下一期中,我们将讨论利用WSS和SPS对象模型的程序设计,以及为一个SharePoint网站定制Web部件。
WindowsSharePointServices被认为是WindowsServer™2003操作系统官方部分的一个附加产品。
WSS提供了一个架构来创建协作式的Web站点,从而使得公司在团队、部门以及大的组织之间,可以方便、可靠地共享信息和文件。
任何使用者都可以通过Web浏览器或是通过微软Office2003内置的协作新功能,比如Word和Excel等来访问一个WSSWeb站点。
.
WSS还提供了生成UIs的基础设施,包含Web部件页和Web部件。
Web部件页和Web部件是SharePoint强大的一面,因为每个WSS站点都提供一个基于浏览器完全自定义的UI。
Web部件还能够用于跟踪每个用户的个性化信息。
下面我们将对Web部件进行更为详细的探讨。
SharePointPortalServer2003用于构建企业级的门户网站,这些网站是微软Office2003System的组成部分。
值得注意的是SPS是建于WSS之上的。
SPS添加了易处理的特性来对WSS进行补充,这些特性有利于用户对大量信息和文档的导航作用。
SPS同时还提供了额外功能来加强门户网站对于索引、搜索、订阅者针对性(audiencetargeting)和单点登陆(singlesign-on)的使用。
WSS和SPS的作用存在本质的区别,如图1所示。
WSS是基于协作主题的,并出于存储和共享基于列表的数据和文档而设计的。
与之对比,SPS门户网站是基于整合主题的。
一个SPS门户网站会对来自不同地方的信息和文档进行整合。
SPS更具价值,因为它为用户提供一种快捷、简便的方法,来搜集分散在专用网和互联网中的信息和文档。
图1WSS和SPS的作用
实质上,WSS提供了存放所有目录的地方,而SPS提供了按照自己的需求来导航和搜索目录的方法。
这两种作用相互补充。
WSS允许一个企业级的公司来创建和维护成千上万的协作式网站,而一个或更多的SPS门户网站允许用户可以搜索所有这些目录来寻找所需的信息。
你应该认识到,SPS依赖于WSS来提供许多基本的服务。
例如,WSS为SPS提供跟踪成员和共享列表与文档的能力。
此外,SPS无需重建自己的界面表现引擎来为门户网站的用户接口生成HTML。
相反而言,SPS利用WSSWeb部件页和Web部件的基础设置,来为一个SPS门户网站构建用户接口。
WindowsSharePointServices
对于任何已经购买了WindowsServer2003操作系统的个人或公司,WSS都是免费的。
WSS的安装文件可以通过Windows更新服务下载到,或是在MSharePoint网站下载:
WSS架构创建于WindowsServer2003,IIS6.0,和ASP.NET之上。
图2显示了如何将WSS架构的基本部分组合到一起。
当你在WindowsServer2003上成功安装WSS之前,你必须首先启动IIS6.0和ASP.NET1.1,来配置一个主机作为应用服务器。
图2WSS的体系结构
只要你对WSS的历史有一些了解,对WSS的学习就会变得容易许多。
WSS是SharePoint第二代产品和技术的一部分。
第一代名为SharePointTeamServices(STS),是早先基于IIS框架的。
与WSS相似,STS框架为共享基于列表的数据与文档提供了一个协作式的框架。
不过STS不是使用ASP.NET来创建,而是采用一个私有的ISAPI扩展来实现。
由于有限的工具支持,定制和扩展STSWeb站点一直是相对比较困难的。
利用WSS和第二代SharePoint,使得站点定制变得更加容易,因为WSS对于如FrontPage2003这样的网页设计器提供了高度兼容。
WSS还提供了一个更好的可扩充模型,因为你可以利用C#和VisualBasic.NET中的任意一种,来为WSS站点和SPS门户网站编写自定义的应用程序和Web部件。
STS和第一代SharePoint的产品和技术还一直存在可扩展性问题。
在这点上底层架构负有不可推卸的责任,因为其在前端Web服务器采用了有状态设计。
这个缺点导致了它不可能利用一个Web集群环境来扩大STSWeb站点的规模。
当微软的工程师们开始设计WSS和第二代SharePoint产品和技术时,他们主要针对STS的可扩展性问题进行设计。
因此,他们设计了这个体系结构来支持WSS和STS对成千上万的用户和Web站点的部署。
WSS的体系结构是基于无状态的前端Web服务器。
它是以集成的存储策略为基础的,其中和Web站点相关联的所有以列表为基础的数据与文档,均存储在一个SQLServer™数据库中,如图3所示。
这个集成的存储策略关键目标是,允许一个WSSWeb服务器在一个Web集群环境中进行高效的扩展。
图3Web集群配置
数据库
WSS依赖于两种不同的SQLServer数据库:
配置数据库和内容数据库。
很自然,配置数据库为每个物理Web服务器,IIS虚拟服务器和WSSWeb站点存放专用的部属配置信息。
而内容数据库则保存与WSSWeb站点相关联的数据。
WSS要求每个配置数据库与各个WSSWeb服务器部署一一对应。
一个简单的部属应包括一个单一的主机,其上运行WSS前端Web服务器组件以及带有配置数据库和单一内容数据库的SQLServer。
一个更具规模的WSS部署,包括一个带有多重前端Web服务器的Web集群方案。
一个WSS部署也可以包含多重的后端数据库服务器。
例如,在某些部署中,可以通过在运行有SQLServer的多重主机上分布许多内容数据库而获得大量优越性。
但是,每个WSS部署只可以拥有一个配置数据库。
配置数据库提供一个信息存储中心来协调所有的前端和后端服务器。
每个内容数据库为一个或更多的WSSWeb站点存储数据。
WSS数据是以站点逐个存储为基础的,其中数据包括列表和文档,以及与站点定制和个性化相关的所有信息。
这个集成存储策略比STS有了明显得改进,STS是将专门的站点数据存储在除了数据库以外的文件系统和注册表中的。
事实上,在WSS中,与一个站点有关的所有信息都被存储在一个单独的SQLServer数据库中,重要的是这样使得备份和恢复Web站点变得更加容易。
如果你刚刚开始使用WSS,在一个运行WindowsServer2003的单独计算机上,你可以安装所有你需要的东西。
一旦你已经安装了WindowsServer2003,通过启动IIS6.0和ASP.NET1.1就可以将计算机配置成一个应用服务器。
当你配置IIS和ASP.NET时,要确保你没有安装FrontPage服务器扩展,因为他们和WSS是不相容的。
然后,你可以通过运行STSV2.EXE安装程序来安装WSS(参见
对于单一机器部署,WSS不需要你使用SQLServer完全版。
WSS的安装程序可选择安装一个MSDE的特别版本,名为WindowsMSDE(WMSDE)。
WMSDE不同于MSDE的标准版,因为它并不限制你使用2GB的存储器和10个数据库连接。
但是,WMSDE比MSDE更受限,因为它只支持微软签名的表模式(TableSchemas)。
这就意味着,你不能使用WMSDE来创建你自定义的数据库和表。
如果你想在开发工作站上安装SPS,那么安装过程将会相当复杂。
首先,许多SPS的特性要求活动目录。
因此,你应该在服务器上安装SPS,这些服务器是活动目录域的一部分。
在运行有WindowsServer2003的主机上安装SPS之前,先把这台机器加入到现存的活动目录于中,或配置它成为一个域控制器。
一旦计算机运行WindowsServer2003在一个域中,通过启动IIS6.0和ASP.NET1.1来将它配置成一个应用服务器。
利用SPS,我们还推荐你安装SQLServer,取代对WMSDE存储门户网站数据库的依赖。
一旦你在计算机上已经安装了WindowsServer2003,以及IIS6.0,ASP.NET1.1和SQLServer,并将它添加到一个活动目录域中,你就可以准备安装SharePointPortalServer2003了。
SPS安装程序首先要安装WSS。
接下来,SPS安装自己在WSS上。
最后,SPS安装程序将会给出向导,使你逐步创建配置数据库和初始化门户网站。
请注意,SPS会创建一个附加数据库用来跟踪SPS服务、用户配置文件、订阅者(audiences)和对单点登陆服务的安全认证等等各个方面的数据。
SPS还为配置数据库和包含门户网站的内容数据库,扩充了标准WSS数据库模式。
在安装WSS或SPS之前,此安装是在一个利用SQLServer(而不是WMSDE)的部署中进行的,你可能需要为Windows账户添加一个SQL注册,这个帐户充当了SharePoint中IIS应用池的作用。
默认下,WSS和SPS配置IIS应用池运行于NTAUTHORITY\NETWORKSERVICE帐户身份下。
如果你不喜欢这种默认设置,你可以重新配置任意的IIS应用池,来使用一个不同的Windows账户。
然而,无论你决定使用哪个Windows账户,你将必须拥有一个SQL帐号来登录到SQLServer。
一旦你已经在SQLServer中为相应的帐户添加了SQL注册,你就必须将帐户添加到安全管理员的服务器任务和数据库创建者中。
如果你不是按照这些步骤进行,你将在安装或配置WSS和SPS任意一个时遇到错误。
那是因为,在默认情况下,WSS和SPS使用IIS应用池运行于NTAUTHORITY\NETWORKSERVICE帐户身份下,此帐户不允许登录到SQLServer。
你必须配置SQLServer,来授权用户拥有创建数据库和配置他们的安全设置的权利。
IISWeb站点和虚拟服务器
WSSWeb站点配置从IISWeb站点级开始。
一个默认的IIS安装创建了一个IIS站点,名为"默认Web站点",并配置此站点通过80端口来监听到达的HTTP请求。
你可以利用IIS管理工具来创建附加的IISWeb站点,用于监听到达的HTTP请求在一个不同的端口或是一个不同的主机头。
图4的例子显示了一个IISWeb服务器和两个已配置好的虚拟服务器。
图4供用户使用的两个虚拟服务器
这个时候我们注意到,WSS的安装完毕后,添加了它自己特有的IISWeb站点,名为SharePointCentralAdministration。
WSS使用这个IISWeb站点来运行SharePointCentralAdministrationHTML页。
在安装过程中,SharePointCentralAdministrationWeb站点被配置使用一个随机的端口号。
在SharePoint术语中,一个IISWeb站点被认为是一个虚拟服务器。
一个虚拟服务器必须通过WSS被扩展,以便运行于WSSWeb站点。
当你默认设置下安装WSS时,它将自动扩展监听于80端口的虚拟服务器。
你也可以扩展其他的虚拟服务器,通过使用SharePointCentralAdministrationHTML页或是一个WSS命令行管理工具,名为STSADM.EXE。
WSS有别于ASP.NET,在WSS中无需利用IIS虚拟目录来配置每个Web站点。
取而代之的是,在配置数据库和内容数据库内部,WSS为WSSWeb站点跟踪所有的配置信息。
这就意味着,只要WSS已经扩展了一个虚拟服务器,并且你开始创建一个Web站点,那么他们将不会出现在IIS的元数据库(MetaBase)中。
而是有一项将被创建到配置数据库和相应的内容数据库中。
事实上,IIS并不知道一个扩展了的WSS虚拟服务器,到底是包含一个单一的WSSWeb站点还是10,000WSSWeb站点。
因为WSS不需要为每个新的WSSWeb站点配置一个IIS虚拟目录,从而得到更好的可扩展性和可维护性。
当WSS扩展到一个虚拟服务器上,并安装一个自定义的ISAPI过滤器,名为WSS过滤器(STSFLTR.DLL)。
它将侦听每个发送给虚拟服务器的请求,并决定是否应该交给WSS或IIS处理。
如果请求需要处理,WSS过滤器再去检查到达请求的URL和配置服务器,来决定谁来处理它。
记住,你可能拥有一个虚拟服务器,你打算在它上运行WSS站点以及其他的ASP和ASP.NET应用。
当WSS扩展到一个虚拟服务器上,它添加一个web.config文件在主虚拟服务器的根目录中。
这个web.config文件为WSS和所有的运行于虚拟服务器的ASP.NET代码提供最初的配置设置。
默认情况下,这个web.config文件包含相当严格的安全设置。
当你想要你的代码更好地控制运行,或是想要测试或开发一个新的定制Web部件,这个时候你可能需要修改web.config文件的配置节。
在SharePoint术语中,一个URL空间是一组所有可能定位到一个虚拟服务器的URL。
WSS将已扩展的虚拟服务器的URL空间分成多个受管理的路径。
受WSS管理的路径被认为是被包含的路径,相反不受WSS管理的路径被认为是被排除的路径。
当WSS过滤器发现到达一个带有URL的请求,并且此URL是被排除路径的一部分,从而就可以给IIS发送一个回复,让标准ASP或ASP.NET来处理。
在一个已经被WSS扩展的虚拟服务器上,应该怎样开发一个标准ASP.NET应用呢?
例如,如果你想开发一个ASP.NETWeb应用在http:
//AcmeServer/webapp1处,以致使得这个虚拟服务器对于WSS仍然有效。
在这一点上,你需要了解怎样配置被包含路径和被排除路径。
特别是,在URL空间中,你需要添加一个被排除路径,它将被用于ASP.NETWeb应用。
图5是SharePointCentralAdministrationHTML页提供的一个用户界面,用于定义受管理的路径。
图5WSS的管理用户界面(用于定义受管理的路径)
注意到图5中所示虚拟服务器的被包含路径和被排除路径。
像一些定义为"夹带通配符"的网站都是被包含路径。
一个通配符的目的是使URL更有效地进行分析。
WSS不允许被排除路径嵌套URL空间中的一个通配符。
在一个到达的请求中,一旦WSS过滤器发现URL的第一部分与一个通配符相匹配,比如http:
//AcmeServer/sites,表明请求应该直接被WSS处理。
当WSS过滤器确定了此请求中的URL是被包含路径时,它就根据配置数据库来定位WSS站点。
利用站点的URL和一个可识别的GUID,WSS跟踪配置数据库中的每个站点。
在配置数据库中还有附加信息,来连接每个站点到它的目标内容数据库。
在一个WSS部署中,常常需要扩展不止一个虚拟服务器。
你可以灵活地进行。
在一个独立的进程中,每个虚拟服务器都可以通过配置,使得它可以利用一个IIS应用池来运行它的WSSWeb站点。
IIS还可以配置每个虚拟服务器,使得他们拥有不同的安全认证需求。
一个要求配置成基本认证,而另一个可以要求配置成Windows集成认证。
在一些部署中,每个被WSS扩展的虚拟服务器都有自己分离的内容数据库。
扩展一个虚拟服务器,也可以附加一个被其它虚拟服务器使用着的内容数据库。
以致允许这对虚拟服务器,提供两个不同的访问节点给WSS站点的一个公共集。
这样做的好处在于,每个虚拟服务器的安全设置都能独立的被配置。
例如,一个虚拟服务器,用于提供公开的Web站点,一般要求配置成SSL和基本认证。
另一个服务器,在防火墙后提供用户入口,可以要求配置成Windows集成认证。
站点集、站点和工作空间
在一个虚拟服务器中,利用站点集将WSS站点分区,站点集即一个或更多站点的集合组成一个所有权单元。
创建一个新的站点集,需要你提供这个站点集所有者的Windows登录账号和e-mail地址。
WSS跟踪站点集所有者的信息,从而可以赋给他们管理权限,以及发e-mail通知他们关于站点集的维护问题。
一个站点集通常包括一个顶级站点,并且它拥有和站点集本身相同的URL。
当你创建一个新的站点集的时,顶级站点也同时被自动创建。
除了顶级站点,一个站点集可以随时添加二级站点,二级站点与顶级站点是父子关系,如图6所示。
每个站点都必须创建在一个特定的站点集中,并且和这个站点集中的其他所有站点一起存储在同一个内容数据库中。
图6虚拟服务器中的站点集
在WSS中,站点集服务器可作为一个备份和恢复单元。
STSADM.EXE管理工具为备份和恢复站点集提供了简便易用的操作命令。
备份一个站点集之后,你可以使之恢复在同一个Web服务器上,或是一个不同的Web服务器上。
你将会发现,对于站点集中顶级站点之下的那些单个站点,利用WSS来备份和恢复是相当困难的。
如果你想独立地备份和恢复一个站点,你应该将它作为顶级站点,创建在一个新的站点集中。
在一个大规模的WSS部署中,当你每天对这些成千上万的站点集进行维护时,你无需单独备份站点集,而是你可以在内容数据库级进行备份。
对于许多公司,备份内容数据库将会是很容易的,因为这个维护过程可以与备份其他SQLServer数据库相同。
现在,让我们回过头去考虑一个基本问题:
到底什么是WSS站点?
首先,一个站点是存储内容的容器。
站点内容都是以列表、文档库和子站点的形式存储的。
第二,一个站点是一个可获取的实体,它的内容可由一组可配置的用户访问。
一个站点既可以定义它自己的用户集,也可以继承其父站点的用户。
每个站点用户都对应一个Windows账号,这个账号被定义在一个活动目录域中,或是在一个本地的Windows安全账号数据库中。
一个站点也可以包含一个配置设置群,以及在站点列表和文档库中定义各种用户的存取权限。
第三,一个站点还会碰巧是一个Web应用,其中带有本身可扩展和完全定制的用户接口。
一个站点所有者或是Web的设计者,可以定制一个网页的布局和外观,并且可以利用浏览器或是FrontPage2003来修改站点的导航框架。
最后,一个站点是使用Web部件页和Web部件技术的基础。
站点所有者或是Web的设计者,可以通过添加和配置共享Web部件来定制Web部件页。
一个使用者可以通过修改、添加和删除Web部件,来使Web部件页更加个性化。
在一个Web部件页中,所有与Web部件有关的定制和个性化数据,都将自动存储在内容数据库中。
对于工作空间,WSS支持许多不同的站点模型。
技术角度来说,一个工作空间就是一个标准WSS站点。
但是,工作空间的用途比其他类型的WSS站点定义得要窄许多,因为它常常关注一个文档或会议。
此外,站点的工作空间中包含预定义的列表,使得其可以和微软Office产品更好得集成到一起,像Word,Excel,Access,和Outlook。
每个站点从一个站点模板被初始化创建。
一个站点模板定义了一个初始化列表集、文档库、Web部件页和Web部件,使这些均存在于一个新建的站点中。
WSS拥有八个站点模板,包括:
TeamSite,BlankSite,DocumentWorkspace,BasicMeetingWorkspace,BlankMeetingWorkspace,DecisionMeetingWorkspace,SocialMeetingWorkspace,和MultipageMeetingWorkspace。
当一个已创建的站点第一次被访问时,WSS会提示用户通过HTML页选择一个可利用的站点模板,如图7所示。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 创建microft Dynamic CRM图形报表的几种方法 创建 microft CRM 图形 报表 方法