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 firstname.lastname@example.org 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.
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.
- Create a Java class that implements the com.extrememessaging.ResponseMaster.dispositions.IDisposition interface.
- Create an entry for the class in the custom Disposition Types File.
- Change the dispositions configuration file to make a category use the new disposition type.
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.
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:
- If you are embedding information in the message headers
- 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.
- 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.
- Create an entry for the class in the custom Message Fields File.
- 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.
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.
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.
- Define the category in the custom Category Definitions file.
- Create new categorization rule files that determine which messages are placed into the new category.
- 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.
- Define the dispositions for the category in the dispositions configuration file.
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)
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.
- Create a new categorization rule file.
- Create a new categorization configuration file that references your new categorization rule file
- 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.
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).
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.
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.
- 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.
- Reference the new class in the Monitor Config File.