Lotus Geek :: Domino Tech Tip: You have a Web-based form that won't save...

Category Technical
Bookmark :

I am at one of my favorite client sites this week, in Bermuda, and I hit upon a problem that drove me crazy for a bit before I realized what was going on. I had a Web-based form used to create a document. The user fills it out, clicks send, gets an alert box message, and then is redirected somewhere else. The problem I was having was that it would pass validation, would appear to save, would give the message, and would redirect - but no document was saved. Checked the server log, no error messages. Nothing. Domino appears to be quite happy - except no document is created.

Now I reported a similar problem awhile back as a part of this post. Back then I found that Domino will simply ignore document.forms[0].submit() when called, especially if from a dialog. Well, in this case this isn't being composed from a dialog, and I am using formulas (@Command([FileSave]) and @Command([CloseWindow]) anyway. Oh, and to top it all off, it was working on another server, just not on this one server in particular. Yes they were the same version, yes it was the same code, blah blah blah. So I was tearing what little hair I have left out trying to figure out what the cause of this problem was.

Turns out that the problem was (or should have been) obvious. The problem was that I had recently added a Web Query Save (WQS) agent that sent an email to a person to begin a workflow with this document - and guess what? My ID (which signed the agent) had permission to run agents on the DEV server (the one that worked), but not on the PROD server (the one that didn't). It appears that if a WQS agent doesn't have the proper credentials to run, it simply prevents the document from writing to disk - no errors, no weird return code to the user, no symptoms at all - nothing. I thought it would write something to the server log, at a minimum, but it doesn't. Incidentally, the server is 6.5.1.

So, while this is probably a DUH thing for most of you, it bit me - and since I love to reveal my stupidity for the world to see, I thought I would share here.

Hope this saves more of your hair than it did mine.

Rock
**Democracy is the worst system in the world, except for all the other ones --Winston Churchill

Comments

1 - Thak god you moved from the WQS. I always felt that if something could wait a couple of minutes for a scheduled agent it should. This way the user experience is not encumbered by the WQS.

By the way, why is Bermuda one of your favorite places?

Posted by Christopher Byrne At 11:38:09 AM On 11/10/2004 | - Website - |

2 - Chris - Well, I am not as religiously against WQS as you are (unlike OLE embedding, which is definitely hellspawn and the bane of my existence), especially in ND6. The improvements in agent performance have made them much more usable. But in general I do agree with you. In this case the original spec was to be notified for each new document, immediately. I cautioned against this, and so I did the WQS agent. But, since we've had this problem, I talked them into going in another direction.

Rock

Posted by Rock At 11:48:20 AM On 11/10/2004 | - Website - |

3 - Maybe it's a security feature. A job security feature for the guy with the correct ID file

-rich

Posted by Richard Schwartz At 09:02:00 AM On 11/10/2004 | - Website - |

4 - Rich S. and Christian B. - I thought of that as well - and I removed the redirect. I also checked the response from the server, and it was a POST 302, which is a URI code, and is normal.

But here is something else enteresting that I didn't mention in my original post: when it was "erroring" and I had removed the redirect, it would dump me back to the default view of the db. When I removed the WQS agent and got it working, it gave me the (in)famous "Form Processed" page.

Richard C. - I agree, we use a control process for agents, etc. This "Production" server is a new server, and is going to be dedicated to this machine. Right now we are going through the process of testing it "here and there" to make sure it works everywhere. We have a control process for releasing agents - which is why my agent didn't work on the production server. But what bugs me is that it didn't tell me that the agent was the culprit, didn't have rights, etc.

In any case I moved away from the WQS agent, and went with a scheduled agent instead that sends a note to the right person if there are new docs to be processed.

Thanks for the discussion!

Rock

Posted by Rock At 08:13:08 AM On 11/10/2004 | - Website - |

5 - I also agree with Richard S. and Christian B.

From time to time, I run into this situation and I have to tell the other developers that they must sign off all agents with a certain notes user id when they're updating the production databases.

They ask me why and I tell them "'cause that user id is the only one with authority to execute agents."

They then have the cheek to ask "well, give me authority to execute agents"!

I say to them "do you wish to received thousands of stupid querys from users?" (in the case of where emails are generated by wqs agents). I guess I don't need to tell you the answer ..

Like you Rocky, it is even more embarrassing when the agents are signed off incorrectly on the webserver

Posted by Richard C At 04:32:40 AM On 11/10/2004 | - Website - |

6 - Had a similar "DUH" moment the other day. Of course with mine, the WQS agent was working perfectly, the log (updated by the agent) was showing no errors, but was verifying that the agent was running. In addition, the "site tracker" code was also capturing all of the correct information from the POST event, but the document was never written to disk. Turns out I had a SaveOptions field set to "0" sitting in a hidden section -AARRRRGGGGHHHHH!!!!! Two hours wasted for this!!??

I thinking about going back to school. Perhaps Truckmasters.

-Devin.

Posted by Devin Olson At 10:56:06 AM On 11/11/2004 | - Website - |

7 - Rocky,

Good catch !! And I would have sympathy for you on this one if you were at a client site in somewhere like Chicago but no sympathy here for you in Bermuda.

TTYL.

N.

Posted by Neil Agate At 09:52:38 AM On 11/12/2004 | - Website - |

8 - Sheesh... ya need a "release process" checklist just like I do

Posted by ZundapMan At 10:29:16 PM On 11/09/2004 | - Website - |

9 - How is the redirect happening? Could it be that the redirect is simply taking you away from the error message that Domino would otherwise be returning to the browser?

-rich

Posted by Richard Schwartz At 12:12:29 AM On 11/10/2004 | - Website - |

10 - I agree with Richard. I had the same problem some days ago. 'So I used EtherReal to look what is going on. The servers response to the POST command was indeed an error, but the browser was returned to the Address in $$Return anyway so nobody could see the error message.

Posted by Christian Brandlehner At 03:22:59 AM On 11/10/2004 | - Website - |