[ic] Order Route Question

Bill Carr bill at worldwideimpact.com
Wed May 21 18:45:54 UTC 2008


On May 21, 2008, at 2:35 PM, <ic at 3edge.com> wrote:

>> -----Original Message-----
>> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
>> users-bounces at icdevgroup.org] On Behalf Of Bill Carr
>> Sent: woensdag 21 mei 2008 16:19
>> To: interchange-users at icdevgroup.org
>> Subject: Re: [ic] Order Route Question
>>
>>
>> On May 21, 2008, at 9:07 AM, ic at 3edge.com 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
bill at worldwideimpact.com





More information about the interchange-users mailing list