Application of Rules
Rules are typically used by a virtual server to choose a pool to handle a request. The rule can inspect any part of the request, possibly modify it, and decide which pool should handle the request.
Further uses of TrafficScript rules include:
- You can use a rule to dictate session persistence information to a pool. After inspecting the request the rule can use the connection.setPersistenceKey() function to provide a string to persist on. This string is used by the “Universal” session persistence method to identify the session the request belongs to.
- Rules can be used to check the response from the server and modify it, or even retry the request (if possible) if a transient error was detected.
- If you use various back-end systems with different presentation styles or even different protocols, rules can be used to integrate them into a single, coherent and consistent service. Incoming requests can be rewritten into the format suitable for the required service, and responses can be rewritten into a single, consistent form.
- For example, HTTP requests that involve a database lookup can be rewritten into SOAP request for a Web Service; the XML response can then be transformed into a suitable HTML document to return using HTTP.
- Rules can override the classes assigned to a connection by the Virtual Server or the Pool. This way, they can specify custom behaviour for each connection. For example, connections to a slow resource can be given a longer response time tolerance. Classes you can assign in this way include “Service Level Monitoring”, “Session Persistence” and “Bandwidth Management”.
- Service Protection classes can use rules. If you have associated a Service Protection class with your Virtual Server, it inspects the incoming packets. The class might use a rule to check the packet for a match with known Web worms or viruses. This rule is executed before the main processing of the Virtual Server is carried out.