Suite TPF to TPF Function Server (TTFS) SABRE / TPF Software

Suite Agenda TTFS - OVERVIEW FORWARD OUTBOUND - REQUEST INBOUND - REVERSE TTFS FEATURES SABRE BACKGROUND CURRENT SABRE TESTING ENVIRONMENT PROPOSED SOLUTION – TTFS PROOF OF CONCEPT PROOF OF CONCEPT PLANNING TTFS PROOF OF CONCEPT – CONCLUSIONS CONTACTS

Suite TPF to TPF Function Server (TTFS) Overview -TPF Software- TPF to TPF Function Server (TTFS) Overview -TPF Software-

Suite TTFS Overview Simulates or provides virtual connectivity for systems with no real connectivity. TPF to TPF Function Server Client Server architecture. Acts as switch, uses the routing table or intercept table to manage the message traffic – INBOUND or OUTBOUND.

Suite TTFS Overview Multiple clients connected to Server, can share same connection. (FORWARD OUTBOUND) Server controls the reverse message traffic and routes it to respective Clients. (REVERSE) Intercept tables used to define the rules and message route definitions.

Suite Server Client 1 External System Configuration tables from repository copied to client and server Transaction initiated Check Intercept table for condition If condition is satisfied send the request to Server Server processes the request Response is sent to Client & transaction completes Response to user Multiple Clients can communicate with similar mode zVM Repository Forward Outbound Request

Suite External System TPF Server VPARS Client 1 C1C2C3Dest C1C2C3Dest C1-V1C2-V1C3-V1Client 1 C1C2C3Dest C1-V1C2-V1C3-V1Client 1 ………… C1-VnC2-VnC3-VnClient n C1C2C3Dest C1-V1C2-V1C3-V1Client 1 ………… C1-VnC2-VnC3-VnClient n Condition Table zVM Repository Administrator Configuration tables updated Administrator can UPD config table dynamically Reverse traffic received Check Rules table for condition. If satisfied send to destination Client. Send request to CLNT Receive response from CLNT Reply to external system. Inbound Reverse

Suite Capability to exchange multiple types of ECB data between Client and Server. Configuration Tables used to manage message routing. Management tools for administration of Intercepts in Client/Server. Usage tools to display Message Statistics, Timeouts and Average Response Time etc.. Data logging for administration and debugging purpose. TTFS Features

Suite Background-SABRE-Background-SABRE-

Suite A Communications Gateway Switch provides TPF connectivity to Sabre’s external trading partners Our TPF testing environments currently face the following limitations : Forward Connectivity - A maximum of 8 TPF Test processors (CPUID’s A-H) can connect with the Sabre Communications Gateway to send traffic (forward transactions) to external trading partners. Reverse Connectivity: Unsolicited message traffic coming from external trading partners into the Sabre Communications Gateway is limited to a single end point (TPF Test System) Background

Suite External Trading Partners zTPF-G CERTCCERTD PKGE TSTA TSTB zTPF-FzTPF-H 9 th VPARS not allowed CERTIFICATION INTEGRATION zTPF Communications Gateway UNSOLICITED MSSGS AKA REVERSE HOST TRAFFIC NORMAL TRAFFIC EXCHANGE AKA FORWARD TRAFFIC X X Current Sabre Testing Environment

Suite Proposed Solution - TTFS External Trading Partners zTPF-G CERTCCERTD PKGE zTPF-FzTPF-H 9 th VPARS not allowed UNSOLICITED MSSGS AKA REVERSE HOST TRAFFIC NORMAL TRAFFIC EXCHANGE AKA FORWARD TRAFFIC X X TTFS SERV TTFS CLNT TTFS SERV TTFS CLNT TEST VPARS WITH NO CONNECTIVITY Communications Gateway

Suite Proof-of-Concept-SABRE-Proof-of-Concept-SABRE-

Suite Parties Involved  HP – Middleware SME  TPF Software – Product  Sabre – TSMO List of Intercepts  Program / Macro to intercept  Data to send the other side  Conditions to trap the intercept RPPCC  Sabre Unique Communications API  Extensively used across applications for external access POC Planning

Suite Sabre/HP/TSI conducted a proof-of-concept to evaluate whether TTFS could resolve current connectivity limitations Two different scenarios were utilized:  Scenario 1 - Isolated Test Bed - To avoid any disruption to our test environments and customers, an isolated test bed consisting of three internal VPARS was initially used to demonstrate the TTFS capabilities.  Scenario 2 - PKGE VPARS as the TTFS Server – PKGE which is one of the 8 test systems with actual connectivity to the Communications Gateway was used as the TTFS/Server to further demonstrate whether TTFS could process outbound / inbound messages from / to an external system. Both scenarios included: –Forward Messaging (SYNC & ASYNC) –Reverse Messages (SYNC) Proof of Concept

Suite Client VPARS with No connectivity TTFSTTFS ACPMXA44 ACPMXA43 Communications Gateway User Terminal Client VPARS with No connectivity ACPMXA42 User Terminal Test Host of External Partners TTFS Server (PKGE) TTFSTTFS POC – Forward/Reverse Connectivity Simulation

Suite Forward Connectivity Simulation Main Goal - to demonstrate that: 1.TTFS running on the client VPARS (ACPMXA43 with no connectivity) intercepts the input message coming from the user and sends it to TTFS 2.The TTFS server (ACPMXA44) accepts the request message coming from the TTFS client (ACPMXA43) and sends it to the Communications Gateway 3.The Communications Gateway receives the input request message, sends the request to the external trading partner, receives the response message from the trading partner and routes the response message back to the TTFS server (ACPMXA44) 4.The TTFS Server (ACPMAX44) receives the response message from the Communications Gateway which in turn sends the response message to the TTFS Client completing the request. TTFS Client (No connectivity) TTFSTTFS TTFSTTFS ACPMXA43 TTFS Server - PKGE Communications Gateway User Terminal Test Host of External Partners ACPMXA44

Suite Main Goal - to demonstrate that; 1.TTFS running on the server (ACPMXA44) would intercept the reverse input message coming from the Communications Gateway and forwards it to TTFS running on the client VPARS (ACPMXA43) that has no connectivity 2.TTFS running on the client VPARS (ACPMXA43) receives the message and delivers it to the application for processing and then intercepts the response and sends it back to the TTFS server (ACPMXA44) 3.TTFS running on the server (ACPMXA44) accepts the response message from the client (ACPMXA43) and sends it to the Communications Gateway which responds to the external requestor TTFS Client (No connectivity) TTFSTTFS TTFSTTFS ACPMXA43 TTFS Server - PKGE Communications Gateway User Terminal (Remote Partner) Test Host of External Partners ACPMXA44 Reverse Host Connectivity Simulation

Suite Overall, the TTFS POC objectives were met  Forward Connectivity Simulation Demonstrated –Synchronous and Asynchronous transactions »Including Schedule DisplaysAvailability »Interline Electronic Ticketing (IET) Requests Through Check-in »Pricing were successfully executed.  Reverse Connectivity Simulation Demonstrated –Synchronous and Asynchronous transactions »Originating from an external client that were successfully executed on the client VPARS as if it had a direct connection to the Communications Gateway  Tool features were demonstrated and results considered successful TTFS Proof of Concept - Conclusions

Suite Over time, TTFS can become an intelligent switch to be used in resolving other TPF Test System connectivity issues SABRE approved TTFS product for TPF 4.1 and zTPF  TPF Software to continue installation of the TTFS product in SABRE environment TTFS Proof of Concept - Conclusions

Suite Contact Information Thiru Thirupuvanam TPF Software Inc. (1) Steve Hackler Sabre Holdings (1)