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 PostbackError 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.
Note:
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 undoing the user entry, but none-AJAX mode doesn't support this.
And:
In fact, in most of cases, the server side exception is not recoverable for InfoPath web forms, because it is hard to determine whether a postback is immutable for the form, so we suggest redirecting the user to a recover page to reopen the form if your application have backuped the form xml in the previous successful postback, like the following:
<script language="javascript">
function InfoJetCustom_OnPostbackError(detailedMessage) {
    alert(detailedMessage);
    var formId = document.getElementById("xdoc_param_form_id").value;
    document.location.url = "RecoverPage.aspx?FormId=" + formId;
}
</script>
InfoJetCustom_OnPostbackError() will be called automatically by InfoJet_OnPostbackError() if it is defined by you.

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:

We suggest to backup the form xml while a successful postback finished in xdoc.aspx, and reopen the backup form while a server side exception occurred or session timeout, the parameter "xdoc_param_form_id" can be used as the identity key of the form backup, like the following:
<script language="javascript">
var formId = document.getElementById("xdoc_param_form_id").value;
document.location.url = "RecoverPage.aspx?FormId=" + formId;
</script>
Please reference:
How to handler the server side exception on postback?
How to handler the session timeout on postback?

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.