mercy baggot street canopy intranet - … project overview p.4 2.0 project overview section 2.1...

13
Mercy Baggot Street Canopy Intranet www.appnovation.com

Upload: lamdien

Post on 06-Sep-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

Mercy Baggot Street Canopy Intranet

www.appnovation.com

* This project is based on Mercy’s internal intranet system. We are unable to show screen shots due to our confidentiality agreement.

Mercy Baggot Street Canopy Intranet

Contents

1.0 Background P.3

2.0 Project Overview P.4

3.0 Objectives P.7

4.0 Development P.9

P.31.0 Background

1.0 Background

Section 1.1 Mercy Project Overview

Mercy Health (Mercy) supports several hospitals and clinics across many different geographical locations. Each geographical

location has historically had its own dedicated intranet site. These sites were on different technologies and had a separate support structure. It was determined that a single unified co-worker portal was needed to support a vision of One Mercy and that began the start of Baggot Street as that portal. Since then Baggot Street has been launched as the home page for over 38,000 co-workers however, that was just step one of the process; Mercy still needed to migrate the documents and structure from the old intranet sites into Baggot Street. One of the main features Mercy wanted to have was the ability to upload and share three types of files used by the network of hospitals. These included:

1. Policies - enforced policies for a department, hospital, region, etc 2. Forms - filled out by both staff and customers 3. User content - personal folder for users to upload anything they want

Furthermore, for policies and forms file-types Mercy wanted to have an approval workflow implemented. However this workflow would be different than a typical workflow because it would be started by a rule, use information about the department and content to know who to assign the workflow to, and then would allow the user to choose all the people that needed to approve the workflow, with the department head always getting final approval in the chain.

Mercy also wants to have the Baggot Street portal become the one place for all co-workers to go to find people, places and things across all of Mercy’s various data stores (Sharepoint, Wiki, Knowledge base, Document Repository, etc).

P.42.0 Project Overview

2.0 Project Overview

Section 2.1

Section 2.2

Mercy first chose which web content system to build Baggot

Street upon and because Mercy had the vision that open source

was the direction they wanted to go Drupal, with it’s high-end

framework with extensible functionalities, was the perfect

choice. This was satisfactory until Mercy wanted to migrate

documents into Baggot Street. Drupal, out of the box, did not

provide a document management solution flexible enough to

meet Mercy’s business logic. Contributed modules such as:

Workflow, Maestro, Revisioning, Actions, and other modules re-

lated to workflow and document management were considered

but didn’t prove to have the power necessary to support our

solution.

In need of a document repository, Mercy then performed a

comparison between Sharepoint and Alfresco. In comparing the

ease of integration, ability to support the enterprise, the ease of

use and the cost Mercy determined that Alfresco was the cor-

rect document repository solution.

Why Drupal?

Why Alfresco?

P.52.0 Project Overview

Section 2.3

Mercy Health originally reached out to Alfresco about using

its software as the backend repository for all of their various

Drupal web properties. As Mercy explained their use case and

business needs to Alfresco, it was apparent that Appnovation’s

Canopy solution would be a perfect fit.

Canopy by Appnovation integrates the highly scalable and popu-

lar open source website development tool with a world class

open source document repository application with allowing for

the best of both worlds. The Canopy framework is a set of ser-

vices and APIs used to accelerate the integration of Drupal and

Why Appnovation & Canopy

Canopy Integration for Mercy Baggot Street

FIREWALL

APACHE REVERSE PROXY

ALFRESCO & DRUPALSYNC USERS AND INTEGRATEWITH ARCHIVE DIRECTORYVIA THE LDAP INTERFACE

ALFRESCO & DRUPAL USEMYSQL 5.XDATABASE

ACTIVE DIRECTORYSERVER

STORAGE

SERVICE DESK

SHAREPOINT

INTEGRATE DRUPAL,ALFRESCO SHAREPOINT& SERVICE DESKCONTENT INFO ONESEARCH INDEX& INTERFACE

LOAD BALANCERUSE STICKY SESSION

ALFRESCOSERVERS IN ASINGLE CLUSTERSHARE THECONTENTDIRECTORY

EACH SOLR SERVER SHARES ITS OWNINDEXES TO DISK

APACHE WEB SERVERSDRUPAL 6.X

INTERNET

SOLRSOLR

ALFRESCO 4.0

CLUSTEREDCLUSTERED

ALFRESCO 4.0MYSQL 5.X DATABASE

SERVER

P.62.0 Project Overview

Section 2.3

Alfresco in an enterprise environment. Canopy combines the

flexibility of Drupal as a front end web development platform

with the power of Alfresco as an Enterprise content manage-

ment and workflow system.

Appnovation was introduced to Mercy by Alfresco because Ap-

pnovation was the only Solutions Integration Partner that had

experience and expertise in integrating the two open source

technologies together. No other providers were introduced for

this reason.

Alfresco and Appnovation began to explain to Mercy Health

how this would be accomplished. After demoing a prototype of

Canopy, Mercy was confident in their ability to supplement their

internal development team in building out a Drupal / Alfresco

integration.

Partnering with Appnovation and utilizing Canopy has

enabled us to combine Drupal and Alfresco to create a world class policy maintenance tool,

along with an awesome foundation for us to create innovative ways for us to collaborate and manage documents. This is just the beginning.

- Brian Boyer, Manager Application Development, Mercy Health Systems

P.73.0 Objectives

Section 3.1

3.0 Objectives

Project Details

Project Teams

10 members from Appnovation:

• 1 Account Manager• 1 Project Manager• 1 Technical Architect• 5 Developers• 1 Quality Assurance Analyst• 1 Themer

9 members from Mercy Health:

• 1 Project Sponsor• 5 Developers• 2 Quality Assurance Analyst• 1 Business Analyst

The objectives of the Mercy Health project were to:

1. Understand the Alfresco system architecture requirements to enable integration with Baggot Street 2. Develop and “stand-up” the Alfresco foundation required for the integration 3. Provide consulting and training to facilitate the Mercy Health team to develop, customize and maintain the integration between Alfresco and Drupal for Baggot Street 4. Provide guidance and training with the Records Management module in Alfresco for the Mercy Health ROi Drupal instance

Ultimately, the final deliverable was an Intranet foundation

setup on the Mercy Health Development Server (tested for 2

content types, data syncing, workflows and LDAP authentication

features).

P.83.0 Objectives

Section 3.2

Project Phases

The approach chosen for this project was a combination of Wa-

terfall and Agile methodologies. The project was broken down

into a number of phases to provide the structure and progres-

sive framework that was required for this type of project:

• Phase 1: Functional Requirements Discovery• Phase 2: Technical Requirements Discovery & Architecture Design• Phase 3: Development (Alfresco Intranet Set-up)• Phase 4: Training

The Appnovation and Mercy Health teams worked very collab-

oratively during design and development phases of this project.

Daily status meetings were held with representatives from both

teams in attendance. These meetings typically lasted about 10

minutes and were effective in ensuring all parties were up-to-

date on recent activities and completed tasks as well as make

Project Management & Communication

PHA

SE 1 Functional

Requirements Discovery

PHA

SE 2 Technical

Requirements Discovery &

Architecture DesignPH

ASE

3 Development: Alfresco Intranet

Set-Up

PHA

SE 4

Training

P.94.0 Development

Section 3.2 any important announcements to the group.

In addition to the daily status meetings, technical discussions

were often held between members of the two teams on an on-

going basis and as needed (sometimes daily). Appnovation and

Mercy Health utilized such tools as WebEx and Skype to allow

screen sharing (for more efficient troubleshooting) and to pro-

vide real-time support and communication.

Section 4.1

4.0 Development

Canopy Integration for Mercy.net & Baggot Street

The Appnovation team developed the Alfresco Intranet founda-

tion for mercy.net and Baggot Street which required setting up

an inventory of Canopy modules and CMIS integration points.

The existing Drupal intranet and website were replicated in a

Mercy Health Development Environment while the Canopy mod-

ules and integration points were added to the system. On the

Alfresco end, Appnovation set up the Java Server and Database

environments based on the infrastructure identified during the

discovery phase. Basic workflows were built as according to the

parameters defined in the goals and requirements section of

this case study and user sign-ins were set up using LDAP authen-

tication.

P.104.0 Development

Section 4.2 Drupal - Alfresco Data Synchronization Integration

Appnovation developed several custom REST based webscripts

for mercy in order to batch certain operations into one call

instead of several. These custom REST based webscripts/APIs

served as a bridge for synchronizing group nodes, group mem-

bers, taxonomy terms and department/sub-department nodes

between Drupal and Alfresco. Content is then able to synchro-

nize in “real-time” meaning that at the time content is created

on Drupal, it will also simultaneously be sent to Alfresco as well.

If for any reason the content was not successfully delivered to

Alfresco, the content will not be saved in Drupal and the user

will be notified.

Custom webscripts were also created in Alfresco to handle the

manipulation of custom metadata so as to allow users to set the

values in a document such as reviewer and department head.

Thus allowing Drupal to trigger another custom script and initi-

ate a workflow.

Appnovation also set terms to be synchronized by using Alfres-

co’s category system and creating a series of scripts to link up

to Drupal’s taxonomy through the ScriptAPI in Alfresco.

Finally, Mercy needed to create folders for each department

called by a Drupal function. The Appnovation team used the

ScriptNode API to create the folder hierarchy based on the par-

ent node of the company to create these folders.

P.114.0 Development

Section 4.3

Section 4.4

Drupal - Alfresco - CMIS - Apachesolr Document Search Integration

Document Upload from Alfrescoto Drupal

The idea behind this functionality is that Mercy Health wanted

to be able to have faceted searching on the documents available

in Alfresco. The Apachesolr module handles this out of the box.

In order for Apachesolr to index documents form Alfresco, CMIS

API was used to retrieve documents from Alfresco. Once the

documents are available in Drupal, they are then saved as an

Alfresco Document node and will be indexed by Apachelsolr the

next time a cron job is executed.

Mercy Health wanted the ability for users to upload their docu-

ments from Drupal to Alfresco. For regular documents, CMIS

API was used to upload content while for form documents cus-

tom webscripts were developed on top of CMIS API to trigger

a workflow in Alfresco. Using CMIS to upload either document

type (regular or form) would then trigger custom scripts built by

Appnovation to set the metadata of the reviewer and depart-

ment head. This custom work was done outside of the CMIS

custom model.

P.124.0 Development

Section 4.5 Custom Workflow

Mercy Health had a custom requirement that when a document

was uploaded, the “uploader” would then be prompted to

choose to the person to set as the reviewer and the department

head. Any reviewer would then be allowed to specify multiple

users to review and approve the document. Once every

reviewer had approved the document, it would then move

on to finally be reviewed by the department head. Once the

document is reviewed by all parties, (finishing with department

head), it is then assigned back to the initial reviewer so they

could then publish the document manually. At any point the

document is rejected the whole process would be returned to

the initial reviewer.

ASSIGN APPROVERS

REVIEW TASKS BYAPPROVERS

DEPT HEAD REVIEWTASK

DOCUMENT REJECTED DOCUMENT APPROVEDBY HEAD

Custom Workflow Diagram

Open Digital Delivered.