Event Listeners Delphi <-> Web

[msd 5]

Hello Developers.

 

I have one simple but not so simple in programming way of thinking request.

 

I need to set up some applications with web service for prepaid ticketing sales. 

 

For example, a customer buys a ticket for some services and that ticket is inactive at that moment. After few days customer wants to activate this ticket and use the service that was subject of that ticket (for example, the ticket offers 3 days of free gaming in the gaming center with 5 locations). And after he activates his ticket web server needs to know which ticket was activated and to tell all other clients with some event which will be recognized by all clients at the moment of activating that that ticket is active for 3 days from today at some time. 

 

I plan to build web service which will be the center point of the app, and when operator sells ticket web service register customer data and with some event, which is listened by all Delphi App clients mark that ticket as available for activating on the any Delphi client app. After activating the Delphi app send the number, date, and time of the activated ticket to web service and web service with some event tell all clients that data.

 

I know that this was simple every time users want to use a ticket Delphi app can contact web service, but users need an offline security system, so every client must know everything about tickets...

 

Scenario: User buy a ticket at gaming location 3, operator fill form and with API mark ticket as sold on the web app, user want to activate this ticket after one week in the gaming location 5, user read QR code and send activating request by API to the web app and the main point of this flow is that at this moment web app fire some event which will be available for all Delphi app to mark time and date of the activated ticket in local DB.

 

I need some expert advice 🙂

 

Thanks for all advice, assistance, and help in the advance...

Edited April 9, 2021 by msd

[David Schwartz 426]

This problem reminds me of a system I had to analyze in college for an Information Analysis course that involved a new meal ticketing system being set up in the cafeterias around campus. They wanted people to be able to buy a meal ticket at any of the cafeterias, right there in line. So Joe would buy a ticket, get it scanned, and go in to have lunch; but his buddy Bob would come by just as he was entering and say "Hey, Joe!" and they'd shake hands and the ticket would invisibly move from Joe to Bob. Then Bob would go to another cafeteria and use it again. They knew there was a problem, and some said it was a bug in the software. But that wasn't it. Joe got what he paid for, but Bob got a free meal.

 

This is a very old and common problem involving a state machine that has nothing to do with Delphi, web apps, firing events, QR codes, or how many gaming centers a company may or may not have.

 

And it's not so much a matter of programming as it is recognizing the nature of the problem and the best approach to a solution.

First, I suggest you rewrite the description, leaving out all of the implementation details. They may be causing you confusion. Express it as a list of "current_state -> event -> next_state" rules.

 

Second, refresh your knowledge of protocols and state machines, and review "protocol sequence diagrams" and maybe "state transition diagrams". (There are certainly tools that let you do this, but a pencil and paper are probably much quicker.)

 

Third, go read some of the RFCs for email handling on the internet from back in the 70s and 80s. The internet was literally designed to survive a nuclear attack that took out random data centers, and the data packets (eg, email messages) would still find their way to their destination in a reasonable time-frame. (Results may depend on one's definition of "reasonable".) What you're trying to model here isn't much different than how basic email delivery is managed.

 

Data moving at 150 baud on a dial-up line is pretty damn slow by today's standards; but sending out a 64 byte packet (probably overkill for this) will still make it 10 miles across town way faster than any human can move.

 

Which leads us to the forth and final thing to do: write up the Terms and Conditions that apply to all kinds of tickets and how they can be used in this network. Starting with the misnomer that "customer buys a ticket"  equals "days of free [access]". That's like saying if you buy a bus pass for a week then you get a week of "free rides". No! If you don't have that pass with you and you're caught, it's going to be even MORE expensive than what you already paid, right? (This was the source of the problems with the meal ticketing system I analyzed. They were selling tickets at the door, but the data was entered manually some hours later, but before the next meal. So the tickets could be used any number of times between when they were purchased and when they got entered into the system. They had to change the rules about when tickets could be purchased, and ensure the data was entered into the system before they could be used.)

 

Terminology is important when it comes to design. In this case, the system might actually support "free passes". And if a center is stuffed to the gills with customers who PAID for tickets, you might want to BLOCK those with "free passes" from coming in, or just during certain times. See the distinction?

 

 

Edited April 13, 2021 by David Schwartz