I have often thought that looking to the design of a Notes form to determine which fields to migrate is somewhat faulty. Those of us who are seasoned Notes developers understand that there are a number of ways to include more fields on a document than are on the form’s design. Here are three situations to consider:
1. Computed subforms on a form may display different fields at different stages of a document’s lifecycle. Thus, there may be ten fields at one stage and five at another stage. None of these fields appear on the main form because these are computed subforms. So why look at the form to migrate these five or ten fields? How do you know which subform to use?
2. The design of some forms may change over time. Fields are added and removed. Thus, the fields on documents may be different based on the age of documents. This is a great Notes feature when used correctly. But which fields should be selected for migration? Fields from a new document? old document? both documents?
3. Some agents or actions will set “hidden” fields on documents. These values are never displayed to users in a form. Thus, they are “hidden”. But the field values may be used for processing the document. Should these fields be included in a migration even though they do not appear in a design?
So basically, I want to both sets of details. I want to see the list of fields and field types on the design of a form and the same for the fields on a document. But which document to choose? Should I only look at the last document created? Probably not, since it will not be a good representation of all documents. Should I randomly select documents? This may possibly be a good choice. This how polls are conducted. We can be reasonably certain that a random selection of documents could represent the entire collection of documents within a certain percentage. I’m comfortable with this approach as I’ve taken a number of statistics courses and used statistics at work and in a thesis. But it has to be well-thought out and explained to business users for them to agree with the approach.
So I’ve solved the problem of the list of fields to use. Congratulations to me! Of course, I have now introduced a new problem. What if use the DXL representation of the Notes form to read the design details? The DXL only gives me the fields listed on the design. I can transform this DXL into the InfoPath form that I need. But what about my solution for getting the correct list of fields from the Notes documents? How do I add all of the fields not included on the design? I can probably build a list of fields and determine if they are on the DXL design. But how do I add them to the InfoPath form? Should I add them during the transformation of afterwards? Should I try to determine if they are on a computed subform(s)?
I have to add the fields to the design or the form will not work correctly later. I tried adding more fields to the XML data file and importing it into a SharePoint list that was using an InfoPath form. The InfoPath form would not open the data record because the list of fields did not match. So I need to resolve this somehow.
The list of fields and field types on the InfoPath form must match the same on the Notes documents. The migrated data must have the same fields and field types as on the Notes documents. The migrated data must also have the same fields and field types as on the InfoPath form. Anything that is missed may result as a failure of the migration effort.
Note: I have not even addressed the issues of managed code yet. 😉