Filtering Packages and Package Entries

Overview of Filtering

A filter is a property of a subscriber that enables that subscriber to receive only content that meets certain criteria. Filters can be used to exclude content that the subscriber is not interested in, or that the subscriber's computing resources cannot handle. Filters can be defined based on the entry type, MIME type, or one or more name/value pairs that are defined for the content. A filter can be an include filter, which means that the subscriber receives all content that meets the filter criteria, or an exclude filter, which means that the subscriber receives all content that does not meet the filter criteria.
When packages are published to channels, name/value filters can be used to limit the packages that are published to individual subscribers. Subscriber-specified name/value filters are compared to the name/value pairs in the published packages. If the filters match the package, then the package is published to the subscriber.
Subscribers use the Publishing Framework plug-in for SAS Management Console to define subscribers. If a subscriber specifies a delivery transport of queue, then that subscriber can specify additional filters to limit the package entries that are included in the packages that are published to that subscriber. Package entry or MIME type filters are compared to the entry type or MIME type of each package entry. If the package entry type or MIME type matches the subscriber's entry type or MIME type filters, then that package entry is included in the package that is published to that queue subscriber.
Note: For each type of filter (entry type, MIME type, or name/value pair), you can define either inclusion or exclusion filters (but not both). If you have previously defined exclusion name/value filters, for example, and then specify an inclusion filter, then all of the previously defined exclusion filters are deleted from the repository.

Enabling Filtering When Publishing Packages

During package development, user-defined name/value pairs are added to packages in the PACKAGE_BEGIN CALL routine. Entry types are added to package entries automatically in the various INSERT CALL routines. User-defined MIME types are added to package entries in the INSERT_FILE CALL routine.
At publish time, filtering takes place when a package is published with the PACKAGE_PUBLISH CALL routine with a publishType of TO_SUBSCRIBERS.

Implementing MIME-Type Filters

MIME types provide details about the information that is being published. For example, specifying the MIME type audio/basic indicates that the file is an audio file and requires software that can interpret such content.
You can define a filter that determines the type of information the subscriber receives. For example, a subscriber who is connecting with a modem might not want to receive some data types that might be large or unwieldy, such as movies or audio. By excluding those MIME types, the subscriber never encounters those types of information.
The MIME type filters are case-insensitive filters. Like name/value pairs, MIME types are user-defined and as such need to be maintained globally to ensure consistent filtering. See the INSERT_FILE CALL routine for a list of suggested MIME types.

Implementing Entry-Type Filters

Each published package contains one or more entries. Each entry is one of several possible types. You can create a filter to include or exclude one or more entry types. Entry types are specified automatically in the various INSERT CALL routines. For a list of available package entry types, see the syntax description of the ENTRY_FIRST CALL routine.

Implementing Name/Value Filters

Publishers can specify name/value pairs that describe the package that is being published. Knowledge of name/value pairs enables you to define filters for a subscriber that determine the packages that are received. If an inclusion name/value filter is defined for a subscriber, then the subscriber receives only those packages that match the name/value filter.
To implement name/value filters across your enterprise, the name/value pairs applied to packages must agree with the name/value pairs that appear in subscriber filters. Maintaining a global list of agreed-upon name/value pairs and including definitions and usage information for each name/value pair enables accurate package description and subscriber filtering in your enterprise.
The name/value filters used in your enterprise depend on the types of packages that you publish and on the types of subscribers that receive those packages. For example, you could define a channel called Maintenance that includes e-mail subscribers and an archive subscriber named MaintReports. You could add a name/value filter to the subscriber definition for the MaintReports archive subscriber that would refuse to accept packages that contain a name/value pair of noarchive. For this filter to be effective, packages published to the Maintenance channel would need to include the noarchive name/value pair in the appropriate way in order to keep unwanted packages out of the MaintReports archive. A global list of name/value pairs would help ensure that the filters and the packages both used the noarchive name/value pair appropriately.
A wide variety of syntax options for name/value filters gives subscribers many filtering options, including filtering based on logical relationships between multiple name/value pairs.
A name/value pair is expressed as either a name or a relationship between a name and a value in the following form:
name < operator value >
where
  • name is a variable to which a value can be assigned. name is not case sensitive.
  • operator relates the variable to the value.
  • value is a character string or numeric value. value is case sensitive.
The following table lists commonly used operators:
Commonly Used Operators
Comparison Operators
Logical Operators
= (equals)
& (AND)
!= (not equal)
| (OR)
? (contains)
The following is an example of a package description that uses name/value pairs that a publisher has assigned to a published package:
market=(Mexico, US) type=report Quarter4 sales _priority_=low
Subscribers can write meaningful filters if they know the conventions that a publisher uses to describe packages. The following examples illustrate filter strings that determine whether the preceding example entity would be selected by the filter. If the package meets the filter conditions, then the package is delivered to the subscriber.
market=(US, Asia, Europe)
No match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name MARKET must match exactly. In this example, the subscriber filters for US, Asia, and Europe, whereas the publisher assigns a value of Mexico and US. The conditions for selection are not met. Therefore, the package is not delivered to the subscriber.
market=(mexico, us)
No match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name MARKET must match exactly. In this example, the subscriber values do not match the publisher values because of case differences.
market=US | market=Asia | market=Mexico
No match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name MARKET must match exactly. In this example, although the OR operator (|) might seem to cause a matching condition, the equals operator (=) requires that each name/value pair that is separated by an OR operator (|) match the publisher name/value pair entirely. A match would result if the subscriber values were written as follows: market=Mexico, US | market=Asia | market=Mexico The first name/value pair in the series would match.
market=(Mexico, US)
Match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name MARKET must match exactly. In this example, the value set does match.
market=(US, Mexico)
Match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name MARKET must match exactly. In this example, the value set matches, regardless of the order of values within the value set.
market?US & market?Asia & market?Mexico
No match. The conditions that are specified in the subscriber name/value pair read: Variable name MARKET must contain the values US and Asia and Mexico. The contains comparison operator (?) identifies the eligible values for consideration. In this example, although the publisher variable MARKET contains US and Mexico, it does not also contain Asia. Because the logical AND operator (&) is used, its condition is not satisfied.
market?US | market?Asia | market?Mexico
Match. The conditions that are specified in the subscriber name/value pair read: Variable name MARKET must contain the values US or Asia or Mexico. The contains comparison operator (?) identifies the eligible values for consideration. In this example, the publisher variable MARKET contains US, and the logical OR operator (|) condition is satisfied.
Quarter4=sales
No match. Because the equals operator (=) is used, the subscriber values and the publisher values that are assigned to the variable name QUARTER4 must match exactly. In this example, because the publisher variable name QUARTER4 does not contain a value and the subscriber variable name QUARTER4 does contain a value of sales, the value sets do not match.
Quarter4
Match. Variable names are not required to have values. In this example, because the publisher variable name QUARTER4 does not have an assigned value and the subscriber variable name QUARTER4 does not have an assigned value, the value sets match.
type=report & forecast
No match. Two conditions must be met. The equals operator (=) requires that the subscriber values and the publisher values that are assigned to variable name TYPE match. In this example, the first condition is met because both the publisher and the subscriber assign the value report to variable TYPE. However, the AND logical operator (&) requires that the variable name TYPE also be assigned the value forecast. Because the publisher variable name TYPE is not assigned a value of forecast, the final condition is not met.
type=report & sales
Match. Two conditions must be met. The equals operator (=) requires that the subscriber value and the publisher value that are assigned to variable name TYPE match. In this example, the values match. Both assign the value report to the variable name TYPE. The AND logical operator (&) also requires that the variable name SALES match. Because both the publisher and the subscriber identify a variable name sales with no assigned value, the final condition is also met.
For more information about name/value pairs, see Specifying Name/Value Pairs.