eiConsole for OpenTravel – Booking Service (Demo)
Welcome to the eiConsole OpenTravel Booking Service Demonstration. The eiConsole and the eiConsole for OpenTravel can be used to easily implement OpenTravel compliant messaging to booking services, such as Booking.com. This demonstration will take a look at one example of how that might be accomplished.
The first screen that you see when you open up the eiConsole is the Route File Management window. The Main Route Grid contains one row for each Route. Multiple Routes together make up an interface. In this case, we have three Routes: a Request to the Booking Service, a simulation of the Booking Service, and a Booking Service Response. We’ll double click the Booking Service Request to take a look at how it appears in the Main Route Grid.
The Main Route Grid depicts the flow of data between any defined Source Systems and any defined Targets. Here we have one defined Source System and our Target System (being Booking.com). The developer or business analyst is then required to configure the stages between the Source and the Target. In this example, we’ll be accepting data from a Web Form and using that to place a Booking Service Request.
The Listener stage handles the connectivity to the Source System. Given that we’re accepting information from a Web Portal, we’ve chosen the HTTP Form/POST Listener and provided a Request Path. The Wait for response checkbox indicates that we expect a synchronous response. Form data will be accepted by the Listener and automatically translated to XML.
The next step is then a Source Transformation of that data into the appropriate OpenTravel specific message. The Source Transformation is made up of two stages. First, if the data is not XML already we’ll do a transformation into XML.
However, since the Form data has already been converted to XML by the Listener, we move on directly to the XSLT Configuration stage.
Data transformations in the eiConsole are built largely using the Data Mapper – a best-of-breed, drag-and-drop data transformation tool which sits on top of W3C Standard XSLT. Here you can see our mapping between Web Form data loaded on the left-hand side and the OpenTravel Hotel Availability Request message (OTA_HotelAvailRQ). The values that have been mapped are marked with checkmarks. These mappings were created through simple drag-and-drop. As a result, the inbound HTML Form data is mapped onto an OTA_HotelAvailRQ message with the Forms/checkin and checkout parameters mapped into the StayDateRange and HotelSearchCriteria.
As a result, the inbound HTML Form data is mapped onto an OTA_HotelAvailRQ message with the Forms/checkin and checkout parameters mapped into the StayDateRange and HotelSearchCriteria.
The next step is the Routing stage where we’re routing the data along to all defined Target systems. XPath and attribute-based Routing Rules also allow us to make rules-based routing available.
In our Target Transformation we’re going to further translate the data from our canonical model, the OpenTravel message into the specific requirements of our Target system. Another XSLT generated by the Data Mapper allows us to accomplish this. This time our Source data is the OTA_HotelAvailRQ message. You’ll note that in addition to being able to navigate the message type we have documentation for each field as we click it.
On the right hand side we’ve loaded in the format for an XML RPC message to be sent along to the Booking Service provider.
Finally, we’ve configured an HTTP POST Transport, used for generic Web Services, to post our XML RPC message to our Booking Service.
Returning back to the File Management screen, we can see that we’ve created a Booking Service Route that basically just simulates the behavior of the Booking Service.
One nice feature of the eiConsole is the ability to stub out trading partners so that you can begin to do some integration testing without them. This Booking Service will accept our XML RPC message and translate it back into an OpenTravel response.
The Response message is then passed along to the Booking Service Response Route.
You can see that the Listener here is a programmable Listener. This Listener is invoked by the HTTP Transport that we saw in the Service Route.
The Source Transform in this case goes from our XML RPC Response into our OpenTravel XML message.
Once again you can see we’ve used the Data Mapper to map onto the OpenTravel message, but in this case it’s the Response.
Then the data is routed along toward two Target Systems.
In the first case we’re just dropping a copy of our generated OpenTravel Response in a directory using a Directory Transport.
You’ll see that the Target Transform is set to a relay, meaning it will do not further transformation from the OpenTravel messaging format before dropping the data in the defined output directory.
However, this time we also have a second response. This Target Transform will take the OpenTravel XML response and transform it further into an HTML response to be sent to the initial requestor.
Here we can see the OTA_HotelAvailRS message being mapped onto the XHTML Schema.
This demonstration of the eiConsole and Data Mapper’s ability to create not only machine readable, but human readable, nicely formatted output. Finally, this response is sent back synchronously to the original requestor using the Synchronous Response Transport.
Once we’ve configured each of the Routes we can test them. Returning to the Request Route we can see how we can test individual stages using the eiConsole’s Testing Mode. In this mode the icons between the Source System and the Target System are replaced by question marks indicating a stage of a test that we may or may not choose to run. We can start our test at any point (indicated by a green arrow) and end our test at any point (indicated by a red square).
When we click the Execute Test button the system will begin to listen for information coming in on the defined Web Form.
Here we see the Web Form that will be used to input the data. We’ll fill out the form and click Get Hotels.
You’ll note that when we do that, as each stage completes the question marks turn into check marks and we can view the data as it appeared at each point.
Here we can see our Form data immediately converted into an XML representation.
Next we can see that information mapped onto a simple OTA_HotelAvailRQ message.
We then further transform that into an XML RPC Method Call.
We stopped the test at this point and didn’t execute the subsequent call to the actual Booking Service.
If we’d like to integration test these Routes from end to end we’ll use the local EIP Emulator. The local EIP Emulator emulates the eiPlatform server environment and will run each of the different Routes in our working directory.
This time we’ll check the Using EIP Emulator checkbox to ensure the data gets posted to the correct URL.
This time it will go from end to end to the booking service, back, and generate our HTML response.
All of the logging as it would appear in the server also appears live in our EIP Emulator dialogue.
In summary, we’ve seen how a set of different Routes can be used to construct an interface, both the Request and Response interface from a Booking Service. We saw that interface consists of a number of different stages between a Source and Target system, configured through point-click, drag-and-drop. After configuration, the Testing Mode in the eiPlatform Emulator can be used to integration and unit test your interface. Taken together these capabilities allow you to build better, faster, and more cost-effective solutions to your standards-based integration needs.
Thanks for watching and please download the eiConsole and give it a try.