InfoJet Service caches the registered form templates in the server's memory. So while the AppDomain or IIS restarts, the registered form templates will be lost, InfoJet Service will throw this exception while the lost form template is required. So we suggest checking whether the form template existing in InfoJet Service before calling the following methods by its publish url and registering it if not existing:
InfoJetService.BuildFormByTemplate(),
InfoJetService.BuildFormByXml(),
InfoJetService.ReloadForm() and
InfoJetservice.UpdateForm(),
like the following:
if( !InfoJetService.ContainsXSN( publishUrl ) )
{
    //Try to load the binary content of the form template by the publishUrl.
    //Then please call InfoJetService.Register().
}
And in xdoc.aspx.cs, you can check it like the following:
string publishUrl = this.Context.Request[ "xdoc_param_xsn_uri" ];
if( publishUrl != null && publishUrl.Length > 0 )
{
    if( !InfoJetService.ContainsXSN( publishUrl ) )
    {
        //Try to load the binary content of the form template by the publishUrl.
        //Then please call InfoJetService.Register().
    }
}
The value of xdoc.aspx's request parameter "xdoc_param_xsn_uri" is the current form's publish url.

There are many reasons can cause the AppDomain or IIS restarts, please check it with the propery System.Web.Hosting.HostingEnvironment.ShutdownReason in the global method Application_End().

The improper configuration of InfoJet Service can cause the AppDomain restarts also, please reference the following sections:
http://www.infojetsoft.com/service_config.htm#InlineFilePath
http://www.infojetsoft.com/service_config.htm#ResourceFilePath
http://www.infojetsoft.com/service_config.htm#TempFolder

And InfoJet Service stores the secondary data source in the session state also, while the AppDomain or IIS restarts, the In-process session state will be lost, the forms using the secondary data source maybe won't work properly, so we suggest using the Out-of-process or SQL Server session state.

InfoJet Service will call the following methods while postback started and finished in the form editing page, so we can disable/enable the save button in them:
<script language="javascript">
function InfoJetCustom_OnPostbackStart(){
    var saveButton = document.getElementById( "SaveButton" );
    if( saveButton )
    {
        saveButton.disabled = true;
    }
}
function InfoJetCustom_OnPostbackEnd(){
    var saveButton = document.getElementById( "SaveButton" );
    if( saveButton )
    {
        saveButton.disabled = false;
    }
}
</script>
While postback, the form maybe contains the dirty data, so we suggest disabling the save button to ensure data integrity.

We suggest adding a custom error page declaraction in web.config like the following:
<customErrors mode="On" defaultRedirect="~/ErrorPage.aspx">
</customErrors>
(1). While using AJAX postback mode, please add the following Relogin directive into the custom error page:
<!--InfoJetSoft.Service.PostbackError-->
<!--InfoJetSoft.Service.ErrorMessage(The detailed error message here)-->
InfoJet Service will call the method InfoJet_OnPostbackError() to stop the postback and undo the previous user input. The directive ErrorMessage can show a detailed error message for user.
(2). While using Non-AJAX(hidden iframe) postback mode, please add the following script into the custom error page:
<script language="javascript">
//The custom error page is shown in an iframe.
if(self.location != top.location){
    //The parent document contains InfoJet Service web form.
    if( parent != null && parent.document.getElementById( "xdoc" ) != null ){
        parent.InfoJet_OnPostbackError("The detailed message here");
    }
}
</script>
The custom error page can catch the script timeout exception also.
And we suggest using AJAX postback mode, because AJAX mode proivdes more controls for the network transmission. For sample, InfoJet Service can discover the network is broken in AJAX mode, and recover the failed postback automatically by calling InfoJet_OnPostbackError(), but none-AJAX mode doesn't support this.

1. If xdoc.aspx is protected by Forms Authentication, the postback will be redirected to the login page. 2. If xdoc.aspx is protected by Integrated Windows Authentication or HTTP based Authentication, or not protected, please reference the following codes in xdoc.aspx.cs:

While the session timeout and user doesn't need to relogin, we can post the form to a page to recover the form data and open it again. While the session timeout, the form session data is lost also, so we suggest reopening the form.
Please reference the following codes in the form editing page:
<script language="javascript">
function OnFormReopen()
{
    var reopenButton = document.getElementById('ReopenButton');
    reopenButton.click();
}
</script>
<form>
    <asp:Label ID="xDocView" runat="server" EnableViewState="False"/>
    <asp:Button id="ReopenButton" PostBackUrl="~/Reopen.aspx" runat="server"
      style="display:none;"/>
</form>
In Reopen.aspx.cs:
string publishUrl = this.Context.Request["xdoc_param_xsn_uri"];
if (publishUrl != null && publishUrl.Length > 0)
{
    if (!InfoJetService.ContainsXSN(publishUrl))
    {
        //Try to load the binary content of the form template by the publishUrl.
        //Then please call InfoJetService.Register().
    }
    string xml = InfoJetService.RecoverNonDirtyFormXml(this.Context);
    InfoJetForm form = InfoJetService.BuildFormByXML(this.Context, publishUrl, xml);
    this.xDocView.Text = form.Xhtml;
}
The method InfoJetService.RecoverNonDirtyFormXml() will recover the form XML from the request without the dirty data. While a postback is fired by a field value change event, and the postback is not finished successfully, the field value in the returned XML will be the old value before the change event, rather then the new field value(the dirty data), because the related calculations or rules maybe not be processed properly.

Please reference How to recover the form XML while error occurs?.
And while the form is post to the login page, we can output the form parameters into the authentication form like the following, so we can recover the form after user login successfully:
protected void Page_Load(object sender, EventArgs e)
{
    foreach (string key in this.Context.Request.Params.AllKeys)
    {
        if (key.StartsWith("xdoc_"))
        {
            string keyValue = this.Context.Request.Params[key];
            HtmlInputHidden hidden = new HtmlInputHidden();
            hidden.ID = key;
            hidden.Name = key;
            hidden.Value = keyValue;
            this.LoginForm.Controls.Add(hidden);
        }
    }
}

To enable submitting via Email, the key "InfoJetSoft.Service.SmtpServer" and "InfoJetSoft.Service.MailFrom" must be set. InfoJet Service will use the "MailFrom" account on "SmtpServer" to send emails. If the Smtp Server needs authentication, the key "InfoJetSoft.Service.MailUserName" and "InfoJetSoft.Service.MailPassword" must be set also.
"InfoJetSoft.Service.TempFolder" is need also, InfoJet Service will cache Email attatchment(xml file) in it. And please grant "Full Control" of the folder to the account running InfoJet Service. If impersonation is enabled, you'd better to grant "Full Control" to everyone.

You could use the following code to print the exported MHT file by clicking a button:
function CTRL23_5::OnClick(eventObj)
{
   XDocument.View.Export( "test.mht", "MHT" );
   if( Application.InfoJetService )
   {
     Application.RunClientCode( "var mhtWindow = window.open( window.location.protocol + '//' + window.location.host + '" + XDocument.View.ExportPath + "');" );
     Application.RunClientCode( "mhtWindow.print();" );
     Application.RunClientCodeOnly();
   }
}
In the exported MHT file, the button control will be hidden, the dropdown, radio and check box will be converted to the plain text. This feature requires the configuration key "InfoJetSoft.Service.InlineFilePath", the MHT file will be exported to the InlineFilePath folder.
And you could use the following html button outside of InfoPath web form to open the MHT file exported from the current form view in a new browser window:
<input type="button" onclick="InfoJet_OpenPrintableVersion(this);" value="Printable Version">
This feature requires the configuration key "InfoJetSoft.Service.InlineFilePath" also.

The session key of the form data cached by InfoJet Service is stored in the HTML hidden field "xdoc_param_form_id" of the InfoPath web form(InfoJetForm.Xhtml). So, when you want to clear the session data used by the current form, you need to submit this session key.
Generally, there are two situations:
1. The user submitted the form to save it, and the user is redirected to another page.
    The value of the session key has been contained in the form, so you could use the following code directly:
    InfoJetForm savedForm = InfoJetService.ReloadForm(Context);
    InfoJetService.ClearFormCache(Context);
    //Redirect to another page.
2. The user clicked one "Close" button to close the browser directly.
    In this case, the whole form won't need to be submitted, but you need to submit "xdoc_param_form_id" to the server side in JavaScript:
    var formId = document.getElementById("xdoc_param_form_id");
    if( formId != null ){
      document.location="ClearSession.aspx?xdoc_param_form_id="+formId.value;
    }
    And in ClearSession.aspx:
    <html>
    <% InfoJetService.ClearFormCache(Context) %>
    <script language=javascript>window.opener=null; window.close();</script>
    </html>
The method ClearFormCache() will clear the temp files used by the form also.
And while user logoff, please call the following method to clear the http session data and the temp files used by the current user:
InfoJetService.ClearUserCache(Context);
The demo program of InfoJet Service contains some codes about this, please reference it.

You need to rewrite the function InfoJetCustom_OnLinkedPictureClick(event, linkedPicture) in infojet.js. InfoJet Service will call this function whenever user clicks linkedPicture. You also need to set src attribute of linkedPicture in this function, and then to call InfoJet_UpdateField(linkedPicture).

To connect Oracle, please design the form template based on the tables of SQL Server first, then create the tables in Oracle with the same structures. And add the following configuration key into web.config:
<add key="InfoJetSoft.Service.GlobalConnectionString"
value="Provider=msdaora;Data Source=XE;User Id=hr;Password=hr;"/>
(Now, only the OLEDB driver is supported.)
The GlobalConnectionString key value will replace all of the database connection strings used in the form templates.