OneList Approvals Technical Overview

Transcription

1 OneList Approvals Technical Overview V 3.8 April 2015

2 Contents 1. OneList Approvals What is OneList Key business benefits of OneList Key features of OneList How does OneList differ from other approval solutions? User Interface Samples Solution Architecture Solution Components Deployment Architecture Security and Authentication Application Authentication Back-end Authentication Authorisation Requirements System Pre-requisites OneList Server Browser Compatibility Outlook Version ios Platform Android Platform Implementation Plan Configuration and Administration Technical Implementation Skills Required Support and Administration Requirements... 17

3 1. OneList Approvals 1.1. What is OneList OneList is an aggregator of system workflow tasks and alerts across multiple backend applications into an accessible, intuitive and information-rich end-user experience for effective and timely executive decision making action. A centralised service definition supports highly configurable, data-driven user-interfaces including: - Native ios (iphone/ipad) and Android Mobile Application - Web App (for internal and non-ios devices) - Outlook Add-in Application Page 3 of 17

4 1.2. Key business benefits of OneList Process execution velocity By bringing together worklists from multiple applications, managers are able to more rapidly access and respond to assigned tasks - this improves overall business process efficiency by reducing approval bottlenecks. Where such delays may otherwise impact ongoing operations (eg delayed replacement of critical equipment causing operational stoppages) this can provide substantial business benefit; Decision effectiveness By consistently tailoring the presentation of key information relevant to the organisation and the decision point, better decision making is facilitated. This information includes: o Key elements from the underlying business object (eg Vendor in the case of a Purchase Order); o Relevant items from related objects o Supporting documentation (eg Scanned quotation attached to Purchase Order or Requisition) o Real-time supplementary information (eg Current Project Budget, or Team Calendar view) Governance and Control Electronic signatures and audit trail provided by an online process are in general more reliable in terms of provenance than physical signatures on paper documents; Task Completeness An always up-to-date task list is more reliable than notifications; Productivity rapid synthesis of information and speed of processing is facilitated by providing consistent navigation of data and an intuitive task execution interface; User acceptance Managers are expecting that systems present information into their native context (at their desk or on the road) and are delighted by the convenience offered by OneList; Compliance by improving the timeliness of approvals, there is inevitably increased procedural compliance; Administration with only one workflow interaction point to administer, ongoing system administration effort and cost is minimised. Page 4 of 17

5 1.3. Key features of OneList Configurable to incorporate all approval tasks across multiple applications with inherent support for SAP workflow tasks; Fully configurable to present the specific information needs and available actions relevant to the organisation and scenario; Simple and consistent user experience that doesn t require the user to navigate to the backend applications; Access to supporting scanned documents hosted in SAP, SharePoint, OpenText or other document store; Retrieval of real-time supplementary information: OneList can execute a secondary call to a backend application for additional information at the time of completing a task - for example, the ability to view a team leave calendar whilst making a leave approval decision; Intuitive design allows for rapid user take-up with no training required; Rapid implementation with cloud-hosted deployment options; Multiple user interfaces, platforms and devices supported; Mobile app has offline capability (for task execution even in aeroplanes!); Multiple tasks can be selected and a quick action applied to all; and Data-driven user interface supports flexible centralised customisation of new scenarios and information display without further client deployments How does OneList differ from other approval solutions? No dependency on any additional software platforms; No infrastructure dependencies OneList can be cloud hosted to reduce in-house infrastructure dependencies; Where universal work list solutions exist, these are typically based on only one backend application such as SAP. In most large environments there are multiple backend applications generating tasks and this forces the user to follow an inconsistent process across different tasks; Other commercially available approval solutions are designed around the approval of a specific task and often require the installation of multiple approval applications or modules; Standard workflow or other approval solutions do not facilitate access to supporting documents external to that application; OneList allows for a consistent user experience in SharePoint, Outlook or native Mobile application based on a single layout configuration; OneList Mobile App allows for approval tasks to be actioned in Offline mode; Supplementary information: the ability to supplement transaction details with real-time related information eg budget, or team leave calendar. Page 5 of 17

6 1.5. User Interface Samples The following images highlight key functionality. Figure 1 - OneList incorporating multiple task categories Figure 2 - Detailed display of application data as required Page 6 of 17

7 Figure 3 - Access to supporting documentation Figure 4 - Online and Offline approval Page 7 of 17

8 Figure 5 - Quick actions Figure 6 - Supplementary Info - for example team calendar Page 8 of 17

9 Figure 7 - OneList integrated into Outlook Page 9 of 17

10 2. Solution Architecture OneList solution comprises a number of technical components that are implemented as required, and supports a variety of technical deployment options as described below Solution Components The OneList solution consists of the following technical components: OneList Server This mandatory component provides core functionality: - Integration Service Adapter Definitions Integration with workflow systems is achieved using plugable adapters. Pre-packaged adapters are available for SAP, SharePoint, K2 and Nintex. - Scenario Configuration The customised grouping and presentation of decision support information is centrally defined here and consistently presented via all User Interfaces. - Notification Service (requires a SQL database for persistence of user profiles and associated tasks): o Generating OneList initiated task notifications via o Native mobile Push Notifications (requires a further cloud-hosted Push Notification Service activation) o Performance Acceleration through pre-caching of tasks. - Admin application for user and system connection administration OneList Web App This is the default user-interface for accessing OneList. The Web App is installed on an IIS server with connectivity to the OneList and Notification Services. This web app can be accessed using both desktop and mobile browsers OneList Outlook App This is an Outlook add-in that renders OneList conveniently in a panel in a Microsoft Outlook client. This app needs to be installed on each user client machine OneList ios/android Mobile Apps These are native applications app for both ios (iphones and ipads and Apple Watch) and Android-based devices. These apps provide rich user-interaction and offline processing capability OneList Cloud Access Point This is the internet-accessible service end-point. This needs to be accessible via: - IQX cloud-hosted service end-point, or - over the internet using a reverse proxy gateway, or - through a VPN connection from the device to an internal server. Page 10 of 17

11 2.2. Deployment Architecture On-Premises Deployment OneList can be hosted on-premises if desired. For mobile access this will require either the provision of secure VPN connectivity from the device to the onpremises server or implementation of a reverse-proxy server in the customer DMZ to manage in-bound mobile connections over the internet. Figure 8 - On Premise Deployment Architecture For performance, scalability and High Availability, the OneList Server can be clustered in a farm configuration. Page 11 of 17

12 Hybrid Deployment The diagram below illustrates the default hybrid deployment architecture. The OneList Server is deployed on an IIS server on the internal infrastructure. This may be a SharePoint frontend server or a stand-alone IIS Server. The OneList Server creates a secure connection with the Cloud Hosted components. All other components are hosted by IQX in the Microsoft Azure cloud, and available to the customer for an annual subscription fee. The key benefits of this approach are: - Limited internal infrastructure requirements - Secure internet-accessible service end-point In order to leverage AD authentication, the customer will need to support Active Directory Federation Services. Alternatively, application-specific forms-based authentication is supported. Figure 9 - Hybrid Deployment Architecture Page 12 of 17

13 3. Security and Authentication 3.1. Application Authentication OneList authenticates via Active Directory (AD). For cloud-hosted deployments this requires AD Federation. OneList can alternatively use forms-based authentication for access to the service Back-end Authentication OneList actions are relayed to the back-end applications and processed under the approver s credentials (or in exceptional cases under a service account). Subsequent mapping to internal systems will then rely on a Single Sign-On framework, including SAP Netweaver Portal Logon Tickets and Microsoft SharePoint Secure Store Service. If no existing identity mapping framework is in place, OneList does provide a credentials vault in the absence of an existing corporate solution. In order for AD Authentication credentials to be passed through OneList Web App to call a connected system (i.e. a double hop), Kerberos is required, or AD trust and delegation must be configured Authorisation Requirements Each connected system is required to support both Service and User account access as follows: Service Account Access This service account is required in order to: - Retrieve tasks on behalf of end-users - Retrieve associated task details. These details are then cached for a more responsive user-experience. User Actions are always performed using the credentials of the end-user User Account In order to access and process tasks in OneList users will require authorisation in connected systems to: - Perform configured actions (e.g. Approve or delegate); - Retrieve attached documents. For SAP connected systems, the user account must contain the authorization object S_RFC for remote access interaction SAP Single Sign On OneList supports the following SAP SSO configurations: - SNC with Windows authentication - SAP Portal Ticket Page 13 of 17

14 4. System Pre-requisites 4.1. OneList Server The minimum specification for the OneList server hosted on premises is: Windows Server 2008 R2 or Windows server Core CPU 16 GB ram IIS.Net framework Browser Compatibility OneList Web App is compatible with the following browsers: Microsoft Internet Explorer 9+ And current major releases of: Chrome Firefox Safari 4.3. Outlook Version OneList Outlook App add-in is available for Outlook 2007 and later ios Platform From a device perspective, the native OneList ios app is compatible with ios 7+ on iphone, ipad and ipad mini devices. The OneList ios app is provided as an ipa file, and available to be signed and published via a customer s preferred mobile Device Management platform. As the app is custom branded for logos and colour schemes it is not available on the Apple app store Android Platform The native OneList Android app is compatible with Android 4.1+ based devices. OneList is tested on common Samsung devices, and is expected to work on all compatible platforms. The OneList Android app is provided as an apk file, and available to be signed and published via a customer s preferred mobile Device Management platform. As the app is custom branded for logos and colour schemes it is not available on the Google Play store. Page 14 of 17

15 5. Implementation Plan A typical OneList implementation plan is illustrated below. The OneList customisation stage duration is dependent on the number of custom scenarios to be implemented. Templates exist for the common SAP approval tasks, and very little further customisation is typically required for these, however integrating with other workflow systems may require more effort. OneList Deployment Plan No 1 2 Project Preparation Testing Phase Requirements Definition OneList Customisation (per scenario) 4 Client Deployment Deployment Decription Define in scope users and approval tasks Determine user-interface requirements Identify source systems and integration approaches Document security architecture Establish test strategy Define deployment architecture Provision consultant Network Access Provision consultant SAP access Provision consultant Remote access Provision SharePoint site Provision Test User accounts Generate and stage test data Provision on-premises server Install Outlook add-in on test workstation Provision test mobile devices Enable ADFS (if cloud access required) OneList Server Installation Custom Branding Service Configuration Unit Testing Business Playback Adjust and validate Outlook Add-In Deployment Mobile app deployment Integration Testing User Acceptance Testing Deploy Service Configuration to Production Resolve Post Deployment issues Days Customer IQX Effort Effort ALL Project management Indicative TimeLine Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Resource Totals Page 15 of 17

16 6. Configuration and Administration 6.1. Technical Implementation Skills Required OneList is designed for enterprise deployment, and consequently supports a high degree of implementation flexibility. Whilst the User-Interface components are standardised (subject to custom branding), configuration of additional scenarios is customised by implementation. For details on Service configuration please reference the OneList Configuration Guide. OneList service configuration is contained in an XML file. To adjust the layout and presentation of information is readily achieved by a technical resource familiar with XML file manipulation and binding to Web Services or proxy class methods. A visual configurator is available for basic layout editing. The source system bindings directly interact with Web Service end-points exposed by target applications or service proxies. OneList is packaged with common-use Line of Business service proxies for rapid deployment. For SAP ERP without Gateway enablement, these service proxies utilise the SAP.Net connector for integration to standard SAP BAPI s via RFC. Typically for common SAP workflow scenarios, no changes or adjustments are required to the SAP environment. New source system bindings or customer-specific SAP service connections may require the provisioning of simplified web services or service proxies. These may be developed within the technology framework most familiar to a customer including SAP,.Net, Java and employ middleware components such as SAP Gateway, Netweaver PI or BizTalk as required. Page 16 of 17

17 6.2. Support and Administration Requirements The centralised service architecture facilitates ongoing support and administration Logging Support and administration requirements may arise due to a variety of factors including: - Source system non-availability; - Source system interface changes; - Authorisation errors; - Solution upgrades. In order to debug and resolve reported OneList issues, error logging is provided on the server file system Application Updates and Extensions OneList is deployed together with an AppManager component. The AppManager components connects with the IQX application marketplace, and new versions of OneList or adapters can be easily downloaded and deployed. Page 17 of 17