There is a FAST pipeline stage called PropertiesFeedingFixture (see %FASTSEARCH%\etc\pipelineconfig.xml) which is essentially a work around to allow feeding Crawled Properties (CP) in absence of proper support of the content API. Instead of feeding a CP via a correspondent of Document.CreateCrawledProperty, the connector uses one of two possible feeding modes: "canonical names" or "plain names".
If the mode is "plain names", the connector creates crawled properties as an according attribute with only the propname as its identifier (CP "0123:name:31" becomes "name"). In this mode we assume that all CPs have the same propset and protocolhandler. The connector has to set these values as the two attributes @@@:)propset and @@@:)protocolhandler respectively. Note that documents are only processed, if there is an attribute @@@:)propset with a valid GUID.
For example:
@@@:)propertiesfeeder | "plain names" |
@@@:)propset | "a09e579e-ce9f-4d19-9e24-394048c6cc4a" |
@@@:)protocolhandler | "aspire" |
There is a newer extension to the "plain names" mode, which allows feeding a fixed set of propsets by using prefixed attribute names. There is always a default propset that is used for all promoted attributes that have no such prefix, which is also the case for the simple usage as described above. In order to map an attribute to another propset, you have to append a prefix to its name. Then the @@@:)propset attribute has to be extended by adding a space character followed by this very prefix and a colon and the new propset. You can add as many prefixes as you like, but the prefixes shall not contain a colon.
For example, using a different propset on fields prefixed st_:
@@@:)propertiesfeeder | "plain names" |
@@@:)propset | "a09e579e-ce9f-4d19-9e24-394048c6cc4a st_:eeafdad1-fa3d-4d8c-9ad9-e78e8b7860f1" |
@@@:)protocolhandler | "aspire" |
On the other hand, if the mode is "canonical names", the connector has to create CPs as attributes with a valid name of a crawled property, e.g. "00130329-0000-0130-C000-000000131346:ows_Title:31" .
For example:
@@@:)propertiesfeeder | "canonical names" |
@@@:)protocolhandler | "aspire" |
In both modes the variant type is selected based on the type of the value of the attribute as the according default Variant Type (VT):
int 3 VT_I4 float 4 VT_R4 double 5 VT_R8 bool 11 VT_BOOL decimal 14 VT_DECIMAL string 31 VT_LPWSTR datetime 64 VT_FILETIME
Also in both modes the string attibute @@@:)nonproperties can list the names of attributes that are not to mapped to CPs.
A possible solution for this is to:
1. Populate the values in the Aspire document with the required parameters to trigger the PropertiesFeedingFixture pipeline stage.
For example, "plain names":
doc.propertiesfeeder = "plain names"; doc.propset = "a09e579e-ce9f-4d19-9e24-394048c6cc4a st_:eeafdad1-fa3d-4d8c-9ad9-e78e8b7860f1"; doc.protocolhandler = "aspire";
or "canonical names":
doc.propertiesfeeder = "canonical names"; doc.protocolhandler = "aspire";
2. Map these Aspire document trigger values to FAST index fields with the appropriate @@@:)name
For Example (in the properties mappings file as configured in the FS4SP Publisher configuration):
<property fast="@@@:)propertiesfeeder" aspire="/doc/propertiesfeeder[.]" type="string" /> <property fast="@@@:)propset" aspire="/doc/propset[.]" type="string" /> <property fast="@@@:)protocolhandler" aspire="/doc/protocolhandler[.]" type="string" />
3. Map Aspire document fields to FAST index fields using full canonical names where necessary
For Example:
<property fast="00130329-0000-0130-C000-000000131346:ows_Title:31" aspire="/doc/title[.]" type="string"/>