Mercy Health 在美国多个不同的地理位置支持多家医院和诊所。每个地理位置在历史上都有自己专门的内网站点，这些站点采用不同的技术，并且每个站点都有单独的支持结构。经确定，需要一个统一的员工门户网站，以支持 One Mercy（患者和提供者门户网站）的愿景。
该门户网站已为 Mercy Health 系统的 40,000 多名员工启动；下一步是将旧内网站点中的文档和结构迁移到新门户网站中。Mercy Health 希望拥有的主要功能之一是能够上传和共享其医院网络使用的三种类型的文件。
其中包括
- 策略 — 针对部门、医院、地区等执行的策略。
- 表单 — 由员工和客户填写。
- 用户内容 — 供用户上传任何内容的个人文件夹。
此外，对于策略和表单文件类型，Mercy 希望实施审批工作流程。但是，此工作流程与典型的工作流程不同，因为它将由规则启动，使用有关部门和内容的信息来确定将工作流程分配给谁，然后它将允许用户选择需要批准工作流程的所有人员，其中部门主管始终在链中获得最终批准。
Mercy 还希望门户网站成为所有医院工作人员能够跨 Mercy 的各种数据存储（他们的 Wiki、知识库、文档存储库、Sharepoint 等）查找人员、地点和事物的一站式平台。
首先，Mercy 需要一个 Web 内容系统。他们选择了 Drupal，因为它具有高端框架和可扩展的功能。然后，Mercy 需要将文档迁移到门户网站中。Drupal 开箱即用，没有提供足够灵活的文档管理解决方案来满足 Mercy 的业务逻辑。考虑了贡献模块，例如：workflow、maestro、revisioning、actions 以及其他与工作流程和文档管理相关的模块，但事实证明它们没有足够的能力来支持最佳解决方案。因此，in 需要文档存储库， Mercy 选择 Alfresco 来提供解决方案。但是，这又带来了另一个问题：如何将 Drupal 和 Alfresco 结合起来？
为了实现这一目标，Mercy 利用了 Appnovation 的 Canopy。 Mercy Health Systems 的应用程序开发主管 Brian Boyer 描述了他们开始寻找和评估软件选项时的过程：
“在 Mercy Health，我们确定我们有一个现有解决方案无法解决的需求，因此我们让 IT 的几个不同领域帮助我们找到一个新的解决方案。他们定义了解决方案的要求，确定了可能满足要求的潜在解决方案，比较了这些解决方案，为最终入围者准备了概念验证，并选择了最适合 Mercy Health 的要求和优势的适当解决方案。”
Canopy 框架是一组服务和 API，用于加速 Drupal 和 Alfresco 在企业环境中的集成。Canopy 结合了 Drupal 作为前端 Web 开发平台的灵活性和 Alfresco 作为企业内容管理和工作流程系统的强大功能。
一旦决定使用 Canopy，就概述了项目目标，并商定了在 Mercy Health 开发服务器上设置内网基础架构（针对 2 种内容类型、数据同步、工作流程和 LDAP 身份验证功能进行了测试）的最终可交付成果，开发工作随即开始。
该项目分为四个阶段
- 阶段 1：功能需求发现
- 阶段 2：技术需求发现和架构设计
- 阶段 3：开发（Alfresco 内网设置）
- 阶段 4：培训
这是由 Appnovation 的十名成员和 Mercy Health 的九名员工组成的团队，结合瀑布式和敏捷项目方法交付的。这两个团队在六个月内紧密合作，每天保持持续和开放的沟通渠道。主要开发方面可以描述如下
Appnovation 团队为 mercy.net 和门户网站（称为 Baggot Street）开发了 Alfresco 内网基础架构，这需要设置 Canopy 模块和 CMIS 集成点的清单。现有的 Drupal 内网和网站在 Mercy Health 开发环境中进行了复制，同时将 Canopy 模块和集成点添加到系统中。在 Alfresco 端，Appnovation 根据发现阶段确定的基础架构设置了 Java 服务器和数据库环境。根据本案例研究的目标和要求部分中定义的参数构建了基本工作流程，并使用 LDAP 身份验证设置了用户登录。
Appnovation 还为 Mercy 开发了几个自定义的基于 REST 的 Webscript，以便将某些操作批量处理到一个调用中，而不是多次调用。这些自定义的基于 REST 的 Webscript/API 充当了在 Drupal 和 Alfresco 之间同步组节点、组成员、分类术语以及部门/子部门节点的桥梁。然后，内容能够“实时”同步，这意味着在 Drupal 上创建内容时，它也将同时发送到 Alfresco。如果由于任何原因内容未成功传递到 Alfresco，则内容将不会保存在 Drupal 中，并且用户将收到通知。
此外，还在 Alfresco 中创建了自定义 Webscript，以处理自定义元数据的操作，以便允许用户在文档中设置值，例如审阅者和部门主管。从而允许 Drupal 触发另一个自定义脚本并启动工作流程。Appnovation 设置了要通过使用 Alfresco 的类别系统同步的术语，并创建了一系列脚本，以通过 Alfresco 中的 ScriptAPI 链接到 Drupal 的分类。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 之上开发了自定义 Webscript，以触发 Alfresco 中的工作流程。使用 CMIS 上传任何文档类型（常规或表单）都将触发 Appnovation 构建的自定义脚本，以设置审阅者和部门主管的元数据。此自定义工作是在 CMIS 自定义模型之外完成的。
最后，Mercy Health 有一个自定义要求，即当文档上传时，“上传者”将被提示选择要设置为审阅者和部门主管的人员。然后，任何审阅者都将被允许指定多个用户来审阅和批准文档。一旦每位审阅者都批准了文档，它将继续前进，最终由部门主管审阅。一旦文档被所有各方（最后是部门主管）审阅，它将被分配回初始审阅者，以便他们可以手动发布文档。在任何时候，如果文档被拒绝，整个过程都将返回给初始审阅者。
2 条评论