On May 21, 2008, at 2:35 PM, <suppressed> wrote: >> -----Original Message----- >> From: suppressed [mailto:interchange- >> suppressed On Behalf Of Bill Carr >> Sent: woensdag 21 mei 2008 16:19 >> To: suppressed >> Subject: Re: [ic] Order Route Question >> >> >> On May 21, 2008, at 9:07 AM, suppressed wrote: >> >>> Bill Carr writes: >>> >>>> Does each order route have to complete before the client sees the >>>> receipt page? I am adding a route that posts the order information >> to >>>> an external POS system via a web gateway. Posting the order is slow >>>> and I do not want to annoy the consumer. I would like to post the >>>> orders to the third party system "as they happen" but I don't want >> to >>>> slow down the checkout process from the end user's perspective. >>>> >>>> Using the IC order Route system seems like a neat and clean way to >>>> handle this. I could always just put the code on the receipt page. >>>> I'm >>>> don't know about the order, as in sequence, of operations at place >>>> order time. >>>> >>>> Any thoughts? >>> >>> Do you need a response from the external POS system to be returned >>> to the >>> customer? >> No, but I would like the result recorded in IC's transaction log >> file. >> >>> If not then you could perhaps make an asynchronous setup where you >>> collect the data that needs to go to the external POS system and run >>> that >>> periodically separate from the order process? >> True, but t would not satisfy my "as the orders happen" condition. > > Currently in the standard store there are 3 routes fired off from the > default: > Log main copy_user > > log does whatever happens in etc/log_transaction and basically can > fail your > order > main follows after that taking care of providing order e-mails > copy_user finally will send the mail to the user > > Perhaps you can add an additional route 'pos' which you could > implement to > work as a background process ( error_ok set to 1 because you do not > care if > it fails, at least not towards the visitor of the site ) ... > > The only thing about the whole approach I am wondering about is if > your POS > system is down while an order happens. How do you envision to catch > this? Thanks to all who replied. I think your correct. I think my design was bad. I'll just come up with a method for syncing the IC transactions and orderline tables with the POS system at regular intervals. Seems like a much more robust approach. Bill Carr suppressed _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.