ServiceGrid Article - Response Filters

From DocWiki

Jump to: navigation, search

Contents

Overview

When pushing a message from ServiceGrid or pulling into ServiceGrid via WebService bridges, the user wishes to specify whether an answer from the target server is meant to be an error or a valid response, instead of the currently programmatic definition. A common example is if a target server returns a SOAP fault in its response. In some cases this means the message was invalid, i.e., it won't work on redelivery. The message can be discarded while another kind of fault may mean that the server is temporarily unavailable. The message should be redelivered.

How does it work?

  1. To every ServiceDefinition from type WebService (PushSoap|PushHttp|PullSoap|PullHttp) it is possible to add ResponseFilters
  2. The filter is composed of the following fields:
Field
Type
Options
Description
SeqNr
Mandatory

Determinates the order in which the response filters will be executed. First in order will be the filter with the lowest sequence number.
Match
Mandatory
All
Matches every response


Response
The filter will match only normal responses.


Error
Only error responses will match with this filter.
HttpCodeRange
Optional
Single number
A single number, e.g., 200


Inclusive range
An inclusive range in the form of A-B, e.g., 200-220 


Mix
A mix of both separated by a comma, e.g., 200, 300-400, 500-503, 508
HttpHeaderRegex
Optional

A field for matching the message itself.
Action
Mandatory
OK
Response will be delivered to the application, push from ServiceGrid messages are marked as sent.


Temporary failure

Generally: Failure notification will be sent to monitoring and to:

Push from ServiceGrid: Message will be resent later.

Pull from ServiceGrid: Message will be discarded.



Error

Generally: Error notification will be sent to monitoring and to:

Push from ServiceGrid: Message will be resent later.

Pull from ServiceGrid: Message will be discarded.



Faulty message

Generally: Faulty message notification will be sent to monitoring and to: Push from ServiceGrid: The response will be delivered to the application and marked as faulty.

Pull from ServiceGrid: The response will be discarded.



Discard The response will be discarded and, for push from ServiceGrid message marked as sent.


Examples

Assume the following response filter exists:

ResponseFilterUI Example 01-13124231.png


And the response to a request looks like:

ResponesFilterUI Example 02-13125014.png


The defined response filter will fire because following conditions are all true:

  • Match: The filter matches everything
  • HttpCodeRange: The response falls into the code range (response code was 200)

When will the response filter NOT match the request?

  • Changing the HttpCodeRange to 200 so it won't be in the correct range...
  • Changing the match field to 'Error' so only error responses will be matched
  • Adding a HttpFieldRegex which won't match the HTTP Header of the response like: .Content-Type: application/xml. (only reponse with content type application/xml will be matched by this value)
  • Adding a MessageBodyRegex which will not match the message body.

What won't effect the matching in this given case?

  • Changing the match field to 'Response' (the response is a normal response)
  • Adding a HttpFieldRegex or MessageBodyRegex which will match the response

Setup

At SD.basicdata > MyCompany > [Company] > Servicedefinitions > [Servicedefinition]

The ServiceDefinition UI has been extended for managing ResponseFilters

ResponseFilterUI 01-21081442.png

ResponseFilterUI 02-27133656.png


http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html


Please be aware that after creating the response filter, you MUST reload the bridge using the function "Reload Bridge" on the main page of the ServiceDefinition.




For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.



Rating: 0.0/5 (0 votes cast)

Personal tools