Mercy Health支持美国许多不同地理位置的多家医院和诊所。 历史上每个地理位置都有自己的专用Intranet站点，这些站点使用不同的技术，并且每个站点都有单独的支持结构。 已确定需要一个统一的同事门户来支持患者和提供者门户的愿景。

已为Mercy Health系统的40,000多名员工启动； 下一步是将文档和结构从旧的Intranet站点迁移到新的门户。 Mercy Health希望拥有的主要功能之一是能够上传和共享其医院网络使用的三种类型的文件。

这些包括：

• 政策-对部门，医院，地区等执行的政策。
• 表格-由员工和客户填写。
• 用户内容-个人文件夹，供用户上传所需的任何内容。

此外，对于策略和表单文件类型，Mercy希望实施批准工作流。 但是，此工作流程与典型的工作流程有所不同，因为它将由规则启动，使用有关部门的信息和内容来知道将工作流程分配给谁，然后允许用户选择所需的所有人员。批准工作流程，部门主管始终在链中获得最终批准。

Mercy还希望使门户成为所有医院工作人员能够在Mercy的所有各种数据存储中找到人员，地点和事物的地方，他们的Wiki，知识库，文档存储库，Sharepoint等。

首先，Mercy需要一个Web内容系统。 他们之所以选择Drupal，是因为它具有具有可扩展功能的高端框架。 然后， Mercy需要将文档迁移到门户中。 Drupal开箱即用，没有提供足够灵活的文件管理解决方案来满足Mercy的业务逻辑。 考虑了诸如工作流，大师，修订，操作以及其他与工作流和文档管理相关的模块等贡献模块，但并未证明它们具有支持最佳解决方案所必需的功能。 因此，在 不需要文档存储库的情况下， Mercy选择了Alfresco提供解决方案。 但是，这带来了另一个问题：如何与Drupal和Alfresco结婚？

  为了实现这一目标，Mercy 利用了 。 Mercy Health Systems应用程序开发总监Brian Boyer 介绍了他们开始寻找和评估软件选项时的过程：

“在Mercy Health，我们确定我们现有的解决方案无法解决的需求，因此我们采用了多个IT领域来帮助我们找到新的解决方案。他们定义了解决方案的要求，确定了潜在的解决方案可以满足要求的产品，比较解决方案，为决赛选手准备概念证明，然后选择最适合Mercy Health要求和优势的合适解决方案。”

Canopy框架是一组服务和API，用于加速Drupal和Alfresco在企业环境中的集成。 Canopy将Drupal作为前端Web开发平台的灵活性与Alfresco作为企业内容管理和工作流系统的功能相结合。

一旦决定使用Canopy，就概述了项目目标，并商定了在Mercy Health Development Server上的Intranet基础设置的最终交付成果（针对2种内容类型，数据同步，工作流和LDAP身份验证功能进行了测试），并开始了开发工作。

该项目分为四个阶段：

• 阶段1：功能需求发现
• 阶段2：技术需求发现和架构设计
• 阶段3：开发（Alfresco内联网设置）
• 阶段4：培训

由十名Appnovation成员和九名Mercy Health员工组成的团队使用瀑布和敏捷项目方法的组合来提供此服务。 这两个团队在六个月的时间里紧密合作，每天保持稳定，开放的沟通渠道。 主要的开发方面可以描述如下：

Appnovation团队为mercy.net和门户（称为Baggot Street）开发了Alfresco Intranet基础，这需要建立Canopy模块和CMIS集成点的清单。 现有的Drupal内部网和网站已在Mercy健康开发环境中复制，而Canopy模块和集成点已添加到系统中。 在Alfresco端，Appnovation根据发现阶段确定的基础架构设置了Java Server和数据库环境。 根据本案例研究的目标和要求部分中定义的参数构建了基本工作流程，并使用LDAP身份验证设置了用户登录。

还开发了几种基于REST的定制REST脚本，以求宽恕，以便将某些操作分为一个调用而不是多个调用。 这些基于REST的定制Web脚本/ API充当了在Drupal和Alfresco之间同步组节点，组成员，分类术语以及部门/子部门节点的桥梁。 然后，内容可以“实时”同步，这意味着在Drupal上创建内容时，它也将同时发送到Alfresco。 如果由于某种原因未能将内容成功交付给Alfresco，则该内容将不会保存在Drupal中，并且会通知用户。

此外，在Alfresco中创建了自定义Web脚本，以处理自定义元数据的操作，以便允许用户在文档中设置值，例如审阅者和部门负责人。 因此，允许Drupal触发另一个自定义脚本并启动工作流程。 通过使用Alfresco的类别系统并创建一系列脚本来通过Alfresco中的ScriptAPI链接到Drupal的分类法，Appnovation设置了要同步的术语。 Mercy需要为Drupal函数调用的每个部门创建文件夹。 Appnovation团队使用ScriptNode API根据公司的父节点创建文件夹层次结构以创建这些文件夹。

开发中还包括Drupal-Alfresco-CMIS-Apachesolr文档搜索集成。 此功能背后的想法是Mercy Health希望能够对Alfresco中可用的文档进行多面搜索。 Apachesolr模块可以立即解决此问题。 为了使Apachesolr索引Alfresco中的文档，使用了CMIS API从Alfresco检索文档。 一旦文档在Drupal中可用，它们便被保存为Alfresco文档节点，并在下次执行cron作业时由Apachelsolr进行索引。

Mercy Health希望用户能够将其文档从Drupal上传到Alfresco。 对于常规文档，使用CMIS API上传内容，而对于表单文档，在CMIS API之上开发了自定义Web脚本以触发Alfresco中的工作流程。 然后，使用CMIS上传任何文档类型（常规或表单）都会触发由Appnovation构建的自定义脚本，以设置审阅者和部门负责人的元数据。 此定制工作是在CMIS定制模型之外完成的。

最后，Mercy Health有一个自定义要求，即在上载文档时，将提示“上载者”选择要设置为审阅者和部门负责人的人员。 然后将允许任何审阅者指定多个用户来审阅和批准文档。 一旦每个审阅者都批准了该文档，该文档将继续进行，最终由部门主管进行审阅。 一旦各方对文档进行了审核（由部门负责人整理），然后将其分配回初始审阅者，以便他们可以手动发布文档。 在任何时候，文档被拒绝，整个过程将返回给初始审阅者。

翻译自: