1. Overview

This document describes some of the advanced customization that is possible with ResponseMaster. While all of these features are supported, we would appreciate it if you contact   support@extreme-messaging.com before     
using them. That way, we can understand how our customers are using the features, and we can let you know if we have anything similar under development.

2. Custom Dispositions

You can create your own custom dispositions to integrate ResponseMaster more directly into your system.
There are three steps to creating and using a custom disposition type.

  1. Create a Java class that implements the
    com.extrememessaging.ResponseMaster.dispositions.IDisposition

    interface.
  2. Create an entry for the class in the custom Disposition Types File.
  3. Change the dispositions configuration file to make a category use the new
    disposition type.

2a. DispositionTypesFile

The custom disposition types file (usually customDispositionTypes.xml) contains the list and definitions of the disposition types. It contains a
root DispositionTypes node with a DispositionType node for each disposition type. Each DispositionType node contains the following elements:

  • Name – The name of the disposition type
  • DetailedDispositionFile – 1 if the disposition type uses a detailed disposition
    file, 0 if not
  • ClassName – The name of the class that implements the disposition type.
    This class must implement the IDispositionType interface.

Please refer to CExampleDisposition.java for an example custom disposition.

3. Custom Message Fields

You can create your own custom message fields if you need to extract information from the responses that ResponseMaster doesn’t provide. Two examples when you would want to do this are:

  1. If you are embedding information in the message headers
  2. If you are using Variable Envelop Return Paths (VERP) to encode information
    about the recipient or the list into the Return-Path or From address.

There are three steps to creating and using a custom message field.

  1. Create a Java class that implements the
    com.extrememessaging.ResponseMaster.MessageFields.IMessageField
    interface.
    Note: You may be able to use our 
    Parameterized Message Fields
    instead of creating your own.
  2. Create an entry for the class in the custom Message Fields File.
  3. Make use of the field in a detailed disposition file or in a custom
    categorization rule. Your new custom message field is treated exactly
    like the message fields that are provided with ResponseMaster.

3a. MessageFieldsFile

The custom message fields file (usually customMessageFields.xml) contains the list and definitions of the fields that will be extracted from a message. It contains a root MessageFields node with a MessageField node for each message field. Each MessageField node contains the following elements:

  • Name – The name of the message field
  • DataTypeClassName – The class name of data type of the message field.
  • FetchingClassName – The name of the class that is used to get the value of the
    field from the message. This class must implement the IMessageField
    interface.
  • Parameter – A string that is passed to the Initialize method of class that
    implements the field. This could be used, for example, to provide
    the scheme used by the message generation system to encode the VERP.
  • NotNull – 1 if this field is not allowed to be null, 0 if it can be null –
    used only by the configuration program.
  • ConstantLength – 1 if the field is always the same length. 0 if the length is
    variable – used only by the configuration program, only valid for String
    fields.
  • DefaultLength – The default length for this field – used only by the
    configuration program, only valid for String fields.
  • ExcludeFromFieldList – 1 if the message field should be excluded from the field
    list in the configuration program. 0 (or missing) if it should be
    included.

Please refer to ExampleMessageField.java for an example custom message field.

4. Custom Categories

You can create your own custom categories if you want to allow the user to interact with you by responding to the mailings you send. There are four steps to creating and using a custom category.

  1. Define the category in the custom Category Definitions file.
  2. Create new categorization rule files that determine which messages are placed
    into the new category.
  3. Add those categorization rule files to the categorization config file.
    Note: The order of the rules is important. Once a message matched
    a rule, processing stops for that message.
  4. Define the dispositions for the category in the dispositions configuration
    file.

4a. CategoryDefinitionsFile

The custom category definitions file (usually customCategoryDefinitions.xml) contains the list of categories. It contains a root Categories node with a Category node for each category. Each Category node contains the following elements:

  • Name – The name of the Category
  • OriginalAddressIsFrom – 1 if the From address should be used as the
    Original To. 0 if the Original To address should be extracted from the
    message.
  • IsDefault – 1 if this is the default category (it should be 0 for all other
    categories)

5. Custom Categorization Rules

You can create your own custom categorization rules to place messages into your custom categories. There are three steps to creating a custom categorization rule.

  1. Create a new categorization rule file.
  2. Create a new categorization configuration file that references your new
    categorization rule file
  3. Add another CategorizationRulesFileName element to the Mailbox(es) that you
    want your rules to apply to. Note: If you place your
    CategorizationRulesFileName first, your rules will be processed before the
    built-in rules; if you place your CategorizationRulesFileName second, your
    rules will be processed after the built-in rules.

5a. CategorizationRuleFiles

The categorization rule files define the text matching rules that determine when a message matches a category. Most of the categorization rules that Extreme Messaging provides are encrypted, but you should not encrypt yours. Each file contains a root CategorizationRule node. Under the root node, there are the following nodes:

  • Name – the name of the rule. This should be unique.
    It typically matches the name of the file that the rule is stored in.
  • Rules – contains a collection of Rule nodes. All Rule
    nodes must be satisfied for the overall rule to be matched.

    • Rule – a rule that should be matched
      • Field – The name of the field of the message that should be compared to the
        value
      • Operator – The method used to determine if the Field matches the Value.
        • Possible values: “Contains”, “BeginsWith”, “DoesNotContain”,
          “DoesNotBeginWith”, “ContainsNumericWord”, “RegularExpression”, or “NotRegularExpression”.
        • ContainsNumericWord means to match a number only if it isn’t part of
          a larger number.
        • RegularExpression and NotRegularExpression use Perl5 regular expression syntax.
      • Value – The value to compare the field to.
      • IgnoreWhitespace – 1 if whitespace should be removed from the field before
        comparing it. Use this when the value to be matched may be wrapped across
        lines. 0 if the field should be compared directly.

Note: the categorization rule files MUST be stored in Unicode (little-endian).

5b. CategorizationConfigurationFile

The categorization configuration file (usually categorization.xml) defines the order in which rules are applied to the message. Once one rule is matched, processing stops. It contains a root CategorizationRules root. The root node contains a Version node which is used just for logging, and a bunch of Rule nodes. Each Rule node
contains the following nodes:

  • RuleFileName – The name (and path) of the categorization rule file.
  • Category – The name of the category that this rule defines.
  • Encrypted – 1 if the rule file is encrypted. 0 if not.

6. Custom Monitors

You can create your own custom monitors if you need to integrate ResponseMaster into another application’s logging, or you need to integrate it into your
systems management software.

There are two steps to creating and using custom monitoring.

  1. Create a Java class that implements the
    com.extrememessaging.ResponseMaster.monitor.IMonitor
    interface.
    Note: It is typically easier to extend
    com.extrememessaging.ResponseMaster.monitor.CMonitorBase
    and
    override the methods that handle the events you are interested in.
  2. Reference the new class in the Monitor Config File.