T PF to T PF F unction S erver (TTFS)

www.tpfsoftware.comSuite

TPF to TPF Function Server

(TTFS)

TPF to TPF Function Server

(TTFS)

SABRE / TPF Software


AgendaAgenda

• 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


TPF to TPF Function Server (TTFS)

Overview-TPF Software-

TPF to TPF Function Server (TTFS)

Overview-TPF Software-


TTFS OverviewTTFS 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.


TTFS OverviewTTFS 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.


Server

Client 1

External

System

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


External System

External System

TPF Server

VPARS Client

1

C1 C2 C3 DestC1 C2 C3 DestC1-V1 C2-V1 C3-V1 Client 1

C1 C2 C3 DestC1-V1 C2-V1 C3-V1 Client 1

… … … …

C1-Vn C2-Vn C3-Vn Client n

C1 C2 C3 DestC1-V1 C2-V1 C3-V1 Client 1

… … … …

C1-Vn C2-Vn C3-Vn Client 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


• 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


Background-SABRE-

Background-SABRE-


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)

BackgroundBackground


External Trading Partners

zTPF-GCERTC CERTD PKGE TSTA TSTB zTPF-F zTPF-H

9th VPARS not allowed

CERTIFICATION INTEGRATION zTPF

CommunicationsGateway

UNSOLICITED MSSGSAKA REVERSE HOST TRAFFIC

NORMAL TRAFFIC EXCHANGE AKA FORWARD TRAFFIC

XX

Current Sabre Testing Environment

Current Sabre Testing Environment


Proposed Solution - TTFSProposed Solution - TTFSExternal Trading Partners

zTPF-GCERTC CERTD PKGE zTPF-F zTPF-H

9th VPARS not allowed

UNSOLICITED MSSGSAKA REVERSE HOST TRAFFIC

NORMAL TRAFFIC EXCHANGE AKA FORWARD TRAFFIC

XX

TTFS SERV

TTFS CLNT

TTFS SERV

TTFS CLNT TTFS CLNT TTFS CLNT

TEST VPARS WITH NO CONNECTIVITY

CommunicationsGateway


Proof-of-Concept-SABRE-

Proof-of-Concept-SABRE-


• 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


• 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


Client VPARS with No connectivity

TTFS

ACPMXA44

ACPMXA43

Communications Gateway

User Terminal

Client VPARS with No connectivity

ACPMXA42

User Terminal

Test Host of Externa

l Partner

s

Test Host of Externa

l Partner

sTTFS Server(PKGE)

TTFS

POC – Forward/Reverse Connectivity Simulation


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 TTFS2. 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)

TTFS

TTFS

ACPMXA43

TTFS Server - PKGE


User Terminal

Test Host of

External Partners

Test Host of

External Partners

ACPMXA44


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)

TTFS

TTFS

ACPMXA43

TTFS Server - PKGE


User Terminal(Remote Partner)

Test Host of

External Partners

Test Host of

External Partners

ACPMXA44

Reverse Host Connectivity Simulation


• Overall, the TTFS POC objectives were met Forward Connectivity Simulation Demonstrated

– Synchronous and Asynchronous transactions» Including Schedule Displays Availability» 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


• 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


Contact Information

Thiru ThirupuvanamTPF Software Inc.

[email protected](1) 919-676-5501

http://tpfsoftware.com

Steve HacklerSabre Holdings

[email protected](1) 682-605-1716

http://sabre.com

mailto:[email protected]



Documents

T PF to T PF F unction S erver (TTFS)