Must persist unpaid itineraries

[Saha Kumar]

Hello all,

I hope this thread does not violate any rules, but here goes my question.

I was planning on persisting only paid itineraries. Looking more deeply into the Pay for Itinerary UC, I no longer think this is possible.

In the Pay for Itinerary UC alternate flow, a list of itineraries is presented to the user after he has logged in. Question: how can this list of itineraries exist? Look at the Prepare Itinerary UC...an itinerary cannot be defined until the user logs in. This is because the prepare UC calls the pricing UC to price an itinerary. Now the price UC demands that the user be logged in.

I'm interested to know how others have gotten around this.

Thank you for your responses.

-Saha

[Saha Kumar]

I am thinking that the requirements would be violated if we do not save the unpaid itineraries.

Please tell how the Payment alternative flow UC could be fulfilled if we do not save unpaid itineraries.

Anybody ?

-Saha

[Parag Bharambe]

I think there are two Itinearies one is departure itineary (destination to arrival) and from arrival to departure (arrival). So when user log in he may be shown all unpaid itinearies.

I think it is not a good idea to save an itineary, because saving the itineary will not add great deal of benefits to a system. FLight selection s all dependenet on availability of seats. And seats availability is very dynamic.

Even if we assume that Itineary is saved today and you log in tomorror or after 10 hours, the saved itineary has not meaning because seats might not be available.

I believe that unpaid Itinearies need not be saved.


Any thoughts?
Parag

[Anderson Fonseca]

I thinking save a BookFlight where exist an association with a itinerary, a payment and seats associated a flight, cause an itinerary can have many flight associated a one segment, thus for each segment can be a diferent seat.

[s khosa]

I think the solution lies in what sites like amazon.com do. Your unpaid itenaries are just like items in your shopping cart. Suppose i add 4 books to my shopping cart and feel lazy enough not to pay for them today. When i log back in couple of days later, i DO expect to see these items in my shopping cart. So Persistence is needed 100%.

BUT the big catch is whatif the amazon has run out of these books in the inventory within last 4 days. So we might need to make some assumptions here.

- either we recheck the avalaible stock of books when user is selecting a particular book for payment.
- or we let user pay for the books, only to revert back to them later with an email saying book is out of stock.

This is typical of real time transaction processing systems. eventhough expectation is that any point all end user transaction data should be live, but business or real life usage scenario also mandate that we are forced that snap shot of data and store it with regards to a particular user session, and then sync it up with real time data at a later stage based on user interaction.

Hope this helps.

I agree with Saha regarding persisting the unpaid itenaries.

Thanks

[Saha Kumar]

Hello all,

Thank you for the good responses. I feel after reading the change itinerary UC and the pay itinerary UC that the requirements are such that we should persist unpaid itineraries. I like, others, have changed my mind back and forth. My latest plan (and possibly last) is to persist unpaid, but in a shopping cart like table (not with paid itineraries). As they pay for itineraries they should be deleted from the persisted shopping cart. My problem with this is: will the travel agent payment response take longer than 5 seconds with the extra db delete? Also, there would be a software process run everyday to clean up shopping carts.

Any thoughts on this latest idea?

Again, thanks for the very good responses and support.

-Saha

[Jesse Jesse]

Hi Saha

I spent a bit of time beating myself up over this. My current thinking is to save unpaid Itinerary�s. Given that the requirements really suck as u know u need to assume stuff either way - in the case of saved unpaid itineraries recheck flight availability etc.

A factor in my end decision, is that the system seems to imply asynchronous credit card processing (through the use of email etc) so it would make sense to save the itinerary beforehand. Also the transmaster API does not show support for issuing credit card refunds so should we let the user change paid itineraries

Anyhow let me know what you think.

Regards

[Saha Kumar]

Hi Jesse

I'm only providing unpaid itineraries to be changed. This seems the practical solution and doesn't violate the requirements. Reimbursement is not an issue this way.

As far as payment itinerary, the email is asynchronous, but the credit card authorization is not (see basic flow). Thanks for the tip though...I'm thinking of persisting the itinerary asynchronously if the credit card is authorized. This will help meet the 5 second requirement. Thanks for settling this worry for me.

-Saha

[Saha Kumar]

All,

Is anyone planning on using JMS in their design? (JMS is not supported by EJB 1.1...correct?)

Thanks.

-Saha

[Abhijeet]

Hi Saha,

I just started working on assignment. I'm in initial phase of sedigning.
But I'm planning to use JMS to send email notification upon payment.


--------------------
Abhijeet Kenjale
SCJP, SCBCd, SCEA-I

[s khosa]

You can assume that you have an SMTP mail client running on your server and send an notification email. The simpler, the better. Can use JMS also, but for sending a simple email, JMS would be overkill.

Thanks

[Vinay Singh]

Well its not that we are violating the requirements by not saving unpaid itineraries. There are people who have passed with very good marks and they have not saved the unpaid itinerary.
But I am saving unpaid itinerary. If you look at boooking mechanism of some of the airlines,they allow you to save an itinerary and then pay within next 48-72 hrs.(South African airlines).
My thinking on this-
If flight has 10 seats for eg and these seats have been booked today, the next customer when books the seat for him flight would be considered full and would be put in wait list.
And if he does not pay within next 48-72 hrs , this data would be deleted.
So there would be a class to track the seats booked and the status of same.
So a customer when logs in next time he can see both his paid or unapid itinerary.