Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Operations Manager i10.62

Develop > Automate operator functions and event change detection > Event Web Service query language > HTTP query parameters

HTTP query parameters

This section describes the HTTP query parameters that are supported by the Event Web Service.

These query parameters apply only to collection resources and are only meaningful when used with the HTTP GET method, or when updating events in bulk with the HTTP PUT method. They are specified within the HTTP query portion of the URL that addresses the resources.

A client can specify that the response feed should be filtered by only including resources where the meta-data or data for the resource matches certain criteria. This can be specified using the query parameter within the HTTP query portion of the URL.

Query filter criteria properties lists the available query filter criteria properties and supported operators.

This section includes:

List of HTTP query parameters
Filtering by date and time: watermark
Filtering by event attributes: query
Paging
Ordering
Data inclusion
Media type

List of HTTP query parameters

The following are a list of parameters that may be specified in the HTTP query portion of the URL. Query parameters can be specified in combination, separated by the ampersand (&) operator.

Query Parameter	Description
`watermark`	Parameter for filtering by date and time. For details, see Filtering by date and time: watermark.
`query`	Parameter for filtering by event attributes. For details, see Filtering by event attributes: query.
`start_index`	Paging query parameter used to define the item from which to start the query. For details, see Paging.
`page_size`	Paging query parameter used to define how many items are displayed per page of an atom feed. For details, see Paging.
`order_by`	Ordering parameter used to specify that the response feed should be ordered by the indicated field. For details, see Ordering.
`order_direction`	Ordering parameter used to specify whether the response feed should be ordered in either descending or ascending order. For details, see Ordering.
`include_closed`	Parameter used to specify whether closed events are included when querying the Events Service (`event_list`). Default value: `false` For details, see Data inclusion.
`include_relationships`	Parameter used to specify whether relationships are included when querying the Events Service (`event_list`). Default value: `true` For details, see Data inclusion.
`include_history`	Parameter used to specify whether history lines are included in the events when querying the Events Service (`event_list`). Default value: `false` For details, see Data inclusion.
`include_cis`	Parameter used to specify whether configuration item properties are included in the events for related CIs, nodes, and affected business services when querying the Events Service (`event_list`). Default value: `true` For details, see Data inclusion.
`include_annotations`	Parameter used to specify whether annotations are included in the events when querying the Events Service (`event_list`). Default value: `false` For details, see Data inclusion.

Filtering by date and time: watermark

A client can specify that the response feed should be filtered based on time. These query parameters apply only to collection resources and are only meaningful when used with the HTTP GET method.

You can query items by time and date using the watermark parameter. If the watermark parameter is specified, only events that have been created or updated after the specified time are returned. For example, when an application that is monitoring new and changed events using the web service shuts down, it will want to remember the time of the last changed event. In this way when it restarts it can query for only those new and changed events since this timestamp.

For instance, watermark=2009-01-01T00:00:00Z indicates that the only resources to be included in the response feed have been updated after the beginning of 2009.

Alternatively, you can get a list of events from a certain sequence number onwards by specifying the sequence_number parameter.

Time format requirements:

dateTime Format. Like all times specified in a query, the value for the watermark parameter must be specified in the XML Schema dateTime format. If there are no resources in the collection that have been updated after the specified date, the response feed will be empty. A poorly formatted value for the query parameter (for example, one that does not conform to the XML Schema dateTime format) will cause a fault response.

For more details about XML Schema data types, see the XML schema document, which you can find in the following location:

http://www.w3.org/TR/xmlschema-2
Time Zones Encoding. When specifying a time zone other than GMT using "Z", you must specify a "+" character. Because this is in the URL it must be URL encoded by replacing it with "%2B". An example would be:

query=time_created%20GT%202009-10-19T17:06:54.453%2B02:00

For a list of URL escape codes for characters that must be escaped, see URL escape codes for characters that must be escaped.

For full details about URL encoding, see the Uniform Resource Locators (URL) Specification at the following location:

http://www.rfc-editor.org/rfc/rfc1738.txt

Examples:

An example of a URL call where only events after 13:59:17 on March 19, 2010, are listed would look like this:

https://<server.example.com>/opr-web/rest/9.10/event_list?format=atom&watermark=2010-03-19T13:59:17%2B02:00
The following example URL returns the first 40 currently open events since 15:59:17 on March 4, 2010 in an atom feed format.

https://<server.example.com>/opr-web/rest/9.10/event_list/?format=atom&watermark=2010-03-04T15:59:17%2B02:00&page_size=40&start_index=1

Filtering by event attributes: query

The query parameter facilitates filtering the request using specific event attribute values. The criteria for the query filter are:

A filter property specifying an event attribute
A supported operator
A value for the property

Compound Filters

You can compose multiple filters for more complex filter queries. Filter query parameters can be used in combination, separated by logical NOTs, ANDs, and ORs, which are resolved in the order specified. To achieve a different processing order of the query, use parentheses.

Examples:

The following example shows two simple filters made into a compound filter query using the logical AND:

https://<server.example.com>/opr-web/rest/9.10/event_list?query=assigned_user%20EQ%20"admin"%20AND%20title%20EQ%20"My Title"
The following example shows a compound filter query made up of a combination of a simple and a complex filter, using a logical AND:

https://<server.example.com>/opr-web/rest/9.10/event_list?query=assigned_user%20EQ%20"admin"%20AND%20related_ci[target_id%20EQ%20"ffca22eea15268533029f17b4c01b008"]
The next example shows how you would compose a compound filter so that the logical ORs are resolved first.

https://<server.example.com>/opr-web/rest/9.10/event_list?query=assigned_user%20EQ%20"admin"%20AND%20(title%20EQ%20"My Title"%20OR%20state%20EQ%20"closed")
The next example shows how you would use the NOT operator to negate an expression:

https://<server.example.com>/opr-web/rest/9.10/event_list?query=assigned_user%20EQ%20"admin"%20AND%20(title%20EQ%20"My Title"%20OR%20NOT%20state%20EQ%20"closed")

Paging

You can optimize the query result by specifying some additional URL parameters. Paging query parameters are used to filter the entries in a response feed to a subset of those that would be returned without the query parameters. Paging query parameters apply to collection resources and will have no affect on an individual resource. They are only meaningful when used with the HTTP GET method. Paging query parameters are applied to a response feed after considering all other filtering query parameters.

There are two query parameters that work together to provide an interface that a client can use to page through a feed with a large number of entries: start_index, and page_size.

Combining start_index and page_size

By combining the start_index and the page_size parameters, you can view the result distributed over more than one page. The value of start_index must be greater than 0.

For example, if you call the URL with a page_size of 5, but do not define the start_index value, the first five items (items 1 - 5) will be returned.

If you call the URL with a page_size of 5, and define the start_index value as 6, five items starting from the sixth item (items 6 - 10) will be returned on the second page. So the result of the query would be that 10 items are returned, distributed over two pages of an atom feed.

So, to return the first page (items 1 - 5) of query results filtered by the severity parameter set to equal warning, you would call the following URL:

https://<server.example.com>/opr-web/rest/9.10/event_list?format=atom&query=severity%20EQ%20"warning"&page_size=5

To get the second page (items 6 - 10) of query results, you would call the following URL:

https://<server.example.com>/opr-web/rest/9.10/event_list?format=atom&query=severity%20EQ%20"warning"&page_size=5&start_index=6

A client using paging can keep the page size constant for every request or can vary the page size for every request. The pages can also overlap. In the examples above with start_index set to 3 and page_size set to 5, the requested page will overlap with the first page. There is no guarantee that a client will not see duplicate entries, or that a client may miss some entries due to additions or deletions between page requests.

Links are set in all feeds to indicate how to get to the first or last page. When not all of the entries are returned due to paging, links also indicate how to get the next and previous pages. The links are described by setting the rel attribute to “first”, “last”, “next”, or “previous”. These links are described in RFC5005, which you can access at the following location:

http://tools.ietf.org/html/rfc5005

Ordering

A client can specify that a response feed should be returned with certain ordering criteria. These query parameters apply only to collection resources and are only meaningful when used with the HTTP GET method.

Data inclusion

With data inclusion query parameters, a client can control the amount of relevant data returned by the query, thereby directly influencing the performance of the response.

Media type

A client can request that a response be returned with a specified media type.

Send Help Center feedback