api/connectors/plugins/lucid.anda/types/CONNECTOR_TYPE. For example, see the lucid.anda-web plugin properties:
Basic configuration properties
The set of basic configuration properties limit the scope of the crawl. The crawler fetches the contents of the specifiedstartLink property, adding any found links found. The connector adds nodes to a database known as crawldb to prevent re-processing. This database tracks indexed nodes as well as which nodes found to be redirects, duplicates, or otherwise aliases of another node.
Regular expressions can restrict the crawl either by defining name patterns.
restrictToTree examples
Example 1: If yourstartLink value is https://altostrat.com, and this site has links to https://archive.altostrat.com and https://cymbalgroup.com, only documents at the domain https://altostrat.com are indexed.
Example 2:
Additional restrictToTree properties are described in Other configuration properties and include:
restrictToTreeAllowSubdomains- Iffalse, all thestartLinksubdomains are excluded. Iftrue,startLinksubdomains are included.restrictToTreeUseHostAndPath- Iftrue, restrict the crawl to thestartLinkpath.restrictToTreeIgnoredHostPrefixes- Defines a list ofstartLinkprefixes that are ignored during the crawl.
startLink value is https://altostrat.com, restrictToTreeis set totrue and restrictToTreeAllowsubdomains is set to true or false.
In the table:
- The headings in columns 2 and 3 specify the settings of the fields.
- A ✅ indicates the URL is indexed.
- An ✘ indicates the URL is not indexed.
Fetcher Configuration Properties
Fetcher configuration properties vary by plugin. Fetcher configuration properties are distinguished by prefix “f.”, for example “f.maxSizeBytes”.Content Filtering and Selection Configuration Properties
These properties are only used by the web plugin. Like the fetcher properties names, they have the prefix “f”.Refresh Policy Configuration Properties
Refresh policies are used to control which items are recrawled, so they only matter on crawls after the first complete crawl, and the default refresh policy is to simply recrawl all items. The refreshAll property is true by default to create that behavior, so the first step in configuring a refresh-policy is to set refreshAll to false. There are five types of refresh policies: “refreshStartLinks”, “refreshErrors”, “refreshOlderThan”, “refreshIdPrefixes”, “refreshIDRegexes”. This is scriptable via a JavaScript function supplied as property “refreshScript”, for example:Dedupe Configuration Properties
Fusion can be configured to deduplicate documents based on:- the entire contents of the document
- the contents of a specified field
- custom deduplication based on a document signature generated by a user-supplied JavaScript function genSignature() which returns a string. The Fusion UI Admin tool provides a JavaScript-aware input box which so that you can create and edit this function directly in Fusion.
dedupeSignature_s field.
If the property “dedupe” (UI control checkbox “Dedupe on Content”) is true but
neither a field or JavaScript function are specified, the raw contents of the document are used for deduplication.
No deduplication signature is generated, therefore the resulting document does not have a dedupeSignature_s field.
Here is an example of a genSignature() function:
f.fieldSelectors property. The entire content object is available here, so implementations of this class can dedupe on any combination of fields. The genSignature() function should return null when the fields needed to generate a signature are not present.
Splitter Configuration Properties
These properties determine how to process .csv and .tsv files.Other Configuration Properties
Property indexCrawlDBToSolr - index most recent crawldb in Solr
This section is only relevant to Fusion 4.x.
crawldb_<data source-ID> which holds the crawldb
for the most recently completed crawl.
The default value is false.
The crawl must finish. Nothing is recorded if a crawl is stopped.
Restricting the contents of the Solr collection to the most recently completed crawl limits the collection from growing very large over time.
It means that at the point where a data source is used to recrawl a website or filesystem, all information about previous
crawls are deleted.
The resulting Solr documents have the following fields:
id. The SolruniqueKeyfield. The value is the concatenation of the map/table in the crawldb to which the doc belongs(see below), and the document ID. The two parts of the composite ID are separated by a|(gate/pipe) character. For example, the id of a document representing aFINISHED_MAPentry for a web page in a web crawl would look like:FINISHED_MAP|https://lucidworks.com/crawlCycle_ti. The crawl iteration, for example, 1 for the initial crawl, 2 for the first recrawl, etc.map_s. The map to which a document belongs in the crawldb
ALIAS_MAPINVERSE_ALIAS_MAPFINISHED_MAPERRORS_MAPSIGNATURES_MAPDELETED_MAP
INVERSE_ALIAS_MAP is the opposite: a mapping of canonicals to all of their aliases. FINISHED_MAP is all items that have been successfully indexed. ERRORS_MAP is all errors. SIGNATURES_MAP will only be there if dedupe is enabled, and it is a mapping of long signature hashes to their canonical item-ID. DELETED_MAP is all of the docs that were deleted in Solr in the last crawl, for example 404s that have failed enough times to be deleted in a web crawl.
FINISHED_MAP and ERRORS_MAP are the maps whose values are actual CrawlItem objects in the crawldb and have the same set of fields, of which the following are useful:
parentID_sdepth_tifetchedDate_tdtemittedDate_tdtlastModified_tdtcontentSignature_sdiscardMessage_slinks_ss