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.
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??
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?