Creating Searches
Creating searches
Using
[SEARCHES] > [TABLE], the Ardexa Web App provides to you the ability to generate data reports from your workgroup data. 
All new searches start with first selecting the table where your data is stored.
All of the following conditions must be met for a table to be available for selection in the
[Tables]list: - the table must be first defined, and
- the table must be populated with data collected from your devices and their sources, otherwise it won't appear in the list, and
Table definitions are pre-configured. To create a new table definition please contact your account manager for assistance. This help article assumes that your table is available.
After selecting the table with your data, the Ardexa Web App will automatically present to you the search view ready for you to manage and execute your searches.
When you first select your table, the total number of records in your selected table are immediately provided to you in the upper-left corner of the view.
The 
button, found on the right-hand side of the view is used to execute searches against your data collected from your devices. At any time while building your search you may click the button and a search will be conducted based on the current parameters you have set in the view.
[GO] 
A search time-frame is period from which you would like the data to be retrieved from the selected table.
Common timeframes are a list of preset periods that are provided by the Ardexa Web App to you for easy selection. The default value is button with
today. If you were to click today selected, this example common time-frame would attempt to retrieve all records from the selected table from midnight (last night) until 11pm, 59 minutes today in your local time.As an example,
today may translate to: Start: 01/01/2019T00:00 End: 01/01/2019T59:59
The
[Common timeframes] field offers the custom value at the end of the drop-down selection list. A custom value allows you to set a specific time-frame including hours and minutes. Custom values are not relative to your present time, i.e. they are fixed.Hint: if you wish to review the literal translation of a pre-set Ardexa [Common timeframe], then do the following:
- 1.Select a pre-set Common timeframe value from the list, eg,
this monththen, - 2.Select the value
customafter your initial selection; the literal timeframe translations will now appear in the view.
However, keeping the selected value as custom will maintain the literal values against the search should you ever decide to save the search.
This is important when you come to retrieve a saved search, as you will be supplied the literal time frames from the past if the value of Common timeframe is kept as
custom.Hence, the pre-set, relative Common timeframe will not be applied if it is saved with a value of
custom. More on the behaviour of custom selection and saved searches below. All searches are conducted using your local time wherever that may be.
Example; you might move time zones, log into the Ardexa Web App and then run a saved search. The search will be conducted using your new time zone and the data retrieved are likely to be different had you been in your old time zone.
Example; two different people in your team run the same 'today' search from different time zones, at-the-very-same-time; then the concept of today would apply locally and the data retrieved for each person would likely be different. Essentially, the period defined for, what is today for me in one timezone is different for what is today for you in another timezone.
The following demonstrates a
today query taken at the same time from different time zones against the same data:Time Zone: AEDT (Australia) | Time Zone: CET (Germany) |
.png?alt=media&token=e7300c2f-0ad3-4d60-9edf-4fe7314625da) | .png?alt=media&token=de043416-909b-4043-989b-618274654c86) |
Current Date-Time: 08/11/2019 @ 12:35pm
Today translation:
Start: 08/11/2019:00:00
End: 08/11/2019:12:35 | Current Date-Time: 08/11/2019 @ 2:35am
Today translation:
Start: 08/11/2019:00:00
End: 08/11/2019:02:35 |
Search filters allow you to selectively determine which records to retrieve from your table by applying custom rules as filters. Filters are used to include or exclude data from being returned in your search. They can be simple or very complex.
A filter is not necessary to run a search; at it's most basic, without a filter, a search will return all records in the table.
A complex search filter in process of being constructed
[AND] / [OR]buttons- These buttons define how the filter rule operate in relation to the surrounding rules that you may create. For example, if you were to create two filter rules, the AND/OR will operate as:
ANDboth rules operate on the data, and both rule conditions must match for the row to be returned/included in the search results.ORboth rules operate on the data, and if either condition of the rule matches the data then the row is returned/included in the search results.
[ADD FILTER] - Adds a further filter entry for you to complete.
- Each filter rule is applied to your search when the search is executed.
- Filter rules can be nested using the
[ADD GROUP].
[ADD GROUP]- For grouping and nesting collections of filters.
- Separated and related to other rules by using of
[AND]/[OR]
(table field)(1st field in the filter rule)- Choose the table field you would like to apply your filter rule.
condition operator(2nd field in the filter rule)- The operator upon which the filter rule is based eg:
=,<=.
conditional value(2nd field in the filter rule)- The test value upon which the filter rule is based.
- Some table fields will resolve and offer pre-defined values, others will require text, numeric or date values to be entered
Click the
button to execute your search.
Search Outputs help define how a search will appear. Changing these values may still require the search to be re-run for the changes to appear.
Select the
[TABLE] tab and enable tabled data via the Enable checkbox. This allows you to view your tabulated search results. 
Rows- Limit how many rows from the search results are added to the CSV.
Date format- Choose the date format to be applied to the
EVENT_TIMEfield. The search will need to be re-run for the changes to take affect.
Columns- Independent of your table columns, choose which of your search result columns are to be included in the
TABLEof data. - Drag your desired fields to-and-from the
Hidden Columnslist, or click on the[Add all]/[Hide all]buttons to add/remove all fields. These changes will be applied in real-time to your tabulated data.
The searches view also displays the total number of
Hidden Columns , a filter box and the ability to reduce the Hidden Column to a smaller more manageable subset.If your list of columns exceed a certain limit, the
[show more] / [show less] toggles will be displayed.
Provided through the customization extension, you have the ability to apply some specialised features to assist in building your searches. These include:
- Force your search to only return duplicated records. Handy for problem data analysis.
A single search table may potentially be populated by many devices and their sources. This scenario will result in many data columns in your search tables, with some of these columns not being relevant to other devices. Yet, at times you may only be interested in viewing data and columns populated by a particular device or devices.
You can use this switch in your SEARCHES to limit the display columns to only those columns of devices mentioned in your search filters (devices that populate those columns)
- This switch will remove all columns for display that are not associated to a device mentioned in your search's search filters.
- This allows you to focus on columns that are sourced from specific device' fields. A handy tool when a given table is sourced from a multitude of devices. In this scenario, fields on other devices also populate columns to the same table under search, however they are not relevant to you in your current search parameters, in which case the
Device Only Fieldsswitch can assist you. - When activated, columns displayed are reduced where a search filter of
deviceand it'svalueare provided in your search filters. - Filters using the operators
INLIKEand=are evaluated.
Consider the following example where we have a complex nesting of search filters using various devices in the workgroup.
- The columns in this table
agent-black-boxare sourced from the devicetest-pi
To restrict table columns to those fields only sourced from
test-pi we would need to do the following:- 1.Include the device in a search filter (any filter)
- 2.Check the box
Device Only Fields
Note: If all devices provided in the search filter are not source providers for the table then all the available columns will disappear as expected.
To return your search columns, either;
- correct your search filter, or
- uncheck
[Device Only Fields]
Note: the following core fields will always be provided:
sourcedeviceevent_time
Search fields contain a variety of resolved data and raw data. Where the data for a particular field is resolved, the option to search against that data is provided to the user as a pre-defined list in a dropdown. eg:
[user_id]will resolve to a list of user names within the current workgroup.- Precise data matches can only be used for operators
LIKE,IN,NOT IN
[action]being a potentially endless list is not provided as a resolved list for selection.- Precise data matches are not necessary for operators
LIKE,IN,NOT IN. Hence, wildcards can be used.
Events, such as device activity, source activity and user actions are collected and stored in the
audit_logs and incident_logs tables for later interpretation. Incident logs capture events from alerts that have been pre-created under the
[ALERTS] tab. The extent and variety logged are only limited by the definition and number of the alerts you create.- User role(s) of type:
owner,admin,power,standard,read-only
NOTE: Like
audit_logs, similar rules apply to searches against theincident_logs table. Please refer to the Audit Logs section for reference.Last modified 2yr ago