Wednesday, 4 November 2015

Using Full-Text Search

Hi Everyone

Sometime you need to do some customization to meet customer requirements. One of these requirements can be an additional field where they can store some references to other systems/documents.

But when you have a reference you have to search it in the system. Here I will guide you, how to customize Acumatica to be able to search additional fields.

The main thing that we have to customize here is PXSearchableAttribute, which always have to be defined on NoteID field (you know that NoteID is main and unique reference to any row in the Acumatica database). IF you can check the code of this attribute you can see:

The main things here are first 4 lines,  that define the way how system will index field from this entity. So we need to add one more type to the Title fields of Other field collections.

But before that we have to determine, what BQL Type should we use for our custom field. It is not a problem if you use extensions with Visual Studio, as you have all code. But in Customization Manager it can be a problem, so lets check first:

OK, now we have a BQL type, lets update exiting PXSearchable on NoteID Field:

Now we can publish customization and use full-text search feature as we wish.


If you want to search field that is related to the different DAC, you can use PXDBScalar, so sub-select required fields to the current DAC. Please note, that this can affect performance of the product.

In the end i want to describe you some additional stuff that you can use with Researchable:
  • Line1Format/Line1Fields + Line2Format/Line2Fields - are designed to define the way, how system will show search results. You can redefine it and see how system change the result.
  • NumberFields - If a field is a number with a prefix like CT00000040 then searching for 0040 can be a problem. All fields that are list here will get special treatment and will be indexed both with prefix and without one - CT00000040, 00000040
  • SelectDocumentUser - Select<> construction that will select the User of the document. If this select is specified then only those records/documents are shown that were either created by the current user or current user matches the User of the document. The company tree hierarchy is not traversed. Ex. Use this setting to filter Expense claims, Timecards, etc.
  • WhereConstraint - Constraint that when set controls whether the given instance of a DAC is searchable or not. Ex: Contact DAC is used to represent different types or records including lead which is searchable where as account property is not.
  • MatchWithJoin -  When a MatchWith Type is used. Join has to be specified for the Entity containing the GroupMask column. Ex. When checking the ARInvoice a join to Customer must be provided. If Customer is not accessible, than invoice should be not accessible ether.
  • SelectForFastIndexing - When specified this select is used for Mass-Process index rebuild. Search may include additional joined tables so that if a searchable fields can retrieved in one select and avoid the lazy-loading for each and every row through selector.

Code from this example:

No comments: