This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Award Travel and integrating the Frequent flier app with the main app Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Award Travel and integrating the Frequent flier app with the main app" Watch "Award Travel and integrating the Frequent flier app with the main app" New topic
Author

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

Bhupesh Arya
Greenhorn

Joined: Jul 25, 2005
Posts: 9
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
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
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.


SCJP, SCEA
Bhupesh Arya
Greenhorn

Joined: Jul 25, 2005
Posts: 9
thanks david
Arvind Patel
Greenhorn

Joined: Nov 28, 2005
Posts: 23
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.


Arvind.<br />SCJP, SCWCD, SCBCD, SCDJWS, SCEA
Suman Ganta
Greenhorn

Joined: Jul 24, 2005
Posts: 18
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
Ranch Hand

Joined: Jan 12, 2006
Posts: 57
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
Greenhorn

Joined: Jul 13, 2006
Posts: 11
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
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
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 ]

Santiago Urrizola : La Plata - Argentina<br />SCEA (89%-92%)<br /><a href="http://gpitech.wordpress.com/" target="_blank" rel="nofollow">http://gpitech.wordpress.com/</a>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Award Travel and integrating the Frequent flier app with the main app