Researching on how to export file attachments from Lotus Notes to InfoPath

Well I have not quite figured this out yet. But I have some pieces to the puzzle. It’s easy for me to get a file attachment in a Lotus Notes document and detach it with code. I can track the file name and the stored location.

Attaching it into an XML file is where the challenge lies. However, I found this Support document on the Miccrosoft Help and Support web site: How to encode and decode a file attachment programmatically by using Visual C# in InfoPath (http://support.microsoft.com/kb/892730).

The problem that I foresee is that I have to include the code with the InfoPath form template and the form template must be fully trusted. These are not good options if I want to use Form Services. Nor will it be easy to convert the file and import it.

I need a way to encode and import the file attachment into the XML itself.

Another option that I have considered is a way to store the file attachments in a separate list and just include a link to the file attachment in the InfoPath form. Of course, this introduces new problems. How do I store the file attachment in a separate list? What is this list and where is it located? What about security requirements?

I’m still thinking this all through. An even bigger challenge is embedded objects in rich text fields in Lotus Notes.

Some other manifest.xsf entries

There are of course many entries in the manifest.xsf file. Some are required and others are optional. Some should be added when using InfoPath with the InfoPath client. Others should be avoided or disabled when using Form Services.

I always enabled the importParameters tag and set some default values for the documentVersionUpgrade tag.

<xsf: importParameters enabled=”yes”></xsf: importParameters>

<xsf:documentVersionUpgrade>
  <xsf:useTransform transform=”” minVersionToUpgrade=”0.0.0.0″></xsf:useTransform>
</xsf:documentVersionUpgrade>

In the beginning, I found the <xsf: views default=”Issue”> tag to be a bit more complex. This is not referring to a Lotus Notes-like view. Instead, it refers to the different forms that can be used to display the stored content. For example, there could be different forms for reading and editing. I add the following tag so that the view can be opened in design mode. Note that the designMode attribute is specified as normal. Normal is the same as not specifying a value.

<xsf: view name=”Issue” caption=”Issue” designMode=”normal”>

Next, the main stylesheet must be defined for viewing content. Issue.xsl is defined below.

<xsf: mainpane transform=”Issue.xsl”></xsf: mainpane>

Then an <xsf: editing> section is included to define how the rich text fields should appear when editing. I have already defined which fields (Details, RelatedDocuments) are of a rich text type elsewhere. Now I need to define the editing component (rich) and the associated properties (autoComplete=”no” and component=”xField”) for these two fields.

<xsf: editing>
<xsf: xmlToEdit name=”RichText_0″ item=”/RecordCollection/Details”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit><xsf: xmlToEdit name=”Details_10″ item=”/my:myFields/my: Details”><xsf: editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit>
<xsf: xmlToEdit name=”RichText_4″ item=”/RecordCollection/RelatedDocuments”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf:editWith></xsf: xmlToEdit><xsf: xmlToEdit name=”RelatedDocuments_14″ item=”/my:myFields/my:RelatedDocuments”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit>
</xsf: editing>

Unbound controls are defined in the <xsf:unboundControls> section. For example, I can define action buttons here.

<xsf:unboundControls>
<xsf:button name=”CTRL_BTN_Details”>
</xsf:unboundControls>

Next, I can define additional application parameters. The lastOpenView parameter identifies the name of the view that was last open in Microsoft Office InfoPath 2007 design mode.  The scriptLanguage parameter identifies the name of the scripting language used to implement the business logic of the Microsoft Office InfoPath 2007 form. The allowCustomization parameter identifies whether the Microsoft Office InfoPath 2007 form can be modified or customized.

<xsf: applicationParameters application=”InfoPath Design Mode”>
  <xsf: solutionProperties lastOpenView=”Issue.xsl” fullyEditableNamespace=”http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-01-01” lastVersionNeedingTransform=”1.0.0.2″ scriptLanguage=”JScript” allowCustomization=”yes” automaticallyCreateNodes=”yes”></xsf: solutionProperties>
 </xsf: applicationParameters>

There are some more settings that I’ll try to cover in my next blog entry. Then I’ll circle back to other XML files.

What goes in the manifest.xsf file?

The manifest.xsf file defines the contents of the form template and how it should be edited (e.g. rules, calculations, data connections, and so on)

Some critical values are stored in the <xsf: xDocumentClass> tag. In my example, I am referring to a form named “Issue”.

manifest.xsf part 1

The key entries are the list of files in the manifest.xsf. These define what makes up the InfoPath form package. Hence, the tag is called <xsf:package>. The list of files is contained in the <xsf:files> tag. Each of the file entries is in a <xsf:file> tag.

For example the myschema.xsd file is defined as:

    <xsf:fileProperties>
     <xsf:property name=”namespace” type=”string” value=”http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-01-01″></xsf:property>
     <xsf:property name=”editability” type=”string” value=”full”></xsf:property>
     <xsf:property name=”rootElement” type=”string” value=”myFields”></xsf:property>
     <xsf:property name=”useOnDemandAlgorithm” type=”string” value=”yes”></xsf:property>
    </xsf:fileProperties>

File entries will be required for template.xml, sampledata.xml, Issue.xsl, Submit.xml, and Issues.xml. The Issues.xml file defines the controls and other view constructs shown to the user in the form. There is one .xsl file for each view. This is not the same as the Notes view.

There are many more settings that I will try to cover later. But this is also where the fields in the list are defined.

 <xsf:listProperties>
  <xsf:fields>
   <xsf:field name=”Description” columnName=”Description” node=”/my:myFields/my: Description” type=”xsd:text”></xsf:field>
<xsf:field name=”Product” columnName=”Product” node=”/my:myFields/my: Product” type=”xsd:text”></xsf:field>
<xsf:field name=”ProductArea” columnName=”ProductArea” node=”/my:myFields/my: ProductArea” type=”xsd:text”></xsf:field>
<xsf:field name=”AssignedTo” columnName=”AssignedTo” node=”/my:myFields/my:AssignedTo” type=”xsd:text”></xsf:field>
<xsf:field name=”Status” columnName=”Status” node=”/my:myFields/my:Status” type=”xsd:text”></xsf:field>
<xsf:field name=”ResolvedOn” columnName=”ResolvedOn” node=”/my:myFields/my:ResolvedOn” type=”xsd:string”></xsf:field>
<xsf:field name=”Created” columnName=”Created” node=”/my:myFields/my:Created” type=”xsd:string”></xsf:field>
<xsf:field name=”Author” columnName=”Author” node=”/my:myFields/my:Author” type=”xsd:text”></xsf:field>

  </xsf:fields>
 </xsf:listProperties>

You can also define script element files in the manifest.xsf file. But then you get into requirements for including code with your InfoPath form. That may prevent you from using the form with Form Services and converting it to a web form.

How to define the fields in InfoPath 2007

You will need a file called myschema.xsd or something similar.  There will be a reference to this schema file in the manifest.xsf (as seen below). 

manifest.xsf

I have an example of a simple schema file below.

The schema file has references to two attributes: “Form” and “UniversalID”. These are not required.

The file will have a section with a name of  “myFields”. You can use a different section name; but you will need to reference it with the correct name elsewhere in other XML files. The field names will be listed in a subsection here. Note that “ref” is used to identify a fieldname with “my:” in front of the fieldname.

The next sections identify properties of the fields. “Details” and “RelatedDocuments” are like rich text fields. Both of these have special properties. The remaining fields are either of type “string” or type “date”. Note that the type definition also includes “xsd:”.

myschema.xsd

Exporting Notes Data as XML for InfoPath 2007

I have some LotusScript code that reads through documents and exports their content as XML. Each document is exported to a single XML file. I’m only handling text at this time.  A sample XML file appears as follows:

untitled22

The following factors are important:

The mso-infoPathSolution solutionVersion value must match the same value in the InfoPath form. Otherwise, you will be asked if you want to use the version stored in SharePoint.

The href value must point to the correct InfoPath form. Otherwise, the form will not open with the data in SharePoint.

The my field names must match those in the XSD file of the InfoPath form. Anything different and the form cannot open the XML file.

The file name of the XML file is used as the title value / web link in the first column of the view listing the data.

I export all of the data for a form to one folder. Then I open the SharePoint application and import the files using the multiple upload feature.

untitled

The result is that the XML data now appears in SharePoint. 

untitled2

I will try and provide more detail on the relationship between the InfoPath form, SharePoint, and the data later.