(eLATAM) Session Manager
(eLATAM) Session Manager
To achieve this, the current implementation of LATAM session manager will be used as a case study,
identifying the main features and functionalities of the component. An architecture vision of the solution
and sequence diagrams will also be delivered for this purpose.
Página 4 de 10
2. Session Manager Architecture
2.1. Business Context
Since applications all over the world require access to PSS to be able to offer Airline’s Products and Services,
a secure and efficient access mechanism is required, capable to operate over the network.
For this purpose SABRE handles security sessions and the apps are responsible to create and release of
sessions through Web Services to have access to SABRE Web Services. To obtain a session is a bottleneck
because of cost, latency and time.
This approach is a SABRE recommendation and there's no out of the box solution available for customers.
See the link below for more details about SABRE session manager recommendations.
https://www.sabretravelnetwork.com/files/ttx/2013%20TTX%20Sabre%20Web%20Services%20Advanced%
20Practices.pdf Replace this with the Dev Studio link for consistent branding
Every SP has resources allocated in SABRE to process transactions under a resource pool (RP) definition.
Based on LATAM experience and best practices over the years ideally there is a one to one relationship
between RP and Apps but also are possible grouping apps by criticality level or other concepts. The balance
allows us to have a fine grained administration, and quick diagnosis of issues. Keep in mind that more RP
requires more administrative tasks to handle.
2.4. Architecture
Since 2010 LATAM has been working on a Service Oriented Architecture (SOA) to access to SABRE in order to
simplify PSS access reducing development time and cost through webservice reutilization.
Application: Business apps that requires access to SABRE. The apps only send a request to a specific
custom webservice.
LDAP: Provides first level of authentication for custom web services through HTTP basic
authentication.
Web Service Layer: Custom web services that orchestrate SABRE web services in order to accomplish
business needs.
Session Manager: Software that handle security sessions to access to SABRE. Apps provide a specific
app name that SM mapping to SP. SM has the capability to handle sessions in a stateless or stateful mode.
SABRE: SABRE web services layer. Web services could be out of the box or sabre commands.
Note that apps, webservice layer and SM are running on premise in the same network reducing latency
when an app sends a request to a specific webservice.
The figure 2 represents SM Logic Architecture. The core of the SM is running over a single server with fault
tolerance mechanism. SM implements a request to out of the box Sabre Web services to create
(SessionCreateRQ), close (SessionCloseRQ) and validate sessions (SessionValidateRQ) and store sessions for
every session pool on hashmaps.
The session pool configurations are fetching from database and an Administrator GUI is provided for data
maintenance.
SM Web services are exposed on an internal ESB for governance purposes and control access from Apps.
Figure 2. SM Logic Architecture
Each session create request must include the ‘returnContextID=”true” element. See Sabre Dev
Studio - Create Session for an example.
Context Changes must be performed using ContextChangeLLSRQ (i.e., not via
SabreCommandLLSRQ).
Following each successful ContextChangeLLSRQ: the application must stop all use of the security
token that was sent on the context change request, and send all subsequent web services
requests using the new security token that was returned in the context change response.
Data Model:
PSS Agnostic:
Security:
Configuration Administrator: