Configuring Error Rules

Body

Matching errors & error rules

DataPower allows one to catch a runtime error and execute custom multistep logic at many places during the processing of a transaction. However; there is often a lot of confusion about the configuration of the error rules. In the webGUI; to add an error rule to a stylepolicy; one needs to first create a named rule that executes the desired business logic. This typically has such actions as generating a custom error message or logging a message to a MQ Q

The other step is to define upon which conditions the rule will match. This step involves creating a 'Matching Rule' and selecting a 'Matching Type' of 'Error Code' and one or more error codes or sets of codes.

In support we often see some confusion in this step. An error rule cannot match to anything but an errorcode. However; when creating the 'Matching Rule' the box will not prevent the user from trying to match on other things such as a URL or header. But when an error occurs the rule will not be matched.
When that occurs you will see this signature in the log:

20130906T095952Z [webapp-firewall][error] web-application-firewall(forAlan): tid(646965488)[9.80.31.39]: Error occurred when connecting to URL 'http://127.0.0.1:9012/'
20130906T095952Z [webapp-firewall][error] web-application-firewall(forAlan): tid(646965488)[9.80.31.39]: Valid backside connection could not be established: HTTP response code in response not allowed, url: http://127.0.0.1:9012/
20130906T095952Z [webapp-firewall][error] web-application-firewall(forAlan): tid(646965488)[error][9.80.31.39]: HTTP response code in response not allowed
20130906T095952Z [webapp-firewall][notice] stylepolicy(default): tid(646965488)[9.80.31.39]: No error rule is matched.
20130906T095952Z [webapp-firewall][info] web-application-firewall(forAlan): tid(646965488)[error][9.80.31.39]: No match from processing policy 'default' for code '0x02030004'

So the key for configuring an error rule is to always match on a errorcode. The rules will be evaluated in the order that they are defined; so the 'catchall' would go last.
 

Here is an example of how you could configure this from the cli:

• match on a specific condition, such as a backend connection failure:

    match backend   error 0x01130007  exit

• match on a subset, such as all MPGW errors:

    match gateway_errors   error 0x011*  exit

• match on any error:

    match all_errors   error *  exit

Here is how it would look when displayed:

  matching: backend [up] (new)  -----------------   admin-state enabled   match errorcode 0x01130007 default   match-with-pcre off   combine-with-or off    matching: gateway_errors [up] (new)  --------------   admin-state enabled   match errorcode 0x01* default   match-with-pcre off   combine-with-or off     matching: all_errors [up] (new)  ---------------   admin-state enabled   match errorcode * default   match-with-pcre off   combine-with-or off