History Of Agency And Sub Agency

Published Date: 02 Nov 2017

Genesis Travel Network is planning to launch a content driven travel portal catering to B2C and B2B markets, which will be selling Hotel, vacation packages, Car Transfer and Sightseeing. The portal is also required to offer airlines,, rail products (Rail Europe and other rail products like Amtrak, JR), cruises in phase II with overall objective to be a platform for global distribution of travel products.

Backed up by travel establishment called ‘Vacations Exotica’, GT’s goal is to dominate the leisure travel business using brick and mortar offices and supported by online portal. GT envisions the portal to be driven by the best technology and content. Further GT would like the portal to be built on a modular manner so that it can start generating revenues as soon as possible along with parallel enhancements. Over a period of time, GT would also like to penetrate in Corporate Travel & MICE Business.

Users

The Travel Management System would be used by employees of Genesis, and users from suppliers and agencies, sub-agencies and travellers.

GT-Functional Overview.png

Users

Description

Employee

(Admin / Call Centre)

The Application portal would be used by Genesis Employees over internet. for the following functions:

Portal setup and Configuration

Product setup,

Defining Contracts

Defining Revenue Model

Accounting,

Manage Bookings and

Call centre support

This portal will act as platform to manage various business components evolved from proposed system, to setup the internal organization processes and to manage the bookings and revenues generated.

The portal will also be used by front office and call centre users to provide the quotes, and generate bookings.

Suppliers

Suppliers of GT will be given corporate account on this portal to manage the rates and inventory provided by them.

This portal will also be used by suppliers to view and act on the bookings of products supplied by them.

Agency & Sub-Agency

B2B portal will be used by travel agents affiliated with GT. This portal will help travel agents to manage their business with GT.

Using this portal travel agent’s will be able to manage their

Organization,

Users,

The B2B portal shall utilize GT’s supplier connectivity framework, thus providing Travel Agencies with following features:

Product Search

Product Quotes

Create/Manage Bookings

Reports

Manage in-person booking requests

Manage contracts with sub-agencies

This portal will be used by Sub agent’s system users mainly to perform

Search,

Quote and

Book products.

The portal will also allow them to manage the booking and financial contacts with agents (B2B).

This portal will not have provision to define mark-ups on products and same will be handled offline.

Travellers

GT will have two categories of walk-in (B2C) customers.

1) Who does the bookings over the counter (OTC) and

2) Are those who will do the bookings online using website of GT.

OTC bookings will be handled by GT staff using Admin-call centre portal. However, online bookings will be done using B2C portal.

Typically the portal will have provision to search, book and manage the bookings of individual B2C customers.

The transactions originating from the B2C portal will be handled in Mid –Office (Call centre).

Modules

Modules can be considered as logical business functions implemented as part of the solution. Each module caters to specific tasks identified to meet a given business function. Solution based upon modular approach provides an architecture that can be extended further for future scalability and integration requirements.

As depicted in the Business Requirements document, the Travel Management System can be divided into following functional modules:

Module

Description

Master Module

This module will take care of setting all the master data such as zones, currencies, payment gateways etc. into the system.

User and Access Module

User management, access management and role management will be managed by user module. This shall be accessed from within the Organization setup module which is explained below.

Organization Setup

This module shall take care of setting up basic organizational structure involving structure, branch locations, contact details etc. for Genesis Travels.

Customer Setup

This module shall take care of setup of each new B2X (B2B or B2C) customer. This shall comprise of customer details such as Customer Type, Trading currency, Branch locations, Grade etc.

Financial Setup

This module shall take care of setting up of all financial details such as taxes, flat mark-up management.

Hotel Product Setup

This module shall be responsible for basic hotel setup including rates, services and inventory.

Package Product Setup

This module shall take care of package product related setup, which includes service package management, itinerary and inventory management.

Sight Seeing Product setup

This module shall take care of sightseeing related product setup.

Transfer Product Setup

This module will take care of transfer related product setup such as Car transfer

Inquiry – Search, pricing and Cart

This module will take care of inquiry/search of products, pricing and cart management.

Booking – Payment

Booking module will take care of bookings, cancellations and payment of products.

Revenue Management

Manages product’s revenue

Rule setup

This module will take care of configuration of various business rules in the system

Following rules will be configured

Pricing Rules

Supplier routing rules

Mark-up Rules

Discount Rules

Product Invoice management

This module will take care of Product invoice management

Payment Gateway

This module will take care of all the payments from customer and users.

Communication

Communication module will take care of sending SMS, emails etc.

Product API integration

This module will take care of integration with other third party API.

Report Module

Contains various statistical reports

Supplier Setup Module

This module shall take care of supplier configuration and setup

Functional Portal

Portal depicts the user interface for the Travel Management system

This application is supposed to be consumed by various groups of end users such as GT staff, Corporate Agents, Suppliers, Travel Agencies and Sub-Agencies. The presentation layer offered by the system for each of these user groups shall be different with respect to the functionality and features.

Module

Description

Admin Portal

This portal shall consist of functionality to administer setups and activations of product, supplier, setting rules, user setup etc.

Travel Agent B2B Portal

This portal shall take care of travel agent related functionality, where agent can work independently once their profile is created.

B2C Portal

This portal will take care of walking users. It consists of user registration and creating their profile, search product, booking of products and manage transactions.

Corporate Portal

This portal will take care of corporate level users.

Supplier Portal

This portal will take care of suppliers. Suppliers can manage their data and setting up rules and pricing setup.

Integrations

Reservation System needs to integrate with various other systems to perform its intended functionality. A brief description of each of the system is as below:

System

Description

Account & Financing System

The Reservation System needs to be integrated with an external accounting system to exchange booking information.

OTA Compatible Services

The Reservation System is required to consume OTA (Open Travel Alliance) compatible services to be integrated with suppliers.

Suppliers can be further classified as Hotelier and other utility supplier, mainly covering sight-seeing and transfer services.

Mostly the system shall integrate with GDS suppliers for hotel, air and ground transports.

XML and Web Services APIs

The reservation system is required to integrate with XML and Web Services APIs over Http.

The integration shall happen over secure channels for data security.

The communication message standards vary across various suppliers and hence integration with every supplier would need an intermediate adapter for request and response message transformations.

Payment Gateway(s)

Reservation system requires integrating with payment gateway for fulfilment of payment from sub-agents and travellers.

Payment done by travel agents needs to be collected in the merchant account of Genesis. So, based on geographical areas multiple payment gateways would be required to be configured, each supporting multiple agents from individual geography.

Communication

Reservation system needs to communicate to users of system using emails and SMSs.

Also order confirmation requires to be confirmed by either email or SMS.

Solution Design

Overall Approach

Outside-In approach

The layered architecture is the basis of modern-day solutions. Identifying various layers of the solution, their structuring and communication pattern is an outcome of the architect’s view of the requirements. The outside-in approach gives prime importance to the end user’s perspective of the solution. The following micro-summary is an architect’s view of the BRS for Genesis travel with the outside-in perspective:

Leisure travel booking experience has to be as exciting as the travel itself. The technology brings this exciting experience for the traveler. Traditionally travel agents play an important role in the leisure travel booking process. GT also has a strong network of around 1000 travel agents. The fact that the travel agent is the first touch point for the traveler, empowering them shall deliver the exciting experience for the traveler. The technology also offers additional channels for the traveler like direct access to the booking web site through a desktop or a mobile device. The solution shall help GT to enrich their reach (B2X) by empowering the travel agents (B2B) as well as giving direct access for travelers (B2C).

GT offers travel booking of one or combination of products like Hotel, Fixed Package, Sightseeing and Vehicle Booking. Leisure traveling is a way of socializing and generally a traveler has a travel period in mind and is interested in getting more information (content) about product that is being booked, its availability (inventory) and the pricing. The solution has to ensure that the right sized product is searched and presented to the end customer through the preferred channel within the best possible response time.

In GT’s business model a travel agent is part of the value chain and shall have its own revenue model. This revenue model allows the travel agent to apply its own pricing rules on top of the pricing offered by GT. The pricing rules consist of the mark-up and discount rules. These rules have different attributes like product, customer, supplier etc.

As an aggregator, GT shall get the content, inventory and the pricing from various suppliers. GT shall apply its own pricing rules before sending the data to the travel agent. The suppliers may provide on-line as well as offline data.

The product based search triggered by the end customer searches the online as well as the huge set of off-line data. The online search is routed to an appropriate supplier. Similar to the pricing rules these routing rules also have attributes like product, customer etc. The result is then aggregated based on the business rules and presented to the end user in a structured manner so that the traveler can take right decision about the booking.

In future, GT may also serve this structured result sets to various other smaller aggregators or travel agents and power their front end tools.

The above description clearly highlights the following facts

         Flexibility of accessibility channel

         Static and Dynamic content

         Dynamic pricing rules

         Dynamic routing rules

         Data aggregation

         Serving the structured result set

         On-line and off-line Data collection from suppliers

The non-functional requirements and these facts help to set the following guidelines of various components of the layered architecture:

         Separation of views and data

         Separation of content and formatting information

         Provision to easily manage the static content

         Exposing the business logic through services

         Separation of rules from the data

         Mechanism to select the content/data provider

         Facility to import and export the data

Architectural Considerations

The overall application can be broken down upon into following logical layers or components:

Presentation Layer (Portal)

Site setup and Configuration components (white labelling, currency setup etc.)

Business Components (Booking Engine, Pricing Engine, Accounts & Invoicing etc.)

Process Orchestration (Messaging, transformation, routing)

Supplier Connectivity Framework components (Routing, Rules Engine, Connectors/Adaptors, Aggregator etc.)

Database Access Components (Data Caching and Access)

Database (offline as well as online Data Storage)

From the architectural standpoint, the following key components have been identified as part of the solution design:

Consumer Applications

Presentation Layer Components/Services

Core Business Components

Rules Engine

Pricing Engine

Booking Engine

Multicurrency

Accounting & Invoicing

Supplier Connectivity Framework

Messaging

Routing

Caching

Adaptors

Transformer

Aggregator

Integration with external sub-systems such as Payment Gateway

The design of each of the above layer within the application shall be governed by certain key considerations based upon functional and non-functional requirements.

As part of middle-out approach, the design team shall focus on the following architectural components in the order mentioned below:

Service Contracts and Message Formats

Service Orchestration and Process Flow

Routing, Pricing, and Aggregation Rules

Supplier Connectivity Framework using ESB platform

Presentation Service components

Database Access Layer

Offline Data Cache for faster product search mechanism

Cross cutting concerns

Presentation User Interface

While the design is guided by above approach, there shall be certain inherent architectural requirements kept in mind such as cross cutting concerns, data persistence and security and following industry standards.

As a practice within BSIL’s architecture and design services, the design shall be based upon best practices and industry standard guidelines.

The High Level Design shall also consider the merits and demerits of potential technology options to build the solution components, to arrive at the most suitable technology stack in order to implement the design.

Technology Options

This section details out various options considered for each critical decision in design, trade-off analysis done for the same, and the reasoning why particular option was selected over others.

Summary

This section provides overview of various design options considered for various areas/section of design. It covers options considered for given area and selected option. Justification/Rational for selected option is been covered in detail in following sections.

Area under discussion

Options considered

Option selected

Architectural Approach

Bespoke web applications

Sophisticated, database-driven websites

Work-flow applications

Artificial intelligence software

Off the shelf product

Different technology to be selected for each logical function within the overall solution, considering the merits and demerits of potential technology candidates.

Integration Platform

Mule ESB

Bespoke Framework

Bespoke Framework

CMS

Drupal,

Bespoke CMS

Drupal

AJAX Framework

jQuery

JavaScript AJAX

jQuery

Number of Tiers

Three Tier

Four Tier

Four Tier

Services

JAX-WS

JAX-RS

Axis2

Apache CXF

JAX-RS

Rules Engine

Drools

Mandarax

OpenRules

JLisa

Bespoke

Bespoke

Data Access Layer

EJB

Hibernate

Hibernate

Auditing

Data Access Layer

Data Access Layer

Authentication (Web)

LDAP

Forms Authentication

Forms Authentication

Authentication(Service)

IP based

IP based

Authentication

(Data Store)

Database Authentication

Database Authentication

Logging

Log4J

Bespoke

Log4J

Data Store

MySQL

SQL Server 2008 R2

Oracle 10g

MySQL

Database Design

Single Database

Multiple Databases (one per Module)

Multiple Databases

Session Management

Database

State Server

Database

Application Design

Architecture

System Architecture

=

Technical Architecture

Layered Logical Architecture

Deployment Diagram

Messaging Architecture

Client sends request to (Servlet) Web service

Web service forwards request to Aggregator EJB component

The Aggregator finds target suppliers for the request based on routing rules (Right now we can hard code these rules). The Aggregator then sends the messages to request queues

Connector MDBs read message from request queue.

Connectors call supplier services and get the response

Connectors send responses to Response Queues

Aggregator reads and merges all responses

Aggregator sends responses back to Servlet

Servlet sends response message to client

Technology Stack

Software

Version

Description

Drupal

6

PHP CMS

PHP

5

User Interface

Apache

6

Web Server

Drupal Authentication and Authorization

Security Framework

Mule

Message Aggregator

Drools

Rules Engine

Bespoke

Rules Engine

Mule Rules

Rules Engine

Hibernate

3.x

Data Access Layer

MySQL

5.5

Database

SMS junction

SMS Gateway

Exchange

Email Gateway

3rd party hosting

Email Gateway

Live2Support.com

Online Chat

Live Person

Online Chat

Tata Communications – Hosted Contact Center

IVR System (Call Centre Integration)

Drishti

IVR System (Call Centre Integration)

Vicidial

IVR System (Call Centre Integration)

CCAvenue

Payment Gateway

IndiaPay

Payment Gateway

Tally

Accounting System

XSLT

Connectors/XML APIs

Web Services

Connectors/XML APIs

XML over HTTP

1.1

XSLT

Web Services/SOAP

1.1

Trans Hotel API Integration

(Provides Hotels, Tours and Transfers)

XML

Hotels Pro API Integration

(XML Request and Response will be used)

XSLT

Hotels Pro API Integration

(XSLT will be used for transformations to and

from API)

XSLT

Tourico API Integration

(Provides APIs for Hotels, Cars, Activities (Sightseeing, excursions etc.))

Use XSLT for transformations

Annexure

Context Diagrams

Admin Context Diagram

GT-AD-Portal Overview Diagram.png

B2B Context Diagram

GT-B2B-Portal Overview Diagram.png

B2B2B Context Diagram

GT-B2B2B-Portal Overview Diagram.png

B2B2C Context Diagram

GT-B2B2C-Portal Overview Diagram.png

B2C Context Diagram

GT-B2C-Portal Overview Diagram.png

Supplier Portal Context Diagram

GT-SUP-Portal Overview Diagram.png

Process Diagrams

RFQ Inquiry Registration Process Diagram

GT-PROS-RFQ enquiry.png

Product Booking Process Diagram

GT-PROS-Product Search & Book.png