Deploying Digital Dashboards Howard Crow Lead Product Manager Microsoft 4-303

Agenda DDRK Architecture Working with Parts Dashboard Schema Deployment Part Distribution Freedom2 Questions

What’s New Standardized nuggets – Web Parts Share Web Parts XML and WebDAV architecture Open, extensible, internet ready Designed as a Service Hosted on the Server Runs in IE Stand-alone XSL skins can support many platforms

Resource Kit Designed to help you understand the new Digital Dashboard Framework SQL Server Sample Digital Dashboard File System Sample Digital Dashboard Digital Dashboard Service Component Web Part SDK Documents Web Part Builder Web Part Gallery The Web Store is Coming!

Choosing A Sample Store Advantage File System SQL Server Exchange Simple Web Part Building Small Deployments SQL Server Relational user and part management Better Personalization security Scalable Application Server Exchange Web Store Active Directory Integration Office Integration Offline support Streaming Media Native WebDAV/XML

Installing The Samples Requirements Windows 2000 + IIS + (SQL 7) Must have IP resolution What is installed Dashboard Factory Admin Dashboard & Sample Web Parts SQL WebDAV IIS Extension Updates www.Microsoft.com/digitaldashboard

Administration Admin dashboard One stop admin of all dashboards Also manage parts The only way to create a root dashboard Great use of Digital Dashboard Service Component Permissions (SQL) File system managed in file system

Build A Dashboard Demo

How The Samples Work

Digital Dashboard Services Component Architecture Office, Outlook, and IE Digital Dashboard WebPart WebPart WebPart WebPart Context, notification, and messages Digital Dashboard Services Component IIS Assembly of parts, dashboard and styles Dashboard Factory Dashboard.asp XSL ..Edit.asp XSL Dashboard APIs for read and writes Store.vbs WebDAV WebDAV Exchange 2000 SQL Server File System Storage of dashboard and part metadata

What Is A Web Part Reusable component for rendering web content and services inside a digital dashboard It is a document – HTML, XML, JS, VBS Wrapped in rendering properties Defined XML Interchange format Stored in two parts Document – HTTP Put, Get Properties – WebDAV PropPatch A Dashboard is a Folder of Parts

The Dynamic Dashboard User Requests a Dashboard with a URL Combination Factory + Dashboard Dashboard makes webDAV call to folder Security token is passed XML stream is returned Filtered for permissions Dashboard XSL Transforms into dashboard HTML is returned to client

Build A Web Part Demo

Deployment

Deploy With File System Only for small deployments Everyone sees same dashboard Save Dashboard in a folder called Template Use wwwroot_default.asp Save as default.htm in root Creates an instance of template for each user Redirects user from http://server Parts updated through MasterPartLink

Deploy On SQL Every dashboard has 2 states Global – “template” User – everyone sees a different view Stored in a join table Create a dashboard for each group Deploy URL by department Make default.asp a redirect Assign url to AD OU - home dashboard Script default.asp to AD

Outlook And Offline Further Reading: July MSDN Mag In Internet Explorer Set as Offline Favorite 2 Levels offline Deploying in Outlook Hosted as Folder Home Page – 2 levels To Host in Outlook Today, use special registry switch [HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\9.0 \Outlook\Webview\mailbox] "url"=http://digidash/home.htm "navigation"="yes"

Types Of Digital Dashboards Personal Digital Dashboard Personal Settings Visible only to me Team/Dept. Digital Dashboard Everyone sees the same dashboard Admin manages the look and feel Corporate Portal Hybrid Parts and Dashboards

Customization Tied directly to NT Security Applies to Dashboards and Parts Levels of Access No Access – Can’t See No NT access Read Only – Can see, but not Read access in NT Personalize – Change General Props Available only in SQL Modify Read & Write

Customization Demo

Dashboard Catalog Corporate Catalog of Web Parts Updates Users can add parts to dashboard Accepts .DWPs and WebDAV parts Updates IN SQL, everyone shares the same part In File System us MasterPartLink Extended Schema for Categorization Searching Parts Personalization

Enterprise Decision Portal Deployment And Interoperability Jason Welch freedom Architecture Group InfoImage, Inc. 4-303 Thanks Howard. This talk is about deployment and interoperability of enterprise decision portals. We will talk specifically about freedom 2, its relationship with DDRK 2.0 and issues we are faced with in deploying enterprise scaling decision portals. Introduce self

Agenda Real-world issues in deploying enterprise portals freedom 2 Architecture Overview freedom 2 + Web Parts = Interoperability Demo freedom 2 vs. DDRK 2.0 Things that we have learned through experience, things our customers have told us, etc.. How our achitecture addresses these real world issues How web parts fit into the freedom architecture and why we chose to use them Demo (quick look at webparts in action) to show benefits, power of, etc….

About InfoImage, Inc. A Leading Enterprise Portal Software Company A Microsoft Global Alliance Partner Founded in 1992 Offices nationwide 300 employees Emphasize that we have been around for awhile and know what we are doing

About The freedom 2 Decision Portal A platform for developing, deploying, and maintaining enterprise portals that offer high degrees of scalability and interoperability A platform for developing, deploying, and maintaining enterprise portals Platform, not a solution – solutions are built on top.

Real-World Issues In Deploying Enterprise Portals Directory management Object management Integration with back-end systems OLTP OLAP Reporting Integration with collaborative systems Scalability Talk to each of these. Explain why it’s something that needs to be thought about, and that each of these is something that our customers have ACTUALLY ASKED FOR. They know that a distributed architecture gives problems. Directory Integration Management Customers want enterprise solutions to work with their existing enterprise directories – they don’t want us to come in with our own flexibility is critical. portals are meant to bring resources (people) together, people live in directories, hence the importance. Don’t want to have to learn new tools Object Management object proliferation – how do you manage that. propagation – how do you do it? Integration Same thing as directory management. Make data available internally and externally, scalability wrap security around it heterogeneous data sources on various oltp – order entry olap – drill down analysis reporting – anything Integration with collaborative systems they want to do all their in the portal Interoperability with their exisiting systems with customer and their systems with their partners Scalability They a solution that will scale and grow with the needs of the organization examples (40000-60000 users) ties back to directory and object management Talk about the things we do to ensure successful deployments, which basically comes down to the names of our methodologies: Solution Plan Solution Architecture Solution Development Solution Deployment Engagement Management

Real-World Issues In Deploying Enterprise Portals Flexibility Reuse Multiple Browser Support Both Extranet and Intranet Quick Deployments Disconnected Users Wireless Flexibility Customizable solution (UI, business logic) customization for the different user communites and devices that they have within the org Reuse Built-in to the design investment vs. purchase reuse at the metadata level ties back to managability Just skim the rest

freedom 2 Architecture Overview

Architecture Overview Federated Portal Architecture Distributed Metadata-driven Based on Windows DNA Not based on the DDRK Our Goals Scalability Interoperability Centralized management Flexible framework with a rich programmability model Ease of integration Now lets take a closer look at what we did to address these types of customer needs starting with the very core of the product architecture…. First lets define the freedom federated architecture. The fundamental philosophy of the federated architecture is “Massive distribution with central management” for extremely high levels of scalability. By effectively leveraging the WinDNA model we are able to provide a platform that can be partitioned, distributed, sliced and diced any which way you want. By describing the distributed components that make up the platform in terms of their metadata and centralizing that metadata we are able to centrally manage an entire federation of portal systems working together as a single unified resource. Point #1 Distributed, metadata-driven architecture Every component of the system is described in terms of… What it talks to What it depends on and what depends on it attributes Behaviors UI characteristics Code elements it made of Security Its admin inferface Its deployment/interchange interface physical location …All this constitutes metadata about a component Point #2 Flexible Framework for integrating with search engines, collaborative systems and back-end systems Integration points: search collaboration directtory svcs. content management;

Architecture Model Freedom Center Presentation Services USER Freedom Center Presentation Services Digital Business Identity/Personalization Freedom Federated Services Portal Layout Object Rels Security Queries & Reports Integration Rules Portal Content Discovery Data Integration Taxonomies Metadata Repository We talked about scalability and management. Now lets take a look at how the some of the other architectural goals were met. Key points to make: illustrates the flow of information within a freedom system The freedom federated services (or freedom server) depends completely on the metadata repository for Everything on the arrows In order to customize the server, all you have to do is manipulate the metadata Everything is funneled through the personalization engine before being presented to the user. Every API is routed through the personalization engine The architecture supports a highly adaptive and flexible platform for developers and administrators that provides a very personalized experience to the end user. Central administration of the metadata results in control over the distributed components – highly distributed system with central management! Enterprise directory system (AD) and robust and scalable repository architecture (MS SQL Repository) are integral to the design of portal systems. Installation Deployment Versioning Management Configuation Registration Interchange Tools Administrator Developer

Physical Architecture Client support MS IE 4 and 5 MS Outlook 2000 Other HTML 3.2 compliant browsers Directory services based on Active Directory Federated services engine based on COM+ and XML

Physical Architecture Metadata repository Microsoft Repository SQL Server 7.0 Tools Microsoft Visual Studio MMC freedom Federation Tools

freedom 2 + Web Parts = Interoperability Allows us to provide a high level of interoperability for our customers There are many portal vendors, and other product and service vendors. We’ve gadgets, nuggets, decision objects, and so on… We need a standard specification allowing us to exchange information We’re talking about the fundamental building blocks of every portal system.

Why Are Web Parts Important ? Standard specification Interoperability We encourage our competitors to also adopt Web Parts Extensibility Everyone has a proprietary architecture for portal parts. It will serve us better to standardize on part definitions in order to have a high level of re-use and interoperability. Solidifies “Dashboard/portal” as a long-term application market in its own right because now there is standard mechanism for deployment. Sharing content between portals from different vendors. Customers can purchase content from more vendors than the one that sold them the portal. The webpart architecture has the added advantage of being extensible allowing ISVs to extend it to fit their own implementations. It allows us to be interoperable and continue to provide freedom value-add to our customers, both at the same time. We can be like everyone – but still have our own value-add.

freedom 2 And Web Parts freedom support for Web Parts Store produces extended Web Part XML Viewer consumes extended Web Part XML Tools to import Web Part definitions (.DWP) Tools to create/register new Web Parts within freedom Tools to export Web Part definitions Support for DDSC functionality

freedom 2 And Web Parts Proprietary extensions to Web Part definitions Added on import Stripped-out during export Once imported, freedom specific lifecycle, propagation, and personalization rules apply Give examples of the extensions Propogation ties to object management built-in object hierarchy class->instances(templates) ->user instances propogation of system-owned metadata properties from the class to the user instances

Web Parts/freedom Architecture Center (viewer) HTML Client Portal Definition + Decision Object XML FCD (Store Module) Import Facility ADO We did not have to rearchitect to fit in the webpart solution – this was natural fit freedom Store Apply freedom Extensions to form Decisions Objects .DWP file Export Facility Remove freedom Extension

Demo… Start out showing freedom center UI Portal page showing cool stuff Portal page showing DDRK webparts Talk about dashboard vs portal pages and differences UI features like add new DOs, persist, add pages, etc. Show DDSC functionality in Russell-like DOs Import 2 parts Add necessary properties to both and talk about the mapping of properties Add roles and talk about how security is enforced Talk about how being a DO is not so much about the definition (Since WP and DO def is almost alike) as it is about the services that freedom offers to a DO Add one DO to container, PP, portal application and portal definition and talk about the lifecycle management and reusability Leave the other DO in class metadata state Switch over and show that one DO appeared on the portal page Browse and add the other DO

freedom 2 Versus DDRK 2.0 InfoImage Federated Portal Architecture gives Enterprise Abilities Scalability Manageability And now… Interoperability Advanced Personalization Services Advanced, Heterogeneous Data Integration You’ve seen what is similar, now let’s look at what is different. Our solution is about scalability: early pilots show capabilites of supporting tens of thousands we have current customers with potential user audiences of 40-60 thousand users manageability: central manage, deploy portals that all work as a single unified systems interoperability: webparts = interoperability at the core of what a portal is