Teknokraaft gets registered with NDC!

New Distribution Capability (NDC) is an initiative spearheaded by IATA which is focused on helping Airlines to distribute rich and comparative content including ancillaries to users.

The concept behind NDC is an XML messaging standard designed to be easier and more flexible than the existing standards.

NDC benefits the airlines, giving them the capability to display their range of products and services in a useful and straightforward way. The end customer benefits with a more transparent booking process so they can make informed decisions about what each airline offers and who they decide to travel with.

NDC provides 3 levels of certifications and it is left to the technology provider to get certified in one of these levels.

According to IATA, more than 50 airlines were using some form of NDC as of early January, and another 50 were expected to come on-board in the near term. GDSs, technology providers and even agencies are also being certified to send and receive NDC messages.

Teknokraaft has taken the 1st step forward in aligning with NDC and has got registered as “XML Capable” with them. This is a clear recognition for our capability to adapt to new technologies and give our clients the best of the future.

Our name is now registered with the official NDC registry and you can check it here under XML capable at http://www.iata.org/whatwedo/airline-distribution/ndc/Pages/registry.aspx

We will be updating you about the progress we make with NDC in the coming days

Web Services

Web service is a web application that can be accessed over internet through web API. API is used for application to application communication. Web services uses XML and standard web protocols to communicate through internet.

Web services use numerous different protocols for the exchange of data. One of the protocols is SOAP (Simple object accessible protocol). HTTP (Hyper Text Transfer Protocol) is the most popular option for service transport. Most firewalls allow HTTP traffic. When all major platforms can access the Web using Web browsers, different platforms can interact. Any web service hosted on windows can also be consumed by UNIX and Linux platform. For these platforms to work together, Web-applications were developed. Web-applications are simple applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform.

Consumers of a Web Service need not know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).

Features:

• Platform independent (They can be deployed in any platform).
• Language independent (They can be consumed using any technology).
• Interoperable.
• Reusable application components.
• Rapid development

Web services platform elements:

• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)
• DISCO

SOAP (Simple Object Access Protocol)

SOAP is an XML based communication protocol to exchange data between computers. SOAP is platform independent so that it can go around firewalls.

WSDL (Web Services Description Language)

WSDL exposes the structure of the Web Service. It is used to locate a web service which is based on XML and describes how to access them. WSDL also describes the methods and properties that the service supports, the data type it supports and the supported protocols.

UDDI (Universal Description, Discovery and Integration)

UDDI is a directory where web services can be registered and find existing web services. It acts as a public registry where we can publish and search Web service. It uses WSDL to describe interfaces to web services.

DISCO stands for Discovery.

It basically groups common services together on a server and provides the links to the schema documents of the services that it describes.

Hope you have a basic idea about Web services now.

The curious case of Look to Book Ratio!

When you start discussing with your suppliers, or while going through their agreement you would have stumbled upon this phrase for sure - Look to Book ratio (L2B). Ever wondered what that is? Here is the definition as per Travel Industry Dictionary - Look-to-book ratio. The number of people who visit a travel agency or agency web site, compared to the number who actually make a purchase. (http://www.travel-industry-dictionary.com)

GDS usually set down a L2B limit for you. Let us say you have a L2B of 250:1. What does that mean? Before that a bit of background. Traditionally GDS does not charge you for the queries you send or the hits you make to their server using the conventional blue screen. When it comes to Web based connectivity, GDS charge you for a hit. This could be due to the fact that the conventional screen requires a trained person to work on it whereas the web based system can be used by anyone who has a basic knowledge of travel industry. This could mean more hits than usual and could be a load on the GDS server and infrastructure. To avoid this or to limit this they bring in this term called as L2B. So if we take the case with L2B of 250:1 it simply means that you can look 250 times but should make 1 booking at least. You can send 250 queries to the server and this could be on availability, schedules, fares etc with multiple options, (carriers, time bands etc) but if you have made 1 booking then the GDS won't charge you for the same. For every hit or query that you take more than 250 to complete the booking, you are charged extra per hit. Even if this is something like 0.02 $ etc, for a large agency this could be a big amount at the end of a month if it is not managed properly.

GDS has varying levels of L2B also. There are different commands that you can use to get Availability, Schedules or Fares individually. These are considered to be relatively light queries and you may be given a L2B like 1000:1 whereas heavy queries like a Power Shopper or Super Best Buy or Master Pricer (as per your GDS) which combines Availability, Schedules and Fares will be charged at 250:1.

This means that wherever possible you should be using light queries to achieve your goal and use heavy queries only when the situation demands it. This is where an experienced Travel Technology company can help you in controlling your ongoing costs. We have seen many times Travel technology companies claiming for faster response, better results etc and Travel Agencies going ahead with them, but then burning their fingers when they see their quarterly bills from GDS. It makes sense to ask these questions on what kind of queries are used to get the results and how they affect your bottom line etc. Clarity is needed from both your GDS and your Travel technology partner too. You should not be afraid to ask these questions and we have seen that many times GDS revise their L2B to agents who ask for it. At the end of the day a L2B of 500:1 is always better than 250:1.

We are sure you will not disagree on that.

Testing strategies for an Online Travel Application

Here are some ideas about how to go about when you need to test a Travel Portal or an OTA.

Techniques we use
Basically OTAs are built with an idea of a multi/ n-Tier structure. This means there are several layers needed to build an OTA and so we think of a multi layered testing approach that will include

1. Provider Testing
1. Testing the linkage between the provider and the application
2. Message testing
1. Testing the XML request and response
3. 
   Functional testing
1. Unit testing
2. Integration testing
3. System testing
4. Expected and Unexpected scenarios
4. Security Testing
1. Error handling
2. Directories Exposed
3. Forbidden Resource
4. Not Used Resource
5. Encrypt Secured data’s
5. Retesting /Regression testing
6. Load / Performance testing
1. Usage Pattern
2. Critical scenarios

Error Prevention

Other than the above, for the entire life cycle we combine some error prevention features like

• Isolating the cause of error
• Locate the point in production environment that causes error
• Keep monitoring for continuous  improvement

Risks
There are so many risk factors while doing a migration test to live / production environment

• Mismatch of data, values, types etc
• Schema changes
• Scenario  changes

Challenges

• Difference in Work flow for each supplier and each vertical
• Difference in  expected values in test and production environment 
• Rapid changes in scenarios  based on market needs
• Response time

Hope you can keep these points in mind and see to it that you roll out a well-tested Travel application.

Happy testing and all the success!

Where do you host your OTA?

There are 2 main choices here.

You can either host your OTA inhouse. That is in your own office. This is possible as long as you are having a decent server class machine with adequate bandwidth, power backup and most importantly a person qualified and experienced to take care of the system. We have seen that either one of these factors would be missing and due to this the experiment fails. Keep in mind that the system when it is live is exposed to live users and frequent down times could be irritating to users and could be enough reason for them to walk away.

The 2nd option here is to host it in a web farm. In India we now have lot of options with major players providing world class services to you. Notable among them are Reliance, Bharti, VSNL, Net4India, Sify and many others. All of these providers now have the best in breed of infrastructure and has very competitive pricing in place. It would be sensible to check with 3 or 4 providers before you choose one. Most of these companies also give you the option to visit their premises so that you can see their infrastructure. This is indeed a good option and will give you the necessary confidence to hand over your precious server to a 3rd party.

When you think of hosting there is also the option of hosting your portal on a server based in US or Europe. The point to keep in mind here is the hosting services from US or Europe companies are not that costly now and you have a lot of options to start with a lower package and upgrade to a higher one as your portal usage increases. Do some Googling and you will come across many players outside India with attractive offers. Do confirm whether their service is as good as they claim to be. Check out their online support system by asking some questions and see how they respond. Ask for references. This is always a great thing to do -be it with foreign or Indian hosting companies.

There is also the option of the co-location servers where you can keep your server in the web farm and use their infrastructure. This is like taking your server to their site and placing it there and using their power, internet connectivity etc. You only pay for their services and you get the option for taking the service of their Hardware Engineer too.

So as you can see the options are many. The choice will come down to your budgets, estimates on traffic/transactions etc. Read, check around and make a wise decision.

OTA - How do we proceed?

We think this is one topic that many people are not that much aware of. Most people feel that if you have a normal account with a supplier, you can go ahead and start building an OTA. This is not right.


Suppliers have 2 modes of connectivity. One is the conventional model which we term as the Blue screen. This is the approach where you type in your commands and you get the results in cryptic mode. This is usually offered as free to travel agents (in India at least). Agents who have this connection should contact their supplier GDS and ask for a Web Service or XML connectivity. The supplier will provide you with 2 agreements, one for the agent to sign and the other for the IT Development provider to sign. There could also be a sign up fees associated with this. (We have seen that this can be waived off depending on the relationship that the agent has with the supplier)


Once the paperwork is over you are provided with a Test credential to login to the Test server of the supplier, the documentations for the XML/Web Services and also your unique identity in the web world. Some suppliers also ask for your work flow details and also about the transaction volume you expect etc. The supplier needs this info to see whether they need to ramp up their side of the infrastructure etc.


You can now start working on the test server. The test server as the name indicates is a server holding test data and so the authenticity of the results may not be 100% and the speed of response may be a bit slow too. You can try out different commands etc with the test server for getting your work flow right and can take the assistance from the documents the supplier provided and also their IT team to complete your development. Normally it will take 2-3 months for a full- fledged GDS integration to be completed and if it is only limited functionality then it could be faster too.


Once you are ready with your work, you can contact the supplier and inform that you are ready to go live. The supplier will go through a process called as certification. This will involve going through your code to see if they can suggest better options, looking at your work flow diagrams, conducting a profiling of the application etc. once they are convinced they will allow you to go live and issue you with a login credentials to their live server. From then onwards you would be hitting their live server and you are fully live.

Why do you need an OTA?

Well this is one of the frequent questions that we have to answer with clients. Rather this should be rephrased as " Do I need an OTA? " The obvious answer is “Yes”. But then I always advise our clients to think about this one more time and let us know whether

1. They need an OTA to channel their existing and future business? or
2. They need an OTA as all others are having one?

The choice made above determines what kind of an OTA you need. If your choice is 2nd then I would sincerely suggest you to not invest much time in this and take up some white label solution of an existing OTA and put your logo into it and put it on your website. Your customers will see that you "also have" an OTA and will appreciate you for that. Your business will as usual happen over the counter and in the present manner

If your choice was no: 1 then you should be serious in how to move forward, selecting your supplier, selecting your Technology partner, selecting your server hosting company etc. You are investing for the future and you better get it right.

You also need to be patient and have a realistic time frame of when your product will roll out. It is always better to come out with a tried and tested product in the market rather than rush through something and then answer all your client calls. Keep in mind that you are working with customers’ travel itineraries and their transactions and so be careful on how you proceed.

The one other point to be kept in mind is that there is always a host of factors in play for an OTA to work and so do not jump into conclusions when something goes wrong. You are dependent on your supplier content, your internet connection, your server performance, your own system performance and not to mention the guy who is using it.

You also need to have a good relationship with your technology team as you will need their regular support in tweaking the product and enhancing it with supplier patches etc. You will have cases of Flights missing, fares not appearing etc. A regular support from the IT team is a must for the successful working of an OTA.

Hope you have some idea about the basics of going in for an OTA by now.

To be continued...