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>
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>
Originally posted by Jonathan Gerrish:
My thoughts and questions, would appreciate your comments, Cheers, Jon:-
1) In the airline industry Milage credit _always_ takes place when the flight departs. Probably FBN has some back end process that credits milage on flown segments to the customers milage account. Therefore we don't need to consider milage credit.
Originally posted by Jonathan Gerrish:
2) The requirements do not detail the FFMS functionality at all. Its HTML/CGI but is it publically visible? ie: do users have to log in. OR, is it internal only and travel agents just input the Frequent Flyer number to access the account. It seems to me there would have to be at least two bits of functionality. i) get/show account, ii) Redeem milage from account plus user login, if its a public site.
3) The booking with milage redemption alternative use case _must_ be an atomic action, so milage should not be redeemed when the flight fails to book, also the flight can't book but milage is not redeemed. This implies the use of transactions. However I am guessing that its not possible to roll back milage redeption (should the actual booking fail), so perhaps it would need to log this error for the attention of a supervisor to manually correct.
Originally posted by Jatin Sutaria:
Event then, this back-end process should have been run on legacy FBN's ImS database and subsequently updated FMS's Oracle database. On still need to assume such a similar back-end process that reads the new FBN's system d/b and updates FMS's d/b(?).
Originally posted by Jatin Sutaria:
If it is an atomic action, it should have been an atomic action for the legacy FBN system with IMS d/b as well. I am still struggling to find out how it could have been atomic for legacy FBN system? As per requirement ,travel agent has to keep custoemr on hold ang go to a shared computer to retrieve customer mileage status. If FBN travel agents with their 3270 terminal do not have access to this system, how would it be possible for above to be an atomic action in legacy FBN system?
Originally posted by Jonathan Gerrish:
Jatin, Hi...
Its atomic in the sense that the travel agent ensures that either both actions succeed, or both actions fail. Error conditions are not explicitly defined in the usecases. ie: what happens to the booking if the loyalty system is down. But you could expect that a travel agent would handle the error condition better than leaving either one of the systems in an inconsitent state?
Has anyone had good scores without the use of transactions, and what level of error handling have you guys assumed? What functionality have you assumed that the milage system provides?
Cheers, Jon
Originally posted by Jatin Sutaria:
To keep it atomic, one may need to have a component that can update both the databases at the same time. Since, such a component would not have been possible in legacy FBN system, one can presume that legacy FBN may have used some other way out. More or less this should be the way the new FBN system should adopt, since re-usability of FMS looks to be an important requirement.
Since We say accruing mileages is the responsiibility of a backend process, one option can be to have a 'Mileage' kinda table in FBN and assume another such backend process that can map FMS system with this table(read from FMS...write into this table). So, you can have an atomic transaction woring now on the same database. Problem could be data in 'Mileage' table would not have most updated data and extent of stale data may depend upon the frequency of this backend process. What do you think of this?
Jatin
Originally posted by Jonathan Gerrish:
Hi,
Yes, I agree, I think we can assume the legacy system would not have been able to access the FMS database. The requirements don't state whether there is some backend process to credit milage, or if its a manual task for travel agents, as you say there must have been some other way out, not detailed in the requirements. As such I think this is beyond the scope of the project.
Originally posted by Jonathan Gerrish:
My main issue is surrounding the redeption of milage.
Originally posted by Jonathan Gerrish:
We would only want to show the Milage Redeption option on the payment screen if the user has a loyalty account, and has sufficient milage allowance to make a redemption. Then if they chose that option we'd attempt to redeem the milage. This to me implies an interface to the milage system like this:-
Interface LoyaltySystem {
boolean isRedemptionPossibleForItinerary(Itinerary it);
void redeemMilageForItinerary(Itinerary it)
}
My worries were around what happens if either of the systems fail at the redemption.... any thoughts?
Thanks, Jon
Originally posted by Jonathan Gerrish:
Hi Jatin,
Agreed. FMS implementation must not be changed. We must assume some kind of interface for loading credited milage into the loyalty system, I think your ideas for reengineering are definately sound ones.
What I am not certain of, is whether defining the mechanism for crediting loyalty points is within the scope of this assignment. We know that somewhere in the system as a whole, this process must happen, but within the context of the assignment, there are no use cases, neither textual references to any process for crediting milage.
One thing that is important to me is to control scope creep. As I said before, I am interested in satisfying the requirements, no more, no less.
Originally posted by Jonathan Gerrish:
[QB}
I think it seems to be somthing we acknowledge would happen, but we do not include it in the design.
[/QB]
Originally posted by Jonathan Gerrish:
[QB}
Do you think this is a component that the examiners would be looking for in our solutions?
[/QB]
Originally posted by Jonathan Gerrish:
[QB}
1) How would you consider the interface for the FMS? ie: what CGI scripts could be available (ShowMilage / RedeemMilage - ie: use milage to pay for flight).
2) Should we consider error conditions, eg: what happens if either milageRedemption or Booking fail?
[/QB]
Originally posted by Jonathan Gerrish:
There is also the issue that the user could book two itineraries in quick succession using the same set of mileage, if the back end processes are not quick enough. I'll make a note of this in my document.
Cheers, Jon.
Live a little! The night is young! And we have umbrellas in our drinks! This umbrella has a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|