Oracle® Hospitality
Payment Interface
Multi-Properties Support
Sizing Guide
Release 20.3
F41840-01 April 2021Oracle Hospitality Payment Interface Multi-Properties Support Sizing Guide Release 20.3 F41840-01
Copyright © 2021, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
iii
Contents
Contents
3
Preface
4
1
Sizing Methodology Overview
1-1
Server Sizing Methodology 1-2
Notes on Virtualization 1-2
Disk Capacity Sizing 1-2
2
Assumptions
2-1
3
Software Components
3-1
4
Hardware Specifications
4-1
5
Transaction Throughput
5-1
Preface
Purpose
This document is designed to offer guidance on sizing a host machine for deploying one instance of Oracle Payment Interface (OPI) to support multiple OPERA properties. The sizing recommendations published in this document are based on analysis of data collected in test labs and designed to provide guidance on the transaction volume that can be supported on specific hardware.
Due to the fact that many environments have nuances specific to them, these guidelines should be used as a starting point when selecting server hardware. Once a system has gone live in the production environment, it may be necessary to modify the server configuration to account for customer specific requirements and conditions.
For special customers with higher transaction volume requirements than what is listed in this document, more powerful hardware configuration should be considered.
Audience
This document is intended for internal use by Presales and Sales consultants that require guidance for estimating the server needs of potential OPI users.
Customer Support
To contact Oracle Customer Support, access My Oracle Support at the following URL: https://support.oracle.com
When contacting Customer Support, please provide the following: Product version and program/module name
Functional and technical description of the problem (include business impact) Detailed step-by-step instructions to re-create
Exact error message received Screen shots of each step you take Documentation
Oracle Hospitality product documentation is available on the Oracle Help Center at http://docs.oracle.com/en/industries/hospitality/
Table 1-1 Revision History
1-1
1
Sizing Methodology Overview
Oracle Payment Interface application is typically deployed on-premise to bridge the PMS systems and partner payment service providers (PSPs). It employs a semi-integrated model and works with the partner PSPs to provide credit card processing functionality to Hospitality PMS systems.
Different from the standard OPI deployment model where one instance of OPI is deployed for each hotel property, we will have to consider, in case of deploying one instance of OPI to support multiple hotel properties, the interaction between different IFC8 instances and OPI, as well as the impact from the interaction between OPERA web service and IFC8 controller.
With the careful consideration of all the interactions and potential throughput limit across the interfaces among OPERA web service, IFC8 controller, IFC8 instances and OPI instance, we will currently only support the deployment model of running the following software on the same machine to support using one instance of OPI to support multiple OPERA properties.
1 instance of OPI
Oracle database for OPI 10 instances of IFC8 IFC8 controller
The 10 instances of IFC8 in this case also means that this deployment supports up to 10 hotel properties using one OPI instance.
Chapter 1 Sizing Methodology Overview
Server Sizing Methodology
There are three main components to servers: Central Processing Unit (CPU)
Random Access Memory (RAM) Storage
Each component has factors that determine proper sizing. At a high level, CPU and memory are driven by the number of threads and the type of processing. Storage requirement is driven by data retention length, system configuration resiliency and necessity for speed of access. The price of memory has gone down considerably in the last few years, as per this document, the price of RAM is not a major factor.
In this case, we will need to consider the overall CPU, RAM and storage requirement for running OPI, IFC8 and Oracle DB on the same machine.
Notes on Virtualization
All recommendations put forth herein regarding the resource requirements for hardware are applicable to Virtualized environments as well as physical ones when current Virtualization technologies such as Oracle Virtual box, are used. Current technologies incur no real overhead cost, and therefore do not require separate consideration when choosing resource requirements.
Disk Capacity Sizing
The amount of disk space necessary for this deployment model is driven by the amount of data, backups, and database log files and application log files that would be generated by OPI, IFC8 and Oracle database retained on the drives.
2-1
2
Assumptions
The specification assumes the following:
1. Unless otherwise noted, the machine only installs the standard software that are listed in the software components section, no other irrelevant workload shall be introduced.
2. Best practices are followed for database maintenance.
3. Data purging is implemented to purge transaction data at a pre-defined interval based upon solution requirements.
4. Proper procedures should be established for maintaining the machine where OPI runs to ensure the data that OPI manages is properly protected – for example, a proper backup process is established to protect the data that OPI manages in order to minimize the risks such as loss of authorization and so on due to the loss of the data managed by OPI.
NOTE:
It should be noted that when compared to the normal OPI deployment model where one instance of OPI is deployed for each property, it becomes even more important to have a proper database backup process in place to protect the OPI transactional data in OPI database, as losing the data could
3
Software Components
In case of deploying one instance of OPI to support multiple hotel properties, we will support the model of running the following software in the same machine.
Table 3-1 – Software Components
Software Component Number of instances
OPI software 1
IFC8 10
IFC8 Controller 1
Oracle database (for OPI), 12c/19c 1
Certainly user can optionally choose to set up IFC, OPI and Oracle database on their own separate machines if the hardware cost is not a concern.
4-1
4
Hardware Specifications
The specifications for the machine running OPI, IFC8 and OPERA database is listed below:
Table 4-1 Hardware Specifications
Hardware Specifications OS Windows Server 2012 R2, 2016 or 2019; 64 bit only CPU 4 core Memory 32GB Hard disk 200GB
To ensure that OPI has been given sufficient memory, please make sure to set both the initial JVM memory size (Xms) and maximum JVM memory size (Xmx) to 4096 MB for OPI service application.
5
Transaction Throughput
The maximum credit card transaction throughput can be supported by this deployment model is listed below.
Table 5-1 Transaction Throughput
Total credit card transaction volume 18,000 / hour
Credit card transaction per minute per site (assuming supporting 10 sites)
30 / minute / site
This deployment model is not recommended if the sites are expecting to process more credit card transaction volume than what is listed above.