locked
Is there an architecture diagram for interaction between Forms Services and SharePoint? RRS feed

  • Question

  • I have an InfoPath 2007 form published to SharePoint 2007 and web-enabled. The submit function posts back to the InfoPath form library.

    The form works fine in the InfoPath client, but when I try to submit a web form, I get an error.

    The site is using Siteminder for authentication, and I'm wondering if that's part of the problem. But I could really use an architecture diagram that shows what happens between which processes using what authentication in Forms Services. When I click "submit" does the browser do anything but post back? Is all the actual logic and "submit" stuff happening on the server? In what process? Is everything contained in SharePoint or is there interprocess communication?


    Thanks!

    Philo


    Philo Janus, MCP Author: Pro InfoPath 2007 Pro PerformancePoint 2007 Pro SQL Server Analysis Services 2008 Building Integrated Business Intelligence Solutions with SQL Server 2008 R2 & Office 2010 Blog @ http://philo.typepad.com/with-all-due-respect/
    Thursday, February 3, 2011 11:20 PM

Answers

  • Philo, your book helped launch me down my career of working with InfoPath and SharePoint - I recommend your book all the time.  It's interesting to see you here 3+ years later (from when I read the book) asking a question.  I haven't actually seen a diagram like that, but I might be able to help with the situation.  In a browser form, the form itself is rendered by Forms Services on whichever WFE the user is on currently.  Authentication is already done by the browser session, so there isn't an additional authentication upon submit unless your submit is going to somewhere besides the form library.

    1. What error do you get?  You didn't specify where the error was (in InfoPath or in the SharePoint page) nor the specifics of the error.
    2. Did you go find the full error details in 1) the Application log of the Event Viewer and 2) the 12 hive log?  These would shed some light
    3. What is Siteminder?  This is in place of regular Windows Auth with AD?

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Leoyi Sun Tuesday, February 15, 2011 6:41 AM
    Friday, February 4, 2011 3:31 AM
  • Man, you didn't mention IE9.  I would by no means be doing any development testing with IE9 - I wouldn't even have it installed on any machine related to any client or development work personally...not until it's RTM'd and fully-tested.  The Beta is quite the bugger...
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Leoyi Sun Tuesday, February 15, 2011 6:41 AM
    Tuesday, February 8, 2011 7:40 AM

All replies

  • Philo, your book helped launch me down my career of working with InfoPath and SharePoint - I recommend your book all the time.  It's interesting to see you here 3+ years later (from when I read the book) asking a question.  I haven't actually seen a diagram like that, but I might be able to help with the situation.  In a browser form, the form itself is rendered by Forms Services on whichever WFE the user is on currently.  Authentication is already done by the browser session, so there isn't an additional authentication upon submit unless your submit is going to somewhere besides the form library.

    1. What error do you get?  You didn't specify where the error was (in InfoPath or in the SharePoint page) nor the specifics of the error.
    2. Did you go find the full error details in 1) the Application log of the Event Viewer and 2) the 12 hive log?  These would shed some light
    3. What is Siteminder?  This is in place of regular Windows Auth with AD?

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Leoyi Sun Tuesday, February 15, 2011 6:41 AM
    Friday, February 4, 2011 3:31 AM
  • Hey Clayton - thanks so much for the compliment!

    This is a back-burner project, so I keep going back to it, and I've basically been beating myself up over it for over a month, and I think I finally got a breakthrough today.

    See, I've been in the event log, and the SharePoint logs, and fiddled with IIS security settings, and tried different kinds of code and and and...

    And it looks like the problem is IE9.

    I finally decided to put aside the submit problem and check out why the text boxes were so slow in the form. So I started doing some javascript forensics, and found that the form was basically tying itself in knots on onkeypress events. Then suddenly I had an inspiration - I remembered that the form didn't get so sticky in Firefox, so I tried submitting it from Firefox.

    Went in the first time.

    RDP'd to a server and tried it on IE7. Submitted. IE8. Submitted. Safari. Submitted.

    IE9 is causing some kind of javascript knot in core.js, and submit events are either getting swallowed or screwed up. There are a few cries for help on this, but nothing major, and I don't think anyone's stuck with it long enough to figure out that IE9 is the culprit.

    [sigh]


    Philo Janus, MCP Author: Pro InfoPath 2007 Pro PerformancePoint 2007 Pro SQL Server Analysis Services 2008 Building Integrated Business Intelligence Solutions with SQL Server 2008 R2 & Office 2010 Blog @ http://philo.typepad.com/with-all-due-respect/
    Tuesday, February 8, 2011 7:27 AM
  • Man, you didn't mention IE9.  I would by no means be doing any development testing with IE9 - I wouldn't even have it installed on any machine related to any client or development work personally...not until it's RTM'd and fully-tested.  The Beta is quite the bugger...
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Leoyi Sun Tuesday, February 15, 2011 6:41 AM
    Tuesday, February 8, 2011 7:40 AM