LDI – Lipper Data Integration Synopsis: Lipper Data Integration (LDI) is an effort to integrate Lipper content sets
into Reuters products and services. LDI will provide this integration with a two-pronged approach, one of which uses FTP Feed drops to services such as Fast Search and NDA. The other approach is to provide the Lipper content set via SOAP-based web services. Lipper Data Integration Web Services (LDI-WS) provides the means for consumers within Reuters to retrieve Lipper database information via Tornado 2.0-based services. With these services, Reuters can then easily integrate Lipper information and services into their core offerings, including but not limited to: Web-based applications, database applications, thick-client applications, workflow engines, and more.
Segment: Lipper
Authors: Bill Evjen, Cole Krems, Bill St. Pierre, Nadene Tanis, Leslie Gabriolek Contributors: Anke Homer, Jim Bertsch, Ed Kennedy, Paul Ashton, Alex Wolf Technical Writer : Barry Klein Architecture Document Version: V0.6 Template Version: v3.1 Date: May 10, 2006 Document Status: Draft Current Project Phase: Definition
2 BUSINESS CONTEXT ........................................................................................ 9 2.1 IMPACT OF THE FEEDS ...................................................................................... 10
2.1.1 Scope of the FRF .................................................................................. 10 2.1.2 Scope of the Lipper Search Feed ............................................................ 10 2.1.3 Scope of the IDN Feed .......................................................................... 11
4.1 KEY CAPABILITIES........................................................................................... 17 4.1.1 Diagrams of Key Capabilities ................................................................. 17 4.1.2 Descriptions of Key Capabilities .............................................................. 18
4.2 DATA AND INTERFACES ..................................................................................... 20 4.2.1 Content............................................................................................... 20 4.2.2 Service Interfaces ................................................................................ 27 4.2.3 Schemas for Stored Data ...................................................................... 28 4.2.4 Diagrams of Internal Data Flows ............................................................ 28
4.3 COMPONENTS ................................................................................................ 29 4.3.1 Diagrams of Key Components ................................................................ 29 4.3.2 Description of Key Components .............................................................. 30 4.3.3 Support for Problem Identification .......................................................... 32 4.3.4 Data Security ....................................................................................... 32
4.4 SERVICE RESILIENCE ....................................................................................... 35 4.5 ARCHITECTURAL DEPENDENCIES .......................................................................... 37
5.1 WIDE AREA VIEW ........................................................................................... 38 5.1.1 Geographic View .................................................................................. 38 5.1.2 Site Failover ........................................................................................ 41 5.1.3 Storage Replication .............................................................................. 43 5.1.4 WAN Links ........................................................................................... 43
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page iii of 65
5.2 DATA CENTER................................................................................................ 43 5.2.1 Placement in Data Center Infrastructure ................................................. 43
10 SERVICE RISK ............................................................................................ 62 Diagrams Figure 4-1 – Diagram of Web-Services Key Capabilities 17 Figure 4-2 – Diagram of Feeds Key Capabilities 18 Figure 4-3 – LDI Systems and Data Flows 29 Figure 4-4 – Diagram of Key Components 30 Figure 4-5 – Creating Permissions for a User 33 Figure 5-1 – Geographic view for Web Services 38 Figure 5-2 – Diagram of Inter-site Communications 39 Figure 5-3 – Geographic view for Feeds 40 Figure 5-4 – Diagram of Inter-site Communications for the Feeds 40 Figure 5-5 – Physical Infrastructure Storage View for Feeds 41 Figure 5-6 – Diagram of the Failover Plan for the LDC 42 Figure 5-7 – LAN & Server view 46 Figure 5-8 – Establishing the Standby Database 51 Figure 5-9 – Upgrading the Standby Database 51 Figure 5-10 – Role Reversal 52
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 1 of 65
1 Introduction 1.1 Overall LDI Project Summary
Lipper Fund Data is available in many Reuters products today. Customers of 3000 Xtra and Rtrader, as well as Reuters Wealth Manager (RWM) and DataScope products, all have access to fund information such as price, performance and fundamental data.
Fund data from Lipper has not been integrated with the fund data on IDN that is collected from contributors and exchanges (ETFs). As a result, fund data is processed, stored and displayed in many different ways, sometimes presenting redundant information with different identifiers (RICs).
The goal of LDI is to harmonize fund data across Reuters and Lipper systems, and to integrate Lipper fund data in such a way that Reuters products have a consistent, homogenous interface for fund data retrieval and display.
Lipper will serve as the master file or database of record (DBoR) for fund data. Copies or subsets of fund information will continue to be held in NDA for cross-referencing and FRD Search. IDN will continue to hold and distribute daily fund price data (NAV) and intraday fund prices from exchanges (ETFs). There will be a unique identification schema for funds.
Access and interface to the fund DBoR will use the Tornado web services platform. This will allow programmatic access to Lipper fund data via the same web-services platform that is used for access to other FRD databases.
Using the Lipper Global Fund Database (GFD) as database of record (DBoR) will provide a consistent, comprehensive source of fund data within the Reuters web-services architecture and meet the open access content requirement of various premium desktops and data services.
The goals of the Lipper funds Data Integration project are:
• Establish GFD as the single funds data DBoR and the authoritative source of funds data • Deliver a set of web services providing access to all aspects of funds data in GFD that integrate
with existing web services and operate together, sharing the same set of reference data. • Where required, deliver a set of designed-for-purpose feeds of funds data • To enhance the current cross-referencing capabilities for funds in NDA • To rationalise third-party feeds of funds data • To rationalise the storage of funds data on IDN • To enhance FRD Search funds coverage
Benefits of the program are as follows:
• Improved cross-referencing between various asset classes • Historical calculated data can be stored in Fund DBoR to meet various product requirements. • Support local language which can meet the local product-development requirement. • Single source of fund data minimizes development effort in developing new data--retrieval
access for various premium desktops and content services. • DBoR update is transactional in nature. Any change in the price history and performance figure
will be reflected in the database.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 2 of 65
• To the extent possible, generic database structures will be used, minimizing the development required to add new data elements.
• Provision of the entire Lipper fund performance and fundamental database in the long run. • Enhanced usability
1.2 LDI Web Services Project Summary
Lipper Data Integration (LDI-WS) provides an aggregator of Lipper information and services which can effectively be delivered in a request-response scenario. The power behind LDI-WS is that it can be centrally hosted in a Reuters data center and provide Lipper content sets to Reuters through Tornado 2.0. Traditionally, Lipper provided data to various Reuters entities on a case-by-case basis, sometimes providing different solutions around the company. This makes consumption of Lipper data inconsistent across the company, and entails a support model which would be difficult to sustain for Lipper. LDI-WS will remedy this problem.
LDI-WS will be a hosted solution which will provide HTTP or HTTPS connectivity to Reuters. LDI-WS will aggregate information and services effectively from various data stores held by Lipper. LDI-WS will use its ability to connect to strategic Lipper data stores that provide a full breadth of information which allows measuring of the historic investment performance of a wide variety of investment funds. Other data abilities would include the capability of providing other disparate information sources such as Lipper Fact Sheets, Lipper calculations and other Lipper services.
The datasets coming from the hosted LDI-WS solution will be constructed using industry standards such as Simple Object Access Protocol (SOAP), and fed into the Tornado 2.0 infrastructure according to its requirements for routing purposes. This provides Reuters with the ability to consume these datasets into their applications or workflows, regardless of the underlying platform or programming language choices. SOAP, being an industry standard for data representation, makes the consumption of data an automated task in many regards.
The goal of LDI-WS is to offer simple, standards-based datasets to present historic investment data of collective investment funds, for any size of user community. To address the specific needs of the Reuters community, extra emphasis is placed on security, fault tolerance, and scalability, all offered from a Reuters data center.
LDI-WS is targeted toward consumers inside Reuters who are working with standards for data flow, and who are interested in having Lipper be a part of their platform and product ambitions. With this said, though, it is the intention of this project to first address the product-requirement needs of the future Reuters Knowledge Wealth Manager (RKWM) product as well as a future version of Reuters 3000 Xtra.
The expectation is to host LDI-WS from two Reuters data centers in a live/live scenario. These two data centers include the Reuters Nutley Data Center (RHDC) and the Docklands Technical Center (DTC).
Please view the Lipper Data Integration website at http://lipper-stl1/lipperdeveloperportal to see the latest statement regarding the project and its functionality.
LDI – Lipper Data Integration V0.4 Definition Stage Page 5 of 65
Ver. Date Author Key Changes 0.4 Mar. 8, 2006 Barry Klein Changed body font, cleaned up
grammar and made usages consistent. Moved architectural details from §1 to §4. Moved Tornado-2 routing script into Appendix A. Revised the diagrams. Populated the References table. Filled out the Glossary. Added tech. details.
0.5 Mar. 30, 2006 Barry Klein Incorporated latest knowledge and cleaned up references, format and inconsistencies.
0.6 April 28, 2006 Barry Klein Incorporated feedback from reviewers. Moved script from Appendix A to Interface Document.
0.6 April 28, 2006 David Burch SI input following review of 0.5 and feedback to Cole Krems & Leslie Gabriolek. Updates to section 5.4, 5.6 and 7.0. URL’s, in ref section, to Capacity Planning documentation, to SMP guide and to Writing Application Logfiles. Terms and definitions added to Glossary.
0.6 May 4, 2006 Barry Klein Incorporated feedback from Bill Evjen: sections 3.2.1, 3.2.4, 4.3.2, 5.1.2 and 5.2.1; from Cole Krems: sections 5.3.1, 5.3.4 and 5.6.4. FRD refs from Ray Tomkins. Extensive changes from Bob Bailey.
1.5 Glossary
Term Definition 3000 Xtra Domestic and international cross-asset information, sophisticated analytics and
functionality for financial-market professionals Ab-Initio The RDC custom subscriber application and Extraction, Transformation and
Loading (ETL) tool in use for NDA systems. API Application Protocol Interface CAO Central Architecture Office CCAT The CoreCat API CCLux A subsidiary of the Luxembourg Stock Exchange, well used for collecting and
disseminating related data and documents. CCS Cisco Content Switch CLRD Company-level Reference Data CMS Content Management System CNR The Central Numeric Repository is where all collected data is stored. CoreCat The Core and Catalogue components together provide the framework
of the NDA data design. The CoreCat API is CCAT. The Core is the central component of the CNR. It conforms to the Reuters Data Model for definition of the main business entities. The Catalogue is the indexing component to the data held in the CNR providing searching
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 6 of 65
Term Definition and cross-referencing capability, both across the Core part of the model and to the data held in the Deep datasets. It holds the names, identifiers and classifications of the main data objects.
COTS Commercial “off-the-shelf” software or hardware CPS Commercial Package Store - a definition store, within LDI-WS, for the
200,000+ possible commercial packages CRS Content Requirements Specification (synonymous with PRS) CSS Cisco Content Switches DAP Data Analysis Portal (see SOFA) DBoR Database of Record DDS Data Distribution System DF4 Data Feeds 4 — a datafeed imported from Lipper FTP into NDA (legacy) DLT Digital Linear Tape Docklands The London data center, also known as DTC. DTC Docklands Technical Center EJV DataScope Onsite (EJV) consists of five primary databases (GovCorp, Mortgage,
CMO/ABS, Municipal, and Common) and two supporting databases (RIGs and Assumptions), and numerous flat files. Together these files cover over 3 million U.S. taxable fixed-income securities
ELF Exchange-Listed Funds ERD Entity Relationship Diagram — a database design documentation specification ETF Exchange-Traded Funds FAST The next-generation search capability within Reuters FCAL A high-bandwidth connection between a server and storage area network. FID Field Identifier FRD Fundamental & Reference Data: consists of highly structured & low-volatility
historical information. Examples of Fundamental Data: company fundamentals (e.g. Balance Sheets, Corporate Actions, Profit Estimates etc), instrument fundamentals (Bond Terms & Conditions, Price History of Equities etc) & Economic Fundamentals (GDP of UK). Reference Data consists of all the identifiers (e.g. RICs, Bridge Vehicles) & the classifiers (e.g. GICs) that enables Reuters content to be retrieved & cross-referenced.
FRF Fund Reference Feed: new feed of fund reference data from Lipper to NDA CoreCat
GDS The Lipper Global Datafeed Server GFD Global Fund Database: a generic term for the collection of Lipper’s Oracle
databases that are used for data loading, entry and maintenance. GFW Global Fund Warehouse – a generic term for the collection of all of
Lipper’s Oracle Data Marts. These databases are used for ad-hoc reporting and as the data sources for products
HTB Header Table IDN will continue to hold and distribute daily fund price data (NAV) and
intraday fund prices from exchanges (ETFs) IDNF A new feed to the IDN IDS Internet Delivery System IP Internet protocol ISG Internet Secure Gateway
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 7 of 65
Term Definition ISIN International Securities Identification Number: a code that uniquely identifies a
specific securities issue. The organization that allocates ISINs in any particular country is the National Numbering Agency (NNA)
ITM IBM Tivoli Monitoring KPI Key performance indicators LAI Lipper Administration Interface LDI Lipper Data Integration LDRP Lipper Disaster Recovery Plan LDS Lipper Data Stores LDI-WS LDI Web Services LFS Lipper FTP Server Lipper A Reuters company that provides research and analysis for more than
130,000 mutual and hedge funds and other collective investments worldwide.
LMT Lipper Middle Tier LWSI Lipper Web-Services Interface MCWS Multex Caching Web Services MDC Macclesfield Data Centre (UK) mDNA Multex mDNA (Market Data Normalization Application), a Reuters
service, is a data-reference management product Multex A set of two feeds (North America & Rest of World) that populate
consensus estimates data from the supplier, Multex MXPDB Multex Permissioning Host NBA New Business Architecture NDA Numerical Database Architecture (FRD-based web service). All Reuters
products offering fundamental & reference data will soon receive it from NDA, which consists of a data repository of content, applications and capabilities to collect, analyse and deliver this content to products.
NDC The Nutley, New York, data center PENStaB, Penda
Systems used to provide RIC add/drop and FID change information from IDN to NDA. PENStaB are FTP servers that regularly poll each of the DRS nodes, looking for new files to retrieve and process. PENDA is a self-sourcing feed that uses the PEN systemto feed data to NDA.
PE, PEN Permission Entity notifications feed of IDN reference data processed into NDA (originally developed to work with Toronto systems)
PIA Project Implementation Architecture PRS Project Requirements Specification (synonymous with CRS) PSX Portfolio Star Xtra (legacy) — a data feed imported from Lipper FTP
into NDA. Provides equity ownership data in 3000 Xtra. PTME Production Tivoli Management Environment
PTUC Primary Technical Use Case QDB Queryable Database: a new Lipper data mart used to provide fund data
to LWS RAC Oracle Real Application Cluster
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 8 of 65
Term Definition RCB Reuters Coherence Boundary — the point at which systems under
Reuters management interact with third-party systems. RDC Reference Data Convergence program and feed RDSS Reference Data Self-Sourcing application that processes the PEN feed and
provides maintenance and data sourcing facilities for Data Operations ReACT Global Capacity Planning data Warehouse
RFS Normally the country in which a fund is registered for sale, except for those international funds with an designation of ‘Offshore’.
RNDC Reuters Nutley Data Center RIC Reuters ID code RKWM Reuters Knowledge Wealth Manager RSC Reuters Service Center RTPN Reuters Trusted Production Network RWM Reuters Wealth Manager SAN Storage Area Network SMP System Management Provisioning
SOAP Simple Object-Access Protocol SOFA The Shared Oracle Forms Architecture provides the enabling
infrastructure for all forms applications that are used to input and maintain data on NDA. The SOFA menu is accessed via the DAP.
ssh Secure shell SunGard a disaster-recovery service TER Total Expenses Ratio Tivoli® IBM’s data-management tool Tornado 2.0 XML Routing Tool WSD Web Services Directory XML Extensible Markup Language XSD XML Schema Definition XSL Extensible Style-sheet Language
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 9 of 65
2 Business Context Lipper Fund Data is available in many Reuter’s products today. Customers of 3000 Xtra, Reuter Trader as well as Reuters Wealth Manager (RWM) and DataScope products all have access to fund information such as price data (NAVs), performance data (TimeSeries) and fund fundamental data (asset-management firm, fund manager, ratings etc.)
However, a different approach had been taken for product integration, sometimes ‘outsourcing’ the development to a third party (e.g. Brainpower or Wall Street On Demand). Moreover, fund data from Lipper has not been integrated with fund data on IDN, which is collected from contributors and exchanges (Exchange Listed) and traded on exchanges (Exchange-traded ETFs). As a result, fund data is processed, stored and displayed in many different ways, sometimes presenting redundant information with different identifiers (RICs).
The LDI project outlines the concept to harmonize fund data across Reuters and Lipper systems and to integrate Lipper fund databases in such a way that Reuters products have a consistent, homogeneous interface for fund-data retrieval and display.
The concept defines the Lipper Global Fund database as the master file or database of record (DBoR) for fund data. Copies or subsets of fund information have to be held in NDA for cross-referencing and FRD Search. IDN will hold and distribute daily fund price data (NAV) and intraday fund prices from exchanges (ETFs). Lipper IDs and other identifiers will be mapped and cross-referenced with ISINs and other available codes.
Access and interface to the funds DBoR will be done through the Tornado 2.0 web-services platform. This will allow programmatic access to QDB via the same web-services API as is used for access to all other FRD databases.
Lipper’s DBoR will provide a consistent, comprehensive source of fund data within Reuters architecture in order to support web services and meet the open-access content requirement of various premium desktop systems and data services.
A Funds Reference Feed (FRF) will be provided to integrate Lipper funds reference data with that of Reuters so that, from a customer’s perspective, all funds data will be searchable and navigable, as an integrated universe, with links out to other relevant datasets.
Fund support companies, fund entities, fund classes and fund quote assets must be correctly stored in CoreCat with their associated relationships. The relevant names, codes and classifiers used in Lipper must be correctly processed from the Funds Reference Feed (FRF) and stored in CoreCat. FRD Search will provide the product families with a single search solution for all fundamental and reference information. The FRF Search engine will index content (both stored and pre-calculated) from NDA, EJV and Lipper. Content is searchable by a range of criteria for: Equity & Companies, Funds (Lipper), Fixed Income, Futures & Options, Indices & Sectors, Economic Indicators (Ecowin), Commodity & Energy, Money and Foreign Exchange.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 10 of 65
2.1 Impact of the Feeds
2.1.1 Scope of the FRF
Scope Includes: • Defining the Lipper funds-reference data required for inclusion in a new feed of Lipper data to
NDA, called the Fund Reference Feed (FRF). This includes pension, insurance and hedge funds. • Mapping Lipper reference data to existing NDA CoreCat reference data. Lipper fund classes will
then be mapped to NDA’s exchange-listed funds (including ETFs). • Adding Lipper IDs to NDA CoreCat. • Managing data overlap and prioritizing updates when multiple sources exist. • The addition of orgid to the Lipper databases for fund entities and fund-support companies. • Removing duplicate fund assets and fund companies from NDA. • Extending the NDA funds business-data model to include additional Lipper data. • Data builds, particularly for fund-support companies. • Data cleanses, particularly for secondary IDs. • Revising NDA fund-company naming standards to adopt Lipper standards. • Revising Data Operations methods of working for the support of funds data in NDA CoreCat. • Ensuring that there is no duplication of effort in Data Operations.
Scope Excludes:
• Processing funds data, other than reference data, into NDA from Lipper. • Feeding Lipper TimeSeries to NDA. • Defining new RIC formats for Lipper data. • Resolving product issues with FRD Search and Lipper Global Fund Screener. • Improving the consistency of IDN Speedguides for funds. • Defining the Lipper data held in NDA Deep (PSX and DF4 feed data) that should logically be
removed, once the integration in NDA CoreCat is complete. • Lipper fund-holdings data. • Specialized, very fund-specific classification schemes available in Lipper that are not deemed part
of the scope of NDA’s cross- reference data.
2.1.2 Scope of the Lipper Search Feed
Scope Includes: The current Funds search within FRD Search, covers NDA exchange listed funds. This capability needs to be extended to offer an integrated search solution across NDA and Lipper Funds data in 2006. The scope includes Searching requirements for an integrated search of NDA Funds and Lipper Funds. In summary, this includes the following, subject to revisions:
• Funds Issues should be searchable by fund reference data including Fund Class Names – search fund classes by all supported names, e.g. long and short names.
• Fund Cross-Reference codes • Fund Support Company – Ability to search the following by long, short, legal names and
alternate names • Domicile – select from drop-down country list • Country Registered for Sale – select from drop-down selection list • Classification Schemes – the priority requirement is to search by Lipper Global Fund
classification scheme. All other schemes should also be available for selection.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 11 of 65
• Asset Type – select from drop-down lists; this is a list of predominant assets in which the fund invests: Bond, Equity, Mixed / Multi Asset, Real Estate, Currency / Money Market or Other
• Geographical Focus – selection list of primary country or region for a fund • Currency – list of currency to select from • Income Type – list of income types - list offering options of paid or retained • Primary Flag – Check box to return primary funds - EU Tax Directive • Fund Classification – selection list – Exchange-Traded Fund, Open Fund, Closed Fund, Open
Fund, Managed ETF, • Fund Identify – selection list – e.g. ABF fund, Closed End, Brokered Managed, Charities etc. • Exchange (not provided by Lipper) • Funds Status – Search requires Active and Pending funds. • Fees/Expenses • Investments • Lipper Leaders • Fund Size (Mlns )
Scope Excludes:
• Defining integration requirements for FRD Search within the respective products e.g. XTRA 5 other Lipper products.
• Defining the architectural solution for section in terms of how the FRD will be sourced and integrated in the search index
2.1.3 Scope of the IDN Feed
Fund data is currently supplied to IDN via three main sources: exchanges, contributors, and Lipper datafeeds. In many cases, the price data contained in the various quotes for a particular fund are identical. The project IDN will establish logical relationships between the various quote records, and link them to one primary RIC, which will be from the DBoR. Content displayed on IDN generally resides in misused FIDs, and when viewing the record template, users have no idea what most of the data actually is. The FIDs, record template, and display templates for the Lipper fund records will be redesigned so they are more intuitive and user-friendly. Additionally, the content of the records will be streamlined on IDN. At the highest level, we plan to accomplish two main objectives for fund data on IDN.
1. The universe of funds should be the same in Lipper and Reuters databases, with price data being updated in a very timely manner.
2. The storage, display, relationships and navigation between various records will be enhanced, enabling more efficient searching and access to fund records.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 12 of 65
Web Services: Lipper is a wholly-owned subsidiary of Reuters. The LDI-WS project is an initiative for Reuters and, more importantly, allows Reuters products to take advantage of Lipper data and services in an easy-to-consume manner. With this said, the LDI-WS project is seen as part of the larger FRD web-services initiative and is therefore working to align itself with any defining architecture in this space. Although there are presently web services in the FRD space, Lipper will be the first of these services to use the proposed central user-data store, MXPDB. This user store, from Reuters Research, will be the only user store for all FRD-based web services. Products desiring to consume FRD content will need to first register their users in the GUI-based administration system of MXPDB. This will generate a user ID with possible Lipper entitlements that can be used to make requests to the Lipper SOAP interface. It is presumed that all other FRD-based web services will migrate to the same user store (EJV and NDA). In addition to the requirement to use MXPDB, there will also be a requirement to use Tornado 2.0. Using Tornado 2.0 entails that Lipper SOAP headers will have to follow a compliant structure to allow for proper routing through the Tornado 2.0 infrastructure. The proposed format for representing a user context within a SOAP header is presented in the LDI Interface Definition document. The provided SOAP header standard is from Reuters Research. Feeds: Fund Reference Feed (FRF): NDA is the strategic DBoR for reference data, including fund reference data. Lipper’s Global Fund Database (GFD) is the strategic DBoR for all funds. It is a requirement of this project to provide reference data on funds to NDA when new funds are added or reference data is changed in GFD. Based on the existing NDA data contribution infrastructure, and Lipper’s existing data-production infrastructure, it has been determined that a data feed provided via FTP should be used for this purpose. IDN Feed (IDNF): It is a requirement of this project to ensure that the universe of funds available on IDN matches the universe of funds that is generally available in Lipper products, and that fund price data is updated in a timely manner. Considering the existing IDN infrastructure, it has been determined that a new data feed, provided via FTP, should be used for this purpose.
3.2 Project Requirement Analysis
3.2.1 Key Performance Indicators
Web Services: The offerings from the Lipper Web services will allow for the end user to consume the whole of Lipper content and services including:
• All information stored within Lipper as it pertains to a fund • All currency information as it pertains to how calculations and price histories are realized • Performance calculations for funds • The ability to get at historical fund information, including historical prices, NAVs, and TNAs
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 13 of 65
• Lipper Fact Sheets (a PDF document that details out a particular Lipper fund) • Static charts (for consumers that are unable to take all the data points in order to create their own
charts) • The ability to perform fund screening • The ability to store fund-screening results on a per-user basis (Peer Groups) • The ability to store an arbitrary list of funds on a per-user basis (Watch Lists)
The Key Performance Indicators (KPI) for the LDI project are to be based upon the initial requirements for the Reuters Knowledge Wealth Management (RKWM) product that is presently being developed in New York, as well as upon the initial requirements for the next release of 3000 Xtra (version 5.1). The intention from Lipper is to build an infrastructure to handle the proposed load from RKWM and 3000 Xtra for 2006-2007. Presently the plan is to support about 100 requests per second per deployed server. We will be able to fine-tune this number and come to a more accurate estimate after the web services are actually built and we can run the proper load tests on the services. With four web servers, this is more than enough to handle the anticipated load from both of these products. 3000 Xtra 5.1 anticipates the number of 3000Xtra users likely to use the e-Dex to retrieve Lipper data, at 2,000 end users per day, peak time being 100 simultaneous users.
LDI-WS will be built to handle current requirements for currently existing products in the RK family, as well as current uses of Reuters 3000 Xtra. Any future loads coming from future product requirements will be sized and funded by the product group making the request before additional hardware is added onto the deployed LDI-WS infrastructure. Also, even though the LDI-WS infrastructure will be built to handle the 2006-2007 usage from RKWM and 3000 Xtra, the LDI-WS team will have to re-engage both of these product groups in the middle of 2007 to work out ways to handle their growth plans for 2008-2009.
LDI-WS is being developed using a fan-out model. This means that, as more usage comes to bear upon the environment, the LDI-WS team will be able to simply add additional servers to the overall infrastructure in a horizontal manner. These additional servers will then pick up any additional load requirements.
Feeds: Not applicable.
3.2.1.1 Performance of Processing
3.2.1.1.1 FRF Performance Requirements
Adds, drops and changes made on Lipper to any of the data included in the FRF must be processed daily into NDA CoreCat. This requirement covers the period between a change being made in Lipper and that same change being visible in NDA CoreCat. Because of legacy requirements, no more than five updates should be made within a given 24-hour period (this requirement is expected to be dropped in 2007).
3.2.1.1.2 IDN Feed Performance Requirements
Awaiting details.
3.2.2 Capacity Planning, Limits, and Management
Web Services: Capacity planning, limits and management will be dictated by a set number of requests per second for each LDI-WS server. This number is presently thought to be about 100 requests per second. We will be
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 14 of 65
able to fine-tune this number and come to a more accurate estimate after the web services are actually built and we can run the proper load tests upon the services. The issue is that some LDI-WS web services are highly CPU-intensive and will have a considerably lower per-second count than services that are merely pushing some simple strings which already exist in the Lipper content stores. The more highly CPU-intensive web services tend to be the services that offer a dynamic calculation of some kind. There are even some calculations, such as those that produce an R-Squared value (a statistical measure that represents the percentage of a fund’s or security’s movements which are explained by movements in a benchmark index) that require an initial set of calculations before the final calculated value can be determined. Our approach will be to do a comprehensive test with all of the LDI web services to come to an average response-per-second number which will then be used to base the number of servers required of the LDI-WS infrastructure when new products come on-board to consume our data. Feeds: The estimates given below are based upon the size of the feeds when they are actually developed, at release of the PRS and Feed Specifications. These capacities will be revised after deployment of the test feeds and again when they go live. FRF: Initially ~50MB; annual increase will vary but is expected to average less than 1.0MB. IDN: Feed capacity will be predictable when the PRS and/or Feed Specification are available as final drafts.
3.2.3 Upgrade Management
Web Services: LDI-WS will be a 24x7 operation and will not have any scheduled downtimes. Software upgrades will include the following operations:
• Windows Server 2003 service packs and patch-management items • Database schemas and data content • Lipper.dll and LipperCalculations.dll upgrades • Web services interface code (.asmx pages) upgrades • Any upgrades to the Oracle ODP.NET data provider
All maintenance tasks should be completed during off-peak hours (8:00 p.m. to 2 :00 a.m. EST) in a manner that does not negatively impact service. Servers should be removed from the load-balanced pool prior to upgrading the software and restarting all processes. This will enable the rest of the farm to be live during the software upgrades. Under normal circumstances, these software releases will be scheduled during off-peak times. Data content will be fed in from the Lipper Denver data center on a daily basis. This is due to the fact that the master copy of the Queryable Database (QDB) is held in Denver and will be simply replicated to other QDB instances within Reuters. There will be no interaction required from Reuters for this to occur. Database content updates will occur at any time. Feeds: Not applicable.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 15 of 65
3.2.4 Support Requirements
Web Services: The LDI-WS will be hosted in the Nutley Data Center (NDC) and the Docklands Technical Centre (DTC). The LDI-WS servers will include read-only tools for viewing event logs and performance-counter snapshots in order for the server’s behaviors to be analyzed. All components located in the Lipper Data Center in Denver will be supported and managed by Lipper. The Radianz line between Lipper and the two Reuters data centers will be managed by Radianz. The following table details the other aspects of LDI-WS and who is providing support: Hardware Supported by Reuters Operations Operating System Supported by Reuters Operations Software components Supported by Lipper Operations and Support
Feeds: Both the FRF and the feeds to IDN, are hosted and managed by Lipper, according to standard policies.
3.2.5 Dependencies
Web Services: Although LDI-WS is made up of purely Lipper services, there are external dependencies which are required to complete the integration process into Reuters. LDI-WS is dependent upon the following components within Reuters:
• Tornado 2.0 – This is used to route SOAP messages to the requestor, based upon requests coming to LDI-WS through the Tornado routing infrastructure
• MXPDB – This will be the only user-data store used within the FRD space and, for this reason, LDI-WS will need to work with and understand MXPDB entitlement requests as well as user-context representations of an MXPDB user.
Each data-center LDI-WS deployed will require a Tornado 2.0 infrastructure to connect to. There will also be requirements to work with a Tornado 2.0 testing facility. MXPDB will be changed to work with the Lipper Web services, but will be put in place to manage the creation of users on the Lipper infrastructure and the assignment of entitlements to these users according to Lipper commercial package availabilities. Feeds: No dependencies are anticipated for the feeds.
3.2.6 Administration
Web Services: The administration of users is largely explained in section 4.3.4 of this document. The current plan is to use MXPDB as a tactical solution until LDI-WS is ready to migrate to GCAP. Feeds: Not applicable.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 16 of 65
3.2.7 Security
Web Services: LDI-WS is a backend system and will be running only within the Reuters network internally, and therefore will have traffic flowing only over a trusted network. Feeds: Awaiting details.
3.3 Architectural Constraints
Web Services: LDI-WS is constrained in using MXPDB and the defined SOAP header from the Tornado team to apply to any authorization processes within the Lipper data stores. LDI-WS cannot make use of Lipper standard server images for its developed products which are part of LDI-WS, such as Lipper’s preference of running Oracle 10g running on RedHat/Intel. Feeds: Oracle replication was determined not to be possible due to the Denver data center’s not being a production-level facility and having no direct communication channel.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 17 of 65
4 Logical Architecture 4.1 Key Capabilities
The principal logical capabilities include: • Lipper Data Stores • Commercial Package Store • User Store • Calculations Server • Lipper Web-Service Interface • Lipper Administration Interface, and • SOAP Router
4.1.1 Diagrams of Key Capabilities
Web Services: A very high-level flow-through diagram that describes the LDI-WS system is presented here, followed by a discussion of the component details.
Figure 4-1 – Diagram of Web-Services Key Capabilities
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 18 of 65
Feeds: Similarly for the feeds:
Figure 4-2 – Diagram of Feeds Key Capabilities
4.1.2 Descriptions of Key Capabilities
The following sections define each of these capabilities in more detail. Web Services
4.1.2.1 Lipper Data Stores
There will be a single database instance in the LDI-WS implementation. This database is referred to as the Queryable Database or QDB, which is not to be the master copy of Lipper content, but rather a collection
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 19 of 65
of multiple databases from the Lipper data center in Denver, Colorado (the Global Fund Warehouse or GFW). GFW datasets will be transformed and placed within QDB for use by the Lipper Web Services.
4.1.2.2 Commercial Package Store
The Commercial Package Store (CPS) within LDI-WS is a definition store for the 200,000+ possible commercial packages.
4.1.2.3 User store
The User Store will map MXPDB users to a commercial package (defined in the CPS) for use by the QDB to create a universe of data that is specific for the selected user.
4.1.2.4 Calculations Server
The Calculations Server is provided as a means to move more CPU-intensive dynamic calculations off of the database and off of the main web servers. The Calculation Server is dedicated to producing these dynamic calculations in the fastest time possible and is callable in an asynchronous manner.
4.1.2.5 Lipper Web-Service Interface
The Lipper Web-Service Interface is a SOAP-based interface to retrieve Lipper content sets in either a SOAP 1.1- or SOAP 1.2-compliant format.
4.1.2.6 Lipper Administration Interface
The Lipper Administration Interface is provided to expose Lipper commercial packages and to register any type of user for a specified package.
4.1.2.7 SOAP Router
SOAP messages to and from the Lipper Web Service Interface will be routed through a Tornado 2.0 infrastructure. All FRD web services will use this routing mechanism.
Feeds
4.1.2.8 Lipper Data Stores
There will be one or more Global Funds databases for the feeds implementation. This database is referred to as the GFD, which is a collection of multiple databases from the Lipper data center in Denver, Colorado. The GFD contains compressed text files which accommodate the specifications contained in the Reuters requests.
4.1.2.9 Lipper Datafeed Scheduling
The Lipper Global Datafeed Server handles all the feeds requests from the Reuters consumers and schedules the Lipper FTP server to prioritize them.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 20 of 65
4.2 Data and Interfaces
Web Services: Awaiting details. Feeds: LDI defines the Lipper Global Fund database (GFD) as the master file or database of record (DBoR) for fund data. Copies or subsets of fund information have to be held in NDA for cross-referencing and FRD Search. IDN will hold and distribute daily fund price data (NAV) and intraday fund prices from exchanges (ETFs), as well as a summary of the available fund data.
4.2.1 Content
Web Services: No impact on Reuters is anticipated. For further details, please see the Web Services PRS.
Feeds: The following datatypes are relevant to the LDI project. Their maintenance, DBoR, storage, and flows will be briefly described below, providing a general overview of the data involved.
Currently there is no complete cross-referencing of funds to exchange-related fund data held on NDA and IDN, and it is not easy for products to navigate between the datasets outlined below. Figure 4-3 shows the dataflows, to be put into place or enhanced, that will enable that navigation.
The table below shows the data sets involved in LDI, the database of record for that dataset, and where it is stored.
Data Element DBoR Storage Gaps Fundamental Fund Data o GFD o QDB
o IDN1 o Search
No new fields as part of LDI but possible extensions to country coverage.
Exchange-traded funds (market prices)
o IDN o NDA o QDB o Search
No gaps
Exchange-listed funds (market prices)
o IDN o NDA o GFD2 o QDB o Search
No gaps
Contributed Quotes o IDN o NDA o GFD o QDB o Search
Some contributed data to be re-instated to IDN for timeliness reasons
1 Note that the Lipper RICs themselves are homed on IDN, but their contents, which are a summary of fund data, are supplied from Lipper via a feed 2 Note that GFD stores a single RIC for a fund, rather than all RICs where the fund is listed on multiple exchanges
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 21 of 65
Data Element DBoR Storage Gaps Lipper RICs o GFD o IDN
o NDA o QDB o Search
Symbology to change. Country coverage to be extended
Cross reference of funds to RICs to companies
o NDA o GFD o QDB o Search
New feed from Lipper to NDA. RDC Generic and RDC Search feeds to be enhanced with cross reference data
NAV TimeSeries o GFD o QDB No gaps ETF TimeSeries (exchange prices only)
o NDA No gaps
Fund support and parent companies
o NDA o GFD o QDB o Search
Parent company support to be extended on NDA. Support companies to be maintained on NDA
Domain data, e.g. currencies and countries
o NDA o IDN o GFD
o QDB o Search
Currently maintained separately on all systems
Fund Classification o IDN o GFD
o NDA o QDB o Search
To be maintained on Lipper and derived on NDA. Quote classification remains on IDN
4.2.1.1 Fundamental Fund Data
Fundamental fund data refers all descriptive information about the fund except price and company information, which is documented separately. Examples of the data would be fund names, management fees, charges, domicile, etc.
This data will be maintained in the Lipper DBs, with GFD as the DBoR. Some data will be stored in NDA to enable Fast Search to function more efficiently. This will be delivered via the FRF and is defined separately. Limited data will also be fed to IDN via new feeds to be defined. All information will be available to product via web services.
4.2.1.2 FRD Domain Principles for Cross-Reference Data
The FRD domain architecture is based upon the principle of the Databases of Record (DBoR) that act as the repositories of all FRD data. The systems that host these databases are the places where primary data maintenance occurs and constitute the definitive records of the particular data they store. The intention is for product systems to use web services to retrieve FRD data. Ultimately the goal is that the web service which exposes a particular class of data will be supported on the DBoR for that class of data. This will ensure that the delay between updates of the data and availability to the products is kept to a minimum. Migration to a proper DBoR architecture will be a lengthy task, since the systems that service the current products are built on the principle of bringing the data together in one place and manipulating it to suit the product in question. Despite this, the decision has been made to move incrementally towards a framework based upon the DBoR concept, and the Reference Data Convergence project is part of that initiative. The RDC project is responsible for implementing the definitive out-bound feed of reference data from NDA. In order to guarantee that the introduction of this feed is a genuine step towards the agreed FRD architecture, the following two principles have to be enforced by RDC.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 22 of 65
A. Systems subscribing to the RDC feed must treat the received data as authoritative, and must not overwrite or otherwise change it, although the container design is a local issue. In many ways, the most appropriate paradigm is a copy feed, although filters may be appropriate if only a subset of the data is required to be held persistently. Since any updates applied directly to the local copy will mean that it is not synchronized with the source, this must be avoided except in emergency situations. The RDC feed contains data from many sources, and often recipients of the data will also be contributors of a subset of the data. Where the recipient system is the DBoR for a class of data3, then corrections, extensions or updates to relevant reference data must be sent back to NDA for cross-referencing and integration into the common feed.4
B. A subscribing system should not be exposing non-reference data for which it is not the database of record via the emerging web-service interface. Clearly, legacy compatibility may mean that this principle has to be waived in certain circumstances.
UDE for CLRD requires that the systems under development by the RDC project adhere to the first of these principles. Without this, UDE will fail to achieve its goals. For further details, please refer to Section 2.13 of the FRD PIA.
4.2.1.3 Fund Quotes
Quote data is the price and distribution information for the funds. This data will be populated from three sources: Lipper, exchanges, and contributors. All quotes will be published on IDN and the specifics are defined for the various data types below. Multiple RICs for the same fund will exist in many cases. A cross-reference of the fund identifiers to the corresponding RICs will be maintained in NDA so clients can navigate to the related records.
4.2.1.3.1 Exchange-Traded Funds
ETFs are predominantly passively managed funds that track a particular index and trade on exchanges in the same manner as equities (There are a handful of actively managed ETFs, but the data-flows will be the same for all types).
The data is received directly from the various exchanges. IDN is the DBoR for the market prices (bid, offer/ask, close, etc.), and the time series will be stored in NDA. It will not be fed to Lipper. The actual NAV is generally not received for ETFs.
4.2.1.3.2 Exchange-Listed Funds
Exchange-listed funds are essentially traditional funds that report their prices on one or more exchanges. This would include both open- and closed-end funds.
Like ETFs, the data is received directly from the various exchanges. IDN is the DBoR for the prices received from the exchanges, and the time series will be stored in NDA. It will not be fed to Lipper.
3 Since NDA is the database of record for company-level reference data, this situation cannot occur by design, only as a mis-operation. 4 It is a local implementation issue as to whether the local update is exposed in a given product before the update has been cross-referenced by NDA.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 23 of 65
4.2.1.3.3 Contributed Funds
Contributed data is provided directly to IDN from either a fund company or third-party provider such as CCLux. These are predominantly traditional funds that want their prices to appear on IDN.
The data is received directly from the various contributors. IDN is the DBoR for the prices received from the contributors, and the time series will be stored in NDA. It will not be fed to Lipper.
4.2.1.3.4 Lipper Summary RICs
Lipper RICs will contain prices and basic fund information provided by Lipper. This data will be maintained and stored in the Lipper DBs, with GFD as the DBoR. Some time series may be stored in NDA to enable graphing functionality, but ultimately, the products should extract via web services. This will be delivered to IDN via new feeds, defined separately. All information will be available to product via web services.
4.2.1.4 Classification Schemes
Classification schemes consist of two distinct levels. The highest level defines type of fund (closed-end, ETF, hedge, insurance, open-end, pension). More detailed classification schemes organize funds by their investment policy (global equity, UK bond, U.S. Large-cap Core, etc.).
The high-level classification will be maintained on IDN for all fund quotes (IDN is the DBoR and the data will be stored in NDA). This will be derived from various fund attributes for the Lipper RICs and is being defined in the IDN PRS, and will be delivered in the FRF. For non-Lipper RICs, this will be maintained directly on IDN and will flow into NDA.
The more detailed classifications will be maintained in the Lipper databases, with GFD as the DBoR. The Lipper Global classification scheme will be delivered in the FRF and will also be delivered to IDN. This and other local schemes will be available via web services.
4.2.1.4.1 Fund-Support Companies
A Fund-Support company is an individual company which is responsible for a particular role or roles in relation to one or more legal-fund entities. These roles are fund manager, advisor, administrator, custodian, promoter and/or sub-advisor. Fund-support company data is maintained directly on NDA and distributed via the RDC feed to Lipper. This data is stored in both NDA and Lipper.
4.2.1.4.2 Fund Parent Companies
A fund’s parent company is the immediate parent company of a fund-support company. The parent company may itself be a subsidiary of another company. A fund’s parent company’s data is maintained directly on NDA and distributed via the RDC feed to Lipper. This data is stored in both NDA and Lipper.
4.2.1.4.3 Domain Data
Domain Data is the generic term used to describe classification schemes for countries and currencies. ISO standard codes are used when available and supplemented as required. For example, GBp is a non-ISO currency code used to identify GB pence. Sub-countries such as Jersey, Guernsey and the Isle of Man are also included. The schemes are maintained and stored on NDA, Lipper and IDN, and are synchronized manually. The application of domain data is carried out on each of the relevant DBoRs for company, asset
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 24 of 65
and quote data, and is supplied respectively as follows: via the RDC feed from NDA to Lipper; the FRF from Lipper to NDA; and the PEN feed from IDN to NDA.
4.2.1.4.4 Reuters Content Consumption
This section focuses on preexisting Lipper content necessary to fulfill the requirements of Lipper Data Integration. The following table summarizes how Lipper content sourced outside of this project will be consumed by this project.
As part of LDI:
• there will be no new data generated other than cross-referencing of existing data • there will be increased country coverage of summary fund data available on IDN • there will be increased country coverage on Lipper to reflect coverage • cross-references will be generated on NDA between funds, their associated quotes and
companies and this cross reference data, distributed via the RDC feed • the cross-reference data will be made available from NDA on the RDC feed for consumption by
Lipper and Search • Search will consume cross-reference data from NDA and a richer set of funds data on a feed
directly from Lipper • Lipper will consume cross-reference data from NDA via the RDC generic feed
Content Source Any missing fields/entities/relationships
Lipper content GFW (Global Fund Warehouse)
No gaps
4.2.1.4.5 Reuters Content Generation
There are no new data entities being built as part of LDI. However, funds-reference data already available in Lipper systems will be distributed, cross-referenced and stored on NDA and then used by FRD Search. Cross-referenced data on NDA will also be distributed to Lipper via the RDC feed, providing Lipper with support and parent-company data as well as with all cross-referenced codes for a fund. The fund’s cross-reference data will also be available to all other consumers of the RDC Generic feed, e.g. mDNA.
4.2.1.4.6 Lipper Content Generation
There is no need for content generation for this implementation.
4.2.1.4.7 Third-Party Content Consumption
There are no new third-party data entities being consumed as part of LDI, other than the reinstatement of the CCLux feed of contributed-fund data to IDN. This feed was discontinued in 2005 because the data is available via Lipper. However, clients have requested its re-instatement because the IDN data was timelier than Lipper’s.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 25 of 65
Content Source Interface type SLAs
CCLux feed of contributed fund data to be reinstated to IDN
CCLux
4.2.1.5 Feeds Supported
4.2.1.5.1 Feed to IDN
Fund data will be delivered to IDN via datafeeds. Currently, all information is updated daily from DF4. Fund-pricing data in IDN is not currently timely enough when sourced via existing Lipper feeds, as there is a significant lag between the data being entered into the Lipper DB and when it is available on IDN. DF4 will continue to be the source for all data except prices, updated once daily. Lipper will provide supplemental price feeds to increase the timeliness of pricing information.
Scope Includes: • Ensuring universe of Lipper funds is the same on IDN as it is in GFD (increasing coverage) • Increasing timeliness of price data • Logical use of FIDs and templates • Simplifying Lipper RIC structure
Scope Excludes:
• Retrieving data via web services • Increasing fund-data content on IDN.
More in-depth information will be incorporated into other tools, accessible through Xtra.
4.2.1.5.2 Data Feeds 4
Data Feeds 4 is produced by Lipper in Macclesfield, UK (MDC). It is a legacy Lipper datafeed product which is picked by NDA from a Lipper FTP site and imported into NDA. LDI web services will provide methods for providing all the data in DF4.
4.2.1.5.3 Portfolio Star Xtra (PSX feed)
The PSX legacy feed is produced by Lipper in Denver and sent, via FTP, to NDA. This feed contains equity-fund portfolio holdings and is used in 3000 Xtra to provide equity ownership data. LDI web services will provide the methods required to duplicate this functionality.
4.2.1.5.4 Fund Reference Feed (FRF)
The Fund Reference feed is a new feed that will be generated by Lipper and sent via FTP for import into NDA CoreCat. The aim of the feed is to facilitate the integration of Lipper fund reference data with the rest of Reuters reference data, enabling NDA to fulfill its role as the database of record for reference data. Reference data in this case includes the names, codes and classification schemes of funds and fund-support companies as well as the relationship between those funds and companies.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 26 of 65
In addition to the feed, changes will be made to the way funds are processed and stored in NDA.
4.2.1.5.5 Reference Data Convergence (RDC)
The RDC Generic Feed delivers reference data which is of general usage across Reuters technical domains, for example to mDNA (in Multex) and CEMP (News). RDC distributes a set of reference data as defined in the RDC Generic Feed Data Definition which has been collected and cross-referenced on NDA. The aim of RDC is to reflect the requirements to enhance the content set, to minimize duplication of the content across Reuters’ technology platforms and to manage reference data as a valuable commodity. The RDC feed will be enhanced as part of the LDI project to contain key funds cross-reference data that will be built as part of the FRF LDI subproject.
Reference data is the glue that binds different content sets and content sources. Reference data for the purposes of Reference Data Convergence comprises:
• Symbology content o the classification and identification of business entities o the mapping of different symbologies such as RIC, Lipper id, EJV Asset Id or Bridge
vehicle o defining attributes and key relationships of business entities
• Static content such as o classification schemes
• Descriptive content such as o help text o content descriptions
The RDC Generic Feed aims to deliver the reference content to internal customers in order to enable them to augment their specialized content with appropriate cross-referencing and descriptive content. Within the FRD Domain, the Numeric Database Architecture (NDA) database is designated the Database of Record for cross-referencing and reference information. NDA provides the central store for the symbology content and for the storage and mapping of different classification schemes such as EJV Asset Classification, Reuters Research Industry codes and NDA Asset Classification.
The Generic RDC Feed is a published data file delivered in an XML format, based on an XML Schema Definition (XSD). It is an event-driven delivery based on NDA database updates, captured and formatted on a regular basis. The feed is generated both as a full extract of the content for initial target-database load and as a file of subsequent changes. The data files are placed on a file-data server to enable the retrieving systems to pull the files using file-transfer protocol (FTP). The full extract is available on request; the delta feed is generated on a regular basis (anticipated to be every 15 minutes).
Lipper will consume the RDC feed to improve the way it currently obtains reference data for fixed-income and equity instruments. The RDC feed will provide Lipper with support-company information which will be maintained on NDA as along with fund cross-reference data.
LDI – Lipper Data Integration V0.4 Definition Stage Page 27 of 65
4.2.2 Service Interfaces
For in-depth detail on the interfaces, please see the LDI Interface Definition Document (IDD)
Web Services: LDI-WS does not consume any interfaces for data or services. Instead, LDI-WS exposes both a main web-services interface and an administrative web-services interface, and it exposes web-service interfaces to Reuters. Feeds: Awaiting details.
4.2.2.1 Services Interfaces consumed
There are no service interfaces which are consumed in the LDI project.
4.2.2.2 Services Interfaces Provided by the Project
Web Services: The main goal of this internal capability (LDI) is to provide an interface for consuming Lipper content sets. Therefore, there are a series of web-services interfaces in place to accomplish this task. The web services will be separated into the following categories:
• Funds • Charts • Watch Lists • Peer Groups • Currencies • Developer Information
Access to the web services will be done through synchronous request/response invocations using SOAP over HTTP. The web services will be able to handle both SOAP 1.1 and SOAP 1.2 message formats.
The other interface available will be an administration interface. This interface will expose the capability of retrieving all the available Lipper commercial packages and will allow for administration systems, such as MXPDB, to assign users to a particular commercial package.
4.2.2.3 Data Extraction and Transformation
Web Services: Awaiting details. Feeds:
The feeds will all be coded in Oracle PL-SQL, and Lipper will determine which updates have been made that need to be provided to Feed customers.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 28 of 65
The files produced are placed on the Lipper FTP Server (LFS), each in its own folder. The exact file folders will be determined at the time of installation. Files will be retained in those folders for 90 days and then they will be archived.
4.2.2.4 Queryable Database (QDB)
Web Services: Awaiting details. Feeds: Not applicable – the QDB is only for web services.
4.2.2.5 Update Cycle
Web Services:
Awaiting details. Feeds: The feeds would be updated once daily, Monday through Friday, including holidays (since each country has its own holidays). Special updates can be done at any time, and will be completed within 60 minutes of initiation, and lack of finding a special update will result only in waiting for the next update; however, a missing daily update will cause an error condition.
FRF: A full feed will be issued monthly, or upon customer request, whereas incremental feeds (deltas) can occur on any weekday.
4.2.2.6 Initial Load and Replays
Web Services: Awaiting details. Feeds:
A full extract is performed for a target system’s initial load or resynchronization. This is in the same format as the incremental changes.
FRF: Full feeds are performed monthly, and deltas are issued daily (M-F, including holidays). Exact file folders will be determined during development. Each feed will have its own folder on Lipper’s FTP server. Files will be retained in those folders for 90 days before being archived.
4.2.3 Schemas for Stored Data
Awaiting details. All required transformations will be handled in the GFD, and therefore will be transparent to Reuters.
4.2.4 Diagrams of Internal Data Flows
The following diagram shows the overall logical architecture for LDI systems and data flows, followed by a description of each of its components.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 29 of 65
Figure 4-3 – LDI Systems and Data Flows
4.3 Components
4.3.1 Diagrams of Key Components
Web Services: This is a logical view of the LDI-WS components. Each of these items will be discussed in more detail starting in section 4.3.2.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 30 of 65
Figure 4-4 – Diagram of Key Components
Feeds: Not applicable
4.3.2 Description of Key Components
Web Services: The Lipper Web Services architecture is made up of multiple layers. At the bottom of the architecture is the Lipper central system. This is where all of the Lipper data, information and services are stored. This is also where the Lipper user and entitlements stores are located. Above the data layer is the Lipper Middle Tier (LMT). This layer provides the web services layer with an API to help retrieve data and to initiate services from the Lipper data layer. Above the API layer (LMT) is the Remote Interface layer, also known as the Web-Services layer. This layer is where Reuters will interact to get at Lipper content and services. Next is an explanation of each of these layers.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 31 of 65
4.3.2.1 Lipper Data Layer – Oracle 10g
All Lipper data content is held in an Oracle 10g database. This is also the location of the Lipper user store and the Lipper entitlements databases.
4.3.2.2 Lipper Data Factory – Lipper Middle Tier (LMT)
The LMT layer performs all of the required data retrieval and processing. Not only does the LMT layer perform data retrieval through a data-object layer, but any additional processing of data is performed through the business logic layer of LMT. The data logic layer is not limited to pulling data from only the Lipper data stores, but instead is constructed in a way to allow the LMT layer to pull data from other internal Reuters data stores in the future.
4.3.2.3 Lipper Services
LMT will also interact with some additional Lipper services, such as providing access to static PDF-based Lipper Fact Sheets and chart generation. Static PDFs are used to analyze funds by the end user. Dynamic charts are used for visually documenting funds and fund peer-groups.
4.3.2.4 Lipper Web Services
The Lipper Web Services are using the API from the LMT layer as well as the API to interact with the various Lipper services to expose Lipper’s core offerings via Tornado-based Web Services to other product groups in Reuters. User credentials will be routed, along with the SOAP requests, to the Lipper Web Services interface in the SOAP header. The user credentials are initially provided via MXPDB (a Reuters Research system). Tornado 2.0 simply routes the user context with the SOAP body message and is not required to partake in the authentication/authorization process.
4.3.2.5 Lipper Admin Web Services
The Lipper Admin Web Services are put in place for only one reason – to provide Lipper entitlement details to MXPDB and to receive an MXPDB User ID from that system. There will be no other interactions and for this reason does not require routing through the Tornado 2.0 system.
4.3.2.6 Lipper Web Services Catalog
In addition to the Web services provided, there will also be a developer catalog of available web services. This developer portal will offer application developers the means to test any web services available. It will also provide best practices and developer contact information. Feeds Packages for programming the feeds’ capabilities.
4.3.2.7 Lipper Databases
There will be one or more Global Funds databases for the feeds implementation. This database is referred to as the GFD, which is a collection of multiple databases from the Lipper data center in Denver, Colorado. The GFD contains compressed text files which accommodate the specifications contained in the Reuters requests.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 32 of 65
4.3.2.8 Lipper Datafeed Server
The Lipper Global Datafeed Server handles all the feeds requests from the Reuters consumers and schedules the Lipper FTP server to prioritize them.
4.3.2.9 Oracle 10g Databases
The functionality of the feeds will be implemented with Oracle PL-SQL packages.
4.3.3 Support for Problem Identification
Web Services: Awaiting details. Feeds: Awaiting details.
4.3.4 Data Security
This section is meant to define a workflow process in the area of authentication and authorization which product groups will utilize when consuming any Lipper dataset. The main components involved in this discussion include the following:
• MXPDB – The Multex Permissioning Host.
• QDB – The Lipper Queryable Database.
• Lipper Administration Web Services Interface – Lipper is exposing an interface for notification of the creation of MXPDB users who require Lipper content.
• LDI Web Services Interface – Lipper is exposing an interface of consumable SOAP-based web services to various Reuters product groups. This will be the main path to consume Lipper content.
• Token – There is a token which will be passed through the Reuters infrastructure to request FRD data.
For Reuters products which wish to consume Lipper datasets from the FRD universe of data, there is a specific amount of workflow and system interactions which need to occur. In order to interact with the Lipper web services, there is a requirement that product groups will need to first establish a user and provide the appropriate level of Lipper entitlements to the user.
The process of creating a user context which is enabled to consume a Lipper dataset is illustrated in the following diagram:
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 33 of 65
Figure 4-5 – Creating Permissions for a User
The authentication/authorization points to remember when consuming any Lipper dataset are: authentication is a product-edge capability; general authorization is a process defined by a bit-flag definition outside of Lipper; and authorization enforcement is accomplished by Lipper, based upon Lipper commercial packages.
The following list defines each of the systems which are involved in this process, first starting with MXPDB, the Multex Permissioning Host.
4.3.4.1 MXPDB – The Multex Permissioning Host
The Reuters database of record for users that wish to consume FRD datasets (including Lipper datasets) is MXPDB, the Multex Permissioning Host. Any product group in Reuters that wishes to get at FRD content to display in their product will need to first place their users in the MXPDB database. Creating a user in MXPDB is a manual process and from an administrator perspective will involve a web-based, tabbed-screen application. There will be a single tab screen which will entail assigning the appropriate Lipper content to a user.
On the Lipper content screen within MXPDB, administrators will be able to turn on a bit-flag to allow for Lipper content. Reuters Research will store this flag and decide whether to process requests for Lipper content based upon the flag’s value.
On the Lipper content screen within MXPDB, administrators will be able to assign either an open entitlement selection or a pre-defined commercial package based upon an agreement made with a specific Reuters product group.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 34 of 65
4.3.4.2 Open Entitlement Selections
An open-entitlement selection process will allow administrators to define a Lipper entitlement universe by selecting criteria based upon the following:
• System-wide – all or nothing • Country registered for sale (RFS) • Asset class • Asset allocation • Full holdings • Total Expenses Ratio (TER)
Once an open entitlement selection group has been defined, MXPDB will then forward on the MXPDB User ID, the product the user is associated with, and the selected entitlements to Lipper (QDB) through the Lipper Administration web-service interface.
4.3.4.3 Predefined Packages
The predefined packages option will be defined on a per-product basis. Not all products will have predefined packages. Products which have predefined packages will be displayed in the MXPDB administration GUI. MXPDB Administrators will be able to associate a user to a defined package.
For example, if the administrator knows that they are creating a user for Reuters Product XYZ, then they will be able to select that product from a drop-down list and view the entitlement packages which are available for Reuters Product XYZ. From there, the administrator will be able to select one of these entitlement packages. MXPDB will then forward on the MXPDB User ID, the product the user is associated with, and the selected package to Lipper (QDB) through the Lipper Administration web-service interface.
4.3.4.4 Lipper Administration Web Services Interface
Lipper will provide a SOAP-based interface to accept notifications of users who have registered for Lipper content. Notifications will include the product type for which the user is being created, the MXPDB User ID, and the Lipper entitlement universe (or pre-defined product entitlements package) that should be associated with the user. The web service interface will respond with a ‘Success’ or ‘Failure’ response.
Lipper’s QDB will store the entitlements, or the Lipper commercial package, that are associated to a set User ID.
4.3.4.5 Interacting with the main LDI Web Service Interface
Web service requests will come to Lipper’s Web Service Deployment and include a Reuters Research token. This token will be used by Lipper to enforce the entitlements of the requestor and to provide, in response, a dataset that is appropriate for the level of entitlements defined.
4.3.4.6 Token Structure
Token encoding will use 3-DES encryption and the shared key for decryption will be provided to Lipper.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 35 of 65
4.4 Service Resilience
Web Services: LDI-WS will be built to handle current requirements for currently existing products in the RK family. For 3000Xtra, the usage estimated is based on the expected number of 3000Xtra users that are likely to use the e-Dex to retrieve Lipper data which is estimated at 2,000 end users per day, peak time would be 100 users at the same time. In terms of resiliency, the maximum recovery time would be within one working day.
Feeds: Both IDN and FRF are recoverable within 48 hours, per Lipper’s current disaster recovery plan.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 36 of 65
Project Service Resiliency Tier Core
Essential Functions (Tier 1, 2, 3, or 4)
Non-Core Value-Add Elements
(Tier 1, 2, 3, or 4) The decision to aim for Tier 3 was based upon the following document:
http://www.ime.reuters.com/doclib/public/documents/details.asp?document=9484 For each category, we have the types of products impacted, followed by the risks:
• Information: Various global-information desktop products – disruption to users and/or reputational damage.
• Transactions: Products which provide transactions data – disruption to users’ workflow.
• Internal & Communications: Most product support & some internal admin systems – inability to update orders, pay suppliers or log issues.
3 3
The tier which the LDI project expects to achieve for its products and services
3 3
Component Service Resiliency Tier Core
Essential Functions (Tier 1, 2, 3, or 4)
Non-Core Value-Add Elements
(Tier 1, 2, 3, or 4)
The business requirements for Wide-area Communications Failure: Tier 3: Single communications link fails with functional but degraded service.
3 3
The business requirements for failover or recovery from the failure of a hardware device (e.g. servers, network devices storage devices, LAN links, chillers, UPS, switchboards, etc.) Tier 3: Single device failure recovered within 5 minutes; re-login may be required.
3 3
What are the business requirements for failover or recovery of a site due to a multi-device failure, rack loss, fire or flood, floor loss, up to and including complete site loss?
Please identify one of the following: Tier 1) Site failover within 1 minute, with only in-flight transactions lost. Tier 2) Site failover of retrievals within 1 minute, updates recovered in 1
hour with only in-flight transactions lost. Tier 3) Site failover within four hours, with up to one hour of data loss. Tier 4) Site failover within 1 day, with up to 1 hour's data lost.
LDI – Lipper Data Integration V0.4 Definition Stage Page 37 of 65
Component Service Resiliency Tier Core
Essential Functions (Tier 1, 2, 3, or 4)
Non-Core Value-Add Elements
(Tier 1, 2, 3, or 4)
What are the business requirements for recovery from a catastrophic corruption of data, rendering the product immediately unusable (e.g. SAN corruption)?
Please identify one of the following: Tier 1) Data restore within 1 hour with maximum 5 minutes data loss. Tier 2) Data restore within 4 hours with maximum 30 minutes data loss. Tier 3) Data restore within 12 hours with maximum 1 hour data loss. Tier 4) Data restore within 12 hours with maximum 24 hours data loss.
To Do To Do
What are the business requirements for survival of a failure of the external power mains?
Please identify one of the following: Tier 1) Survive dual mains failure for 7 days or single mains failure
indefinitely. Tier 2) Survive mains failure for 3 days, and single generator failure. Tier 3) Survive mains failure for 3 days. Tier 4) Survive mains failure for 30 minutes.
To Do To DO
The requirements for maximum scheduled downtime: Tier 2: Downtime to be scheduled: 8 hours / month
2 2
4.5 Architectural Dependencies
Web Services: Awaiting details. Feeds: Awaiting details. The following table summarizes all gaps for this project. Where gaps exist, details are noted below.
System or Project Brief Description of Dependency
Existing Capability (Yes/No)
Existing Capability
Gap (Yes/No)
Is the capability at least as resilient (i.e. Service Tier) as this project’s
target Tiering (Yes/No)
Tornado 2.0 SOAP routing No No Unknown at present MXPDB User registration Partial
4.5.1 Dependency Gaps
Web Services: Awaiting details.
Feeds: Not applicable.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 38 of 65
5 Physical Design 5.1 Wide Area View
5.1.1 Geographic View
Web Services: The plan is for the Nutley and Docklands sites to be redundant with each other in the future as required, depicted in the following diagram:
Figure 5-1 – Geographic view for Web Services
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 39 of 65
With the exception of the existing DBoR, the LDI infrastructure will be deployed in the HDC, with future plans for full deployment of live redundancies in the DTC.
Fund data collected by Lipper will be stored in the DBoR hosted in the LDC. The DBoR will push fund information to the QDB hosted in Reuters technical centers.
The QDB and Calc Engines will respond to requests from the web-service layer and ultimately to the application logic from the client.
Figure 5-2 – Diagram of Inter-site Communications
Feeds: The following figures shows the differences for the feeds:
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 40 of 65
Figure 5-3 – Geographic view for Feeds
Figure 5-4 – Diagram of Inter-site Communications for the Feeds
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 41 of 65
5.1.2 Site Failover
Web Services: Initial deployment will be in a single site (Nutley) with expectations of deploying into the Docklands Technical Centre in 2007. If one of the sites is shut down for any reason and there is a failover to the other location, some end users will experience latency in the responses received from the Web services.
Tornado 2.0 will determine which site to use for failover.
Feeds: Failure of the LDC will invoke Lipper’s disaster-recovery plans, accomplished using SunGuard recovery services. This is recognized as a risk as it may take several days to restore services from a SunGuard data center.
Failure of the primary FTP server will invoke Lipper’s disaster-recovery plans, accomplished by promoting the Denver mirrored-FTP server to a live status. Failure of the LDC will invoke Lipper’s disaster-recovery plans, accomplished by rerouting all FTP traffic to a hot standby in Lipper’s Macclesfield, England, data centre (MDC).
Figure 5-5 – Physical Infrastructure Storage View for Feeds
5.1.2.1 Failure of the Global Fund Database (GFD)
Web Services and Feeds: Failure of the GFD will invoke Lipper’s disaster-recovery plans, accomplished using SunGuard recovery services. This is recognized as a risk as it may take several days to restore services in a SunGuard data center.
5.1.2.2 Failure of Lipper Data Center
Web Services and Feeds: Failure of the Lipper data center will invoke Lipper’s disaster-recovery plans, accomplished using SunGuard recovery services. This is recognized as a risk, as it may take several days to restore services in a SunGuard data center. No hot or warm standby is planned for the data center. The diagram below depicts the plan:
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 42 of 65
Figure 5-6 – Diagram of the Failover Plan for the LDC
5.1.2.3 Failure of Nutley Data Center (2006)
Web Services: No service redundancies are planned in the NDC for 2006.
Feeds: Not applicable because the feeds do not interface with the HDC.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 43 of 65
5.1.2.4 Failure of Nutley Data Center (2007)
Web Services: Full redundancy is planned in 2007, via Tornado 2.0, with failover to the Docklands Data Centre (DDC).
Feeds: Not applicable because the feeds do not interface with the NDC.
5.1.2.5 Failure of Docklands Data Centre (2007)
Web Services: Full redundancy is planned in 2007, via Tornado 2.0, with failover to the NDC.
Feeds: Not applicable because the feeds do not interface with the DDC.
5.1.3 Storage Replication
Web Services: The GFD DBoR updates each rack cluster in the QDB. HDC and DDC are updated via Oracle streams from Denver.
Feeds: The FTP server replicates out to the Macclesfield data center (UK).
5.1.4 WAN Links
Web Services: Data links between Lipper and Nutley data center are dual T-1 lines, via Reuters Trusted Production Network (RTPN). Data links between Lipper and Docklands technical center are dual T-1 lines, via the RTPN. Data link between Nutley and Docklands technical center is via the current Reuters infrastructure. Data link between client and Nutley data center is via Tornado 2.0. Data link between client and Docklands technical center is via Tornado 2.0. Data links between the SunGard Data Recovery Center and the Nutley and Docklands technical centres are via a single T-1 line to each center and using the RTPN. Feeds: The feeds use the public Internet.
5.2 Data Center
5.2.1 Placement in Data Center Infrastructure
Web Services:
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 44 of 65
Cabinet space required for full implementation in each of the Nutley and Docklands centers will be 26 rack units without the disk array. Actual cabinet space will be dependent upon potential use of Reuters’ equipment. Reuters will own the infrastructure deployments in both Nutley and Docklands.
Placement of physical servers and communication equipment will come from the Reuters operations group.
Feeds: Not applicable, due to the feeds’ being stored in the LDC, Denver.
5.3 LAN, Servers & Storage View
5.3.1 LANs, Servers & Storage
Web Services: In each data center installed, the two Cisco Content Service (CCS) switches are connected through Tornado 2.0, and also, via Ethernet, to the web-services hosts which, in turn connect, again via Ethernet, to two QDB hosts with teamed NICs using SunFire V440 with four CPUs and 1.6GB RAM. These are connected, via a pair of McData fiber switches (24 ports, one primary, one secondary), to a Clarion disk array with 1.0TB raw. Please see Figure 5-7.
Feeds: Physical deployment of additional servers is not necessary, as infrastructure equipment is already in place in Denver. Refer to Figure 5-7 to view current physical infrastructure.
5.3.2 Project Servers
Web Services: Servers specified are Reuters-accepted hardware.
Node Description Web Service Hosts ProLiant DL360: Generation 4, 1U dual-processor rack server. Processors:
Two Intel Xeon processors: 3.06-GHz/800MHz. CPU Cache Memory: 1.0MB level-2 cache. Memory: 6.0GB PC2700 DDR RAM. Disks: 2 x 72GB 10K U320 hot-plug hard drives, 1 x dual NC7782 Embedded Gigabit PCI-X NIC, RPSU, DVD-ROM Operating System: Windows 2003 Disk: Internal 2x72GB Mirrored Software: Microsoft IIS, Microsoft .Net, Reuters standard Anti-Virus, Connectivity: HTTP/HTTPS protocol request from client,
QDB / Calc Engine Hosts
Sun Fire V440 Server: 4 * 1.593GHz UltraSPARC IIIi, 8.0GB Memory(16 * 512MB DIMMS), 4 * 73GB 10Krpm Ultra320 SCSI Disks, DVD-ROM, two power supplies Operating System: Solaris 10 Disk: Internal OS and application mirror, Dual HBA for SAN Raid 0+1 with 1.0TB (raw terabytes) of disk space (2.0TB mirrored, QDB only). Software: Oracle, Oracle RAC Connectivity: SQL/RPC request from web service
Disk Array Model: EMC CX500 Assumption: Possible use of current Reuters hardware
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 45 of 65
Feeds: Physical deployment of additional servers is not necessary, as infrastructure equipment is already in place in Denver.
5.3.3 Detailed Server Connectivity
Web Services:
Node Description Web Service Hosts Network Connectivity: (1) dual NC7782 Embedded Gigabit PCI-X NIC,
HTTP/HTTPS protocol request from client (Tornado 2) QDB Network Connectivity: (2) 1-Gigabit NIC’s, SQL/RPC request from web service
Storage Connectivity: Dual 2GB HBA’s for SAN connectivity
Feeds: Physical deployment of additional servers is not necessary, as infrastructure equipment is already in place. Refer to Figure 5-5 to view current Physical Infrastructure Storage View.
5.3.4 Storage View
Web Services: The QDB’s will require 300GB of storage per QDB database, with annual growth of 25% (based upon current data trends), configured with the Reuters standard of RAID 5. Each server will contain two HBA’s for redundant SAN connectivity. Internal disks will store the operating system and applications, using RAID 1. Feeds: Physical deployment of additional servers is not necessary, as infrastructure equipment is already in place in Denver.
5.3.5 LAN View
Web Services: Network appliances specified are Reuters accepted hardware.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 46 of 65
Figure 5-7 – LAN & Server view
Node Description Cisco Content Service Switch
Model: 11000 Operating System: IOS Connectivity: 10/100/1000 Assumption: Possible use of current Reuters hardware
Network Switch Cisco 3750 Operating System: IOS Connectivity: 10/100/1000 Assumption: Possible use of current Reuters hardware
SAN Fiber Switch Model: McData Assumption: Possible use of current Reuters hardware
Feeds: Awaiting information.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 47 of 65
5.3.6 WAN/LAN Protocols between Servers
Web Services: Please refer to Figure 5-2, above (Inter-site Communications). The Lipper DBoR (GFD) communicates with the QDB via Oracle messaging streams or via TCP/IP, and with web services via HTTP and HTTPS. The Web Services layer also communicates with the Application Logic via HTTP and HTTPS.
Feeds: The Lipper DBoR (GFD) communicates with the Lipper FTP server via FTP. Refer to Figure 5-4, above (Inter-site Communications).
5.4 Capacity Planning and Scalability
Web Services: The web services front end, QDB and Calc-server capacities are scaled by adding servers, as needed, to the clusters.
The KPIs are to be measured from the delivery of the data center. Client-side times are a function of the main message delivery and all ad content; they cannot be considered as parameters for the site. Currently, LDI deployment is based on the ability to sustain the amount of average traffic by a factor of four (to represent the ability to sustain a failover within a single data center and failover to a secondary data center.) This requirement represents the capacity at deployment. As the site usage grows, the business unit will establish a high-water mark that must be exceeded before additional capacity must be added. Capacity and utilization monitoring is provided for the following infrastructure components.
5.4.1 Physical Stats – Operating Systems and Cell Network Components
Operating Systems
Collection of physical stats for Windows 2K3 (web services front end) and Solaris 10 (QDB and Calc- servers) is achieved by deploying standard IBM Tivoli Monitoring (Capacity) profiles; these profiles are readily available within the Tivoli Management Framework.
Full details of the statistics collected, granularity and how the deployed solution extracts, transfers and loads metrics into the Reuters ReACT central capacity store, is documented in the “ITM Capacity Planning stats for Windows and Solaris platforms design” document. Document URL is provided in the reference section.
Cell Network Components
Capacity collection for the networking cell components, described in the LAN view section (Distribution switches used to connect the Load Balancers, switches and firewalls) is achieved using IBM’s Netview. Following component discovery, data is collected using snmpget methods. Metrics are stored in the Netview SNMP collections database and extracted on a daily basis. Format of the output is to a standard agreed by the Global Capacity Planning group. Collection from the Netview Management server into ReAct is via an FTP pull.
The statistics collected are as follows:-
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 48 of 65
Firewalls
All Interface utilization (In/Out octets), System Load, Connections, ProcUsage
Switches
Interface utilization (In/Out octets) for Infrastructure links deemed critical to the Service and CPU Total last minute.
Load Balancers
In/Out octets for Load Balancers are typically collected at the Distribution switch end. This is due to a restriction within NetView discovering Cisco load balancers.
5.4.2 Application Stats
Web-Services Servers
The standard ASP ITM Capacity profile is deployed to all web-services servers. This profile supplements the standard OS profile, and provides ASP web statistics for the following metrics:
Request Execution Time, Request Queued, Request Rejected and Requests/Sec
The URL to the full design document is provided in the reference section.
QDB
No custom capacity collections are anticipated.
Feeds:
The FRF, full size, is approximately 50MB, with annual growth expected to average less than 1.0MB. The IDN feed capacity depends upon determinations made in the final drafts of the PRS and/or Feed specification.
5.5 Software Component and Device Failover
5.5.1 Software Resiliency
Web Services:
ENTERPRISE GRIDS WITH REAL APPLICATION CLUSTERS “Real Application Clusters (RAC) enables the enterprise to build database servers across multiple systems that are highly available and highly scalable. In a Real Application Clusters environment Oracle runs on two or more systems in a cluster while concurrently accessing a single shared database. What this provides is a single database system that spans multiple hardware systems yet appears to the application as a single unified database system. This extends tremendous availability and scalability benefits for all your applications.
• Flexibility and cost effectiveness in capacity planning, so that a system can scale to any desired capacity on demand and as business needs change
• Fault tolerance to failures within the cluster, especially computer failures.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 49 of 65
“Real Application Clusters enables enterprise Grids. Enterprise Grids are built out of large configurations of standardized, commodity-priced components: processors, servers, network, and storage. RAC is the only technology that can harness these components into useful processing system for the enterprise. Real Application Clusters and the Grid dramatically reduce operational costs and provide new levels of flexibility so that systems become more adaptive, proactive, and agile. Dynamic provisioning of nodes, storage, CPUs, and memory allow service levels to be easily and efficiently maintained while lowering cost still further through improved utilization. In addition, Real Application Clusters is completely transparent to the application accessing the RAC database and does not need to be modified in any way to be deployed on a RAC system.
“Real Application Clusters gives users the flexibility to add nodes to the cluster as the demands for capacity increases, scaling the system up incrementally to save costs and eliminating the need to replace smaller single node systems with larger ones. Grid pools of standard low cost computers and modular disk arrays make this solution even more powerful with the Oracle Database 10g. It makes the capacity upgrade process much easier and faster since one or more nodes can be added to the cluster, compared to replacing existing systems with new and larger nodes to upgrade systems. The Cache Fusion technology implemented in Real Application Clusters and the InfiniBand support provided in the Oracle Database 10g enables capacity to be scaled near linearly without making any changes to your application.”
Feeds: There is no software resiliency built into the DBoR or FTP servers.
5.5.2 Operational Resiliency
Web Services: QDB’s utilize RA; Web services and calculation servers utilize load balancing from the Cisco Content Switch (CCS).
The web services front end will be four Windows 2003 servers accessed from one of two CSS load balancers. One CCS will be live whereas the other will be in standby mode. In the event of a live CCS failure the standby CCS will automatically promote itself to live status. In the event of a web services front-end-server failure, the CCS will recognize the outage and automatically redirect all queries to the remaining three Windows servers.
Feeds: There is no operational resiliency built into the DBoR or FTP servers.
5.6 System Management View
The diagram below shows the Hazelwood PTME environment used to manage the LDI implementation. A functionally equivalent environment exists in London for future 2007 SR/DR deployment.
A mandatory requirement for managing any application server is the Tivoli endpoint (lightweight client framework); each LDI server running Tivoli endpoint is assigned a primary gateway to which they log in. A secondary gateway is provided in case of a primary gateway failure. Assigned to LDI Windows servers are gateways HDCP-RPTR01 (primary) and HDCP-RPTR02 (secondary). Gateways for Solaris 10 are proposed for the PTME environments H2 2006 – the gateways assign for QDB and Calc-servers will be either HDCP-RPTR51/52 or 61/62.
LDI – Lipper Data Integration V0.4 Definition Stage Page 50 of 65
Feeds: DBoR and FTP systems are managed by Lipper staff.
5.6.1 Instrumentation and Monitoring
Web Services: Monitors used by this deployment include Monitoring in the following areas
• Processes / Services • Filesystem / Logical Disk • OS Component Threshold • RDBMS • Heartbeat • Cluster Status • Hardware • Application specific events
Application-specific monitors are detailed below. WebServices Servers The following WebServices application processes and services are defined in the SMP profile: The following application events are logged to one of the standard six Windows event logs (System, Application, Security, DNS Server, File Replication Server, and Directory Service), and are defined according to the REUTERS_WinApp_Event definition:- Feeds: Instrumentation and monitoring for DBoR and FTP systems are provided using Lipper-accepted monitoring tools by Lipper staff.
5.6.2 Maintenance Availability, and Housekeeping
Web Services: IIS logs, system logs, and temporary storage spaces are cleaned up by scheduling weekly scripts. Feeds: A daily script is run on the FTP server to purge all hosted data posted more than six months previously.
5.6.3 Rolling Upgrades
Web Services: Servers are load-balanced or arranged in clusters so that upgrades will happen one at a time, with zero outages. To upgrade an application, software, server, or operating systems without loss of service to a user, the upgrade will be completed on one server at a time. The cluster transparently maintains the environment, and users are unaware that the upgrade is taking place. QDB is designed, where possible, to support a rolling upgrades without service interruption.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 51 of 65
ROLLING RELEASE UPGRADE The Oracle Database 10g supports the installation of database software upgrades, and the application of patchsets, in a rolling fashion - with near zero database downtime - by using Data Guard SQL Apply. The method by which this is done is shown below.
Figure 5-8 – Establishing the Standby Database
After instantiating the standby database and configuring Data Guard to replicate changes made on the production database to the standby database, the standby database is upgraded.
Figure 5-9 – Upgrading the Standby Database
This configuration can run in this mixed mode for an arbitrary period to validate the upgrade in the production environment. When satisfied the upgraded software is operating properly, a database role reversal and switchover can be done.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 52 of 65
Figure 5-10 – Role Reversal
The role reversal is composed of several sub-steps, including: Data Guard switchover making the original standby database the production database; re-pointing the database clients to the new production database; upgrading the standby database; and raising the compatibility level of both databases. There are several points during this process when the configuration is run in a mixed mode to validate the upgrade. During those times the upgrade can be aborted and the software downgraded without data loss. During the rolling upgrade, the standby database is available for disaster recovery. For additional data protection during these steps, a second standby database may be used in the Data Guard configuration. By supporting rolling upgrades and rolling patch updates, Oracle has eliminated a large portion of the maintenance windows that DBAs reserve for administrative tasks, and enables 24x7 operation of the enterprise.
Feeds: Periodic hardware, operating system and software upgrades take place on Lipper’s DBoR and FTP servers during off-business hours.
5.6.4 Backup, Restore and Service Restoration
Web Services: Web Servers: Each server is to have a full backup completed weekly and an incremental completed nightly. Backup/restore method, connection to library (HBA, LAN) will be conducted according to standard Reuters policy. QDB’s: A weekly full and daily incremental backup will be completed on the database using using RMAN. Oracle database will also be backed up with adequately sized transaction REDO logs on local disk to allow for s24 hours redo. One SNAP will also be completed every 24 hours in hot backup mode. A weekly full and daily incremental will be completed on the operating system using Veritas backup. Feeds: Daily incremental and weekly full backups are completed on the Lipper DBoR and FTP servers.
5.6.5 Active Directory Controllers
Web Services: Active Directory controllers are not required for this application.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 53 of 65
Feeds: Active Directory controllers are not required for the feeds.
5.6.6 Provisioning
The System Management Provisioning system (SMP) is a standard tool used to deploy Management capabilities. For LDI Servers, SMP running on the HDC Inventory Server (HDCP-INV01A) is used.
LDI servers are managed by defining capabilities within an SMP Profile (also referred to as an SMP class). It is recommended that four classes be used to manage the LDI implementation (production and pre-production environments, Web Services and QDB)
Further in depth information on SMP is provided in the “SMP Reference Manual and User Guide” URL is provided in the reference section. Profiles (classes) are discussed in the section “Profile and Target interaction.”
This section details, at a high level, the capabilities that will be used by the LDI implementation. Capabilities that are readily available but not integrated into the provisioning system are noted in the section “Capabilities Delivered Outside of SMP”; these capabilities can still be deployed or used by servers under Management, and are typically installed automatically by Tivoli (by virtue of endpoint and Framework), via manual instructions or scripted and deployed outside of SMP.
Where the status of planned capabilities is unknown – for example, Oracle 10g threshold monitors – these have been highlighted in red and marked as a risk.
Standard Monitors ‘Processes and Services’
By default, this capability monitors a standard set of processes (processes and Services on Windows platforms), and includes configurable parameters for automatic restart, number of instances running and level of alert severity. The level of monitoring will be extended out to include application-specific processes and services during the delivery phase of the project.
Application-specific details are documented in the Instrumentation and Monitoring section(5.6.1), above.
Standard Monitors ‘Filesystem/Logical Disk’
This is a standard offering using pre-defined threshold settings that monitor /, /tmp, /var and C:
Standard Monitors ‘OS Threshold Monitoring’ – Windows platforms
This capability is provided by an ITM Monitoring profile and contains a pre-defined set of monitors and thresholds. Monitors for the LDI implementation will be provided in the following areas:
Application-Specific Monitors – Custom Log Files and Formats
Two Tivoli event classes (REUTERS_Logfile_Event and REUTERS_WinApp_Event) are provided to support the formats defined in the document “Writing Application Logfiles to Generate Tivoli Logfile Events. ” The URL is provided in the reference section.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 54 of 65
Application-specific details are documented in the Instrumentation and Monitoring section.
Housekeeping Function
The LDI implementation will make use of the housekeeping function provided via the Provisioning system. For file-system logs, weekly housekeeping is sufficient.
The capability, essentially a Perl and configuration script, will be scheduled using built-in OS schedulers (see “Scheduling Function – Independent Simple Schedules and Jobs”).
Configuration parameters allow for files to be archived, deleted, purged or truncated. Specifics will be provided to Operations during the delivery phase of the project.
Scheduling Function – Independent simple Schedules and Jobs
By definition, simple schedules use locally available tools such as UNIX cron or Windows Task Scheduler. The premise of simple scheduling is that the “best-fit” scheduling solution should be used, one that is available, for example, from standard build or standard layered application. For instance, MSSQL is ideal for some SQL environment scheduling.
The LDI implementation will make use of cron, Windows Task Scheduler and, for scheduling of Operating system backups, the simple scheduling service built into Tivoli Storage Manager.
The LDI implementation will also, when scheduling simple jobs, follow the rules laid down in the “Scheduling – HLD for Simple Scheduling” document. This includes, for example, using strong passwords and not scheduling jobs using root or domain-Administrator accounts.
Backup, Restore and Service Restoration (include/exclude specifics)
The Tivoli Storage Management agent is delivered as part of Management Provisioning. All LDI servers receive the necessary client code and a default option file; this file specifies backup of all necessary OS files and directories.
Additional configuration (files and directories to be included in the daily backup) are documented below. These additional configuration details will be provided to Operations during the delivery phase of this project for inclusion in the LDI SMP profiles.
5.6.6.2 Capabilities Delivered Outside of SMP
Application-Specific Monitors RDBMS – Risk
A standard monitoring solution for Oracle 10g does not exist, and therefore availability is likely to be outside of deployment phase timescales.
A work request has been raised against Shared Infrastructure (“Management Systems development”) in order to address this shortfall.
The project notes the absence of this offering as a deficiency with low-medium impact.
Standard Monitors ‘OS Threshold Monitoring’ – Solaris platforms – Risk
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 55 of 65
Status of this capability, level of monitoring and details are unknown at the time of writing. Availability of this capability is likely to be outside of deployment phase timescales and therefore use is noted as a deficiency and a low risk-impact.
A work request eWRF24 has been raised against Shared Infrastructure – “Management Systems development” to address the shortfall.
Scheduling Function – Structured Scheduling
By definition, structured scheduling is used when:
a) Cross-system dependencies exist
b) Running of scripts (or jobs to be scheduled) is absolutely critical to the operation of the service and requires stringent monitoring and alerting – i.e. a day-end run of a business schedule, processing business-critical data
Structured scheduling requires the fault-tolerant agent provide by Tivoli (Tivoli Workload Scheduler).
For the LDI implementation, there is no requirement for structured scheduling.
Management Monitoring – Heartbeating
The Heartbeating mechanism is delivered automatically to all servers logged into a Tivoli gateway. There is no requirement to define or deploy this mechanism using SMP.
All servers receive the Heartbeating capability through their primary or secondary PTME gateways.
Management Monitoring – Cluster Alerts
The cluster alerting capability for Solaris Veritas clusters uses HASTATUS to write availability events which, in turn, are picked up by the Tivoli TEC adapter. The following status-change events are detected and sent to Formula via TEC:
• Status change of a VERITAS node
• Status change of a VERITAS group/resource
• Location change of a VERITAS group
For the LDI implementation, there is no requirement for Cluster Alerts.
Hardware Monitoring – Windows platforms
LDI Web Services servers will use Reuters standard offering “HP hardware monitoring.” At the application-server end, the Microsoft SNMP Service is configured to send traps to an SNMP consumer. The consumer in this instance is the Tivoli gateway the endpoint logs into (as described at the start of this section).
Configuration of this capability is dependent on the version applied by the standard Reuters Build Server. For servers built prior to 1.4.0, the SNMP service is configured manually by Operations (a Tivoli task is provided to assist with this). Servers built using 1.4.0 or greater (due Aug 2006) set the SNMP consumer IP address automatically, providing that this address was supplied during the build process.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 56 of 65
Additional detail is provided in the “Reuters Windows HP Hardware Monitoring Design” document.
Hardware Monitoring – Solaris platforms - Risk
The design work for a standard Hardware Monitoring solution (Sun Servers) does not start until H2 2006 (July scheduled).
Level of monitoring and details are unknown at the time of writing. Availability of this capability is likely to be outside of deployment timescales and therefore use of is noted as a deficiency and low risk impact.
Inventory Scans
For the LDI implementation there is no requirement for inventory scans.
Backup, Restore and Service Restoration (CBC Design)
This capability is covered in detail in the Backup, Restore and Service restoration section of the PIA.
Capacity Management – ‘OS’ Statistics
This capability is covered in detail in the Physical Stats section of the PIA
Custom Capacity Collectors – Application Stats
Application-specific capacity collectors are not used in LDI.
Data Mover Capability
Data Mover is a readily available PTME capability.
Data Mover provides the ability to move data from one or more endpoints (servers) to another endpoint. Primarily this will be used by the PTME to collect Capacity-Planning Statistics from LDI servers to a single storage point within the PTME. This function is automatically deployed by Tivoli framework to all servers running the OS Statistics collection capability. Access and iLO
Access to servers from the Lipper network is necessary to trouble-shoot possible problems. This would include terminal-services connectivity to the web servers and secure-shell connectivity to the QDB’s.
It is anticipated (to be confirmed during the delivery phase of the project) that the LDI servers documented in this PIA are connected to the Nutley and Docklands lights-out solutions (HP iLO and Cyclade console access)
Feeds: DBoR and FTP systems are managed by Lipper staff.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 57 of 65
6 Migration Strategy The LDI is a brand-new capability and therefore does not require a migration strategy. Presently, many Reuters groups retrieve Lipper content via an FTP file drop. This service will be stopped over time with the expectation that Reuters groups will now build to the web services that LDI-WS provides.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 58 of 65
7 New Technologies Web Services: The server image utilized for the LDI-WS web servers is the standard Windows 2003 server from Reuters (Standard Build). The LDI-WS software installer supplied to the Reuters data center group will include components required by LDI-WS including the Lipper.dll, LipperCalculations.dll, and the Equis Charting component. The server image utilized for the QDB and Calc-servers is the standard Solaris 10 build from Reuters (Standard Build). For QDB standard build for Oracle RAC will be used. The LDI-WS architecture includes the following new technologies
• Oracle 10g • Oracle Real Application Clusters (RACs) • Oracle Streams • Oracle Data Guard
Feeds: Not applicable.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 59 of 65
8 Standards & Policies Web Services: Awaiting details.
Feeds: Not applicable.
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 60 of 65
9 Material Costs Web Services: This section is intended to provide a framework for understanding specific materials required for deployment and operation of the LDI project.
Included is a material list for all test environments and production resilience environments as well as the first production deployment. At this stage of definition, it is expected to be at least 80% accurate.
Feeds: Not applicable.
9.1 Hardware
These are the hardware costs to deploy into two Reuters data centers, with one of these data centers containing the staging environment (RED ENVIRONMENT).
Hardware Device Description Hardware
which uses Software
Components Qty. Total Cost
Two 4-proc Sun Solaris Servers Production 4 £18,428 Four 2-proc Wintel Servers Production 4 £7,475 Load Balancers/Switches/Routers Production £69,565 Two 4-proc Sun Solaris Servers Production 4 £18,428 Four 2-proc Wintel Servers Production 4 £7,475 Load Balancers/Switches/Routers Production £69,565 Two 4-proc Sun Solaris Servers Testing/QA 2 £18,428 Two 2-proc Wintel Servers Testing/QA 2 £3,737 Load Balancers/Switches/Routers Testing/QA £69,565 Communication Line for QDB Updates Production 1 £40,550
9.2 Shared Storage
Shared Storage Type Volume Cost
9.3 Licensing
The following licenses are required by LDI.
Required Software Description Quantity Total Cost
Oracle 10g Licenses for Nutley 2 £159,000 Oracl/e 10g Licenses for Docklands 2 £159,000
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 61 of 65
Required Software Description Quantity Total Cost
Oracle 10g Licenses for Nutley RED 1 £79,500 Windows Licenses for Nutley 4 £512 Windows Licenses for Docklands 4 £512 Windows Licenses for Nutley RED 2 £256
9.4 Bandwidth
Awaiting details.
Description of Connection Peak Bandwidth
Average Bandwidth
Forecasted Growth Cost
9.5 Miscellaneous
Awaiting details.
Full Description and summary of use Quantity Total Cost
Confidential – Internal Use Only August 28, 2013
LDI – Lipper Data Integration V0.4 Definition Stage Page 62 of 65
10 Service Risk Web Services: Awaiting details. Feeds: No risk to Reuters is anticipated.
