Award Travel and integrating the Frequent flier app with the main app

[Bhupesh Arya]

Hi,

I have some doubt on how the frequent flier app will integrate with the main application. How will the Pay for Itinerary UC be implemented when the customer decides to use the award travel.

Do we make an assumption that Frequent Flyer System be used for viewing the account status? How will the Swing client integrate with the Perl/CGI app in this case?

Would definitely apprecite your help.

Thanks
Bhupesh

[David Follow]

Bhupesh,

one idea would be to integrate directly with the database, because all the relevant information (status, amount of points, etc.) should be available in the database. Worst case, make the asumption...just to keep things simple.

D.

[Bhupesh Arya]

thanks david

[Arvind Patel]

I think you can't access the database directly as it would as good as rewriting the FFMS.
I would recommend using a Wrapper for perl/cgi system.

[Suman Ganta]

Yeah.. I think writing a wrapper to the http responses of FFMS would be a better choice. This avoids understanding of the data model of the existing system.

[Parag Bharambe]

If the customer select to pay using mileage account, then pricing itinerary will see if the customer is eligible to be awarded travel based on his mileage account. If yes, then it will reduce the mileage account accordingly, find out taxes and provide the cost of intermarry to the user. This design ensure that Price Itinerary will be used, irrespective of payment using card or using your frequent flyer miles?

Do we need to think about how customer will be awarded his frequent flyer or we can leave it on View Frequent Flyer Miles, which does not take into account how we used the miles in calculating the price of itinerary??

[Nelson Karan]

Originally posted by arvind patel:
I think you can't access the database directly as it would as good as rewriting the FFMS.
I would recommend using a Wrapper for perl/cgi system.

I understand your point, that updating the database directly is a little like rewriting the system. But from another perspective, we can view it as keeping the mileage system intact, while we just "extend" our travel system to be able to update the mileage points. But why would we choose this route?

One thing that I think *must* be considered is transaction processing. Is it possible to do a transaction that consists of: (1) calling remote PERL module API, and (2) updating the travel system database to confirm that payment has been made? If not, we need to find a way to do this, don't we?

[Santiago Urrizola]

I think you can't access the database directly as it would as good as rewriting the FFMS.

Totally agree with that, documentacion say, there is no informacion about the systema, so you must make a reverse ingeniering from the database, with some times, very bad results.

This design ensure that Price Itinerary will be used, irrespective of payment using card or using your frequent flyer miles?

I thinks yes, think in system extensibility (more payment methods in a future).

How will the Swing client integrate with the Perl/CGI app in this case?

Wy rich client application for agents, should be diferent than web application for customers ?

Is it possible to do a transaction that consists of: (1) calling remote PERL module API, and (2) updating the travel system database to confirm that payment has been made?

Yes wy not ... conatiner transactions or you muest implement some manual commit and rollback mechanism.

[ July 17, 2006: Message edited by: Santiago Urrizola ]
[ July 17, 2006: Message edited by: Santiago Urrizola ]