The comments in that example do the best job of describing the crawl process that I've seen. The section that describes the incremental crawl BCS Model configuration is just below the section referenced by johnnyjob. The relevant bit is:
This is the same as in a full crawl, unless several things are configured to enable your shim to more intelligently decide what to emit. Here's what needs to be configured to enable this behavior:
- The SpecificFinder of the Entity has to return a field containing the number of deleted direct child items in that particular container and this field must be identified in the model file by defining the 'DeletedCountField' property on the SpecificFinder method instance, where its value must be the name of the field that returns the delete count.
- The AssociationNavigator for which this Entity is the SourceEntity must include in its return type descriptor a last modified time DateTime field and this field must be identified in the model file by defining the 'LastModifiedTimeStamp' property on the AssociationNavigator method instance, where its value must be the name of the fiels that returns the last modified DateTime.
- The AssociationNavigator for which this Entity is the SourceEntity must have an input filter defined, and that input filter must have the 'CrawlStartTime' string property defined:
<FilterDescriptor Name="LastModifiedFilter" Type="Input">
<Property Name="CrawlStartTime" Type="String">x</Property>
- The AssociationNavigator for which this Entity is the SourceEntity must take a DateTime input parameter, and that parameter must be associated with the filter described in #3:
<Parameter Name="lastModifiedTime" Direction="In">
<TypeDescriptor Name="lastModifiedTime" TypeName="System.DateTime" AssociatedFilter="LastModifiedFilter" />
If this is the case, then the association navigator is called, and your shim will be provided the last modified time to determine what items to return.
I've implemented this in a BCS model for the SQL Connector and it is working.