...
This objective of this tutorial is to teach the readers how to go about creating
Rules Engine rules
Refiners (also referred to as search result filters)
Primary Details and More Details in the search result
In regards to rules one should note that the empeses in this tutorial is on how to use rules and not so much on how to go about implementing them. There is a relative steep learning curve for creating rules that will be covered in details in the yet to be publised Advanced Rule Tutorial.
Ayfie Locator Saga Architectural Overview describes the overall Ayfie architecture. Below we have copied the graphics that shows the part of that architecture that relates to the Rules Engine:
...
Install the File Server Connector as instructed in section Connector Management of the Ayfie Locator Installation Guide.
Once installed, create a new connection with the test_data directory we created above with our one test file as the data source:
...
The Rules Engine menu bar option is normally not visible. To visualize it, add the URL key-value pair se=1 to the end of the URL as shown here (the key-value pair has to be preceded by a ? or a &):
...
Below we have superimposed our architecture graphics from above upon the Rules Engine UI to drive home the point that the Rules Engine consists of two separate rules set, one for the index side that is carried out before the documents are indexed, and another one for the search side that is carried out before the result is passed on to the end user:
...
To insert and test the rule, do the following.
Click the green Rule Engine Editor icon
Insert the XML from above into the editor
Click the green test button below and verify that the resulting document field is as intended
...
After now having tested and verified that the rule works, save the rule like this:
Name the rule Hello World! by replacing the “CUSTUM_RULE_<DATE>” string in the input field below the rule XML
Click the blue Save New Rule button down to the right
For the rule we just made to take effect, the document has to pass through the index pipeline. That is, it has to be re-indexed. In this simple single document case, that is easiest done by just re-fetching the document as shown in the graphic below for using the same document id as we have used earlier to test the rule.
...
Locator comes with a large number of factory prepared search fields that are tailored to known and well established Locator use cases across the Ayfie customer base. In addition Locator also has what is referred to as dynamic search fields that are template type fields that can be used as the basis for creating new customized search field on the fly to address unique customer requirements. Below we have listed the two that will be used in this tutorial. For a more in-dept explanation in regard to dynamic fields, consult with https://ayfie-dev.atlassian.net/wiki/pages/resumedraft.action?draftId=3073769489. Dynamic Fields Explained.
via_ti_: An Ayfie prepared field (via) of type text (t) that will be indexed (i). Text in this field can be searched word by word.
via_tsi_: The same type of field as the one above except that data in this field will also be stored (s) in the indexed and displayed with the search result.
via_sid_: An Ayfie prepared field (via) of type string (s) that will be indexed (i) and have docValues (d) which is good for refiners. The string stored in this field can only be searched in its entirety from end to end and not word by word.
...
The field will be based on the dynamic field via_ti_ and named via_ti_department. As explained in https://ayfie-dev.atlassian.net/wiki/pages/resumedraft.action?draftId=3073769489 Dynamic Fields Explained, the field will inherit the following features:
...
Instructions on how to log in to the database is found in section Installation Verification of the Ayfie Locator Installation Guide.
Below one can see the same refiner after the selection_limit field has been changed from 1 to 1000. Notice how the radio buttons have become checkboxes.
...
By consulting with Dynamic Fields Explained we see that we need a dynamic field with the prefix via_simd_ or via_ssimd_ (both are multivalued). Since we just need the data to be indexed so that it can be used by the refiner and we do not need it to be part of the search result itself, we can use via_simd_ (that has no second s for storage) even though both will have workedwork.
Go ahead and create the index field via_simd_job_titles the same way we have done it earlier in this tutorial.
...
Once inside the search side document pipeline we enter the rule engine editor to have a look at the document before any search side rules are executed. In the list of key-value pairs there will be some that starts with SDKHit.Metadata@. Among them one will find any dynamic fields with an s for storage (check https://ayfie-dev.atlassian.net/wiki/pages/resumedraft.action?draftId=3073769489 Dynamic Fields Explained for a reminder on index field naming). A little bit earlier in this tutorial we purposly used the prefix via_ipsid_ instead of via_ipid_. If we had used the latter, we would still have been able to create the skill level refiner, but the skill level would not have been among the search side document key-value pairs. As we can see here below, due to the s in via_ipsid_skill_level the field made it intp the document that is retreived from the index:
...