APOS+HH+Technical+Specification+v1 2

PR-506500 APOS Household Technical Specification
Version 1.21 Direct Distribution January September 20082009
Page 1 of 62
Commercial In Confidence
Table of Contents
1 2 Document control ........................................................................................................................................... 5 Introduction .................................................................................................................................................... 8 2.1 Document purpose ................................................................................................................................. 8 2.2 Project overview ..................................................................................................................................... 8 2.3 Dependencies ......................................................................................................................................... 8 2.4 References ............................................................................................................................................. 8 Current environment .................................................................................................................................... 11 Application design ....................................................................................................................................... 14 4.1 Application architecture ........................................................................................................................ 14 4.1.1 Architectural goals ........................................................................................................................... 17 4.1.2 Standards and naming conventions................................................................................................. 17 4.1.2.1 Service and portal considerations ............................................................................................... 17 4.1.2.2 DB2 standards ............................................................................................................................ 17 4.1.2.3 PRPC standards ......................................................................................................................... 17 4.1.3 Externalised parameters .................................................................................................................. 17 4.2 Overall system design .......................................................................................................................... 18 4.3 PRPC technical design ......................................................................................................................... 19 4.3.1 PRPC enterprise context model ....................................................................................................... 20 4.3.2 Screen designs ................................................................................................................................ 20 4.4 Integration ............................................................................................................................................. 21 4.4.1 APOS motor vehicle......................................................................................................................... 21 4.4.1.1 Pega single sign-on..................................................................................................................... 21 4.4.1.1.1 Overview of process ............................................................................................................... 21 4.4.1.1.2 Integration method summary ................................................................................................. 22 4.4.1.2 Client and quote searches .......................................................................................................... 24 4.4.1.2.1 Client search .......................................................................................................................... 24 4.4.1.2.2 Quote search .......................................................................................................................... 25 4.4.2 ANUBIS/RedBack ............................................................................................................................ 26 4.4.2.1 What is RedBack?....................................................................................................................... 26 4.4.2.2 Java APIs ................................................................................................................................... 26 4.4.2.3 Wrappers and helper functions ................................................................................................... 26 4.4.2.4 ANUBIS/RedBack methods and testing ...................................................................................... 27 4.4.2.5 Quote numbering ........................................................................................................................ 27 4.4.2.6 Policy numbers............................................................................................................................ 27 4.4.2.7 Premium calculation .................................................................................................................... 28 4.4.2.8 Quote XML .................................................................................................................................. 29 4.4.3 Quick Address (QAS)....................................................................................................................... 29 4.4.4 SecurePay ....................................................................................................................................... 29 4.4.5 Dialogue ........................................................................................................................................... 30 4.4.6 Email and fax ................................................................................................................................... 30 4.4.7 Stellent (document archiving) .......................................................................................................... 30 4.5 RedBack methods ................................................................................................................................ 30 4.5.1 Security/login ................................................................................................................................... 31 4.5.2 Quoting ............................................................................................................................................ 31 4.5.3 Premium/option calculation .............................................................................................................. 35 4.5.4 Cover note fulfilment ........................................................................................................................ 37 4.5.5 Update cover note............................................................................................................................ 38 4.5.6 Client search and quote search ....................................................................................................... 38 4.5.7 Payments ......................................................................................................................................... 39 4.5.8 Printing ............................................................................................................................................. 39 4.6 ANUBIS changes .................................................................................................................................. 39 4.6.1 Australia Post and BPay payment batch processes ........................................................................ 39 4.6.2 Cancel cover note (UG127S) ........................................................................................................... 40 4.6.3 Household policy enquiry (UG025S)................................................................................................ 40
3 4
Page 2 of 62
Commercial In Confidence 4.6.4 Blocking updates to APOS generated policies in ANUBIS .............................................................. 40 4.6.5 Dialogue interface (notice prints) ..................................................................................................... 41 4.6.5.1 Data changes .............................................................................................................................. 41 4.6.5.2 Program changes ........................................................................................................................ 42 4.7 Notice development (Dialogue) ............................................................................................................ 43 4.7.1 Document design ............................................................................................................................. 43 4.7.2 Notice data elements ....................................................................................................................... 43 4.7.3 Notice business rules ....................................................................................................................... 43 5 Database design ........................................................................................................................................... 44 5.1 Pega DB2 ............................................................................................................................................. 44 5.1.1 Schema ............................................................................................................................................ 44 5.1.2 Database procedures....................................................................................................................... 44 5.1.3 Environments ................................................................................................................................... 44 5.1.4 Capacity planning ............................................................................................................................ 44 5.1.5 Archiving .......................................................................................................................................... 45 5.1.6 Reporting ......................................................................................................................................... 45 5.2 UniVerse XML (APOS) data .............................................................................................................. 45 5.2.1 File layouts ....................................................................................................................................... 45 5.2.2 Environments ................................................................................................................................... 45 5.2.3 Capacity planning ............................................................................................................................ 45 5.2.4 Archiving .......................................................................................................................................... 46 5.2.5 Reporting ......................................................................................................................................... 46 5.3 UniVerse ANUBIS data...................................................................................................................... 46 5.3.1 File layouts ....................................................................................................................................... 46 5.3.2 Environments ................................................................................................................................... 46 5.3.3 Capacity planning ............................................................................................................................ 46 5.3.4 Archiving .......................................................................................................................................... 46 5.3.5 Reporting ......................................................................................................................................... 47 Infrastructure design ................................................................................................................................... 48 6.1 Hosting.................................................................................................................................................. 48 6.2 Environment.......................................................................................................................................... 48 6.3 Infrastructure components .................................................................................................................... 49 6.3.1 HTTP server..................................................................................................................................... 49 6.3.2 Application server ............................................................................................................................ 49 6.3.3 Database server............................................................................................................................... 49 6.3.4 User desktop .................................................................................................................................... 49 6.3.5 User environment............................................................................................................................. 49 6.4 Proposed network topology .................................................................................................................. 49 6.5 System operation .................................................................................................................................. 50 6.6 Availability and reliability ....................................................................................................................... 50 6.6.1 Database.......................................................................................................................................... 51 6.6.2 Application server (WebSphere) ...................................................................................................... 51 6.6.3 Integration points ............................................................................................................................. 51 6.7 Usage and volume considerations........................................................................................................ 51 6.8 Performance ......................................................................................................................................... 52 6.9 Scalability/extendibility .......................................................................................................................... 52 6.10 Failure management ............................................................................................................................. 52 6.11 Backup and recovery ............................................................................................................................ 52 6.12 Disaster recovery .................................................................................................................................. 53 Security design ............................................................................................................................................. 54 7.1 Security and control requirements ........................................................................................................ 54 7.2 Sign-on process .................................................................................................................................... 54 7.3 User authentication, sanctions and delegated authority levels ............................................................. 54 7.4 Database connectivity........................................................................................................................... 54 7.5 ANUBIS connectivity............................................................................................................................. 54 7.6 Quick Address (QAS) ........................................................................................................................... 55 7.7 SecurePay ............................................................................................................................................ 55 7.8 Dialogue................................................................................................................................................ 55 7.9 Email and fax ........................................................................................................................................ 55
Page 3 of 62
Commercial In Confidence 7.10 Stellent (document archiving) ............................................................................................................... 55 7.11 PRPC access and privileges ................................................................................................................ 55 7.11.1 Access groups............................................................................................................................. 55 7.11.2 Operators .................................................................................................................................... 55 7.11.3 Workbasket access ..................................................................................................................... 55 8 Development approach ................................................................................................................................ 56 8.1 Timeboxes ............................................................................................................................................ 56 8.2 Release and configuration management .............................................................................................. 56 8.2.1 PRPC release and configuration management................................................................................ 56 8.2.1.1 RuleSet name and versions ........................................................................................................ 57 8.2.1.2 Check in/check out ...................................................................................................................... 57 8.2.1.3 Access groups............................................................................................................................. 57 8.2.1.4 Migrations and skimming ............................................................................................................ 57 8.2.1.5 APOS code management process .............................................................................................. 57 8.2.2 Java release and configuration management .................................................................................. 59 8.2.3 ANUBIS release and configuration management ............................................................................ 59 Test strategy ................................................................................................................................................. 60 9.1 Initial connectivity and unit testing ........................................................................................................ 60 9.1.1 Test strategy .................................................................................................................................... 60 9.1.2 Test team ......................................................................................................................................... 60 9.1.3 Test environment ............................................................................................................................. 60 9.1.4 Test tools ......................................................................................................................................... 60 9.2 System testing ...................................................................................................................................... 60 9.2.1 Test strategy .................................................................................................................................... 60 9.2.1.1 Functional testing ........................................................................................................................ 60 9.2.1.2 Technical/environmental testing.................................................................................................. 61 9.2.1.2.1 Performance and load testing ................................................................................................ 61 9.2.1.2.2 Security penetration testing .................................................................................................... 61 9.2.2 Test team ......................................................................................................................................... 61 9.2.3 Test environment ............................................................................................................................. 61 9.2.4 Test tools ......................................................................................................................................... 61 9.3 User acceptance testing ....................................................................................................................... 61 9.3.1 Test strategy .................................................................................................................................... 61 9.3.2 Test team ......................................................................................................................................... 62 9.3.3 Test environment ............................................................................................................................. 62 9.3.4 Test tools ......................................................................................................................................... 62
Page 4 of 62
1 Document control
For more information: Author: Inputs: Filename: Kylie Henson (Team Leader T&PD Application Development) Kylie Henson (Team Leader T&PD Application Development) Jason Little, John Banting, Phil Stafford-Jones, Daniel West, Tom Hanel Data on 'Au.qbe.pri' (G:)\WQBE\WA\Infosys\ANUBIS POS\Documentation\APOS HH Technical Specification v1.1.doc Released version(s) of the document can be found in Clarity against project PR-506500 Distribution: Name Jason Little Title Enterprise Application Architect, Solution Design and Architecture Action Required Signoff Approval Signature: _______________ Date: _______________ Reviewed 27/03/2007 28/03/2007 27/02/2007 15/02/2007 27/02/2007 20/02/2007 22/02/2007 27/02/2007 12/03/2007
Markus Marbach John Banting Faraz Mahmood Daniel West Carolus Walraven John Greaves Grant Pearce Mike Vickridge John McFarlane Peter Strigas Richard Briscoe Adam Kersivian Carlos Yanez Jeremy White John Hetherington Anita Bertschinger Ryan Holmes Mike Macri Nevil Downing Anne Louis David Horner Version history:
Senior System Architect, PegaSystems ANUBIS/RedBack Team Leader Java Team Leader Manager Sales System Development E-business Consultant Manager, Information Security National Product Manager Householders Project Manager Enterprise Architect Team Leader, Enterprise Applications Business Logic Pega System Architect Engagement Leader (ASIA), PegaSystems Team Leader, Document Analysis Manager, Voice & Networks Manager T&PD Direct AD Senior Systems Analyst Developer (Java and Pega) Developer (ANUBIS/RedBack) Senior Developer (ANUBIS/RedBack) Developer (ANUBIS/RedBack and Java) Developer (ANUBIS/RedBack)
Review Review Review Review Review Review Review For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information For Information
Phil Stafford-Jones J2EE Architect (Pega developer role)
Michael Butterworth Senior Systems Analyst (APOS motor vehicle team leader) Review
Page 5 of 62
Date 12/12/2006 16/02/2007 13/04/2007 13/04/2007 14/01/2008
Version 0.1 0.2 1.0 1.1
Name Kylie Henson Kylie Henson Kylie Henson Kylie Henson
Description First draft (issued for review 12/02/2007) Revision following peer reviews (including my own review) and additional changes that have been identified Master signoff Revision to include comments from Jason Little during sign off and changes that occurred during the projects construction phase Updated premium calculation rules in ANUBIS/RedBack section
07/09/2009
1.2
Kylie Henson
Glossary: Term / Acronym AAP ANUBIS API APOS ASCII B2B B2C BLOB BPM BRE CM CPU CVS DBA DR ECM EP ESB FBL/FSL GST HADR HTML HTTP HTTPS IP J2EE Australia Asia Pacific acronym Back-end policy system of record management used by Direct Distribution Application Programming Interface ANUBIS POS. Front-end point of sale solution for Motor Vehicle insurance used by Direct Distribution American Standard Code for Information Interchange Business 2 Business Business 2 Consumer Binary Large Object Business Process Management Business Rules Engine Configuration Management Central Processing Unit Concurrent Versions System Database Administration Disaster Recovery Enterprise Content Management Extra Premium Enterprise Service Bus Fire Brigade Levy/Fire Service Levy Goods and Services Tax High Availability Disaster Recovery Hyper Text Markup Language Hyper Text Transfer Protocol HTTP Secure Intellectual Property Java 2 Enterprise Edition. Defines the standard for developing component-based multi-tier enterprise applications Description
Page 6 of 62
Term / Acronym JAR JDBC JMS JNDI JSP MD5 PDF PDS POC PRPC (Pega) QA QAS QMS RBO ROC RP SD SLA SMTP SOA SOAP SOE SOPDC SSL SSO T&PD UAT UI URL UROC UTC WAR WR XML Java Archive Java Database Connectivity Java Message Service Java Naming and Directory Interface Java Server Pages
Description
Message-Digest algorithm 5 a widely used cryptographic hash function with a 128-bit hash value Portable Document Format (Acrobat files) Product Disclosure Statement Proof of Concept (aka prototype) Pega Rules Process Commander BPM/BRE software tool purchased by QIA Quality Assurance QuickAddress DPID software used by Direct Distribution to determine a delivery point ID Quote Management System (QBE Pega application) RedBack Object Record of Conversation Returned Premium Stamp Duty Service Level Agreement Simple Mail Transfer Protocol Service Orientated Architecture Simple Object Access Protocol Standard Operating Environment Sydney Olympic Park Data Centre (aka Homebush) Secure Sockets Layer Single Sign On Technology and Program Delivery a business unit of QBE AAP User Acceptance Testing User Interface Uniform Resource Locator Updated Record of Conversation Coordinated Universal Time a high-precision atomic time standard Web Application Archive Work Request Extensible Markup Language
Page 7 of 62
2 Introduction
2.1 Document purpose
This document is the technical specification for the APOS Household project PR506500. It provides both detailed technical requirements and the architecture and application design required to deliver the functional business requirements. It also includes database, infrastructure and security requirements, and outlines the development approach and test strategy. Whilst some of this detail is documented separately, it is summarised then referenced within this document, making this technical specification the starting point for any technical requirements/design for the APOS Household project. It is important to note that this document will continue to evolve and be updated following the initial construction, review and sign off process. This document does not include detailed task lists with associated estimations (and costings). This is being documented separately in the detailed project schedule.
2.2 Project overview

The APOS Household project is the second phase of the APOS program of work. The first phase delivered motor vehicle point of sale functionality via a J2EE platform with an ANUBIS back end. This second phase entails delivering household point of sale functionality via a Pega platform which is integrated with the current J2EE motor vehicle system (so also utilising the ANUBIS back end). The primary business driver here is the ability to deliver proposal free new business processing for household insurance for Direct Distributions customers. At the moment there is a real gap in service between motor vehicle and household point of sales systems, in that motor vehicle is proposal free but household still requires the customer to complete a proposal form after an initial quote.
2.3 Dependencies
Development and delivery of the APOS Household application is dependent on the following: The Household Underwriting Guide not changing during the project Production of a combined PDS for building, contents and valuables Clean up of suburb and postcode information within ANUBIS (at both national and branch levels) Clean up of policy options stored within each branch of ANUBIS Clean up of endorsements stored within each branch of ANUBIS Implementation of email and fax capabilities (to be implemented under a separate project/work request prior to the APOS household release) Implementation of Stellent for document management and archiving (to be implemented under a separate project/work request prior to the APOS household release) The investigation and strategy regarding the use of the Rational Testing Suite
2.4 References
The following references have a bearing on this document: Reference Source Description/Comments Business case Data on 'Au.qbe.pri' (G:) Business case for the APOS Household project \WQBE\WA\Planning\ANUBIS POS\Household\1. Concept\Business Case\ANUBIS POS HH Business Case V0.2.doc Project proposal Data on 'Au.qbe.pri' (G:) Proposal for the APOS Household project \WQBE\WA\Planning\ANUBIS
Page 8 of 62
Reference
Business requirements specification
Solution design and estimate
Prototype requirements
Integration design document
Pega data dictionary
Pega elaboration document
Configuration management plan
Pega security integration guide
Source POS\Household\1. Concept\Project Proposal\Project Proposal ANUBIS POS Householders v0.5.doc Data on 'Au.qbe.pri' (G:) \WQBE\WA\Planning\ANUBIS POS\Household\1. Concept\Business Requirements\Requirements Documents\Low Level BRA\APOS_HH_Business_Requi rement_Specification v1.2.doc Data on 'Au.qbe.pri' (G:) WQBE\WA\Planning\ANUBIS POS\Household\1. Concept\SD&E\Solution_Design_ _Estimate_WR353300_v1 11.doc Data on 'Au.qbe.pri' (G:) \WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Prototype\APOS_HH_Pr ototype_Requirement_Specificati on_v1.0.doc Data on 'Au.qbe.pri' (G:) \WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Technical Specification\ APOS Householders - technical design 0.2.doc Data on 'Au.qbe.pri' (G:) \WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Technical Specification\ APOS Householders Data dictionary v0.2.xls Data on 'Au.qbe.pri' (G:)\WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Technical Specification\Elaboration\APOS Household Elaboration V1.0.doc Data on 'Au.qbe.pri' (G:) \WQBE\WA\Planning\ANUBIS POS\Household\1. Concept\PM Deliverables\CM Plan PR506500 V0.1.doc Data on 'Au.qbe.pri' (G:) WQBE\WA\Infosys\ANUBIS POS\Pega\AuthenticationAndInte gration4-2.pdf Data on 'Au.qbe.pri' (G:) WQBE\WA\Infosys\ANUBIS POS\Pega\ PegaSample0402_SSOExampleServlet.war Data on 'Au.qbe.pri' (G:) WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Technical
Description/Comments
Detailed business requirements for APOS Household
SD&E for the APOS Household project
Functional and technical requirements for the APOS Household prototoype
Technical design for APOS Household integration aspects
Data dictionary for APOS household work objects
PRPC Technical Design for APOS Household
CM Plan for the APOS Household project
Pegas documented Single Sign-on method being adopted for integration of Pega Household within the current APOS motor vehicle system Also sample SSO Java integration files
QBE DB2 standard
DB2 standards for QBE group
Page 9 of 62
Reference Confluence APOS motor vehicle system APOS motor vehicle system Java code
Source Specification\DB2 Standards.doc http://dev.anubispos.qbe.com/con fluence https://int.anubispos.qbe.com/anu bispos Data on 'Au.qbe.pri' (G:) WQBE\WA\Infosys\ANUBIS POS\ APOSMV-23Nov06.ZIP Data on 'Au.qbe.pri' (G:) WQBE\WA\Infosys\ANUBIS POS\RedBack\Documentation\ APOS UI_RedBack_Anubis Interface.doc Data on 'Au.qbe.pri' (G:) WQBE\WA\Infosys\ANUBIS POS\RedBack\Documentation\ RedBackMethods - detail.doc http://wqbeapos:8080/JavaRBOS cope/ScopeLogin.jsp ?URL=http://wqbepos:5559/rgw/N ATIONALandmodule=UWSALES http://intranet.qbe.com/files/group/ iits/nonDMSfiles/QBE_Information _Systems_Security_Policy.pdf
Description/Comments Repository of APOS documentation and IP (QBE network) Existing APOS motor vehicle application (integration environment) Source code from existing APOS motor vehicle system of specific interest are the RedBack integration wrappers and helper classes which Pega should leverage IP from, if not actual code snippets Reference for mapping of RedBack integration points corresponding to each existing APOS motor vehicle screen. Good for understanding common functionality to be replicated in Pega System generated RedBack Methods interface documentation (these can also be found on Confluence). They describe the method and input/output parameters RedBeans Scope testing tool unit testing tool which may be useful for validating/debugging integration points Security policy and guidelines
APOS motor vehicle system screen to RedBack mapping RedBack methods interface documentation RBO Scope test tool
QBE Group Information Security Policy
Page 10 of 62
3 Current environment
The APOS motor vehicle project delivered a J2EE application which allows the Direct business unit staff to: Quote and bind motor vehicle policies via a simple, easy to use process workflow oriented web user interface Apply consistent and automated underwriting outcomes using a BRE Process policy payments using the integrated SecurePay credit card payment gateway service Produce a simple ROC using the Dialogue print service thus promoting a paperless proposal transaction for the customer Improve conversion rates by allowing immediate policy completion at the point of sale This application successfully interfaces to the ANUBIS policy management system using a middleware layer known as RedBack. Figure 1 shows the high level architecture of this system.
Figure 1. High level architecture of the current APOS J2EE application
Page 11 of 62
Commercial In Confidence Figure 2 shows the network within which the current APOS application operates.
Page 12 of 62
Figure 2. QBE network
Refer to Confluence for other documentation on the current APOS system.
Page 13 of 62
4 Application design
The aim of the APOS Household project is to design, develop and implement the screens, business values, and underwriting rules and algorithms to write new business for household products (building, contents and valuables) using Pega and make this product available via the existing APOS application. Design of the APOS Household application is detailed under the following areas: Application architecture an overview of the application architecture used to provide the solution PRPC technical design describes the business and supporting functions the PRPC application will address Integration describes the various PRPC supporting integration points ANUBIS describes the changes required to ANUBIS to support the APOS Household solution Notice development details the development of notices using Dialogue
4.1 Application architecture

A major component of QBEs target strategic architecture is the business logic layer that consists of Business Process Management (BPM) and Business Rules Engine (BRE) applications. This application layer will be used to augment and replace business rules that currently reside and are duplicated across various core insurance (legacy back-end) systems. Figure 3 conceptualises where the BPM/BRE integration layer fits within the QBE target strategic architecture.
Figure 3. Target Strategic Architecture for the Australia, Asia Pacific region for QBE
Pega Rules Process Commander (PRPC) is a J2EE application, chosen by QBE for the business logic layer. It is both a Business Rules Engine (BRE) and Business Process Management (BPM) or workflow application. Figure 4, courtesy of PegaSystems Inc., encapsulates at a high-level the main application architectural components of PRPC.
Page 14 of 62
Figure 4. PRPC J2EE Application Architecture courtesy of PegaSystems Inc. (www.pega.com)
Figure 5 shows the anticipated solution design for the APOS Householders project.
Page 15 of 62
Figure 5. APOS Householders architecture
The use of Pega will support the 3 tiered architecture already in place for APOS: The first tier supports the user interface developed under Pega. Certain high-level validation is carried out against the data model within this tier The second tier for Pega is logically separated from the Pega UI whilst physically running on the same application server and provides the Business Rules Engine (BRE) capabilities. Also in this tier are the existing processing for web services and database connectivity including RedBack
Page 16 of 62
Commercial In Confidence The final tier is the ANUBIS Server where all database queries are channelled via RedBack methods
The QAS technology will be introduced into this existing architecture, and will be developed such that it is an enterprise service available to all applications within the QBE Group. 4.1.1 Architectural goals The goals of the above architecture can be stated as follows: Consistency with T&PDs enterprise architectural strategy Fully integrated with the existing infrastructure Maximise reuse of services and functionality building common components in an enterprise platform to allow for reuse across multiple business units (in both future APOS releases and also other projects and initiatives within the QBE group) Ability to adopt out of the box Pega workflow and pre-built QBE functionality such as system automated referrals, SLA and operational reporting Ability to delegate appropriate business rule maintenance to non-developers, with rules able to be released into live independent of a software (WAR file) release Scalable, robust and secure Standards and naming conventions The following section(s) describe standards and naming conventions to be applied to the solution. Service and portal considerations While not within the immediate scope of the APOS Household project, consideration within the design is essential to encapsulating longer term requirements related to Service and Portal integration Service Orientated Architecture (SOA) PRPC is built on SOA principles. QA of the build will ensure that rules are not embedded within the presentation layer and that Service endpoints or interfaces can be introduced within the application overtime with minimum rework Portals To allow for future portlet integration and streaming, all screens will be generated by default as JSP (Java Server Pages) as apposed to static HTML DB2 standards Compliance with the QBE DB2 standards document which specifies database naming and coding conventions for any DB2 development. This applies where these standards are not explicitly superseded by global/industry standards. PRPC standards Pega supplies a number of guardrails and rule naming conventions when designing an application. These conventions are to be adhered to. Refer to PegaRULES Process Commander Designing Your Application with SmartBuild for further details. The internal data model naming conventions will aim to align with the Acord standard, and overall reuse within the design and build should aim to be maximised across the enterprise. Refer to the Pega elaboration document for further information specific to the APOS Householders project. 4.1.3 Externalised parameters The following externalised parameters are external to the core application but will be used by it during its operation: Area Application External parameters Name
4.1.2
4.1.2.1
4.1.2.2
4.1.2.3
Page 17 of 62
Area Logging and tracing
Error messages Single sign on
Externalised application access Dialogue RedBack/ANUBIS environments
RedBack configuration
Uniobjects configuration SecurePay configuration
Archive configuration
QAS
Email and fax service
External parameters Version Logging levels Logging email addresses Email server and login Log file output locations and formats Performance timing parameters All error messages displayed on screen Pega base URL URLs for each action type (e.g. client redirect) ANUBIS URLs for client search, quote etc Application username Application password Access details SOAP URL For each Pega environment, need to define integration parameters for each corresponding RedBack/ANUBIS environment URL Username Password Uniobjects host Uniobjects account URL Merchant ID Password Timeout CurrencyCode ProxyHost ProxyPort Archive location URL Username (if required) Password (if required) QAS URL Username (if required) Password (if required) URL Username (if required) Password (if required)
4.2 Overall system design

The existing technical infrastructure, processing and data structures developed for APOS motor vehicle will remain, and the current APOS user interface will continue to be used for motor quotations, client searches and quote searches. Pega will be introduced into this architecture and will be used as both the user interface and business rules engine to deliver quote, fulfilment and payment functions for the Direct home products. This approach is illustrated in Figure 6 below. The Pega system will also accommodate client creation/maintenance, quote recall and cover note update functionality.
Page 18 of 62
Figure 6. APOS/Pega integration overview
When a user selects the Home icon on the existing APOS splash page, the currently active browser window will be used to display the Pega screens for the household point of sale process. Additionally linkages to existing quotations (quote recall) will be facilitated from the quote search and client screens. Whilst a combined household product will be presented to the customer through both the quote/policy fulfilment workflow and the associated documentation, separate policies (with all of their options, excesses, endorsements etc) will still exist in the back end (ANUBIS) for building, contents and valuables. Any one APOS quote workflow can produce at most one building, one contents and one valuables policy.
4.3 PRPC technical design

The detailed PRPC technical design is documented elsewhere but it covers: Models definintion of the APOS quote model Work fundamental units of work, WorkBaskets, WorkParties, WorkStatuses, Cover and Object Ids Class groups database mapping, properties, local actions and routing rules Portals standard user and management views Build approach and conventions Detailed flow and subflow design Details business rule design Security access groups, operators and workbasket access Service Level Agreements Correspondence written and email
Page 19 of 62
Commercial In Confidence Business calender Reports Integration specifications (used in conjunction with details specified in this document) Refer to the Pega elaboration document for further information. 4.3.1 PRPC enterprise context model PegaRules Process Commander (PRPC) follows object orientated principles with one of the primary aims being rule re-use. Starting with the basics: A Class is used to group a number of related rules A Class Hierarchy is used to organise these classes into a structure which promotes Class inheritance. Rules common to two or more classes should be placed in a parent class There are 2 main approaches to Class Hierarchy design. Organisation based and process based. The method pursued is based upon the best approach to promote re-use across the enterprise. If it is assumed that Insurance Processes are the common goal across QBE then the base Class Hierarchy can be thought of as a common application process framework
Figure 7 below shows the product component structure that will be used for APOS household. It represents the separation and componentisation of the architecture to maximise reuse of process across product and product across channel taking into consideration emerging strategies such as risk assembly, product architecture and BPR.
Figure 7. APOS Household Pega product component structure
4.3.2
Screen designs Refer to the business requirements specification for screenshots (mockups) of the new screens required for APOS householders. The following screens/functions within the current APOS motor vehicle system need to be replicated in Pega for APOS household: Client
Page 20 of 62
Commercial In Confidence Payments Underwriting page Policyholders Send/print
Refer to the business requirements specification for more details, and to the existing APOS motor vehicle system for the screen look and functionality.
4.4 Integration
This section defines the system and database integration points external to the PRPC APOS application. This section will be used in conjunction with PRPC technical design details specified in the document of the same name. Essentially the integration points are: APOS motor vehicle ANUBIS via RedBack QAS SecurePay for online credit card payments Dialogue for notice production Email and fax connectivity Stellent (for document archiving) 4.4.1 APOS motor vehicle Pega single sign-on Overview of process Users will continue to log in via the existing APOS Java interface and it is a requirement to then utilise new household functionality without the need to resign-on to Pega. This will be validated as part of the proof of concept. Refer to references for complete documentation. Single sign-on (SSO) is a way to enable a user authenticated within one application (APOS) to switch to another application (Pega Householders POS) without having to manually sign-on to the second application. APOS users will continue to authenticate to APOS and utilise existing functionality. The following is the existing screen layout for the sign-on process:
4.4.1.1 4.4.1.1.1
Page 21 of 62
The current process to authenticate the user as a valid user in ANUBIS, and retrieve ANUBIS sanction and delegated authority levels (via RedBack method RB.Security) will be used. After a successful authentication of the user from the sign in process, the APOS J2EE splash page will be presented, which will be an exact replication of the current APOS J2EE page with the addition of a home icon:
By clicking the home icon, the end user will be redirected in a seamless fashion (within the same browser although different application sessions) to PRPC which will contain the household functionality, and they wont have to re-enter their log-in details. The same will apply if the user is recalling or updating an existing household quote or cover note (via client and quote search functionality). For simplicity of design and to minimise risks, this redirection will be one way, with the householder Pega screens closing on completion of the quote/fulfilment/payment process and the originating page being redisplayed to the user. As part of the URL redirection a number of ANUBIS specific session properties will need to be passed and incorporated into the Pega users session. 4.4.1.1.2 Integration method summary Pega single sign-on works under the principle that the user has already individually authenticated within the originating application and as such is treated as a trusted application. Pega Householders POS is invoked by the
Page 22 of 62
Commercial In Confidence originating application via a URL which contains a number of attributes and a security token. This token identifies the individual user but authenticates that user against a Pega defined application group. Example URL: https://pega.qbe.com/prweb/Apos?pzAuth=GuestandFrom=APOSandUserID=f mahmoodandSenderTime=20061128030510andunixLoginName=fmahmoodan duserDept=H1anduserKey=anduserLevel=6anduserName=F.MAHMOODandu serNo=1018anduserTerminalNo=1482anduserSecurityMask=NNNNNNNNNNN NNNNNNNNNNNYNandpw=55edf3553ffef566f4fs253ffg The URL will be constructed with the following URL parameters: Name pzAuth From Password UserID Value Guest APOS Application password not published to individuals or visible in URL Current APOS user id
Comment [KH1]: Comment from Jason Little during sign off: Security issues have been noted with this approach hence the technical solution w be reviewed and this documentation amended accordingly. Note that since this comment was made we receiv an exemption from the security team to go live w this solution until such time as the enterprise LDA solution was implemented, at which time we will expected to change this integration method
SenderTime
Date in UTC format
Optional parameters - These will consist of the following ANUBIS security details: unixLoginName As per ANUBIS
userDept userKey userLevel userName userNo userTerminalNo userSecurityMask doActivity pw
As per ANUBIS As per ANUBIS As per ANUBIS As per ANUBIS As per ANUBIS As per ANUBIS As per ANUBIS Specific entry points into PRPC Above encrypted in MD5 as 32 char hexadecimal string
Both the invoking application and PRPC encrypt this string which is passed in the password (pw) parameter of the URL. PRPC compares the result to determine validity. Within PRPC this requires: Creation of a custom authentication activity that evaluates the security token and a timeout activity that re-authenticates the user. To minimise potential disruption to a user the timeout values for Pega and APOS should be the same. In addition, when a session times out on Pega the redirected URL should be the main APOS menu. Creation of an authentication service which identifies the above activities and is used instead of the standard AuthService. This involves the definition of a custom Servlet mapping in the PRPC web.xml to allow custom authentication to be invoked, for example APOS will invoke https://pega.qbe.com/prweb/Apos with the appropriate token. Define an Application ID (APOS) containing: o a password to use when constructing the security token (known only to application not individual users) o the lag time or interval the timestamp is valid for Page 23 of 62
Commercial In Confidence The access group to associate operators identified by this application ID Note that these operators will not have individual passwords within PRPC, these are handled externally by APOS. o Within the invoking application (APOS): A new integration Servlet is required that constructs the input string (refer Security token above) and converts this string to an array of bytes. MD5 128-bit cryptography is then applied via the Java MessageDigest class (http://java.sun.com/j2se/1.4.2/api/java/security/MessageDigest.html) to produce an 128 bit binary message digest. This binary object is then converted into a zero padded hexadecimal string, the result being a 32 character hexadecimal string. The Servlet then invokes the PRPC URL with this string, substituting the password with the security token. 4.4.1.2 Client and quote searches As outlined in section 4.2 above, the current APOS motor system will continue to be used for client and quote searches (accessed from the icons on the current splash page). When a household quote or cover note is selected via these existing processes, the browser will be redirected to Pega, where the retrieved quote or cover note will be displayed. Client search/creation/maintenance functions will need to be replicated in Pega as part of the household quote/fulfilment process. 4.4.1.2.1 Client search When a user does a client search there are three ways that they can edit or create a household quote/cover note. New quote button The user can begin a new quote from the client maintenance screen by selecting the appropriate option from a drop down list and selecting a button. Java changes The current New Quote button should be replaced by a drop down list which has the options Please Select, New Motor Vehicle Quote and New Household Quote, and a Go button. When the New Household Quote option is selected and the Go button pressed, the browser will be redirected to the Pega application (via the Pega Controller), with a new request parameter named clientNo, which will contain the number of the client being edited. Just like all other request parameters, the clientNo parameter will be encrypted into the password (pw) parameter of the URL. Pega changes The Pega application will need to accept the clientNo request parameter, after which it will issue a RedBack call to retrieve the client details (RBGetClient) and display the Cover Required screen for a new quote, with the selected client attached to the quote. Quote listing The user can edit a quote listed in the Quotes section of the client maintenance screen by clicking the view/edit link of the quote. Java changes
Page 24 of 62
Commercial In Confidence Each APOS household quote in the quote listing will have its edit link URL changed to point to the Pega controller, which will redirect to the Pega application. The URL will contain an additional request parameter quoteNo, which will contain the quote number for the quote being recalled. Just like all other request parameters, the quoteNo parameter will be encrypted into the password (pw) parameter of the URL. Pega changes The Pega application will need to accept the quoteNo request parameter, after which it will issue a RedBack call to retrieve the quote details (RBGetQuote) and display the Disclosure page ready for the user to edit and/or fulfil the quote. Policy listing The user can edit a cover note listed in the Policies section of the client maintenance screen by clicking the view/edit link of the policy. Java changes Each APOS household cover note in the policy listing will have its edit link URL changed to point to the Pega controller, which will redirect to the Pega application. The URL will contain the additional request parameter policyNo, which will contain the household virtual policy reference number (e.g. P123456H1) for the cover note to be updated. Just like all other request parameters, the policyNo parameter will be encrypted into the password (pw) parameter of the URL. Pega changes The Pega application will need to accept the policyNo request parameter, after which it will issue a RedBack call to retrieve the quote/cover note details (RBGetQuote) and display them ready for the user to edit. 4.4.1.2.2 Quote search Java changes When the user searches for a single quote (search type = Quote No Search), if the quote number entered corresponds to an APOS household quote, the browser will be redirected to Pega with an additional URL parameter, named quoteNo, which will contain the quote number for the quote being recalled. Just like all other request parameters, the quoteNo parameter will be encrypted into the password (pw) parameter of the URL. When the user searches for a range of quotes (search type = Other Search), any APOS household quotes listed will have their href attributes changed to point to the Pega Controller, so that if they are selected the application will redirect to the Pega application (including the abovementioned quoteNo request parameter). The existing APOS application will need to inspect the value of the busClass property of retrieved quotes to determine if the quote is a motor vehicle or household quote. The existing APOS application needs to be changed to allow the user to restrict the quote search to household quotes. Home(H) will need to be added to the Business Class drop down list, with all combinations of building, contents and valuables classes (i.e. B, C, S, BC, BS, CS, BCS) falling under the H classification. Pega changes The Pega application will need to accept the quoteNo request parameter, after which it will issue a RedBack call to retrieve the quote details (RBGetQuote) and display the Disclosure page ready for the user to edit and/or fulfil the quote.
Page 25 of 62
RedBack changes The existing APOS application defaults the business class to M if the business class is not supplied to RBGetQuoteSummary. This needs to be changed so that all business classes are returned in the result list if no business class is selected. 4.4.2 ANUBIS/RedBack Analysis has shown that a Pega solution would be, in most instances, better implemented by integrating directly with ANUBIS rather than using the existing Java service layer. There are some Java services that might still be used where no additional development effort is required. Where the existing Java services are utilised the layer developed within the existing APOS application will be deployed as a Java library (JAR) along with the RedBack library within the Pega Java Virtual Machine. Pega has integration services which allow for the discovery and extrapolation of Java objects and methods so that external components can be integrated with Pega Work objects and rules. 4.4.2.1 What is RedBack? RedBack is an IBM middleware product deployed as a jar file on the application server (WebSphere) that allows the Java (or in this case Pega) layer to communicate with the underlying ANUBIS data layer UniVerse. Java APIs This Java API is basically a Map of String's (it actually uses vectors underneath) to pass the data back and forth. The main RedBack class of interest is com.ibm.redback.redbeans.RedObject. See BaseRedbeanService, RedBeanFactory and QuoteServiceImpl for examples on how to use the API within the Java zip attached (see references). An example of the API usage is as follows: import com.ibm.redback.redbeans.RedObject; RedObject ro = new RedObject("http://wqbeapos:5559/rgw/RED", "QUOTE:Quote"); ro.getActiveConnection().setUserId("username"); ro.getActiveConnection().setPassword("password"); try { ro.open(); ro.setProperty("param", "test"); ro.callMethod("SomeMethod"); String result = ro.getProperty("result"); } catch (Exception e) { e.printStackTrace(); } A wrapper class au.com.qbe.anubispos.RedObjectWrapper is available that simplifies the use of RedObjects.1 4.4.2.3 Wrappers and helper functions The Java team as part of the APOS motor vehicle project have developed a number of helper functions and wrappers to facilitate interchange. These include: UniverseUtils.java, MVListTransformer.java and MVList.java these classes offer a number of helper functions developed by the team, including the handling of multi-value lists (or dynamic arrays). For example, a code and description table are returned as two separate
4.4.2.2
Source: Confluence http://dev.anubispos.qbe.com/confluence/display/ANU/Development+Guide
Page 26 of 62
Commercial In Confidence delimited lists (separated by sub-value ASCII 252, value 253 and field 254 marks refer to g:\WQBE\WA\Infosys\manuals\Universe\Universe Programmers Guide, pg 33) by the interface, the calling application must interpret these lists and reassemble the associative elements also handling null pointers. It may be appropriate that these helper functions are incorporated into the Pega application, there a number of options to be determined as part of the POC (which ever option is determined the main intention here is to capitalise on the IP developed previously): o Incorporation as a streamlined Java wrapper JAR file provided by the APOS Java team. o Import as distinct Java functions within PRPC (preferred). o Inclusion in Rule mapping (alternate preferred). BaseRedbeanService.java and RedObjectWrapper.java put a level of abstraction above the existing Java-RedBack interfaces hiding complexities around such areas as Security. On ANUBIS security each RedBack method invocation is required to pass a security token (a number of properties mapped to each RedBack methods parameters). These are contained within the RedObjectWrapper class. A similar approach will need to be adopted within Pega (ie. each individual interface should not require explicit security parameter mapping).
4.4.2.4
ANUBIS/RedBack methods and testing The RedBack layer generates both class and method integration documentation which is for the most part self describing in terms of usage and parameters. This documentation has been included in the references section and is also available on Confluence The business requirements specification also details where and when the appropriate RedBack methods should be invoked Developers should be aware that in some instances (it may not be immediately apparent that some) outputs from ANUBIS may not be immediately required but may need to be passed back in subsequent calls. The RedBack Object Scope Test tool can be used to unit test and verify ANUBIS integration methods. Refer to references for URL.
4.4.2.5
Quote numbering The existing APOS motor vehicle application utilises a RedBack method to generate a unique quote number from ANUBIS (incremented table sequence). Within Pega each quote or work object generates a unique workitem number. In the instance of QMS this reference is used to generate a quote number. There are essentially two options here: 1. ANUBIS continues to generate the quote number and this is stored against the workitem (exposed as a data field on the workobject table for searching and retrieval purposes like a foreign key) 2. Pega generates the workitem or quote number automatically and prefixed with a H to uniquely separate from existing Motor quotes. This unique value is then passed to ANUBIS on quote save The first option will be adopted so as to utilise the current processes and reporting.
4.4.2.6
Policy numbers ANUBIS will continue to generate policy numbers as per the existing APOS motor vehicle application, however in addition to the individual building, contents and valuables policy numbers that will be required for APOS household, a virtual policy reference number will also be generated. This will be the clients reference number and will link the individual policies created on ANUBIS. It will need to be displayed to
Page 27 of 62
Commercial In Confidence the user for quoting to the customer, and it will also have to be able to be searched on. 4.4.2.7 Premium calculation Premium calculations will continue to be performed by ANUBIS. Additional calculations within Pega will be developed to replicate current short term, instalment calculations, and premium override functions in APOS. In addition, the translation of multiple premiums for product classes building, contents and valuables to a single effective premium (and vice-versa) will be handled within Pega. In terms of the premium override functions, new rules are required for Household due to having only one set of discount/loading fields but needing to spread the discount/loading across the multiple product classes/policies. The following steps and rules apply: User must make a selection from the premium grid (i.e. select a radio button next to a total) before applying a discount/loading User selects Change of Premium radio button (Discount, Loading or Target Price) If Discount or Loading is selected, user then enters an amount and selects either Dollars or Percentage radio button The discount/loading amount (dollar or percentage) is applied to the total premium, which is then rounded up to the next dollar for annual, and 6 monthly and short term frequencies, and up to the next 5 cents for monthly and fortnightly frequencies (note that the premium grid figures dont change when a discount or loading is applied) After this rounding the discount/loading dollar amount and percentage are (re)calculated based on the rounded total premium amount. The percentage is rounded to 2 decimal places If Target Price is selected the Total field becomes editable and the user enters the price to match, and then the system calculates the discount/loading dollar amount and percentage. The percentage is rounded to 2 decimal places The following fields are passed back to ANUBIS via RedBack method RBUpdateQuote: discount type (discount or loading or nil), discount/loading dollar amount, discount/loading percentage, resultant total premium amount (after discount/loading) ANUBIS will apply the same discount/loading percentage across all policies, rounding the individual policys premium amount up to the nextnearest dollar for annual, and 6 monthly and short term frequencies, and up to the nearestnext 5 cents for monthly and fortnightly frequencies, and recalculating the discount percentage (rounded to 2 decimal places) after the total premium rounding. Order of precedence between product classes is building, contents then valuables. The last policy will receive the remainder of the discount/loading dollar amount
Example: User has been quoted building, contents and valuables and selects annual premium of $1083 (building $385, contents $457, valuables $241). They then choose to apply a 10% discount. 10% of $1083 = $108.30 Total premium (discounted) = $(1083 108.30) rounded up to next dollar = $975 Total premium discount amount = $(1083 975) = $108 Total premium discount percentage = (108/1083)*100 = 9.97% Building premium (discounted)= $(385 (9.97% of 385)) rounded up to nearestnext dollar = $347
Page 28 of 62
Commercial In Confidence Building discount amount = $(385 347) = $38 Building discount percentage = (38/385)*100 = 9.87% Contents premium (discounted) = $(457 (9.97% of 457)) rounded up to nearestnext dollar = $4112 Contents discount amount = $(457 4112) = $465 Contents discount percentage = (465/457)*100 = 10.079.85% Valuables discount amount = $(108 38 465) = $245 Valuables premium (discounted) = $(241 254) = $2176 Valuables discount percentage = (245/241)*100 = 9.9610.37% 4.4.2.8 Quote XML The existing APOS motor vehicle application utilises RedBack methods to store and retrieve the Pega equivalent of a work object (or the working quote data model) to the ANUBIS database (as XML). With Pega this data is stored by default within the workobject (BLOB on DB2) so the need to store the actual quote XML definition in ANUBIS is removed. However, it is understood that the key or indexing information on this table is used for existing APOS searching and acts as a fascade over the underlying ANUBIS database for APOS. The call to the RedBack commit quote XML method is still valid therefore although the actual XML does not need to be included as it is not used for anything besides maintaining model state within APOS and reporting requirements are against Universe Quote tables. Future migration of Householder solution within QMS framework will see explicit relational quote data mapping to the underlying QMS data model for such purposes as strike rate reporting. This is not within scope of the present solution and is currently met by existing ANUBIS reporting mechanisms. 4.4.3 Quick Address (QAS) QAS is a commercial software package that is deployed as a standalone application service (WAR on WebSphere), so is accessible either via Java or embedded HTML. Quarterly data import files are provided by the vendor. It is understood that this product is currently licensed to Western QBE (Direct) although it may be appropriate at a later stage that the license is extended for Enterprise use. QAS will be initially utilised to identify and validate single line data entry for Risk Address (client address to be raised under separate work request). There are two primary methods to invoke the service: 1. As a SOAP web service 2. As an embedded JSP fragment (with underlying Java API) Either method is technically possible from within Pega. SOAP is the preferred method (barring any performance issues) allowing QAS validation/formatting to be enabled as a corporate service (potentially via ESB regardless of type of invoking application). Where this WAR is deployed will be discussed with IT Midrange. 4.4.4 SecurePay QBE has an established relationship with SecurePay to provide secure online payment and verification services to a number of existing QBE internet applications, the latest version of which is present within the APOS motor vehicle system. This facility is via a Java API which transmits encrypted messaging between the POS application and the SecurePay gateway, which in turn interacts with the appropriate financial institution. It requires the install of a SecurePay.jar within the Pega application server (WebSphere).
Page 29 of 62
Commercial In Confidence Existing IP from the APOS Java team should be leveraged here. Note that an issue was raised in regard to problems with class loading (incompatible XML versions between SecurePay and WebSphere 6) experienced in APOS motor vehicle project. SecurePay comes with it's own XML JAR files and WebSphere has it's own XML JAR files. As WebSphere loads the XML JAR files, it loads it's own XML JAR files in preference to the SecurePay ones and then uses it's own XML JAR files to process SecurePay payments. This caused issues so the WebSphere class loader was changed so that the SecurePay XML JAR files were used in preference to the WebSphere XML JAR files. This problem will also need to be overcome with the APOS household application. 4.4.5 Dialogue It is the intention that the existing APOS Dialogue document composition service will be utilised. This service capability is two-fold: 1. Online SOAP Web Service call from APOS 2. Batch overnight document production from ANUBIS using watched directory scheduling The current APOS motor vehicle application produces the motor data as a fixed string. Ideally XML would be the preferred approach for Householders from the context of reusability. This would need to be raised as a change request. Pega will translate the Pega Work Object into a fixed format required by the existing RBPrint service and initiate the request to ANUBIS. For immediate prints, Pega will display the returned PDF (this integration to dialogue for online printing may be directly to Dialogue as opposed to the existing Java Service layer as this would represent as a more enterprise reusable approach). 4.4.6 Email and fax Allow functionality and necessary infrastructure to facilitate email and fax capabilities (including automatic schedule attachment, standardised email correspondence generation and an appropriate failure mechanism) from within the existing APOS motor vehicle system and the new APOS householders application. Note that the existing email address validation that currently occurs in the APOS motor vehicle system for client email addresses, is expected to apply to the email addresses captured for household. This validation uses the standard Apache Commons Email Validator class refer http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/EmailVali dator.html for details. 4.4.7 Stellent (document archiving) The current archiving solution for APOS motor vehicle is file system based. APOS schedules are written to a network directory. It is the intention that client correspondence is archived within the Enterprise Content Management system Stellent as QBE moves more towards a client model with associated meta data requiring definition. It is anticipated that archiving services will be SOAP based (these are well documented by Stellent and have been previously proved via POC of Pega-Stellent integration) and would include document commit as well as search and retrieval.
4.5 RedBack methods

As stated above, RedBack will be used as the middleware to allow the Pega layer to communicate with the underlying ANUBIS data and program layer. Refer to the business requirements specification for the location and timing of the specification RedBack integration points.
Page 30 of 62
Commercial In Confidence A new module UWHSALES will be created. It is intended where possible to retain the existing motor vehicle methods and properties for use in the household system. If we have to create a household method it will be prefixed as RBH. Since the household quote can contain up to 3 product classes (building, contents and valuables) many of the properties will have to become multi-valued (MVd). One of these is BusClass, which we can use to define what system we are running, so this property will become BusClassMV in both systems. It is intended that this modification will be done prior to the implementation of the household functionality and that this will be the only change made to the APOS motor system. Examples of the use of BusClassMV will be something like: IF BusClassMV = 'M' THEN stat<-1> = RBO.getProperty('','VehSchedule',VehSchedule) stat<-1> = RBO.getProperty('','VehGrade',VehGrade) stat<-1> = RBO.getProperty('','VehSumInsGood',VehSumIns) stat<-1> = RBO.getProperty('','MainDriverDOB',MainDriverDOB) stat<-1> = RBO.getProperty('','VehUsage',VehUsage) END ELSE stat<-1> = RBO.getProperty('','Schedule',Schedule) stat<-1> = RBO.getProperty('','Category',Category) stat<-1> = RBO.getProperty('','ConstructType',ConstructType) stat<-1> = RBO.getProperty('','OccupancyCode',OccupancyCode) stat<-1> = RBO.getProperty('','JointSingle',JointSingle) stat<-1> = RBO.getProperty('','SpecialDwellType',SpecialDwellType) END Another is when we use BusClassMV to call different subroutines for household: IF BusClassMV = 'M' THEN CALL RB.CalcPremium (.) END ELSE CALL RBH.CalcPremium (.) END 4.5.1 Security/login RB.Security This is a UniObject method that authenticates and gets user sign-on and security level and delegated authority limits. It does not need to be changed for household. RB.Available This subroutine is called by all methods (within I_RB.INITIAL) to check that RedBack is available (GLOBAL.CONTROL REDBACK.AVAILABLE = 1). It will not have to be changed as separate control of RedBack availability is not required for motor versus household (i.e. RedBack is either available for both motor and household, or for neither). RBGetDefaults This is a special loader method within class Defaults that is run once at initialisation and loads ANUBIS control information. This method populates many vehicle properties that are not required for household. These properties are found in GLOBAL.CONTROL JAVA.DEFAULTS. It appears that no new controls need to be loaded for household, so this method need not be changed unless we separate the controls that are required for each system. If this is to be done create a new method RBHGetDefault for household with just the controls required for household. 4.5.2 Quoting RBGetQuoteId This is a method within class WriteQuote which allocates the quote identifier to the quote. Household quotes will be numbered in the same numeric sequence as motor vehicle ones, so this method will not change.
Page 31 of 62
RBRiskSearch This method within class RiskLocation searches for risk location postcodes and suburbs. It will not have to be changed. RBGetRiskLoc This method within class RiskLocation gets the risk location information and will not have to be changed as it locates the correct location for the suburb within the postcode, which is compatible with the ANUBIS household logic. RBValidateUserBranch This method within class Quote validates the user branch sanctions and will not have to be changed. RBGetAgents This is a method within class Agents which gets the list of available branch agents for the user. The property name for household will be Schedule instead of VehSchedule. Use BusClassMV to determine which property name to use. RBGetExcesses This is a method within class Excesses which gets theft, age, undeclared and inexperienced driver excesses. It is not required for household as household does not have these excesses. The fixed and removable excesses (as in motor) are returned as part of methods RBCalcAnnualPremium and RBCalcPremium. RBGetAuthority This method within class Authority gets the user authority levels. Household, like motor, has delegated authority limits on sum insured, premium discount/loading and rule levels. This method will not have to be changed. RBTrackAuthority This method within class TrackAuthority logs the transaction details of delegated authority overrides. The RiskDesc property will need to be changed as follows: For building and contents, RiskDesc = RiskAddress (RiskStreetNo, RiskStreetName, RiskSuburb) For valuables, RiskDesc = RiskAddress: :Cover (e.g. 10 HAY ST SUBIACO $1000 per misc item, $5000 per event) RBGetQuote This method is within class QuoteXML and it retrieves the quote and covernote data using the quote or policy number. Changes are required with this method due to the complication of having multiple product classes within the one quote. Where the PolicyNo get property has been set (i.e. the quote has been converted to covernote) do a locate in the PolicyNoMV attribute on APOS.QUOTE to check that this is a valid covernote for that quote. Where BusClassMV is not set to M then loop through the PolicyNoMV attribute for each covernote and do the following: Read the HPOLICYx records Check that the policy and renewal status are both set to C Accumulate the Balance and BalancePaid properties Accumulate the CheckSum of each policy record Set the accumulated Balance and BalancePaid properties. Set the BeforeImageMV property to the accumulated checksum. RBUpdateQuote
Page 32 of 62
This method within class WriteQuote populates the APOS.QUOTE record. It also calculates various values that also need to be stored in the APOS.QUOTE record but are not available from the UI. Very large changes are required with this method due to the complication of the three product classes within the one quote. Many properties will become multi-valued and new properties will be required. Currently it only needs to handle one product class motor vehicle. It returns to the UI the checksum of the APOS.QUOTE record after it has been updated. It will need to handle multiple product classes on the one quote. This will require extensive changes to loop through each business class (using BusClassMV) on the quote. All new household RedBack properties required by ANUBIS will have to be extracted from the UI (GET) and stored on the APOS.QUOTE record. The following is a list of the new RedBack input properties that this method will have to extract (get) from the UI. RedBack property description Wall constuction type Roof type Building occupancy type Dwelling type Special dwelling type Rewired flag Joint building or contents policy number Main residence QBE insured flag (Y/N) Building age Contents specified items description Contents specified items amount Valuables specified items description Valuables specified items amount Building instalment amounts Contents instalment amounts Valuables instalment amounts Original premium payable (undiscounted/unloaded) PropertyName ConstructionType RoofType OccupancyType DwellingType SpecialDwellingType RewiredYN JointPolicyNo MainResQBEInsuredYN BuildingAge SpecItemDescCTMV SpecItemAmtCTMV SpecItemDescSRMV SpecItemAmtSRMV InstalCentsBDMV InstalCentsCTMV InstalCentsSRMV PremCentsOriginalMV
In order to meet the premium discount/loading requirements outlined in section 4.4.2.7 above, RBUpdateQuote will use PremCentsOriginalMV and DiscountFactor to calculate the premium payable for each class. The result will be stored in a new APOS.QUOTE field called PremCentsMV. It will also then recalculate the discount/loading percentage and store the result in a new APOS.QUOTE field called DiscountFactorMV. We will also need to calculate the following values and store them on APOS.QUOTE in the pre-assigned attributes. The calculation logic will be the same as for motor. Call routine RB.CalcBreakdown for each product class (as per motor) to return the tax components included in the premium amount. For instalment policies calculate the tax components of the initial instalment and of the ongoing (regular) instalment. Field Building Instalment Policy Fees Description Multivalued field containing the policy fee component of the building policy instalment amountAssociated with field InstalCentsBDMV Multivalued field containing the policy fee component of the contents policy instalment amount. Associated with field InstalCentsCTMV Multivalued field containing the policy fee component of the valuables policy instalment amount. Associated with field
Contents Instalment Policy Fees
Valuables Instalment Policy Fees
Page 33 of 62
Field Building Instalment FBL amount Contents Instalment FBL amount Valuables Instalment FBL amount Building Instalment GST amount Contents Instalment GST amount Valuables Instalment GST amount Building Instalment STD amount Contents Instalment STD amount Valuables Instalment STD amount
Description InstalCentsSRMV Multivalued field containing the FBL component of the building policy instalment amount. Associated with field InstalCentsBDMV Multivalued field containing the FBL component of the contents policy instalment amount. Associated with field InstalCentsCTMV Multivalued field containing the FBL component of the valuables policy instalment amount. Associated with field InstalCentsSRMV Multivalued field containing the GST component of the building policy instalment amount. Associated with field InstalCentsBDMV Multivalued field containing the GST component of the contents policy instalment amount. Associated with field InstalCentsCTMV Multivalued field containing the GST component of the valuables policy instalment amount. Associated with field InstalCentsSRMV Multivalued field containing the STD component of the building policy instalment amount. Associated with field InstalCentsBDMV Multivalued field containing the STD component of the contents policy instalment amount. Associated with field InstalCentsCTMV Multivalued field containing the STD component of the valuables policy instalment amount. Associated with field InstalCentsSRMV
Multivalued properties Currently under motor there are various properties which are also applicable to household product classes (e.g. PremCoverType). These properties are defined as single valued fields however for household we will need to create new multi-valued properties for these fields (see APOS.QUOTE layout). Where the business class is not equal to M then these new properties will have to be referenced instead of the existing motor properties. These existing motor and corresponding new household RedBack property names are: Motor name PolicyNo PremCoverType FinanceFlag FinanceCode PremCents PremAnnual PremAnnualOpt PremFixedExcess PremRemExcess PremRemExcessResult ExcessImposedCode ExcessImposedDollars PremFBL PremSTD PremPolicyFee PremGST NCBYears TotalSumIns VehSchedule Motor format P123456M1 1 Y ANZ 35000 30000 5000 100 50 100 X1 350 5000 2500 1500 2000 5 25000 A Household name PolicyNoMV PremCoverTypeMV FinanceFlagMV FinanceCodeMV PremCentsActualMV PremAnnualMV PremAnnualOptMV PremFixedExcessMV PremRemExcessMV PremRemExcessResultMV ExcessImposedCodeMV ExcessImposedDollarsMV PremFBLMV PremSTDMV PremPolicyFeeMV PremGSTMV NCBYearsMV TotalSumInsMV ScheduleMV Household format P123456B1}P123456C1}P123456S1 4}4}5 Y}N}N ANZ}} 15000}10000}5000 13000}9000}4500 5000}2000}1000 100}100}100 50}100}75 50}0}25 X1}X2}X3 350}400}0 5000}2500}0 2500}1500}1000 1500}1000}2500 2000}1500}1000 5}3}0 300000}30000}10000 M}C}W
Write the new household properties to the APOS.QUOTE record. All fields on this record are ALWAYS overwritten with the new values. RBUpdateXMLQuote
Page 34 of 62
Commercial In Confidence This method is within class WriteQuote and it writes the latest UI quote data onto a UNIX directory and updates an associated UniVerse file index. It is called by the UI after the call to method RBUpdateQuote. The changes required for this method are the writing to APOS.XML.INDEX with the multivalued PolicyNoMV and with the product classes that make up the quote. This data is also required in the quote to cover note and the payment process. Modify method to read the BusClassMV attribute from the APOS.QUOTE record. Copy this field to APOS.XML.INDEX<12>. Also copy field PolicyNoMV from APOS.QUOTE to APOS.XML.INDEX<2>. These 2 attributes are associated and are now multi-valued NOT single valued. Refer to file layouts in : Data on 'Au.qbe.pri' (G:)\WQBE\WA\Planning\ANUBIS POS\Household\2. Planning\Technical Specification. PLEASE NOTE: Because these fields are alternate index fields the existing indexes will have to be deleted and re-built after installation of these changes. 4.5.3 Premium/option calculation RBGetOptions This method is called by class Options and it gets the available options. Three of the input properties for class Options for this method will now be multi-valued (associated to BusClassMV): BusClassMV (will be done prior to the implementation of the household functionality) CoverTypeCodeMV ScheduleMV These will control what options are returned. Use BusClassMV to determine which property names to use. Property OptionNoMV will now be prefixed with the product class (e.g. B01). OptionNoMV will NOT be prefixed with an M for motor. RBValidateOptions This method within class Options validates the selected options. As for RBGetOptions, property OptionNoMV will now be prefixed with the product class (e.g. B01). RBCalcOptions This method within class Options calculates the annual option premium for the selected options. Refer to RBCalcAnnualPremium as the annual premiums (property PremAnnualMV) will be for each product class for the specified cover (includes the periodic cover). As for RBGetOptions, there are property name changes and property OptionNoMV will now be prefixed with the product class (e.g. B01). RBCalcAnnualPremium This method within class Premium calculates the annual premium without options for use in RBCalcOptions. The annual premiums (property PremAnnualMV) calculated for motor are the annual premiums for the covers (e.g. comprehensive, nominated driver, preferred drive) however for household the calculated annual premiums will be for each product class for the quote for the specified cover e.g. building replacement (B4), content replacement (C4), valuables $1000 per item, $5000 per event (S4). As for motor the annual premium for the periodic covers will also have to be calculated. New properties for class Premium for this method include:
Page 35 of 62
Commercial In Confidence ConstructType OccupancyCode JointSingle SpecialDwellType SpecValExcess MiscValExcess
Many of the properties will now be multi-valued: BusClassMV (will be done prior to the implementation of the household functionality) ScheduleMV (instead of VehSchedule) CategoryMV (instead of VehGrade) NCBYearsMV FinanceFlagMV CoverTypeCodeMV TotalSumInsMV RBCalcPremium This method within class Premium calculates the annual premium including option premium. As for RBCalcAnnualPremium the calculated premiums (property PremCentsMV) will be for each product class for the quote for the specified cover. New properties for class Premium for this method include: ConstructType OccupancyCode JointSingle SpecialDwellType SpecValExcess MiscValExcess Many of the properties will now have to be multi-valued: BusClassMV (will be done prior to the implementation of the household functionality) ScheduleMV (instead of VehSchedule) CategoryMV (instead of VehGrade) NCBYearsMV FinanceFlagMV CoverTypeCodeMV TotalSumInsMV RBCalcInstalments This method within class Premium calculates the monthly, fortnight or payroll instalments of the annual premium. It requires changes because the quote will require the instalment schedule for each product class. Input properties for class Premium for this method that will now be multi-valued and new properties include: BusClassMV (will be done prior to the implementation of the household functionality) ScheduleMV (instead of VehSchedule) CategoryMV (instead of VehGrade) TotalSumInsMV PremCentsActualMV (instead of PremCents) The new output properties are: ConstructType JointSingle OccupancyCode SpecialDwellType InstalCentsBDMV InstalCentsCTMV InstalCentsSRMV InstalCentsMV (will be the total of the above instalments)
Page 36 of 62
RB.CalcBreakdown Called by method RBUpdateQuote rather than the UI, this subroutine calculates the GST, stamp duty and fire service levy of the premium. It will need to be changed to include an argument for location code so that FSL can be calculated. RB.PREMCALC This subroutine calculates the premium, instalments and breakdowns. It is called by subroutine RB.CalcPremium (called by methods RBCalcAnnualPremium and RBCalcPremium), RB.CalcInstalments (called by method RBCalcInstalments) and RB.CalcBreakdown (called by method RBUpdateQuote). This subroutine already handles household policies so it does not need to be changed. 4.5.4 Cover note fulfilment RBQuoteToCNote This method within class QuoteToCNote gets the quote id from the UI and allows an existing quote to be converted to a cover note OR allows an existing cover note to be altered. This is a very large method that will need some major changes to handle the 3 household product classes in 1 quote. It must now also be able to detect when a product class (i.e. building or contents or valuables) has been removed from a previously fulfilled quote and take appropriate action to cancel the removed cover note. The main change is to place the bulk of the existing logic within a FOR/NEXT loop which loops through each policy number within the PolicyNoMV field on APOS.QUOTE and processes each policy one at a time. Many fields on the APOS.QUOTE record which were previously single valued and non-associated are now multi-valued and associated with the business class attribute (field no. 6). This is the primary element of the CLS association. Refer to the APOS.QUOTE file layout for all fields within this association (look under column titled Depth/Assoc). RBQuoteToCNote will also write the policy numbers to attribute 1 of POLNO.INDEX using the APOS household virtual policy reference number as the key. This reference number will also be written to attribute 74 of the HPOLICY.B file. The POLNO.INDEX record will be used by the payment processes to disburse the payment to the associated policies. Validation Add any mandatory field checking for the building, contents and valuables policies. Accumulate the checksum of each of the policies HPOLICY.A, HPOLICY.B, HPOLICY.C and HPOLICY.D records before checking the result to the parameter BEFOREIMAGE.MV. Update Check to make sure the following new household properties are being written to the HPOLICYx records: Property File/field Value ConstructionType POLB(35) [4,1] B,C OccupancyType POLB(35) [6,1] B,C DwellingType POLB(35) [5,1] B,C SpecialDwellingType POLB(35) [7,1] B,C RewiredYN POLB(35) [9,1] B,C JointPolicyNo POLB(43) B,C MainResQBEInsuredYN POLB(35) [10,1] B BuildingAge POLB(45) B,C SpecItemDescSRMV POLB(38) S SpecItemAmtSRMV POLB(40) S SpecItemDescCTMV SCHEDULE C SpecItemAmtCTMV SCHEDULE C Commit
Page 37 of 62
Commercial In Confidence All updates for all the product classes M, B, C, S must be contained within the transaction QUIESCE. That means that the COMMIT must be after the final loop iteration (i.e. after the NEXT statement). This will ensure database integrity against software errors. 4.5.5 Update cover note RBQuoteToCNote This method within class QuoteToCNote will need to be changed to cancel a cover note when a product class has been removed from the quote since it was last updated. This should only be done where the MODE parameter is set to AC indicating an alteration of an existing cover note. Read the POLNO.INDEX record which has a key of the quote id prefixed with the text APOS. E.g. APOS9999 where 9999 is the quote number or id. This record should exist for all quotes that have been converted to cover note(s). If it does not exist then set the property ErrMsg with an appropriate error message and set the severity level to fatal (2). Field one of this record (POLNO.INDEX) is multi-valued and will contain all the policy numbers that were linked to the quote the last time RBQuoteToCNote was called. Check that each of these policies still exist on field 4 of the APOS.QUOTE record. Where one of these policy numbers is on POLNO.INDEX but not on APOS.QUOTE then that cover note will have to be cancelled (refer to the ANUBIS changes section for changes required to UG127S). 4.5.6 Client search and quote search RBClientSearch This method within class GlobalSearch performs a client search from various selections. It will not have to be changed. RBGetQuoteSummary This method within class ClientInquiry gets APOS quote information for a client or from search criteria. For the UI to distinguish between motor and household quotes the property QuoteClassMV can be used. For motor quotes the product class is M and for household the product classes could be any combination of B, C or S. The method will have to be changed so that a search by any of these household product classes can be performed. Business class (F10) in APOS.XML.QUOTE will be multi-valued (change dict item). RBGetPolicySummary This method within class ClientInquiry gets policy summary information for a client. For the UI to distinguish between motor and household policies the 8th character of property SummPolicyNoMV can be used. For motor quotes the product class is M. This method will need to be changed to display the APOS household virtual policy reference number in brackets after the Policy No. e.g. P123456B1 (H1) RBGetClaimsSummary This method within class ClientInquiry gets claim summary information for a client. It will not have to be changed. RBGetComments This method within class ClientInquiry gets client or policy comments. It will not have to be changed. RBGetHistory This method within class ClientInquiry gets client or policy history information. It will not have to be changed. RB.GetPolicyStatus This subroutine is called by method RBUpdateQuote and subroutines RB.LogPayment and RB.Payment, and it retrieves the policy status. This method already handles household policies, so it will not have to be changed.
Page 38 of 62
Commercial In Confidence 4.5.7 Payments RBValidateCreditCard This method within class Payment validates a credit card number. It will not have to be changed. RBValidateBSB This method within class Payment validates a bank state branch number. It will not have to be changed. RBValidateAccountNo This method within class Payment validates a bank account number. It will not have to be changed. RBLogPayment This method within class SecurePayment logs that a credit card payment is about to be made via SecurePay. Using the household virtual policy reference number read POLNO.INDEX to get the multivalued list of the ANUBIS policy numbers and then for each policy loop around and check the policy status and if refund/reversal that the amount is not greater than the payments. If data is accepted write RBO.BEFORE.PAYMENT including the policy numbers and the amounts into fields 10 and 11. RBLogCancel This method within class SecurePayment logs that a credit card payment is about to be cancelled via SecurePay. This method will not have to be changed.. RBPayment This method within class SecurePayment processes the successful payment to the cover note and the general ledger. Loop throught the muti-valued policy numbers and the payment amounts in fields 10 and 11 of RBO.BEFORE.PAYMENT to pay/refund the ANUBIS policies. This method also handles the reversals/refunds. Refer section 4.6.1 below for payment processing rules. 4.5.8 Printing RBPrint This method within class Printing generates an immediate print or overnight request of the quote or ROC pack. The immediate print calls SR.APOS.PRINT which formats the input for Dialogue. The overnight requests are written to file APOS.PRINTREQ. The ROC data is written to file APOS.ROC. This method will not need to be changed if the virtual product class of H is used as the policy reference for notice prints (see Dialogue interface section below).
4.6 ANUBIS changes

4.6.1 Australia Post and BPay payment batch processes Similar to the SecurePay payments, this process (UG506 run as part of UWDAY.TWO) will need to cater for a payment that could cover the three product classes (building, contents and valuables). A virtual policy reference number will be generated when the quote is fulfilled, and this will be the clients reference number for any further enquiries. This reference number will be made up of client no:'H':nnn where nnn is a sequential number starting with 1. This reference number will be written to POLNO.INDEX and will contain the multi-valued list of the ANUBIS policy numbers making up the virtual household policy.
Page 39 of 62
The reference number will also be printed on documents that are sent to the customer and single payment will be collected via a barcode on the covering letter of these documents which makes use of the reference number. The payment processing rules are: When making the initial payments by this virtual policy reference number, the sequence of payment to individual policy is building, contents and then valuables When paying an EP/RP, if the payment/refund matches the balance of all policies then the necessary credits or debits are made to all the policies If the payment/refund does not match the balance of all policies then the credit or debit is posted to each policy until the payment is exhausted. If the payment/refund has an excess the excess is posted to the last policy.. The non zero balance policy report will identify any linked policies with the policy balance 4.6.2 Cancel cover note (UG127S) The UG127S routine is currently used by ANUBIS within the cover notes driver to allow the cancellation of a cover note for any product class. Change this subroutine so it can be called by either a RedBack process or by an ANUBIS program. Use the common variable DEFAULT$$ to determine if the caller is RedBack. This variable is set to the value REDBACK within the insert item I_RB.INITIAL which is at the top of all RedBack methods. UG127S will need to interrogate DEFAULT$$ and when it is set to REDBACK perform the following: Execute Insert item I_APOS.FILE.OPEN Bypass any INPUT, CRT or PRINT statements Bypass any file OPENs these are already done by RB.QuoteToCNote and the file variables are held in common When a fatal error occurs translate the RETURN.FLAG error code to an actual error message before returning to the calling method. Set the error severity level to 2 (fatal). RETURN.FLAG must be set to null by the calling routine just prior to UG127S being called Make sure that this routine is always called within the transaction commit cycle (QUIESCE) in RB.QuoteToCNote. 4.6.3 Household policy enquiry (UG025S) The ANUBIS enquiry screen for APOS household policies will append the APOS household policy reference e.g. H1 in brackets to the policy cover e.g. will display as "B3 (H1)". As per section 4.5.4 above, the POLNO.INDEX file will be updated with the virtual policy number and corresponding B/C/S policy numbers so that the existing ANUBIS search on old policy number will allow a search on APOS virtual policy number to retrieve the related ANUBIS policy numbers. 4.6.4 Blocking updates to APOS generated policies in ANUBIS Cover notes issued via APOS must be blocked from being recalled and updated through ANUBIS. Programs UB609S (building and contents cover note alteration), UP609S (pleasure craft cover note alteration) and US609S (valuables cover note alteration) will need to be changed accordingly. Also, programs UB603S (building proposal update), UP603S (pleasure craft proposal update) and US603S (valuables proposal update) will need to be changed to include the same logic in UM603S that sends a new DDR when APOS details have changed.
Page 40 of 62
Commercial In Confidence 4.6.5 Dialogue interface (notice prints) Outlined below are the ANUBIS data and program changes required to accommodate the Dialogue interface for APOS household notices. Note that in addition to this we need to liaise with Salmat to set up the new batch structure and modify the Notice Insert Spreadsheet. Data changes Suggest a virtual product class of H which will link to the building, contents and valuables Dialogue to use the product class of H for household policy. New records required for household quote: Record Name Description HHQUOTE Summary quote information such as dates, cover types, sum insured, risk address etc HBQBEN Building component benefits HBQEXS Building component excesses HCQBEN Contents component benefits HCQEXS Contents component excesses HVQBEN Valuables component benefits HVQEXS Valuables component excesses New records required for household schedule: Record Name Description HHSCHED Summary schedule information such as dates, cover types, sum insured, risk address etc HBEXCESS Excesses applicable to building component HCEXCESS Excesses applicable to contents component HVEXCESS Excesses applicable to valuables component HHSPECITMS List of specified Items will need separate lists for contents and valuables Note: more will probably be required once document design has been finalised Existing records that require modification: Record Name Description COVLET Allow for new conditions on covering letter INSERTS Allow for household inserts to be included in quote and ROC pack MESSAGES Allow for any marketing messages that may be required DDR Use the APOS household virtual policy reference number as policy number Records that dont require modification: Record Name Description HEADER File header record BRADDR Branch address record CLIENT Client detail address record MVEXCESS Motor vehicle excess record MVSCHED Motor vehicle schedule record DRIVER Named driver list record ENDKEY Endorsement No. and heading detail record Issues: If the same Dialogue pub file is used for household as for motor, then we need to modify the format of the ROC record to include the class of business ie H or M We have to be aware of normal ANUBIS printing that will eventually migrate from Compuset to Dialogue where we currently mix household and motor policies in one print batch file
4.6.5.1
Page 41 of 62
Commercial In Confidence The business has to be aware that if they move to a C5 policy booklet (half A4 size) then the location of the address block is different for a C5 envelope as opposed to a DLX and hence will have to be incorporated with the new design Also moving to a C5 envelope will require existing notice redesign and major style sheet changes unless these are to remain DLX or are moved to Dialogue also
4.6.5.2
Program changes Existing programs: Program Name APOS.BATCH SR.APOS.PRINT SR.NOTICE.BUSTYPE SR.NOTICE.BRADDR SR.NOTICE.CLIENT SR.NOTICE.COVLET SR.NOTICE.INSERT SR.NOTICE.MARKET SR.NOTICE.QUOTE SR.NOTICE.PREM SR.NOTICE.OPTIONS SR.NOTICE.EXCESS SR.NOTICE.ENDORSEMENTS SR.NOTICE.SCHEDULE SR.NOTICE.DRVLST SR.NOTICE.DDR SR.NOTICE.SALUTATION SR.NOTICE.FINANCECO
Description Batch APOS notice production program run from NATIONAL APOS notice program harness called immediately for PDF generation and also called by APOS.BATCH for overnight notice generation Subroutine to calculate the notice business source from the agent code Subroutine to generate the BRADDR (Branch Address) record. Also takes into account the special branch addresses we offer to intermediaries Subroutine to generate the CLIENT (Client detail) record Subroutine to generate the COVLET (Covering letter) record Subroutine to generate the INSERT record Subroutine to generate the MESSAGES (Marketing message) record Subroutine to generate the quote record Subroutine to generate the premium detail array Subroutine to generate the option list and applicable endorsements Subroutine to generate the excess records Subroutine to generate the ENDKEY (Endorsement key) records Subroutine to generate the schedule detail record Subroutine to generate the DRIVER (Named driver) records Subroutine to generate DDR record Subroutine to return the nice customer salutation for the covering letter Subroutine to return the finance company full description and branch from the stored code on the policy record
Coding structure changes identified: Modify Insert in BPS> I.DIALOGUE:

EQU EQU EQU EQU EQU MTR$ BLD$ CNT$ VAL$ PLC$ TO TO TO TO TO 1; 2; 3; 4; 5; * * * * * Motor Building Contents Valuables (Special Risk) Pleasure Craft (Boat)
COMMON / DIALOGUE$ / DLG.CLASS, ; * Dialogue Class (M or H) DLG_POLICY.NO$ ; * multivalue as per position above DLG_MASTER_POS$ ; * master policy number position DLG_POLA.REC(5,100),
Page 42 of 62
DLG_POLB.REC(5,100), DLG_POLC.REC(5,100), DLG_POLD.REC(5,50)
All existing APOS notice printing programs to be modified to use the new two dimensional array structure as follows. Current programs use array structure of:
1. AGENT.NO = POLA.REC(11) 2. POL.STATUS = POLA.REC(1)[1,1]
Need to modify to:

1. AGENT.NO = DLG_POLA.REC(MTR$,11) or AGENT.NO = DLG_POLA.REC(DLG_MASTER_POS$,11) 2. POL.STATUS = DLG_POLA.REC(MTR$,1)[1,1] or POL.STATUS = DLG_POLA.REC(DLG_MASTER_POS$,1)[1,1]
New code for household to use something similar:

BLD.SUM.INS = DLG_POLB.REC(BLD$,20)+0 CNT.SUM.INS = DLG_POLB.REC(CNT$,20)+0 VAL.SUM.INS = DLG_POLB.REC(VAL$,20)+0
4.7 Notice development (Dialogue)

Waiting on notice business requirements, including notice layout, data elements, rules within the notice (e.g. de-duplicating endorsements), stock requirements, insert requirements 4.7.1 Document design Same document and print pack requirements as APOS motor Notice data elements Notice business rules Record of Conversation and policy documentation will not exceed 6 pages in any one mail-out Australia Post processing of new household reference number in our barcodes
4.7.2 4.7.3
Page 43 of 62
5 Database design
The database design outlines the database schemas, procedures, environments, capacity planning, archiving and reporting requirements for the Pega DB2 and UniVerse databases.
5.1 Pega DB2

5.1.1 Schema The Pega DB2 database will store both session data (work objects) and BRE data (PegaRules). It is likely that a new table will be created in the database to store APOS household work objects. Schemas for both the PegaRULES database and the work object table can be supplied if required. The Pega DB2 database will provide an externalised view of the Pega data at quote completion. PRPC stores quote data out of the box in a binary format or BLOB on the PegaRules database. The database schema will be converted to an XML schema for import into PRPC to create Data-object mappings. The XMLSpy tool and the DB2 Connect V8 ODBC drivers will be used to facilitate this process. 5.1.2 Database procedures Database administrators to: create environments as per DB2 naming standards and as supplied by data modeler setup all housekeeping jobs (backups etc) apply table changes (after approval from data modeler) support and maintain new environments as per DBA work practice Environments The Pega databases are currently hosted on P-Series DB2v8 and the APOS Household system will make use of these existing environments. The following table illustrates details of the Pega DB2 hosting environment naming and location. Environment Sandpit Development System Test UAT Training Production PegaRules PEGSDPT PEGDEVT PEGSYST PEGUTST PEGEDUC PEGPROD Location 10.88.6.49 10.88.6.49 10.88.6.49 10.88.6.49 10.88.6.49 10.88.6.47
5.1.3
An environment map will also be included in the QBE PRPC Enterprise Principles document, to be published soon. 5.1.4 Capacity planning Whilst data volumes will increase, the additional DB2 requirements for Pega will not substantially affect existing available capacity. Ongoing monitoring will be required.
Page 44 of 62
Commercial In Confidence To assist in projection of anticipated volumes within both PegaRules and UniVerse databases, the following numbers of household quotes have been extrapolated from ANUBIS: Period 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 Total Average/month 5.1.5 Total household quotes 7119 8613 8272 8193 9415 7371 7498 56481 8069
Archiving Whilst archiving will not be an immediate concern for the APOS Household project, an archiving strategy in relation to Pegas internal workobject BLOB database may need to be considered in the longer term. Clearer decisions will be enabled once it is understood what the levels of throughput are and how much physical storage is required in this regard on a transaction basis. POS work objects will be isolated to a new table TPG_POS_WORK to facilitate overall future archiving requirement strategies. i.e. POS work objects are much more transitory vs negotiated (which are used as electronic filing records). This strategy will be related to business requirements for period of retention of completed quotes for enquiry purposes within APOS. It has been suggested that a period of 18 months retention may be satisfactory in this regard, a sufficient period to cover renewals. Data warehousing may offer an alternate longer term store.
Comment [KH2]: This was an addition by Jaso Little during sign off
5.1.6
Reporting Refer to the Pega elaboration document for any new Pega reports required.
5.2 UniVerse XML (APOS) data

5.2.1 File layouts The file layout will be as per APOS motor except for field 2 (policy number) on the APOS.XML.INDEX file which will be multi-valued when we have multiple policies. Environments As per the current environments: Environment Development System/integration testing UAT Training Production 5.2.3 Partition wqbedev wqbeint wqbeuat wqbetrain wqbeprod
5.2.2
Capacity planning The APOS.XML file is an operating system file, or UNIX directory, and as such monitoring of file system utilisation by the Midrange team will determine whether any extra capacity will be required.
Page 45 of 62
Commercial In Confidence The APOS.XML.INDEX file is a static file which would need resizing should it fall into an overflow situation, however the file is currently not in overflow and if this occurred it would be managed as part of the usual DBA maintenance. 5.2.4 Archiving The APOS.QUOTES file is the only file currently archived. The quotes are archived after 90 days. This process is run weekly as part of NAT035. The APOS.XML file is a large file that should also be archived regularly. APOS.XML.INDEX is only very small (with basic quote details) and is useful as an audit trail, so this file will not be archived. 5.2.5 Reporting As per the existing APOS system, no reporting on this XML data is required.
5.3 UniVerse ANUBIS data

5.3.1 File layouts The existing IBM UniVerse database will be used (variable length file system, hosted on the mid-range IBM p570 in Homebush). No new files will be required, but there will be new fields required on some existing files and a new alternate index to link an APOS quote number with policy numbers from each product class (building, contents, valuables). The new fields for existing UniVerse files have yet to be specified, but refer to section 4.3 of the Low Level Business Requirements (Functional Specification) document for field requirements. 5.3.2 Environments As per the current environments: Environment Development System/integration testing UAT Training Production Partition wqbedev wqbeint wqbeuat wqbetrain wqbeprod
5.3.3
Capacity planning It is expected that the number of household quotes and cover notes will not change. The conversion rate to policy is likely to increase because the fulfilment process will allow the customer to pay and take out the insurance immediately with no need to complete a paper proposal form and send it back, but this is just an update of a policy record. There are approximately 25 UniVerse files updated by APOS. Any increases to the size of these files will not be substantial so will be managed as part of the usual DBA maintenance. Note that the APOS.QUOTE file is a static file which is currently in overflow so it will need to be resized during the next round of file maintenance.
5.3.4
Archiving Archiving of ANUBIS data from UniVerse will be as per the existing system and processes.
Page 46 of 62
Commercial In Confidence 5.3.5 Reporting Since existing UniVerse files will be updated with data captured via APOS, the current ANUBIS reports and extracts will cover any reporting requirements for APOS household.
Page 47 of 62
6 Infrastructure design
This section describes the infrastructure requirements necessary to facilitate and support the proposed application solution. This information will be used in consultation with the relevant QBE IT areas to facilitate the proposed infrastructure solution.
6.1 Hosting
As per the current APOS and Pega applications. No upgrades required for the IBM p570. J2EE WebSphere deployed PRPC application PegaRules DB2 database connectivity Connectivity to ANUBIS Email SMTP connectivity CVS repository all PRPC environmental migrations should be managed and stored within a CVS repository Install of QAS and required RedBack and SecurePay integration libraries
6.2 Environment
The following APOS WebSphere hosting environments will be used: APOS WebSphere Environment Development Nightly Selenium integration test System/integration test UAT Production URL https://dev.anubispos.qbe.com/anubispos http://nit.anubispos.qbe.com/anubispos https://int.anubispos.qbe.com/anubispos https://uat.anubispos.qbe.com/anubispos https://www.anubispos.qbe.com/anubispos SSL Yes No Yes Yes Yes Connectivity QBE network(s) QBE network(s) QBE network(s) QBE network(s) QBE network(s)
The following Pega WebSphere hosting environments will be used: PRPC WebSphere Environment Sandpit Development System Test UAT Production URL SSL Connectivity Internet - (for subsequent releases) http://snd.pega.qbe.com http://10.88.6.42:9082/prweb/ http://dev.pega.qbe.com http://10.88.6.42:9081/prweb/ http://sys.pega.qbe.com https://uat.pega.qbe.com https://pega.qbe.com No Yes Yes QBE network(s) QBE network(s) and Internet QBE network(s) and Internet No No QBE network(s) QBE network(s)
Existing web security certificates will be sufficient (i.e. no new certificates will need to be obtained/used).
Page 48 of 62
6.3 Infrastructure components

All data collected via the APOS user interface lives in memory on the server until it is saved to the database. Since the number of users will not be increasing dramatically after the household release, the current infrastructure will be sufficient. It is important to note however, that in light of the enterprise applications currently being planned and developed, the existing infrastructure will need to be reviewed generally to ensure sufficient capacities such as memory and CPU are available to all applications and their environments. 6.3.1 HTTP server IBM HTTP Server v6 Edge Component (xlxprd01) Application server IBM WebSphere Application Server v6 WebSphere Application Server deployed on IBM Pseries (paxpega1) running AIX 5.3 OS. Database server DB2 on AIX V8 Enterprise Server Edition Dev databases on DB2dev01 (10.88.6.49) Prod databases on DB2prd01 (10.88.6.47) and DB2prd02 (10.88.6.48) User desktop SOE User environment Internet Explorer 6+
6.3.2
6.3.3
6.3.4
6.3.5
6.4 Proposed network topology

There will be a single Pega production instance deployed at Sydney Olympic Park data centre (SOPDC). APOS users will access Pega via QBE internal networks, although subsequent Pega releases may need to offer internet connectivity. Figure 8 below shows the operation of Pega over the QBE networks.
Page 49 of 62
Figure 8. Operation of Pega over the QBE networks
6.5 System operation

The following is an outline of the system operations: 1. User access to the Pega application is by a specified URL. Typically of the form: https://pega.qbe.com/prweb/PRServlet 2. The browser communicates with the HTTPD virtual server on the HTTP Server. This will be by SSL 3. The HTTPD virtual server will redirect requests via the plug-in to WebSphere on paxpega01 4. WebSphere configured JNDI (Java Naming Directory Interface): 1. JMS connection pooling used for MQ connectivity 2. JDBC connection pooling used for relational database connectivity 3. SMTP for email
Formatted: Bullets and Numbering
6.6 Availability and reliability

The current service level agreements have a system availability target of 99.9% (during normal business hours), which is expected to be upheld by the APOS household application. There is no requirement to have APOS Household available when ANUBIS is not available (e.g. during overnight batch jobs). Note that Pegas current required hours of operation are as follows:
Page 50 of 62
6.6.1
Monday to Friday 06:00 - 21:00 (AEST) Saturday to Sunday 08:00 -17:00 (AEST) Database As per the current APOS and Pega applications. In production, Pegas DB2 database backups are done on-line. However, the current procedure for new releases of PRPC applications includes downtime and an off-line backup. The production Pega DB2 database has been created as High Availability Disaster Recovery (HADR) i.e. mirror image with second production database in standby mode.
6.6.2
Application server (WebSphere) As per the current APOS and Pega applications. The WebSphere application server and the P-Series platform will be typically unavailable for backups and daily maintenance: 30 minutes for nightly maintenance and log retrievals Pseries backups are online so there is no downtime in this regard.
6.6.3
Integration points The following integration points will impose availability constraints: Integration point ANUBIS SecurePay Dialogue Availability As per existing ANUBIS availability (midnight to 6:15pm WST/WDST) As per existing APOS motor vehicle availability (24 x 7, with 99.97% planned availability (outages only every couple of months for approx 30 min)) As per existing APOS motor vehicle availability (potentially 24 x 7, as only unavailable during occasional and short periods of maintenance/upgrades etc) Subject of a separate WR
Email/fax
6.7 Usage and volume considerations

There will be an increase in the usage of the APOS system with the household release - there wont be any additional users on the system but the existing users will be on the system more of the time. ANUBIS load will not be materially affected, as users will go from using ANUBIS directly for household new business, to using APOS with ANUBIS interface RedBack usage will increase, however we have sufficient capacity within the current system to absorb any increase (we currently have 5 responders running at approximately 20% load) Application server usage will increase. Current estimates suggest that 8 concurrent transactions per minute would be suitable with the current APOS motor vehicle solution able to support up to 16 concurrent transactions per minute. Additionally, current benchmarks for other components are: 1. AJAX response = 100 milliseconds 2. Page to Page change = 250 milliseconds 3. Credit card transaction = 15 seconds 4. Print document = 5 seconds Emailing documents (NB: currently not in scope for this release) we will need additional storage space as part of the Stellent solution. It is anticipated that there will be 24,000 emails within the first year (15% adoption by customers), with the adoption rate increasing to 20% in the second year and 25% in the third year. Each email would be made up of some simple covering text on the email, and up to two pdf attachments (one for the Dialogue created document (quote, ROC or update ROC) and one for the policy wording/PDS). A total error rate of between 2 to 2.5% is expected.
Formatted: Bullets and Numbering
Page 51 of 62
6.8 Performance
The following table has been devised to describe the application response time requirements for key functions/operations required by a user from the APOS Household system: Key function Client search return list with defined parameters (surname, first name, state) Select client from list to display Client screen Start Household quote from splash screen to present Existing Client page Start Household quote from client screen to present Location page Change of any/screen in logical process flow using Next/Back button Change of screen to call and display Underwriting page Population of any pick list in the quote/fulfillment UI (including RB or BRE) Add new row of data from any table in the quote/fulfillment UI Calculation and display of premium on Premium page when requested Process credit card payment via SecurePay to present receipt number Produce and display pdf in browser for any immediate print request Application response time 1 sec Sub 1 sec Sub 1 sec Sub 1 sec 1 sec 1-2 sec Sub 1 sec Sub 1 sec 1 sec 10-15 secs 15 secs
The expectation from the business is for a high performance user interface that meets the response times that have been specified. The high performance user interface is required to meet the conditions of a direct call centre where the operator is dealing directly with the customer over the telephone. The following metrics from the business should be used as a possible guide to place the above requirements into perspective: Total Peak User Load = 150 users Total Peak Concurrent User Load = 80 users Peak Transactional Load = 8 concurrent quotes facilitated by the system per minute
6.9 Scalability/extendibility
In the first instance, the APOS Household solution must be able to support the current APOS user base (i.e. internal user base for Direct Distribution). Delivery of the APOS Household solution will also provide a basis for the technical framework required to support any B2B or B2C initiatives, although it is recognised that extending the application to these other delivery methods will require additional work.
6.10
Failure management
System failures will be handled in the same way that they are for the current APOS motor vehicle application (e.g. emails to the system administrator/s). However, the definition of a system failure and what is worthy of going to the system administrator, including what is communicated in the email, is something that will need to be workshopped between the business and the technical team during the APOS Household development, so that some of the issues encountered with the current motor system are rectified.
6.11
Backup and recovery

The Pega DB2 database will be backed-up nightly, as per existing Pega implementations. ANUBIS backups will continue to run as per existing schedules.
Page 52 of 62
Commercial In Confidence Care and due process will be required in restoring backups of the Pega and ANUBIS database to ensure the records are kept in synchronisation.
6.12
Disaster recovery
As per the existing DR strategy for ANUBIS, APOS and Pega.
Page 53 of 62
7 Security design
7.1 Security and control requirements
The following basic security requirements apply: Connection via HTTPS (SSL certificate) Password and authentication compliance with QBE IT Security Policy and Guidelines Individual user audit trail support for both production process and rules maintenance Granular and role based user and administrator access definition QBE IT Security to undertake security assessment of proposed solution and to perform penetration testing against deployed application QBE IT Security to gate keep any necessary firewall changes to facilitate solution connectivity The security standards for the existing APOS motor vehicle application are also applicable to the household functionality: The household release is to have the same levels of security as the current motor vehicle application. It is not expected that the list of authorised users will increase, as the existing personnel within the call centre will have access to both the motor vehicle and household products The existing security processes and policies for motor vehicle, to set up and manage user-ids and log-ins, will be applied to the household release. This includes sanctions and delegated authority levels
7.2 Sign-on process

The single sign-on solution outlined in section 4.4.1 will require Pega to treat APOS as a trusted system. To increase security, WebSphere executing Pega will be configured to only allow the initial requests from WebSphere executing APOS. This eliminates the risk of the URL being launched directly from the browser with an encoded token.
7.3 User authentication, sanctions and delegated authority levels

The current process to authenticate an APOS user as a valid user in ANUBIS, and retrieve ANUBIS sanction and delegated authority levels (via RedBack method RB.Security) will be used.
7.4 Database connectivity

PRPC will be required to connect to its own DB2 instance (PegaRules database). A user profile is defined at the application level to allow this connectivity and typically configured within the application server (WebSphere) JDBC connection pooling configuration. As part of standard practice, individual users are not defined against the datasource. PRPC will connect to ANUBISs UniVerse database via the RedBack layer. Refer Integration section above for more details.
7.5 ANUBIS connectivity

To transact with ANUBIS, a user requires an ANUBIS user and sanction definition. The APOS application uses the ANUBIS user definitions so user authentication in APOS involves connection to ANUBIS (via UniObjects) to authenticate the ANUBIS user. Once this is done any APOS initiated transactions will be accepted (after a user is logged in they get a secure key that needs to be sent with every secured RedBack request to validate the users credentials).
Page 54 of 62
7.6 Quick Address (QAS)

QAS data is not confidential. There is no username/password requirement for this service. It is freely available to anyone who could physically connect to the port and decipher the information.
7.7 SecurePay
The current APOS system does not store the credit card details when not required. The communication between our server and the SecurePay gateway is SSL encrypted and subject to a merchant username and password. This merchant username and password is stored in a file in an unencrypted form.
7.8 Dialogue
Data that is required by the Dialogue document composition service is transmitted in an unencrypted but secured form.
7.9 Email and fax

This is the subject of a separate work request.
7.10
Stellent (document archiving)
This is the subject of a separate work request.
7.11
PRPC access and privileges

This section defines PRPC specific access and privilege definitions. For further information refer to the Pega elaboration document.
7.11.1
Access groups An access group represents the authority level available to a group of operators within PRPC. Held within an access group are the following rules: List of rulesets, in hierarchical order, that anyone in this access group can access List of roles that anyone in this access group has List of skills that anyone in this access group has List of work pools that operators are able to work from Operators Operators are people who are given access to the APOS Household application. Operators will have the following attributes stored in their operator profile records: login name password which organisation, division, and work unit this operator belongs to the operators access group workbaskets this operator can access (via association with workgroup) Workbasket access Every operator belongs to a workgroup, and each workgroup has a default workbasket.
7.11.2
7.11.3
Page 55 of 62
8 Development approach
The following development approach will be undertaken to ensure key areas of the implementation have been appropriately covered: Iterative design and build, allowing for multiple walkthrough validation checks with the appropriate business representatives Prototype/proof of concept to explicitly validate the overall design approach, specifically the key areas below, early on in the project to identify any possible issues or risks and implement suitable mitigation (if required) Screens and workflow this also incorporates business rules however the key point here is to workshop/prototype look and feel to ensure as much as practically possible (balancing strategic considerations) that the user experience between APOS motor vehicle and APOS household are consistent ANUBIS integration successful integration across the application tiers is a critical part of the application Security and single sign on user experience should not be adversely affected by Pega and APOS being hosted from different application servers on separate Pseries partitions
8.1 Timeboxes
APOS Householders functionality will be developed in the following four timeboxes: 1) Quoting 2) Cover note fulfilment and client search 3) Quote search/recall, update cover note and printing (notices) 4) Payments Each timebox will consist of the following activities: Requirements review and analysis (if required) BRE rules loaded and test Build and unit test QA/review by Solution Design and Architecture team to ensure compliance with enterprise architectural strategies (first timebox only) Prepare for system testing Conduct system and integration testing Rework Retest Documentation/management wrap-up Prepare for UAT Issue to UAT UAT, including support and rework
8.2 Release and configuration management

There will be four environments: development, integration/testing, UAT, and production. Prior to development code moving to another environment, development code must be locked, i.e., prevented from being changed. All code will be unlocked from change once moved into production. 8.2.1 PRPC release and configuration management This section defines how RuleSets are used to maintain, migrate and manage rules in PRPC. It also describes the process the QMS project will use to manage access groups and
Page 56 of 62
migrations from the development environment, through testing environments and into production. 8.2.1.1 RuleSet name and versions Each RuleSet Name defines a major partition of the rule database. Together with the RuleSet Version, a RuleSet Name is a major aspect in Access control, Managing the contents of the rule database and Moving applications (sets of rules) from one environment to another. A RuleSet Version is in the form NN-NN-NN, characterises the development of a rule instance, and of the application it belongs with. The three segments are known as the major version, minor version, and patch version. The rule resolution algorithm uses version numbers to find the most appropriate single rule instance to execute in a specific situation. The Move Rules utility uses Version numbers to determine which rule instances to extract from your system. 8.2.1.2 Check in/check out PRPC has an inbuilt configuration management tool. This means before a rule can be altered it must be checked out into a users ruleset so that they can make changes before checking in. Upon check-in, the user is prompted for a short description. This description should include a brief description of the changes and the reason for change, as well as the defect/CR number that required the change. This creates an audit trail of changes and also allows a user to look at a snapshot of the rule before and after the changes. Access groups Access groups make a set of RuleSet versions available to requestors. This allows the flexibility of not only restricting particular RuleSets to application end users but also development teams. Migrations and skimming The migration tool within PRPC converts selected rule instances into a text XML format, exports them as individual text files, and consolidates these files into a ZIP archive. Though controlled from your browser session, this tool executes on the server. The Skim option of the Move Rules tool causes a resetting of the RuleSet Version values in the highest version of existing rules. For each rule instance in a specified RuleSet, the Move Rules tool identifies the highest numbered version, adds one to the major part of the version, and sets the minor and patch values both to "01". Skimming simplifies the topmost rule versions in a RuleSet after multiple iterative development cycles. For example, if the highest version was previously 01-21-06, the skimmed version number is 02-01-01. A lower version 01-21-05, or 01-18-53, of the same rule is unaffected by the skim function. 8.2.1.5 APOS code management process Figure 9 below shows the rule development and migration cycle for the APOS Household project.
8.2.1.3
8.2.1.4
Page 57 of 62
The migration is verified, then the access groups of the users of the new environment can be incremented to include the newly migrated ruleset version
6. Change Access Group
1. Create New RuleSet Version
On the first iteration, RuleSet Version 01-01-01 created. Subsequent iterations will increment the RuleSet Version.
By fully qualifying the ruleset version in the access group of the operators, it is possible to migrate a new ruleset, then test to ensure it is fully functional before allowing the real users to access the new functionality
5. Verify migration in new environment
PRPC Rule Development and Deployment Cycle
2. Build rules into current RuleSet
Check In / Check Out applies
Note: Test -> UAT UAT -> Production Do NOT involve steps 1 to 3 as all rules and rulesets originate from Dev
4. Migrate RuleSet version to next environment
3. Lock RuleSet
Ensures no more rules can be created in this version and no existing rules can be altered.
E.g. Dev -> Test Test -> UAT UAT -> Prod
Figure 9. PRPC rule development and deployment cycle
The process for migrating rules and managing access to rulesets for the APOS Household project will be as follows: When the first migration from the Development environment into the test environment is ready to take place (e.g. QBE-Generic-Underwriting:01-0101), the ruleset version will be locked. This ensures no more rules can be created in this version and no existing rules can be altered. It will then be migrated into the test environment. The operators who are involved in testing will have this ruleset fully qualified in their access group A new ruleset version, or patch, will be created in the development environment (01-01-02). All bug fix rules and rules to handle CRs will be created in this new patch. Check In / Check out will apply At the next planned migration, this ruleset will be locked and then migrated into the test environment. Once the migration has been verified, the access group of the test users will be altered to include this new ruleset version. The benefit of this approach is more apparent if you consider migrations into the production environment. By fully qualifying the ruleset version in the access group of the production operators, it allows us to migrate a new ruleset, that has been tested in the UAT environment, test to ensure it is fully functional in production before allowing the real production users to access the new functionality Migrations will follow a controlled sequence through all environments before ending up in production. For example, rules will be created in the development environment, then migrated into the system test environment and system tested. Once the system testing has been completed, the ruleset version will be migrated into UAT for the users to verify. After UAT sign-off, the migration into production will take place at a scheduled time to minimise impact to users In the immediate term, release management will be controlled from within the project team. Alignment with existing processes for external/integrated systems (e.g.
Page 58 of 62
Commercial In Confidence ANUBIS) change migration will also be necessary. Eventual consideration must be given to the management of potentially multiple PRPC development streams under a centralised configuration manager. 8.2.2 Java release and configuration management The existing Subversion repository archive for APOS motor will be used to store APOS Household Java assets. The APOS motor codeline will be used and we will produce a separate JAR file in the Ant build script to deploy to Pega. This has the advantage that the new RedBack connector will be available for both motor and Pega usage and should reduce future maintenance costs. ANUBIS release and configuration management As per existing APOS system.
8.2.3
Page 59 of 62
9 Test strategy
This section outlines the proposed testing strategy describing at a high-level the testing tasks to be performed in order to validate the completeness and scalability of the proposed solution.
9.1 Initial connectivity and unit testing

9.1.1 Test strategy Responsibility: APOS Household project team and supporting IT Unit testing is typically undertaken as part of the build process, and includes any required rework Given the integration points, in particular to the existing APOS application, ANUBIS and SecurePay, it is important to establish at an early point connectivity from PRPC to supporting integration points in the event that contingencies in design approach need to be undertaken. This will be achieved via the prototype/proof of concept No explicit outputs, undertaken as part of build
9.1.2
Test team APOS Household project developers who are undertaking build activities. Test environment Development environments. Test tools Pega unit testing PRPC internal tools (Clipboard, Tracer, Performance Analyser (PAL)) Java unit testing Junit ANUBIS unit testing none RedBack unit testing RBOScope
9.1.3
9.1.4
9.2 System testing

9.2.1 Test strategy Responsibility: APOS Household project team and supporting IT Test plan and associated test cases to be documented and carried out in a structured manner. There will be several iterations Inclusive (but not exhaustive) of: o Functional testing (including ANUBIS specific changes) o Technical/environmental testing o Testing of integration points between Pega, APOS, ANUBIS, QAS, SecurePay, Dialogue, email/fax and Stellent o Regression testing (including APOS motor vehicle) Any errors are to be tracked (in JIRA), resolved and retested. Major issues escalated as required. Minor issues may be deferred with business agreement Output: test cases and results are to be documented for Quality Assurance and review Pass/Fail criteria error free result or minor incidents reported and accepted by business Functional testing Testing the system functions that are required by the business. Refer to the business requirements specification.
9.2.1.1
Page 60 of 62
Commercial In Confidence 9.2.1.2 9.2.1.2.1 Technical/environmental testing Performance and load testing The integrated APOS/Pega/ANUBIS application that is developed will need to be tested for performance and robustness. Overall, the user experience should not be adversely affected by APOS and Pega being hosted from different application servers on separate partitions of the IBM P570. Whilst there wont be any additional users on the APOS system, the existing users will be on the system more of the time so there will be additional system usage. 9.2.1.2.2 Performance and load testing undertaken against APOS to ensure robustness and scalability within infrastructure and application (PRPC and integration points). Identify any bottlenecks or limitations Ensure performance for audience users is within reasonable expectations Test connectivity performance of integration points Application response times should be tested by using Apache Jmeter The Webroller or WAPT load testing tool may be employed for the purpose of load generation (or may use Jmeter) Compuware Vantage or Application Expert tools may be used to assess/further diagnose any performance impact brought about by node or network bottlenecks The Pega Application Profiler tool may also be used for performance testing Need to investigate impact to database, CPU, network and memory
Security penetration testing Responsibility of IT Security Requires: launch of penetration test tools against UAT and pre-production application infrastructure Test cases and results should be documented and tracked. Any potential security issues are to be clearly specified and prioritised for resolution by the infrastructure project team. Upon correction, the associated infrastructure will be retested Pass/Fail criteria no major security vulnerabilities identified and outstanding
9.2.2
Test team APOS Household project team (T&PD staff) and supporting IT. Test environment System testing/integration environment. Test tools As per existing APOS application (Selenium), which provides for automated regression testing. Apache Jmeter, Webroller or WAPT, Compuware Vantage, Application Expert and/or Pega Application Profiler tools for performance and load testing (see above).
9.2.3
9.2.4
9.3 User acceptance testing

9.3.1 Test strategy Responsibility: Direct business unit (WQBE managed by National Operations department) Requires: successful completion of previous testing activities and the provision of a UAT environment
Page 61 of 62
Commercial In Confidence 9.3.2 Test cases and results are to be documented and tracked. Any errors or issues are to be clearly specified and prioritised for resolution by the project team. Upon correction, the associated function will be retested Pass/Fail criteria error free result or minor incidents accepted by the business
Test team APOS Household project team (Direct business unit staff) and a selection of current APOS users. Test environment User acceptance testing environment. Test tools There will be no automated testing tools used in UAT, however if at an enterprise level a decision is made to adopt the use of the Rational suite, then the business will look to see what can be leveraged for UAT of APOS Household.
9.3.3
9.3.4
Page 62 of 62

APOS+HH+Technical+Specification+v1 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

APOS+HH+Technical+Specification+v1 2

Uploaded by

Copyright:

Available Formats

PR-506500 APOS Household Technical Specification

Version 1.21 Direct Distribution January September 20082009

Phil Stafford-Jones J2EE Architect (Pega developer role)

Date 12/12/2006 16/02/2007 13/04/2007 13/04/2007 14/01/2008

Version 0.1 0.2 1.0 1.1

Name Kylie Henson Kylie Henson Kylie Henson Kylie Henson

2.2 Project overview

Business requirements specification

Solution design and estimate

Integration design document

Pega data dictionary

Pega elaboration document

Configuration management plan

Pega security integration guide

Detailed business requirements for APOS Household

SD&E for the APOS Household project

Functional and technical requirements for the APOS Household prototoype

Technical design for APOS Household integration aspects

Data dictionary for APOS household work objects

PRPC Technical Design for APOS Household

CM Plan for the APOS Household project

QBE DB2 standard

DB2 standards for QBE group

QBE Group Information Security Policy

Figure 1. High level architecture of the current APOS J2EE application

Refer to Confluence for other documentation on the current APOS system.

4.1 Application architecture

Figure 4. PRPC J2EE Application Architecture courtesy of PegaSystems Inc. (www.pega.com)

Figure 5. APOS Householders architecture

Area Logging and tracing

Error messages Single sign on

Externalised application access Dialogue RedBack/ANUBIS environments

Uniobjects configuration SecurePay configuration

Email and fax service

4.2 Overall system design

Figure 6. APOS/Pega integration overview

4.3 PRPC technical design

Figure 7. APOS Household Pega product component structure

Commercial In Confidence Payments Underwriting page Policyholders Send/print

Date in UTC format

userDept userKey userLevel userName userNo userTerminalNo userSecurityMask doActivity pw

Source: Confluence http://dev.anubispos.qbe.com/confluence/display/ANU/Development+Guide

4.5 RedBack methods

Contents Instalment Policy Fees

Valuables Instalment Policy Fees

Commercial In Confidence ConstructType OccupancyCode JointSingle SpecialDwellType SpecValExcess MiscValExcess

4.6 ANUBIS changes

Coding structure changes identified: Modify Insert in BPS> I.DIALOGUE:

Need to modify to:

New code for household to use something similar:

4.7 Notice development (Dialogue)

5.1 Pega DB2

5.2 UniVerse XML (APOS) data

5.3 UniVerse ANUBIS data

6.3 Infrastructure components

6.4 Proposed network topology

Figure 8. Operation of Pega over the QBE networks

6.5 System operation

Formatted: Bullets and Numbering

6.6 Availability and reliability

6.7 Usage and volume considerations

Formatted: Bullets and Numbering

Backup and recovery