Whilst for most scenarios the default data object configurations is appropriate SmartIQ offers much more granular such as defining what fields the data can be filtered by, how it should be filtered and what to fields to display to end users or to omit completely from responses. For example an employee table could be configured so that it can be filtered only by id or surname and to ignore some legacy fields no longer used by the organisation. Making its use in forms much simpler for form designers.
Filter fields are passed to data objects at run time to return targeted results. Their use and how they appear will depend on both their both their connection type and object type. For technologies such as web services and database stored procedures they will mimic input parameters whereas for database tables they will list the columns available to build where clauses. See the documentation on the specific data connector for how filter fields apply to specific date objects. Add filter fields as needed.
The 'add custom' field allows you to add fields that aren't already present in your data. This allows for the addition of placeholder fields for any data that is to be written to the data connector in future, or data relationships to be drawn in the Designer. Best not to duplicate already available filter fields.
Required filters are filter fields where a request to a data source will not occur when the filter value resolves to NULL or to an Empty String at run time.
These can be particularly useful for calling data-connections where accidental calls with empty filters can result in large (too large to process) data sets. Required filters protect form designers from common mistakes.
Filter value not presence of filter
A required filter does not mean that the filter must be provided each time the data object is used, rather as stated above that when the filter is used ensure its value does not resolve to a null or empty value.
The image below shows the field EmployeeNo configured as a required filter.
Auto filters are filter fields that is automatically applied each time the data object is used to make a request, filter fields values will be sourced from the users profile at run-time. Auto filters are useful when the results returned always relate somehow to the user at run time, for example retrieve all staff that report to the current user. Ensuring that users can only see their own staff.
Auto filters aid mobile syncing where when configured can return records of interest to the current user for offline use.
The following image depicts the EmployeeNo Filter 'Auto Filtered' to the user's UserId. Thus at run time results will be returned depending on the user making the request.
Schema fields allow the SmartIQ Administrator to omit fields that are not required by the business. This could be that they are redundant or not of interest to the business processes targeted by SmartIQ Using schema fields ensures responses are kept to a minimum to ensure optimal performance.
Support For Schema Fields
Schema fields are not supported by all technologies and will appear only where applicable.
By default where schema fields are applicable a select all Schema fields option will display. To specify particular schema fields uncheck the option and use the dialog provided to select the appropriate fields.
The image below shows a redundant title field being excluded from the schema field list. Essentially making it ignored to SmartIQ.
Display fields define which fields can be seen by end users during a Form. In the image below the salary field is excluded as a display field.
Updated about 2 months ago