Skip to main content
The API details provided apply to SuperOffice v.9.2 and higher. Find searches do not yet support custom entities or extra tables. SOAP API access via the Services88 endpoints, therefore online Apps must request Services88 to use this API.
The first thing to understand is that search is based on a selection. However, a search doesn’t explicitly require a preexisting selection to perform a search. Using the API the same way the SuperOffice Find dialog works, implicitly creates a selection on a per-associate per-entity basis.

Steps

The steps used to perform a search are:
  1. Get the list of available search entities.
  2. Determine which entity to base the search such as company, contact, sale, project, and so on.
  3. Get the data source used to perform the search, the name of a dynamic selection archive provider.
  4. Get the available data source columns, for specifying return fields and criteria.
  5. Set the search criteria.
  6. Perform the search.
  7. Read the results.

Get the search entities

The Find page dynamically displays all entities that support the new Find system. Find Dialog
Your Find options may not be the same as shown. Available entities depend on the current user’s license.
To determine which entities are available, use the MDO endpoint to get a list of available entities using the SelectionMemberTypeV2 MDOList provider.
The result is an array of MDOListItem and contains the following details. Use the name of the ExtraInfo property to define the search entity.

Results (some properties omitted for brevity)

Use header options to specify an Accept-Language to replace the resource strings with localized labels.

Get the entity data source

You need 2 key pieces of information to get the data source, the archive provider and the selection ID. These are both available in a SelectionForFind instance. Use the ExtraInfo value from the previous results to get a SelectionForFind instance. Use the SelectionAgent.GetSelectionForFind(entityName, typicalSearchId) method to obtain the SelectionForFind type for a particular entity. The value of typicalSearchId determines some internal logic.

SelectionForFind properties

The ProviderName property is the name of the archive provider used to search. In this example, when contact is used as the entity name, the results return ContactPersonDynamicSelectionV2 as the archive provider name. The SelectionId indicates the selection’s primary key for this associate/entity pair. The selection has a default list of criteria used to pre-populate a new selection of this entity type.

SelectionForFind result

The selection ID used here does not appear as an available Selection in SuperOffice. It’s only used for Find purposes.

Provider names

All dynamic Find Selections use an archive provider whose name ends with the V2 suffix. However, when using the Find API, do not rely on this list, instead use the API as shown to ensure you always get the correct provider. These providers are exclusively used together with the new CriteriaGroups for specifying restrictions. Retrieve the SelectionForFind type, then use the provider name and selection ID to set the desired search criteria.

Get the search columns

Search columns are used to define what field to select and specify the criteria for limiting the result set.
Because these never change at runtime, make sure to use caching when able.

Selection criteria

Just like a SQL SELECT statement, where there are any number of select fields and any number of WHERE clause criteria, selections use archive provider columns to determine select and criteria fields. A selection criterion is set using CriteriaGroups. One CriteriaGroup is an ArchiveRestrictionGroup and contains an array of ArchiveRestrictionInfo, and each ArchiveRestrictionInfo is implicitly joined by an AND operator. CriteriaGroup Take the following SQL, for example:
The first WHERE criteria (C.name LIKE 'Super%' AND C.business_idx = 2) is a criteria group, comprised of 2 distinct criteria. To build the equivalent into an ArchiveRestrictionGroup, it looks like this:
CriteriaGroups is an array of ArchiveRestrictionGroup, and each group is implicitly joined by an OR operator. As seen in the example above, the Name and Rank share the same numerical value, represent the order they appear in SuperOffice. The Name and Rank for the next ArchiveRestrictionGroup in the array is 1, and any subsequent group would increment accordingly.

Archive columns

To specify a field restriction you first need to get an ArchiveColumnInfo instance. While it’s possible to lookup archive provider columns using the NetServer documentation reference, it’s recommended to get and cache the columns using the API. This is required to set the required information in an ArchiveRestrictionInfo.

Get archive provider columns

Get archive provider column results

JSON

Important ArchiveColumnInfo properties

Get field operators by data type

A field operator determines what type of operation the criteria performs, such as comparison or range. Use the RestrictionType property to get the available operators for a given data type.

REST JSON results

JSON
Use the Type property to specify the ArchiveRestrictionInfo Operator property.

Example: Working with columns and operators (WebApi client)

Set search criteria

Fetching and saving criteria

The new search routines introduce the concept of criteria groups, where all criteria in a group are connected by AND operators, and all groups in the array of CriteriaGroups are connected by OR operators. Selection CriteriaGroups The main points to understand are:
  1. Each ArchiveRestrictionInfo in an ArchiveRestrictionGroup is implicitly joined by an AND operator.
  2. Each ArchiveRestrictionGroup is implicitly joined by an OR operator.
The grouping and use of the AND and OR operators as such means it’s simple to define, maintain and comprehend how groups of criteria are applied to search routines. The database layout to support this has been in place for a long time and was used in an equivalent fashion for Saint Status definitions. There, each criteria group was in a separate tab in the user interface; in the new Find screen, criteria groups are instead stacked vertically. Selection CriteriaGroups Selection criteria are fetched and stored using the GetDynamicSelectionCriteriaGroups and SetDynamicSelectionCriteriaGroups methods on the Selection agent. Using them will retrieve and save all groups, and avoid having to make assumptions about the StorageKey concept used in the Find agent methods. This example demonstrates how to get existing CriteriaGroups for a given selection.
The following example demonstrates how to set the criteria for the personalized person entity. The criteria say to return all persons where the first name starts with B and ends with Y, or the first name starts with R and ends with Y. The SQL equivalent is:
This code sets the criteria for the personalized selection equal to the SelectionForFind.SelectionId. The SetDynamicSelectionCriteriaGroups[Async] method returns the criteria groups that were passed in.
HTTP
The search is performed using the Archive endpoint, which facilitates passing common parameters, including:
  • Provider name
  • Desired columns
  • Sort order
  • Restriction
  • Entities
  • Page
  • Page size
The selectionId in these examples is obtained from the SelectionForFind.SelectionId property in previous snippets.

Summary

This article has demonstrated how to search SuperOffice using the same routines used by SuperOffice Find. This way guarantees your applications receive the same results observed both in Selections and using the Find dialog.