Web Content Management System, Migration and Maintenance Services for ECDC Web Portal

Transcription

1 Web Content Management System, Migration and Maintenance Services for ECDC Web Portal Current System Description Reference H March 2015 Page 1

2 Table of Contents 1. Introduction Purpose and Scope How the SAD Is Organized Architecture Background Problem Background System Overview Goals and Context Significant Driving Requirements Solution Background Architectural Approaches Analysis Results Requirements Coverage Summary of Background Changes Reflected in Current Version Views Logical View View Description View Packet Overview Architecture Background View Packet: Entity relations diagram View Packet: Sequence diagram Development / Implementation View View Description View Packet Overview Architecture Background View Packet: Component diagram View Packet: Package diagram Process View View Description View Packet Overview Architecture Background View Packet: Activity diagram Physical / Deployment View View Description View Packet Overview Scenarios / Use-cases View View Description View Packet Overview Architecture Background View Packet: Use-case diagram Relations Among Views Referenced Materials Appendices Appendix: Glossary and Acronym List Page 2

3 List of Figures FIGURE 1: WEB PORTAL FIGURE 2: ECDC VISUAL IDENTITY FIGURE 3: LEFT HAND NAVIGATION FIGURE 4: SOCIAL NETWORK LINKS FIGURE 5: SEQUENCE DIAGRAM FOR THE CREATION AND PUBLICATION OF A NEW PAGE TO THE WEB PORTAL. 31 FIGURE 6: COMPONENT DIAGRAM FIGURE 7: ADVISORY FORUM CRM DATA ACCESS FIGURE 8: CRM COMPETENT BODIES DATA ACCESS FIGURE 9: MANAGEMENT BOARD CRM DATA ACCESS FIGURE 10: CONTENT TYPE HUB FIGURE 11: ACTIVITY DIAGRAM FOR THE PAGE APPROVAL FIGURE 12: ADVISORY AND MANAGEMENT WEB PART USE CASE DIAGRAM FIGURE 13: ECDC WEB CONTENT BOX WEB PART USE CASE DIAGRAM FIGURE 14: COUNTRY INFORMATION SMALL MAP WEB PART USE CASE DIAGRAM FIGURE 15: CUSTOM FORM USE CASE DIAGRAM FIGURE 16: ECDC CONTENT QUERY WEB PART USE CASE DIAGRAM FIGURE 17:ECDC TV WEB PART USE CASE DIAGRAM FIGURE 18: EVENTS WEB PART USE CASE DIAGRAM FIGURE 19: RELATED PAGES WEB PART USE CASE DIAGRAM FIGURE 20:FILTER PICTURE LIBRARY WEB PART USE CASE DIAGRAM FIGURE 21: HEALTH TOPICS WEB PART USE CASE DIAGRAM FIGURE 22: IMAGE ROTATOR WEB PART USE CASE DIAGRAM FIGURE 23: RELATED NEWS WEB PART USE CASE DIAGRAM FIGURE 24: OPEN DOCUMENT WEB PART USE CASE DIAGRAM FIGURE 25: PICTURE VIEWER WITH DROPDOWN WEB PART USE CASE DIAGRAM FIGURE 26: PHOTO GALLERY SMALL PICTURE WEB PART USE CASE DIAGRAM Page 3

4 1. Introduction Sub-sections of Section 1 include the following. Section 1.1 ( Purpose and Scope ) explains the purpose and scope of the SAD, and indicates what information is and is not included. This tells you if the information you re seeking is likely to be in this document. Section 1.2 ( How the SAD Is Organized ) explains the information that is found in each section of the SAD. This tells you what section(s) in this SAD are most likely to contain the information you seek Purpose and Scope This SAD specifies the software architecture for the Web Portal of ECDC. The Web Portal is built on Microsoft SharePoint platform. Since SharePoint applications heavily depend on the underlying SharePoint farm and its configuration, corresponding information will also be included where it is relevant. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents. What is software architecture? The software architecture for a system * is the structure or structures of that system, which comprise software elements, the externally-visible properties of those elements, and the relationships among them [Bass 2003]. "Externally visible properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. This definition provides the basic litmus test for what information is included in this SAD, and what information is relegated to downstream documentation. Elements and relationships. The software architecture first and foremost embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, a software architecture is an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. Elements interact with each other by means of interfaces that partition details about an element into public and private parts. Software architecture is concerned with the public side of this division, and that will be documented in this SAD accordingly. On the other hand, private details of elements details having to do solely with internal implementation are not architectural and will not be documented in a SAD. Multiple structures. The definition of software architecture makes it clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. The neurologist, the orthopedist, the hematologist, and the dermatologist all take a different perspective on the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. And the kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement s behavior. Although these perspectives are pictured differently and have very different properties, all are inherently related; together they describe the architecture of the human body. So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software system s structures. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment which view we are taking of the * Here, a system may refer to a system of systems. Page 4

5 architecture. Thus, this SAD follows the principle that documenting a software architecture is a matter of documenting the relevant views and then documenting information that applies to more than one view. None of these structures alone is the architecture, although they all convey architectural information. The architecture consists of these structures as well as many others. This example shows that since architecture can comprise more than one kind of structure, there is more than one kind of element (e.g., implementation unit and processes), more than one kind of interaction among elements (e.g., subdivision and synchronization), and even more than one context (e.g., development time versus runtime). By intention, the definition does not specify what the architectural elements and relationships are. Is a software element an object? A process? A library? A database? A commercial product? It can be any of these things and more. These structures will be represented in the views of the software architecture that are provided in Section 3. Behavior. Although software architecture tends to focus on structural information, behavior of each element is part of the software architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the software architecture and will be documented in the SAD as such. Behavior is documented in the element catalog of each view How the SAD Is Organized This SAD is organized into the following sections: Section 1 ( Introduction ) provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading Section 1, which describes how the document is organized, which stakeholder viewpoints are represented, how stakeholders are expected to use it, and where information may be found. Section 1 also provides information about the views that are used by this SAD to communicate the software architecture. Section 2 ( Error! Not a valid bookmark self-reference. ) explains why the architecture is what it is. It provides a system overview, establishing the context and goals for the development. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural approaches that have been utilized in the architecture. It includes information about evaluation or validation performed on the architecture to provide assurance it meets its goals. Section 3 (Views ) and Section 0 ( The utilization of the web parts is one of the most important and used in Web Portal. Below are the use cases for a selection of web parts: Page 5

6 Figure 12: Advisory and Management web part use case diagram Page 6

7 Figure 13: ECDC Web Content Box web part use case diagram Page 7

8 Figure 14: Country Information small map web part use case diagram Page 8

9 Figure 15: Custom Form use case diagram Page 9

10 Figure 16: ECDC Content Query web part use case diagram Page 10

11 Figure 17:ECDC TV web part use case diagram Page 11

12 Figure 18: Events web part use case diagram Page 12

13 Figure 19: Related pages web part use case diagram Page 13

14 Figure 20:Filter Picture Library web part use case diagram Page 14

15 Figure 21: Health Topics web part use case diagram Page 15

16 Figure 22: Image Rotator web part use case diagram Page 16

17 Figure 23: Related News web part use case diagram Page 17

18 Figure 24: Open Document web part use case diagram Page 18

19 Figure 25: Picture Viewer with Dropdown web part use case diagram Page 19

20 Figure 26: Photo Gallery Small picture web part use case diagram Relations Among Views ) specify the software architecture. Views specify elements of software and the relationships between them. A view corresponds to a viewpoint, and is a representation of one or more structures present in the software (see Section 1.1). Sections 0 ( [Kruchten 1995] Page 20

21 Referenced Materials ) and Appendix ( Appendix: Glossary and Acronym List ) provide reference information for the reader. Section 5 provides look-up information for documents that are cited elsewhere in this SAD. Section 6.1 is a directory, which is an index of architectural elements and relations telling where each one is defined and used in this SAD. The section also includes a glossary and acronym list. Page 21

22 2. Architecture Background 2.1. Problem Background System Overview The Web portal is the public ECDC web site used to emit information regarding ECDC work and programmes. The current version 1.1 was out on the 13 th of September of 2013 and is powered by SharePoint The Web Portal 1.0 was powered by SharePoint 2007 and went live at September Page 22

23 Figure 1: Web Portal Goals and Context The general goal/objective of the Web Portal it to provide an overview of the mission and activities of ECDC. More specifically it offers detailed information about the organization, its activities, various health topics, list of its publications and related media Significant Driving Requirements The most Significant Driving Requirements for the Web Portal are: Page 23

24 1. Compliance with ECDC branding. All ECDC related material has some specific color and style guidelines; 2. Left hand navigation in all content pages ( ations/basicnavigation_portal1.1_v1.0.xlsx); 3. Improved usability 4. Timely notification of users: Social bookmarking. 5. Content editors should be able to modify content and add functionality to pages 2.2. Solution Background Architectural Approaches ECDC as an organization is using Microsoft technologies, making this a natural choice also for the Web Portal. More specifically Microsoft SharePoint is the application platform that Web Portal is built on. In light of this the system is based on / using: (Development platform) The.NET framework v3.5 and the C# programming language; (Development environment) Visual Studio 2010 Team System; (Database software) MS SQL Server technologies utilized by SharePoint Farm; (Web server) Internet Information Services (IIS); (Server operating system) Windows Server technologies; ( server) Microsoft Exchange; (Deployment): SharePoint solution packages and Windows PowerShell scripts MS SharePoint version 2010 is the version that currently powers the big majority of content 1.1 version of the Web Portal except the following sub sites: EPIET, ESCAIDE, EAAD migration. Various features of SharePoint are utilized inside the web portal. More specifically: Managed metadata service: This is a SharePoint feature that facilitates the publishing and subscription of managed terms or words in order to govern companywide taxonomy. Content types: A content type is a group of reusable settings that describe the shared attributes and behaviors for a specific kind of content. Content types can be defined for any item type, including documents, list items, media files, and folders. Document libraries: They are used for storing various types of files like Word documents, Excel spreadsheets, text files, Pdf documents. Timer Jobs: They are periodically executed tasks inside SharePoint Server. They provide a task execution environment. CSS Styles: Web Portal common branding comes in the form of CSS stylesheets. SharePoint supports the custom branding of the different websites. Page 24

25 Javascript: Custom javascript is utilized by SharePoint in order to enhance the client side experience of the user. Masterpages and layouts: Different master pages form the basic structure of the various pages of the portal (admin, search, public pages) while page layouts arrange the structure of different pages inside different sections (health topics, home, web part page etc) Resource files: They are used for making the application content easily available to multiple languages RSS feeds: Really Simple Syndication (RSS) is a widely used technology for transmitting information across the Internet and intranets. SharePoint offers support for syndicating content from the various lists. Business Data Catalog: A SharePoint feature for integrate business data from back-end server applications. The web portal can present data from CRM by the aid of this. Web Parts: This is a component on a web page, some code/functionality packaged in the form of Web Part. They are reusable. In addition to the out of the box web parts, custom ones are utilized by the portal Content Type Hub: it allows the centralization and sharing of content types through the Metadata Service Application. Content deployment: it deploys content from a source site collection to a destination site collection. The complete source site collection can be deployed, or a subset of sites can be deployed. In addition to special SharePoint features, the web portal utilizes some special ASP.NET features: Http handlers: An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint") that runs in response to a request made to an ASP.NET Web application (like SharePoint). The web portal is utilizing handlers to redirect old urls (before the migration) to new urls and for serving RSS feeds, Analysis Results The architecture is based on the principles exposed in the book Patterns of Enterprise Application Architecture (Martin Fowler, 2002), which is considered as a reference in the field of enterprise application development. No formal analysis has been performed to evaluate the architecture Requirements Coverage The Web Portal 1.1 covers the general requirements as stated in the section. More specifically: Page 25

26 1. It adopts the ECDC design guidelines with a strong ECDC identity; Figure 2: ECDC visual identity Page 26

27 2. Left hand navigation in all content pages; Figure 3: Left hand navigation 3. In order to improve usability larger font size is used, less words per line are placed, and bullets are used to make lists clearer Page 27

28 4. Timely notification of users: Social bookmarking. Figure 4: Social network links 5. Content editors can add, configure or remove web parts on various pages in order to add functionality Summary of Background Changes Reflected in Current Version 3. Views The views presented in this SAD are the following: Name of view Rationale Module view? Componentandconnector view? Allocation view? Logical Describes how the system is structured in terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between Yes Yes Page 28

29 elements shows dependencies, interface realizations, part-whole relationships, and so forth. Example diagrams: Entity Relations Diagram, Class Diagram, Sequence Diagram Development / Implementation Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes development artifacts and deployment artifacts. Example diagrams: Component Diagram, Package Diagram Yes Process Describes how the run-time system is structured as a set of elements that have run-time behavior and interactions. Yes Example diagram: Activity Diagram Physical / Deployment Describe how the system is mapped to the hardware. Yes Yes Example diagram: Deployment Diagram Scenarios / Use-cases Describes functionality of the system, its external interfaces, and its principal users. Example diagram: Use Case Diagrams 3.1. Logical View View Description The logical architecture primarily supports the functional requirements what the system should provide in terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from the problem domain, in the form of objects or object classes. They exploit the principles of abstraction, encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also serves to identify common mechanisms and design elements across the various parts of the system View Packet Overview Page 29

30 This view has been divided into the following view packets for convenience of presentation: Entity relations diagram: Shows the entities at play and their internal relationship between each other. Class diagram: Describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Sequence diagram: Shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages. Architecture Background The Web portal 1.1 is developed in SharePoint This was a natural choice since the previous Web Portal was running on SharePoint 2007 and the migration would be easier. SharePoint is quite suitable for the creation of web sites or intranets. It offers comprehensive security model, with definition of different roles. Additionally the content editing and the web part usage empower the content editors to add by themselves information and functionality to the pages View Packet: Entity relations diagram Not applicable View Packet: Sequence diagram Web editor team members do not access directly the production Web Portal environment. Instead, they are making any updates to the staging environment. As soon as they select to publish a page, SharePoint environment takes over: the Content Deployment feature is utilized for transferring the updated content to the production environment. Below is the sequence diagram that describes the procedure: Page 30

31 Portal environment. Figure 5: Sequence diagram for the creation and publication of a new page to the web portal 3.2. Development / Implementation View View Description The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunks program libraries, or subsystems that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy of layers, each layer providing a narrow and well-defined interface to the layers above it. The development architecture of the system is represented by module and subsystem diagrams, showing the export and import relationships. The complete development architecture can only be described when all the elements of the software have been identified. It is, however, possible to list the rules that govern the development architecture: partitioning, grouping, visibility. For the most part, the development architecture takes into account internal requirements related to the ease of development, software management, reuse or commonality, and to the constraints imposed by the toolset, or the programming language. The development view serves as the basis for requirement allocation, for allocation of work to teams (or even for team organization), for cost evaluation and planning, for monitoring the progress of the project, for reasoning about software reuse, portability and security. It is the basis for establishing a line-of-product View Packet Overview This view has been divided into the following view packets for convenience of presentation: Component diagram: Describes how a software system is split up into components and shows the dependencies among these components. Page 31

32 Package diagram: Describes how a system is split up into logical groupings by showing the dependencies among these groupings Architecture Background The source code of the application is developed and stored in the form of MS Visual Studio 2010 solution. It consists of multiple sub solutions that are organized in the following subfolders: Applications It contains the solution for the custom version of RSS feed BDC It contains the Business Data Catalog implementations for present data from CRM as SharePoint lists HttpHandlers It contains the http handlers that were developed for - redirecting the SharePoint RSS feeds to the custom implementation of Web Portal RSS feeds, - redirecting from some old links to the new location of them after the migration. There is a specific list that contains the old and news Url mapping Metadata Contains the definition for the content types stored in the content type hub Templates Contains custom forms used for News, Events, Publications, Scientific Advice, Publications, Call for Grants, Call for Tenders Tools Contains various small console applications and tools, used to aid the migration, address issues and bugs, or perform other supporting development tasks UserInterface Contains all the artifacts that support the user interface of the portal. More specifically it contains javascript files, master pages, page layouts, stylesheets, form layouts, and an event receiver that performs UI configuration WebConfig Contains features that add entries in the web.config WebParts This is a quite important subfolder since it contains the work done for the various web parts. More specifically it contains: - ECDC.TV.Player: used for playing videos Page 32

33 - ECDC.WP.SP.WP.AFMB: used for diplaying the Advisory and Management board members - ECDC.WP.SP.WP.CompetentBody: used at the Competent body page - ECDC.WP.SP.WP.ContentDisplay: This is a custom content box - ECDC.WP.SP.WP.CustomForm: It enables the building of custom form by using xml definitions. - ECDC.WP.SP.WP.FilterPictLibrary: A custom image display control that uses a dropdown list - ECDC.WP.SP.WP.ImageRotator: used for displaying images from a custom list - ECDC.WP.SP.WP.Members: used for displaying information from a list containing ECDC contacts. - ECDC.WP.SP.WP.OpenDocument: Presents the documents of a list as entries inside a dropdown control. - ECDC.WP.SP.WP.Organization: Displays information from a list containing organizational information items. - ECDC.WP.SP.WP.PhotoViewerDropDownList: It is a photo viewer web part - ECDC.WP.SP.WP.TessyRedirection: used for redirecting requests for old urls to the new ones for the TESSy related pages. - ECDC.WP.SP.WP.TessyReports: Used for displaying TESSy reports as they are retrieved from Reporting Server - ECDC.WP.WebParts.PhotoGallery: Used for displaying images as a photo gallery. Page 33

34 View Packet: Component diagram Figure 6: Component diagram Above the high level component diagram of the application can be found. The Content Type Hub, Managed Metadata Service, CRM and Tessy contribute data that is displayed by the various pages of the Web Portal View Packet: Package diagram CRM integration CRM provides information to the Web Portal in order to populate three lists: - Advisory Forum - Management Board - Coordinating Competent Bodies Page 34

35 Figure 7: Advisory Forum CRM data access Figure 8: CRM Competent Bodies data access Page 35

36 Figure 9: Management Board CRM data access This is done by using Business Connectivity Services of SharePoint. The related CRM fields for the contacts are mapped to columns of SharePoint lists in order to encapsulate the external CRM data to a SharePoint list form Content Type Hub Page 36

37 The Content Type Hub is a central location where content types can be defined and published. In this manner there is a central repository of reusable content types. Even updates are reflected to the subscribed web applications. Such content type hub is utilized by the web portal. Some base content types are defined at the hub. These type are imported in Portal. The imported ones are used again in order to produce new derived custom content types that are specifically tailored to the Web Portal needs. The following diagram depicts the base types that are provided by the ECDC content type hub. Figure 10: Content Type Hub 3.3. Process View View Description The process architecture takes into account some non-functional requirements, such as performance and availability. It addresses issues of concurrency and distribution, of system s integrity, of fault-tolerance, and how the main abstractions from the logical view fit within the process architecture on which thread of control is an operation for an object actually executed. A process is a grouping of tasks that form an executable unit. Processes represent the level at which the process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In addition, processes can be replicated for increased distribution of the processing load, or for improved availability. The software is partitioned into a set of independent tasks. A task is a separate thread of control that can be scheduled individually on one processing node View Packet Overview This view has been divided into the following view packets for convenience of presentation: Page 37

38 Activity Diagram: Describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control Architecture Background View Packet: Activity diagram In specific pages an approval workflow is attached. An example is the World Health Day 2014 page: Figure 11: Activity diagram for the page approval 3.4. Physical / Deployment View View Description The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers, or processing nodes (or just nodes for short). The various elements identified networks, processes, tasks, and objects need to be mapped onto the various nodes. We expect that several different physical configurations will be used: some for development and testing, others for the deployment of the system for various sites or for different customers. The mapping of the software to the nodes therefore needs to be highly flexible and have a minimal impact on the source code itself View Packet Overview This view has been divided into the following view packets for convenience of presentation: Page 38

39 Deployment diagram: Describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware Scenarios / Use-cases View View Description The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios instances of more general use cases for which we describe the corresponding scripts (sequences of interactions between objects, and between processes). The scenarios are in some sense an abstraction of the most important requirements. This view is redundant with the other ones (hence the +1 ), but it serves two main purposes: as a driver to discover the architectural elements during the architecture design as we will describe later as a validation and illustration role after this architecture design is complete, both on paper and as the starting point for the tests of an architectural prototype. View Packet Overview This view has been divided into the following view packets for convenience of presentation: Use-case diagram: Describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases. Architecture Background Web portal audience is divided into three categories: - Public anonymous end users. These are the end users that consume the information presented by the various pages of the web portal. They do not authenticate but access it in an anonymously. - Web Editor Team members. These are the ECDC users that add content to pages, add and configure web parts, upload images and files View Packet: Use-case diagram The utilization of the web parts is one of the most important and used in Web Portal. Below are the use cases for a selection of web parts: Page 39