iQrailway: on the right track for smart transportation with SAP Hybris (part 2 of 2)


In the first part of this blog post, I started detailing our approach to real-time integration when it comes to the three major domains common for all transportation systems: Search, pricing and reservations. Now let’s take a closer look at pricing and journey planning.


In the world of retail, pricing is typically done by defining the price list. You basically need to configure a price for each particular product and/or his variants. This is achieved in Hybris by PriceRows.

In the world of transportation however, it’s not that simple anymore. First of all, you need to ask yourself what the PRODUCT really is in this context. Is it a fare? A physical ticket? And what does such a ticket represent?


Of course, it represents a journey from point A to point B on a certain date, which may involve one train, or multiple connecting trains. Typically, such a ticket is valid also for X number of passengers which might be of different categories (adults, children, seniors etc).

Needless to say, for even medium size railway networks, number of possible combinations of routes is astronomical. Now try to define price list for that…

We decided that in our solution pricing will be dynamic. You definitely don’t want to configure PriceRow for each possible journey, nor for each possible leg of such journey. In transportation, price is usually built from some price components that relates to factors like travelled distance, type of vehicle (high speed trains are more expensive than regio), time left to departure, number of still available seats, rail card, type of passenger etc.

That’s why we’ve implemented a rule-based pricing engine that computes prices for multiple fare offers in real-time. So, for example instead of configuring a gazillion of PriceRows for each connection, you can configure price per kilometer, or per distance interval and then add on top of it a complementary fee for the high-speed trains. You can think of price dependent on the time left until departure or on number of still available seats, so what about different prices at peak hours? Passenger discounts? All is possible with the right set of rules.


Journey Planner (Searching)

In the world of retail, search is usually done by a document-based search engine like elasticsearch or solr, which typically has Apache Lucene underneath. In such a setup, all available products together with their attributes are represented by documents stored in the index.

In the transportation context, such approach doesn’t make much sense. In order to index all available “products”, you would need to compute or configure all possible combinations of available journeys in time. What you really need to do here is to not only find optimal paths of going from point A to point B, but also to take into consideration the time dimension: the Timetable (as the available connections are different in different moments of time).

What you need is a Journey Planner that uses in-memory graph and timetable to search though a large number of paths. And here again due to our loosely coupled architecture, we have the freedom to use search engine of our choice.




What I shared here with you is just the tip of an iceberg, basics that enable further development. There is much more we want to achieve with iQrailway. The world is moving really fast nowadays – AI, machine learning, blockchain, bitcoin, IoT, hyperloop – to name just a few technologies that may have a big impact on how we live and, hopefully, how we travel.
That’s why we develop iQrailway: to have a robust foundation that enables transportation industry to innovate quickly and deliver the best-in-class experience to all of us.

You can be the first one to comment on this story.

Leave a Reply

Your email address will not be published. Required fields are marked *