David, In answer to your questions:
1. what did the user do A: this is a batch pick and pack scheduled job (we wrote this, it collects all Orders and issues a CreatePickListFromOrder and CompletePack OFBiz service call; each Order is processed within a single transaction; the process loops thru all available Orders). 2. what did you expect (or hope!) to happen A: we expect the "capture" to be successful; if not, we would prefer that we get the error returned and our code will take it from there (not pick and pack that particular order and move onto the next order within the batch). 3. what actually happened A:in our case the "capture" returned (from Verisign) a valid error code (system was trying to re-use an authorization code that had already been captured ... but could be any valid error returned). Once the "capture" failed, OFBiz tries to "re-authorize", based on our current configuration (we think) but ultimately we'd prefer that we get the valid error code returned to our code from the "capture" attempt, then we can ignore that Order and move to the next one in the batch. We'll continue our research and provide additional insights as they come to us, thanks. Regards, Nick Rosser [EMAIL PROTECTED] O: 516.742.7888 x221 C: 516.901.1720 F: 516.742.9169 Visit us at www.salmonllc.com -----Original Message----- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 5:10 PM To: [email protected] Subject: Re: Urgent Prod Issue: payment "capture" workflow / processing Nick, What might be most helpful is to describe the symptoms and errors you're actually seeing instead of an interpretation of them (it's hard to guess at whether you interpretation is correct or not, or what that might mean relative to what people know about the system). For example, what do you mean by "the service does not appear to return a clean error"? The most complete way to answer that is answering the questions: 1. what did the user do 2. what did you expect (or hope!) to happen 3. what actually happened You also mention DB locks, and until those are known to be caused by the issue it might be best to treat them as an independent symptom, possibly to an independent problem. The DB locks may actually be the cause of certain problems as opposed to being caused by. The best thing for DB lock wait timeout errors (which is what I assume you're getting based on what you said, but you should verify that) is to send over the actual error message the user sees and the relevant errors in the log file (possibly before and after the main error). Going back to the beginning of this problem: why are the captures failing? Is there an error message that might help lead to a resolution? Is it because the CC processor is down or something and you don't like the way OFBiz is handling it? If so, what is the process you'd like to see OFBiz follow in order to handle it? BTW, these are questions I'd start asking were I working on fixing this. You don't necessarily have to answer all of them on the mailing list, though that would be the best way to get help from the community. You can also just use these internally to help focus the efforts of your people. -David On Oct 15, 2008, at 12:47 PM, Nick Rosser wrote: > Hi, > > We have recently deployed OFBiz into our clients production > environment. The > following is typical of a serious issue we are experiencing: > > * run Pick n Pack, in a batch job > > * if we get an error in the "capture" process: > o the service does not appear to return a clean error > o it attempts re-auth, capture again etc. > o ultimately we are experiencing DB locks because of the above (I > assume that while waiting for the payment processing the 80 or so > users are experiencing db locking issues) > > Is there a way to simply return a "capture" failure, we'll skip that > Order and move on? > > BTW: in dev test/debug, we are seeing some pretty complex code > managing all these iterations (re-auth etc.) but ultimately the order goes into > 'pick' and is 'completed'. We are assuming that the store setting "Ship If > Capture Fails = Y". Could someone confirm? > > We are also looking into the usage of the following "store" settings, so if > anyone has insight as to how these setting may relate to the problem it > would be much appreciated: > > Assume this setting will keep retrying to authorize (for n times?) if the > authorization fails: > Retry Failed Auths = Y > > Assume these are as labeled, keep trying in the event of a failure: > Auto Order Cc Try Exp: Y > Auto Order Cc Try Other Cards: Y > Auto Order Cc Try Later Nsf: Y > Auto Order Cc Try Later Max: blank > > (BTW: our client ships 2000 orders per day, and runs their operation > with 80 customer service reps . any help appreciated since this is impacting > their business) > > Regards, > > > > Nick Rosser > > [EMAIL PROTECTED] > > O: 516.742.7888 x221 > > C: 516.901.1720 > > F: 516.742.9169 > > > > Visit us at www.salmonllc.com > > >
