Converse agora com nosso suporte
Chat com o suporte

Migrator for Notes to SharePoint 7.2 - User Guide

Migrator for Notes to SharePoint Migrator for Notes to SharePoint Console
Overview Console configuration using the setup wizard Advanced configuration options Database discovery QuickPlace/Quickr discovery Domino.Doc discovery Discover directory entries Import database records Notes databases Applications Classification Rules Classification Rule Properties SharePoint Targets Scheduled tasks Reports Task history Link Analyzer/Updater/Finalizer License
Migrator for Notes to SharePoint Designer Migration jobs Appendix: Reference information

Generating documents from Lotus Notes

This feature allows you to generate Microsoft Word 2007 (OpenXML) documents from Lotus Notes documents. Microsoft Word is a very flexible and powerful environment and Migrator for Notes to SharePoint supports a wide range of migration scenarios:

1
Migrate Notes rich text to new (blank) Word document - In this scenario the user wants to map the rich text portion of their Notes documents (typically the "Body" field) to Word 2007 documents (DOCX files) created from scratch. The generated rich text content is pretty much the only thing in the resulting documents. The fidelity of the migrated content is very high and includes tables, fonts, bullets, images, doc links, and much more. The known limitations are listed at the end of this document.
Optionally, the user may want to migrate specific Notes data items to Standard Document Properties such as Author, Category or Description within the generated Word documents.
As these documents are generated, they will be checked into the designated SharePoint library.
A large number of existing Migrator for Notes to SharePoint features apply here, including the ability to set created/modified metadata, document permissions, target folders, content types, workflow state, version history, data transformations and more.
Furthermore, the user may want to migrate specific Notes data items to specific metadata columns in the document library. When the document is opened in SharePoint, these properties will appear as "Server Properties" in the Word user interface.
2
Migrate Notes rich text to new Word documents based on existing templates - This scenario is similar to the one above except that the user can specify the Word 2007 template (DOTX file) they want to start with. The generated documents will pick up the headers, footers, or backgrounds of the original template. If the template includes any rich text content, the migrated content will be appended to it.
If the Word template defines Custom Document Properties, the user may want to migrate specific Notes data items to these Custom Properties as well as to the Standard Properties.
3
Migrate Notes documents to Word documents with embedded content controls and legacy controls - In this scenario, the user is using the Word template as a "form" with rich layout and data entry fields (and possibly data validation rules, computations, actions.). For each Notes document, Migrator for Notes to SharePoint will generate an equivalent Word document with specific Notes data items mapped to these controls.
•
If the user is taking advantage of SharePoint's automatic mapping of SharePoint meta-data columns to Word content controls (exposed to SharePoint developers as "Quick Parts") then the best approach is to simply map the Notes data items to the metadata columns in the document library and let SharePoint synchronize them with Word.
•
Migrator for Notes to SharePoint can also set the contents of the content controls or legacy controls directly with the mapped Notes data. They will continue to appear as data entry fields in the document, but they will not be synchronized with SharePoint metadata columns.
•
Migrator for Notes to SharePoint can also replace the content controls or legacy controls entirely with the mapped Notes data. They will no longer appear as data entry fields.
 
* 
NOTE: The user may still want to map a Notes rich text "Body" field to the document in addition to populating the controls, as described in the first two scenarios.

Using this feature

When designing Target Data Definitions in Migrator for Notes to SharePoint, you can add target columns of type WordDocument. You must also specify a column Name (which is used in the field mapping process).

Specifying a Template is optional. If you do not specify one, you will always get plain word documents containing whatever rich text contents and standard properties you choose to map from Notes. If you want to specify a template, simply click on the Template property and press the details button to launch the Word Template Options dialog.

In the Word Template Options dialog you can optionally import a Microsoft Word 2007 template (.DOTX file) using the Import button. Note that a complete copy of the imported template will be saved as part of your Target Data Definition and will be used as the basis for any documents that you generate with it.

If the imported template contains any of the MSWord Content Controls that are supported by Migrator for Notes to SharePoint, and these controls are not bound to SharePoint columns or XML data, then they will appear as mappable controls in the Mappable Fields section of the dialog. The content controls that are supported are RichText, PlainText, DatePicker, ListBox, ComboBox.

Word Template Options dialog also includes a complete list of the available Mappable Fields, which are the parts of the generated Word documents that you might want to map Notes data to. This list includes the main rich text Body of the document, all the Standard Properties available in every Word document (Author, Created date, Subject, Title, Keywords, Category, Status and Revision) and well as any Custom Properties that may have been defined by the Word template you loaded.

If desired, you can customize how these Mappable Fields appear on the Mapping tab. (Recall that Migrator for Notes to SharePoint maintains the distinction between the reusable Target Data Definitions that describe the schema of your SharePoint targets and the mapping of source columns to target fields in a specific migration job.) You can clear certain Mappable Fields that you do not want to show on the Mapping tab. You can also override some of the Mappable Field properties such as the MappableName that is visible on the Mapping tab, the AutomapNames property that provides a hint as to which Notes source columns should automatically map to the target field, and the AllowMultiple property which controls when mapping of two or more source fields to one target field should be allowed.

For embedded content control type fields, you can define how the data value will be mapped to the content control using the Mapping Behavior property. This property has the following options:

•
Set Value
•
If the control contains an initial value added by the template designer, this is preserved and then all mapped values will follow this initial value.
•
If the control only contains PlaceHolder text (typically shown in gray) and often says something similar to "Click Here to enter text", this content gets removed prior to adding values.
•
Replace Control
•
If multiple fields are mapped to a control with this behavior set, then only the FIRST mapped value is handled. After that all other mapped values are ignored.
•
If the control has non-placeholder content added by the template designer, it is discarded with the control when the control is replaced.

Content controls in MSWord may be data bound to either SharePoint fields or XML data. We do not allow mapping to any data bound content controls as MSWord would ignore our content in favor of the bound data resulting in data loss for the user.

Note that your Target Data Definition may well contain additional target fields that are not part of the generated Word Document. In particular, you can add target columns for any additional metadata properties that should be written to the SharePoint document library, rather than inside the generated Word documents (as described in scenario #3).

You may also want to specify Folder names as well as the alternate locations for embedded attachments and OLE objects that should be migrated separately to SharePoint. These are existing features that are described elsewhere, but they apply equally well to Notes documents.

One final thing you may wish to enable in your migrated Word documents is the new "Migrate Attachment Icons" feature. While this is not always desirable when migrating to List Items, it looks pretty nice in Word Documents.

Once you save your Target Data Definition, the various parts of the WordDocument field you defined will be available on the Mapping tab.

In most cases, you will (at a minimum) want to map the Html version of your Notes documents to the Doc.Body field and map the Subject (or a similarly descriptive Notes item) to Doc.FileName. You can also add additional mappings for standard properties and custom properties as needed.

When you run the job, Migrator for Notes to SharePoint will generate one Word document for each Notes document. You can inspect the migration log for any issues.

 
* 
NOTE: Large images that do not fit within the page margins of the target Word document will be automatically resized during migration taking the size, orientation and margins of the template into account.

Direct folder migration

On the Advanced tab of your Target Data Definition, you can indicate that you want to migrate to a folder in your target list or library. In this mode of operation, every record you extract from the data source will result in a folder being created, instead of a document.

The only additional requirement is that you map at least one item to a target column of type ‘Folder ‘. This controls the new folder names. Many of the usual document migration features will now apply to folders including:

•
Mapping of permissions (using the "Map Reader/Author fields" check box on your Advanced tab)
•
Mapping created/modified metadata to folders (using the "Preserve Created/Modified" check boxes on the Map Data tab)
•
Mapping additional data items to folders (requires creating a new Folder content type).
 
* 
NOTE: Many job features that would apply to document migration will not apply to folder migrations. For example, document generation and duplicate document handling options would be disallowed in this context.

Extracting information from Domino.Doc Binders

With this new feature, you can migrate all the information from your Domino.doc Binders to SharePoint folders. To support this, a new option has been added in the Domino.Doc Source Data Definitions. Simply check the Binders only radio button on the Document Selection tab. When this job is run, Binders are extracted instead of Documents.

Each row in the Preview Data Query tab represents a Binder in the current file cabinet. Additional columns have been added for all of the standard Binder metadata available in Domino.Doc. You can add additional columns to this query as well.

Putting these features together, you would typically map the {Title} property of your data source to a Folder column in your target. Simply checking Map Reader/Author fields, Preserve Created/Modified identities, and Preserve Created/Modified dates should bring over most of the other metadata but you can certainly add additional mappings if desired.

Note that this feature will only write new SharePoint folders; it will not update existing ones with the same name. So a best practice is to run the Binder migration job first (to create the folders with all the properties intact) and then run you normal document migration job. Remember that the Migrator for Notes to SharePoint migration console makes it easy to sequence multiple migration jobs for one database, and to automate these jobs for many databases of the same type.

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação