Defining filtering

The filtering described in this section is completely separate from the ad hoc filtering performed in the Summary View.

However, unlike the Summary View filtering, this filtering cannot be "turned off" without changing the project configuration.

A filter is simply a MainView Middleware Administrator (MVMA) implementation of a standard filtering mechanism. A filter defines a set of objects returned based on filter definition.

Filters are applied both to application objects and to views. The primary target, or purpose, of filters in MVMA, are the middleware assets (connections and related objects) that the user manages via Product Administrator-defined projects. The filter limits the results returned to those that conform with the searcher's memberships and use patterns. In this way, users receive the results that match their needs and roles.

As the administrator, you also gain increased control over user activities and improve overall application security. 

Getting started with filtering 

Configuring filters is done on a namespace basis. The namespaces are the application contexts from which the Administrator selects specific objects. This parameter indicates whether IBM WebSphere MQ or EMS objects are used in the filter.

The namespace that you select determine which objects are displayed in the drop-down list for the object type. It is against these objects that a filter is applied. See the Configuring a filter section below.

These parameters or properties define a filter assigned to objects within specified namespaces:

  • Filter Name – Unique, Administrator-supplied filter identifier.
  • Filter Type – Wildcard, Logical Expression or Properties Filter.
  • Filter Expression – The specific expression based on filter type (not applicable to Properties Filters).
  • Namespace – Sets whether IBM WebSphere MQ or TIBCO EMS objects are displayed in the object type pull-down during filter configuration.
  • Object Type – Associated with IBM WebSphere MQ or EMS namespaces, and are the objects of 'x' types correlated with the objects that exist within each.
  • Permission (Properties Filter only) – Inquire, Operator, Administration.

On what objects can filters be applied?

Apply Wildcard or Logical Expression filters to the following IBM WebSphere MQ object types:

  • Queue
  • Channel
  • Process
  • Subscription
  • Topic
  • Listener
  • Namelist
  • Service
  • Authinfo
  • Comminfo

EMS object types to which Wildcard or Logical Expression filters can be applied are:

  • Queue
  • Topic
  • Durable
  • Route
  • ConnectionFactory
  • Group
  • User
  • Store
  • Channel
  • CMLedgerSubject
  • CMListener
  • DestinationBridge
  • IncomingRouteSelector
  • OutgoingRouteSelector
  • Transport

IBM WebSphere MQ object types to which Properties Filters can be applied:

  • QueueManager
  • Queue
  • Messages
  • Channel
  • Process
  • Subscription
  • Topic
  • Listener
  • Namelist
  • Service
  • Authinfo
  • Comminfo
  • Connection
  • AuthorityRecord
  • ChannelAuthRecord
  • Cluster

These are generic filters. Once applied to specific projects, they control access of specific users to the target middleware asset. 

Configuring a filter

To configure a new filter

  1. Select Filters from the Navigation Panel. The Filters View is displayed:
  2. Click the + icon to open a new Filters properties workspace.
  3. Select a filter type:
    Wildcard Expression (default), Logical Expression or Properties Filter
    The filter type that you choose determines or matches the filter expression entry.
    • If you choose Wildcard Expression, the filter expression should be in wildcard format:*.aaa.
    • If you select Logical Expression, you must first create Wildcard Expressions, then apply them. When ready to apply the Logical Expression, enter an expression that combines the names of defined Wildcard filters with logical operators '&' (the AND operator), '|' (the OR operator) or '!' (the NOT operator) in the filter expression field.
    • Properties Filter is only applicable to WebSphere MQ. In addition to selecting a namespace and object type, as shown in the following steps, you need to additionally configure the Permission the filter should relate to (select from InquireOperator or Administration if the object type selected relates to a managed middleware object or Read or Write in case Message is the selected object type). See also the Properties Filters sections below for further information.
  4. Enter a Filter Name.
  5. Choose a namespace from either wmq or ems. This also has the effect of restricting unauthorized users from accessing administration objects. Note that for the Properties Filter, only wmq is available.
  6. Select the specific object type to which to apply the filter. Refer to the previous section for reference.
  7. Save your work. The new filter is added to the Filters Summary View.

Note

When you create a filter, it is saved with previously created filters. You can use any filter from this database and apply it to project connections.

Copying a filter

To copy a filter

  1. Select Filters from the Navigation Panel.
  2. In the displayed Filters View, click on the Operations arrow icon next to the relevant filter.
  3. Select Copy.
  4. In the displayed Properties for New Filter dialog, define filter settings as required.
  5. Click the Save icon to save your settings.

Editing a filter

To edit a filter

  1. Select Filters from the Navigation Panel.
  2. Click on the relevant filter name in the Filters View.
  3. Modify the filter settings as required.
  4. Click the Save icon to save your settings.

Auditing a filter

To audit a filter

  1. Select Filters from the Navigation Panel.
  2. In the displayed Filters View, click on the Operations arrow icon next to the relevant filter.
  3. Select Audit.
  4. In the displayed Audit Events dialog, define a time period you want to audit for the selected filter, and click Submit.
  5. Browse the list of events that are generated for the selected time period.

Deleting a filter

To delete a filter

  1. Select Filters from the Navigation Panel.
  2. In the displayed Filters View, click on the Operations arrow icon next to the relevant filter.
  3. Select Delete.
  4. In the displayed confirmation message, click OK.

You can also delete a filter from a specific project only, as described in Deleting a filter from a project, see below.

Filter examples

Here is an example of how to apply filters to connections for queues:

  • Create a filter (filter.aaa) to apply to queues that start with 'AAA*'. (The filter is a 'positive' filter, to display those results when the user applies it).
  • Add filter.aaa to a particular connection.
  • When the Queues summary is opened, results are returned with only queues that start with AAA displayed (note: filters are also case-sensitive).

For Wildcard filters, the filter expression should be in wildcard format. Valid wildcard characters are "*" (any character, any number of times) and "?" (any character, singular).

For Logical Expressions, you must first create Wildcard filters, then apply them. When ready to apply the Logical Expression, enter a string that combines the names of defined Wildcard filters in the Filter Expression field. Valid Logical Expression characters are "!" (not), "|" (or), "&" (and), "^" (xor).

For all the following examples, the Namespace is wmq and the Object Type is Queue. The "result" is the result when the filter is applied to a project. The examples work with the following queue names:

  • AQUEUE
  • BQUEUE
  • CQUEUE
  • ATESTQUEUE
  • BTESTQUEUE
  • CTESTQUEUE
  • ABESTQUEUE
  • BBESTQUEUE
  • CBESTQUEUE

Example 1: Wildcard 

Create a Wildcard filter called End-QUEUE to include all queues with names that end with "QUEUE".

Wildcard Filter Expression: *QUEUE

Example 2: Wildcard 

Create a Wildcard filter called Begin-A to include all queues with names that begin with the letter "A".

Wildcard Filter Expression: A*

Example 3: Wildcard 

Create a Wildcard filter called Begin-B to include all queues with names that begin with the letter "B".

Wildcard Filter Expression: B*

Example 4: Wildcard 

Create a Wildcard filter called Contain-TEST to include all queues with names that contain the word "TEST".

Wildcard Filter Expression: *TEST*

Example 5: Wildcard 

Create a Wildcard filter called Contain-EST-35 to include all queues with names that contain "EST" as characters 3-5.

Wildcard Filter Expression: ??EST*

Example 6: Logical 

Create a Logical Expression for all queues with names end with QUEUE and begin with B. Note that Begin-B and End-QUEUE are names of Wildcard filters that we defined in the previous examples.

Logical Filter Expression: (Begin-B)&(End-QUEUE)

Result: 


Example 7: Logical 

Create a Logical Expression for all queues with names that do not begin with B, contain TEST anywhere, and end with QUEUE.

Logical Filter Expression: (!Begin-B)&(Contain-TEST)&(End-QUEUE)

Result:

  

Example 8: Logical 

Create a Logical Expression for all queues with names that do not begin with B, contain EST in positions 3-5, and end with QUEUE.

Logical Filter Expression: (!Begin-B)&(Contain-EST-35)&(End-QUEUE)

Result:

  

Example 9: Logical 

Create a Logical Expression for all queues with names that begin with "A" or "B" and end with "QUEUE".

Logical Filter Expression: (Begin-A|Begin-B)&(End-QUEUE)

Result:

Properties filters for managed objects

Properties filters are similar to Wildcard and Logical filters but are more granular, operating on properties of objects. 

Properties filters allow Administrators to control not only what properties are visible to users, but whether those properties may be modified or set upon creation by users or whether an object type is at all accessible. It is a combination of the Property filter definition and the project permissions for users and groups that controls how an object's properties are viewed and interacted with by users.

Properties filters scenarios

The following scenarios illustrate the basic concepts behind Properties Filters:

  • A user with INQUIRE permissions is allowed to view all properties of WMQ objects. When a Properties Filter with INQUIRE permissions is applied to a connection in a project this user is a member of, this user is then restricted to viewing only the properties that are present in the Selected Properties box of this filter. Properties Filters with OPERATOR or ADMINISTRATION permissions have no effect on users with only INQUIRE permissions.
  • A user with OPERATOR permissions can view all properties of WMQ objects and is also allowed to modify all modifiable properties of WMQ objects. When a Properties Filter with OPERATOR permissions is applied to a connection in a project this user is a member of, this user is restricted to being able to modify only the properties that are present in the Selected Properties box of this filter. This user can also be restricted in the viewing of properties by applying a Properties Filter with INQUIRE permissions to the same Connection in the Project. Properties Filters with ADMINISTRATION permissions have no effect on a user with only OPERATOR permissions.
  • A user with ADMINISTRATION permissions is not only allowed to view and modify properties for existing objects, but can also modify properties when creating new objects. To restrict the operations of a user with ADMINISTRATION permissions, a Properties Filter with both OPERATOR and ADMINISTRATION permissions is required. To also restrict what properties the administration user can view, a Properties Filter with INQUIRE, OPERATOR, and ADMINSTRATION is required.
  • Empty Properties Filter: If the Selected Properties box is left empty only the required properties will be available to the users for the Object type specified in the Properties Filter.
  • Disable Object Type: To disable access to an Object Type, select the Disable Object Type checkbox during the creation of a Properties Filter. Note that this will automatically associate the filter to the INQUIRE permission so objects of that type will not be available in the Summary View of the object for any user.
  • Securing Object Operations: Properties Filters can also be used to secure object operations (such as Start Channel or Resume Cluster). If there are no Properties Filters for the object type, the user with OPERATOR or ADMINISTRATION permissions will be able to perform the action. If there are Properties Filters for the Object Type, but the required property is missing in the Selected Properties column, the operation will fail.

The table below lists the WebSphere MQ properties for specific operations, that, when missing from the Selected Properties column (see the following procedure), will cause the operation to fail.

Object Type

Operation

Properties

Channel 

Start

Status

Stop

Status

Ping

Status

Reset

Message Sequence Number

Resolve

In Doubt Status

Listener 

Start

Status

Stop

Status

Service 

Start

Status

Stop

Status

Connection

Stop

Connection ID

Cluster 

Suspend

Status

Resume

Status

To associate a set of properties to the filter

  1. Select Properties Filter as the Filter Type.
  2. Define a Filter Name, an Object Type, and the relevant Permission (select one of InquireOperator, or Administration).
  3. Select one or multiple properties in the All Properties box and associate them to the filter by clicking < so they are moved to the Selected Properties box. Note that the << and >> buttons add/remove all properties.
  4. (Optionally) Select Disable Object Type if you want to disable access to the Object Type chosen in this Filter. See the Disable Object Type scenario under the Properties filters scenarios above.
  5. Click the Save icon to save the filter.

Properties filters for messages

Properties filters for messages are used to control read or write access to a message's headers or content.

To set up a properties filter for messages

  1. Select Message as the object type. This populates all parts of a message that can be filtered in the All Properties selection box. 
  2. Select the Read or Write permission to control the messaging operation and the granted user permission the filter should relate to. 
  3. Select the parts of a message that should be available for Read or Write. 
    • To enable access to the message content select 'MsgData' as an available property. 
    • To enable access to the message descriptor or any supported header type select the related header identifier as an available property, such as MQMD for the message descriptor, or MQDLH for the Dead Letter Header. 

A user with Read and Write permissions can modify messages with message properties filters applied due to the 'what-is-writeable-must-be-readable' pattern, meaning that any property selected for Write will be displayed to the user when editing a message even if no filter is set up for Read explicitly has that property selected. 

Applying filters to connections

Filters are applied to connections in projects. The assignment of a filter to a project controls access to the objects under the connection.

To assign a filter to a project and specific connections within it

  1. Select Projects from the Navigation Panel.
  2. Click on the project name to display properties for the project.
  3. Expand the Connections and Filters category to display all project connections.
  4. From the drop-down menu adjacent to the required connection, click Add Filter. Alternatively, click the Associate Filters icon just below the Connections and Filters category bar.

  5. In the displayed Associate Filters to Connections dialog, choose specific filters and connections from the lists available. Note that you can add multiple filters to multiple connections, if required. Once you have selected the relevant connections and filters (filters limit the types of filters available; select from All Filters, Object Filters Only (both wildcard and logical filters) or Property Filters Only), click Associate.

    Note

    The dialog does not reflect current associations; if you already have some associations be aware that each time you access this dialog, all connections and all filters are in the "Available" columns. If you are also working with both EMS and WMQ connections, a Namespace field is displayed in which you can select the namespace and then only connections and filters for that namespace will appear in the transfer box selection. 



    The filters are applied to the connection(s).

  6. Save the project.

Note

When applying multiple filters to a connection, MVMA will display objects matching any of the filters for the related connection. If, for example, you associate two wildcard filters to a connection, one matching all queues where the name starts with 'AMQ.' and one matching all queues beginning 'SYSTEM.', then you would see all queues starting 'AMQ.' or 'SYSTEM.'. Therefore if you apply multiple filters to a connection, carefully check whether the results meet your expectations or whether you should set up a separate logical filter to provide the intended combination. 

Dissociating filters from connections

Filters that you associated with a project and connections can be dissociated as required.

To dissociate a filter from a project and specific connections

  1. Select Projects from the Navigation Panel.
  2. Click on the project name to display properties for the project.
  3. Expand the Connections and Filters category to display all project connections.
  4. Click the Dissociate Filters icon just below the Connections and Filters category bar.
  5. In the displayed dialog, select the relevant filters to dissociate and then click Dissociate.

Deleting a filter from a project

To delete a filter from a project

  1. Expand the Filters icon to view current filters for a connection. This is the + icon in the Filter category.
  2. Select the Operations trash can icon for the filter that you want to delete.
  3. Select Save from the options above Project Properties to save changes.
Was this page helpful? Yes No Submitting... Thank you

Comments