Within the Changeset page, objects can be found with the use of queries. In the case of an “update” or “delete” action, a query can be used to find the object that will be modified. If the query matches multiple objects then that action will apply to all matched objects.

Queries can also be applied to parameters that are looking for a related object (Reference Properties). In this situation, the query must match against one object. If multiple objects are found, the query generates a validation error.

If a query is used on an upadate or delete action, an multiple matches are found then the action will be applied to each match. Using the simulate run feature helps to ensure that the Changeset meets the desired outcome.

When performing a search within a changeset it is critical to factor in the changes that will be performed by the Changeset. A Changeset could be updating a object that could either qualify or disqualify it from the result result set. This is why the InProd Changeset query functionality factors in any changes that will be performed by the previous actions, ensuring a predictable outcome.

Simple query

Basic queries can be created with the format of parameter=value. String values should contain single quotation mark and integer based fields do not require a quotation mark.

Multiple queries

Multiple conditions can be added by separating each query element with a comma and a space. Example:

name=’lab1’, state=’Enabled’

Note: If there is no space after the comma, it will be seen as one query instead of two separate queries.

Variable driven queries

InProd Changeset Variables can be used at any point within the query text. As the variable value is resolved before the query is executed, any component of the query can be a variable including the entire query.

Query methods

There are times when a simple exact match query is not adequate. InProd supports a number of query methods that can be used in these situations. To apply a query method, a double underscore is placed at the end of the field name, such as name__startswith=’lab’ The supported query methods are:

• __startswith: matches the beginning of the text
• __endswith: matches the end of the text
• __exact: this is the default used on all fields and is not needed to be applied
• __contains: finds a partial match in any part of the value
• __regex: apply regular expression matching, powerful but complex in nature

Additionally, a lower case ‘i’ can be placed at the beginning of any query method to make the query case-independent. For example name__iexact=’lab1’ will match ‘Lab1’ and ‘lab1’

Related fields

Some objects contain a link to a related object, such as the “Application” object parameter which has the “Host” field. Performing a query against the dbid value is not very useful. Related queries can match against parameters of the related object. Again, the use of a double underscore is used to separate the field names. The following examples are used to create a query on the “host” object within the “Application” object

• hostDbid__name=’Centos’ looks for a host called ‘Centos’
• hostDbid__name__iexact=’centos’ will match any case (‘Centos’ or ‘centos’)

Dependant objects

When performing Genesys changes there are situations where it is desirable to update all dependant objects. Using the related fields query syntax it is possible to return all of the Genesys Application objects that have an entry within their connections tab to the Application object in question. In this example, all Applications will be matched that has a connection to the application named ‘MS4_Primary’

connections__applicationDbid__name=MS4_Primary

Key Value Queries

Key value parameters contain dictionary data, such as the “annex” parameter that exists on all objects and the “options” parameter on the “Application” object. The value of any given key can be queried against with the use of a double underscore. For example, to query against the “log” section of an application looking for objects that have the ‘buffering’ enabled use

log__buffering__iexact=’true’

Folder path Queries

As the normal search functionality does not work well for locating a folder, a folder specific search parameter called ‘path’ was added

Path is defined by [Tenant Name]/[Root Folder]/[Folder n+]

• Tenant = Environment
• Root Folder = Applications
• Optional folder = Core_componets

DN folder path queries

As DN folders are nested under a switch object they use a slightly different format

[Tenant Name]/[Switch name]/[Root Folder]/[Folder n+]

• Tenant = Environment
• Switch = SIP_Switch
• Root Folder = DNs
• Sub Folder = Agent_Extensions

.