680 likes | 851 Views
XPS Implementation Methodology. September 2000 Please sign in and take a book from the table. Implementation of Design. Requirements, Analysis, and Design. Maintaining XPS. Phases of Implementation. Requirements, Analysis, and Design. Requirements, Analysis, & Design.
E N D
XPS Implementation Methodology September 2000 Please sign in and take a book from the table.
Implementation of Design Requirements, Analysis, and Design Maintaining XPS Phases of Implementation
Requirements, Analysis, and Design Requirements, Analysis, & Design • Evaluate business processes • Evaluate user and data interaction • Design implementation of XPS
Implementation of Design Requirements, Analysis, and Design Implementation of Design • Configure Portal Environment • Configuration Considerations • Extending XPS
Implementation of Design Requirements, Analysis, and Design Maintaining XPS Maintaining XPS • Required Skill Sets • Backup and Recovery Guidelines • Growing your Portal • Risk Mitigation • Data Maintenance
Requirements, Analysis, and Design Outline • Requirements, Analysis and Design • Implementation of Design • Maintaining XPS
Requirements, Analysis, & Design 6 Steps involved in this phase of implementation • Identify Portal Vision • Identify Data Access Strategies • Identify Portal Business Logic This is an iterative process…decisions made in later steps may require that you revisit previous steps. • Identify Web Delivery Reqs • Identify Portal Security • Identify Portal Architecture
1. Portal Vision Objectives of this step: • Identify Users and Roles • Identify User Data Requirements • Determine Content Sources • Identify Data Types • Determine Information Flows
1. Portal Vision Things to consider: • Who are your users? • What are the pains you are trying to resolve? • What content do your users require, and how do they use it? • Are there opportunities for business process streamlining? • Note: Think functionally, don’t try to design yet*
content source user IT Employee DB Customer HR News Feed Sequoia.com Stock Feed Press Releases Email Employee My Sequoia Technical Docs Delivery Support Clientele Discussion Group PR Tracker Portal Vision - Case Study
Exercise Create Portal Vision Diagram
Data Presentation Implementation Smart Summary Taxonomy Data Entry Templates Indexes Metasearch CDAs searching content directly Data Management Implementation Spiders/DSAs Connectors Senders Receivers Repository Indexes 2. Data Access Strategies Objectives of this step:
Polled Directory Spidering Data LinkDB Data Data Source Adapter
XML Message Extending Data Interaction
2. Data Access Strategies Things to consider: • What are expected user, data, and request volumes? • How time-sensitive is content? • How often is data created and modified? • How will your users use and navigate through content? • Are there opportunities to aggregate data to minimize drill-down? • What are content access requirements and limitations?
2. Data Access Strategies Guidelines: • Search time-sensitive content directly through a custom CDA • High-volumes of highly-transactional and relational data will fare better in a relational database than a document repository • Common URLs, Data Entry Templates, and logical categorizations of content fit well into a taxonomy • Using a Smart Summary reduces drill-down • Only content routed to an Index can be queried in a Taxonomy or Enterprise Search
Data Presentation Role CDA Sequoia Software Internet Site E,C MySequoia Internet Site E,C CNBC Stock Quotes (personalize) E,C CNBC News Feed (personalize) E,C Exchange Inbox (personalize) E Discussion Group D,S PR Tracker Application D,S Clientelle Application S Employee Application H Data Acquisition Role Spider Press Releases Directory Technical Documents Directory Smart Summary DB Employee DB DE Template Customer Support Requests Index Press Releases, Technical Documents, Department List MetaSearch Enterprise, default internet search engines Case Study – Task List
Exercise Build Project Task List Identify: • Spiders • Data Entry Templates • CDAs • Indexes • Meta Search
3. Portal Business Logic Objectives of this step: • Identify Requests to Process • Identify Custom Scripts • Identify Agent Flows • Identify Dispatcher Rules • Identify Transformation Requirements
Business Rules • Dispatcher Rules (simplest logic) • Evaluate for all messages • Evaluate against message (not attachment) • Evaluate to True or False • Process linearly (Always Rule1; 2 only if False) • One requested agent/flow per rule Rule 1 Rule 2 Rule 3 False False True True True Agent/Flow Agent/Flow Agent/Flow
Business Rules • Flows (more complex logic) • Called from Dispatcher Rule • Decision Points evaluate against message (not attachment) • Process linearly or in True/False Path • Process multiple agents sequentially • Can be nested (to componentize logic) Agent/Flow Agent/Flow Agent/Flow ? Next False True Agent/Flow
Business Rules • Scripting Agents (most complex logic) • Called from Dispatcher Rule or Flow • Evaluate against message or attachment • Business logic up to you • Case statements • If/then • Multiple requested processes from single condition
3. Portal Business Logic • Things to consider: • What are the types of requests coming into the portal? How? • What information needs to be sent from the portal? How? • What are your logging, auditing, and error processing requirements? • How does data need to be manipulated within the portal? • What are the message and content structures going in and out of the portal?
3. Portal Business Logic • Guidelines: • Create smaller, reusable flows and chain them together • Create common auditing and error processing scripts to reuse in flows • Create a debugging script to flow to after each step in a flow • Consider how agents identified in previous step interact with each other • Note: Most agents have expected message schemas as inputs and outputs (most will require some form of transformation when chained together)
XML Press Releases Spider Index Taxonomy Request Technical XML Spider Index Taxonomy Documents Request XML Smart Employee Data Spider Email Request Summary Smart XML Spider Index Taxonomy Summary Request XML CS Requests DE Form DE Agent Email Request Case Study – Business Flow
Data Processing Flows Role Press Release & Tech Doc Spider to Index Schedule Taxonomy CS Request Data Entry to Transformation to SMTP Sender bound for CS New Employee Spider to Script to Smart Summary and Transformation to SMTP Sender bound for IT Smart Summary Spider to Index Schedule Taxonomy Data Processing Components Role Script Create Biztalk message from Employee DB Spider attachment Case Study – Project Task List
Exercise Create Business Flow Diagram Create XPS Message Flow Diagram Build Project Task List Identify: • Scripts • Flows
4. Web Delivery Objectives of this step: • Determine “Look & Feel” • Determine Personalization Levels • Identify list of CDAs (or modifications to existing CDAs) • Determine Rendering Requirements • Identify new Pages (or modifications to existing Pages)
4. Web Delivery • Things to consider: • Do different users have access to different Pages? CDAs? Functions in a CDA? • How will users navigate through the portal site (tabs, links, taxonomy)? • What are your branding requirements? • What does the layout of your Pages look like? • What CDAs can be personalized? • What are your requirements for browser support? • What content relationships need to be secured?
4. Web Delivery • Guidelines: • Involve end-users for usability studies • Consider decisions in previous steps – you may find you need to revisit some • Utilize the Role object within a CDA for role-based functionality rather than creating 2 similar CDAs
Data Management Role Smart Summary Department Contact List Taxonomy Press Releases, Technical Documents, CS Request DET C Press Releases, Technical Documents, Department List E Data Presentation Role Rendering Department Contact List Case Study – Project Task List
Exercise Build Project Task List Identify: • Smart Summaries • Taxonomy • Rendering Rules Revisit CDAs
5. Portal Security Objectives of this step: • Identify Portal Access Requirements • Identify Content Security Requirements (roles, logins, etc) • Identify Security System and Security Broker Requirements
5. Portal Security Things to Consider: • Do portal roles need to be revisited based on data security requirements? • How will uniform login requirements across systems be satisfied – is the same username/password combination maintained? • Will source data require updates? What is the security level on the source data? • How will portal login be managed? • Is your portal inter- or intra- net based?
6. Portal Architecture Objectives of this step: • Identify Server Requirements • Identify Load Balancing Requirements • Create Architecture Diagram
6. Portal Architecture Data Services Tier (Index, Taxonomy, Repository, Smart Summary) Agent Tier (Load Balancing, Flow Processing) CLUSTER Transportation Tier (Receivers, Message Processors)
6. Portal Architecture Things to Consider: • What are concurrent user volumes? • What are data persistence volumes? (Indexing, Taxonomy, Smart Summary, Repository) • How frequently is persistent data modified? • What are request volumes? • How complex is your business logic? • What are your fault tolerance, redundancy, and availability requirements?
6. Portal Architecture Guidelines: • Each cluster has a single ConfigStore – this can be a point of failure and an availability risk • A single load-balanced server can be a point of failure and an availability risk • Use IIS configuration best practices to support user request volumes • Frequently accessed/updated persistent data services and high volumes of this data may warrant a separate server
SQL Cluster Server SQL Hot Backup Cluster Server XPS Load Balanced Servers (CDS, Receivers, IIS) Router Case Study: Portal Architecture Diagram
Exercise Create Architecture Diagram
Implementation of Design Requirements, Analysis, and Design Outline • Requirements, Analysis and Design • Implementation of Design • Maintaining XPS
II. Implementation of Design 1. Configure Portal Environment These steps represent the development effort involved in delivering an e-business portal. 2. Configuration Considerations 3. Extending XPS
1. Configure Portal Environment • Single-server development environment • Remote access for developers • Importing exported configurations • Portal/cluster auditing levels • Managing multiple portals vs. multiple clusters
Message Processing Request Processing Spidering Business Rules Agents Repository Data Entry Smart Summary Taxonomy 2. Configuration Considerations
Repository Agent • Things to consider: • Identify required metadata • Identify logical data categories • Identify versioning requirements • Use NT file system storage best practices for media device design • Repository security rules apply ONLY to documents within the repository and only evaluate when a user tries to open the document • Without spidering & indexing (or a custom CDA), access to repository documents is provided only through the Publish tab