Creating new queues

To create a new MER queue you must create a CO of type DnqERQueue for each OU which is to use the queue. To help you do this, FTM SWIFT generates, during customization, a script with a name of the form: 
deployment_dir/instance/admin/ou_dnqcecoo.cli
where:
deployment_dir
Directory specified in the CDP initialization file.
instance
Name of the FTM SWIFT instance.
ou
Name of the OU.
This script contains the following commands: 
add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr Purpose  -val <Purpose>
add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr USE
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr TEMPLATEADMIN
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr CHANGELOCALADDR
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr ValidateRM
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr ActionList  -val '<Action>,...,<Action>'
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr ActionListRequireOpen  -val '<Action>,...,<Action>'

;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr BrowserPrintActionList -val '<Action>,...,<Action>'

;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr AllowDrafts -val <AllowDrafts>
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr MonitorThresholdRouting -val <ThresholdRouting>
;add -ct DnqERQueue  -ou DNIvOU  -co <Queue>  -attr MonitorThresholdUser    -val <ThresholdUser>

com -ou DNIvOU
The customization process substitutes the placeholder DNIvOU in the script with the name of the OU. To modify and run the script for the OU you are going to change, do the following:
  1. Copy the script for the OU to change into your home directory.
  2. Copy the commands once for each MER queue that is to be created.
  3. Ensure that all commands that are to be executed are activated, that is, that they are not preceded by a semicolon character (;).
  4. Replace the following items in the copy of the script as required:
    <Queue>
    The MER queue name. This name can be at most 30 characters long and can contain only:
    • Characters of the set [A-Za-z0-9]
    • Periods (.)
    • Hyphens (-)
    • Underscore characters (_)
    Purpose <Purpose>
    The purpose of the MER queue, which defines which actions can be performed on the messages in the queue. For more information about MER queues and their purposes, refer to MER queues. Possible values:
    Value to configure Resulting purpose Description
    Create Create For newly created messages
    Edit Edit For messages that are to be edited
    DblAuthorize1 Authorize For messages that are to be approved by a different user
    Retype Retype For messages for which a different user is to reenter data
    Authorize1 Confirm For messages that are to be approved by any user
    Display Display For messages that are to be viewed, but not edited, before they can be processed further
    General1 Application For messages for which two routing steps are to be carried out without an intervening business action
    Note:
    1
    Some of the queue purposes were originally introduced with different names and later renamed for clarity. To facilitate migration from older versions of the product, the configuration still expects values that refer to the original names:
    DblAuthorize
    For an authorize queue that enforces the four-eyes principle.
    Authorize
    For a confirm queue that does not enforce the four-eyes-principle.
    General
    For a general-purpose application queue.
    ValidateRM
    This attribute is valid only for queue purposes Create and Edit, where messages can be validated. If the attribute is present, validation of FIN messages in the user interface includes RM checking, unless RM filtering is not disabled. For configuration of RM filtering, refer to the description in Configuring the Authorization checking service. If the attribute is absent, message validation does not perform RM checking.
    Note: RM checking for MX messages is not available in the MER Facility. MER is unaware of the SWIFTNet service for which an MX message is being processed, but that information is required for RM checking.

    Some FIN messages (for example, system messages) are excluded from RM checking by definition. Test and training messages can be excluded by configuring the attribute RMABypassTT in CT DnqEROUOptions accordingly. For excluded messages, the MER user interface skips RM checking.

    To set this attribute, activate the corresponding add command by removing the semicolon (;) from the beginning of the line.
    The value of the RMABypassTT attribute of the CO DnqEROUOptions of type DnqEROUOptions specifies, for an OU, whether the ValidateRM attribute is to be ignored for test and training (T&T) traffic:
    true
    The ValidateRM attribute is ignored when a pilot SWIFTNet service is used. Consequently, RMA traffic filtering is never carried out for test and training traffic, regardless of whether the ValidateRM attribute is specified.
    false
    The ValidateRM attribute is respected for all message traffic, including traffic to or from a pilot SWIFTNet service. This is the default.
    For more information, see Specifying whether to filter T&T traffic.
    ActionList <Action>,...,<Action>
    This attribute specifies a comma-separated list of the names of up to five standard business or custom actions that are to be made available for messages on the queue. (For more information about custom actions, see Configuring custom actions.) The MER user interface presents the actions in the order in which they are listed. If the ActionList attribute is not specified, only the standard business actions that are defined for the queue purpose are available. If an empty list (one blank) is specified, no standard business or custom actions are made available. The standard business actions are:
    Action name Description Notes
    dnq.submit Submit Available only for queue purposes Create, Edit, and Display.
    dnq.accept Accept Available only for queue purposes Authorize, Retype, and Confirm.
    dnq.reject Reject
    If this attribute is specified, only the actions that it lists are available. For example, if you created a custom action with the CO name FIN2Discard, and if you want only that custom action and the standard business action Accept to be available, specify: 
    -attr ActionList  -val 'dnq.accept,FIN2Discard'
    Standard user actions such as Redirect, Unlock, or Save as Draft are made available automatically when appropriate.
    ActionListRequireOpen <Action>,...,<Action>
    This attribute specifies a comma-separated list of the names of standard business or custom actions that are to be excluded from the context menu in the message list. The user is required to open the message in order to carry out the action. For example, if you want to exclude the standard business actions Accept and Reject from the context menu, specify: 
    -attr ActionListRequireOpen  -val 'dnq.accept,dnq.reject'
    BrowserPrintActionList <Action>,...,<Action>
    This attribute specifies a comma-separated list of the names of actions that allow browser-based message printing. You can specify standard business actions, custom actions, or the print action (dnq.print). If you specify a standard business or custom action, the action is processed, a formatted output is created, and the web browser gets control to print the formatted output. The print action only invokes the browser-based message printing and no further processing is made. Dependent on the actions included in the list, browser-based message printing is invoked in the MER Facility, if the corresponding standard business or custom action is specified in the attribute ActionList, too. For example, if you created a custom action with the CO name FIN2Discard, and if you want that the custom action FIN2Discard and the standard business action Accept invoke browser-based message printing, specify: 
    -attr ActionList  -val 'dnq.accept,FIN2Discard'
-attr BrowserPrintActionList  -val 'dnq.accept,FIN2Discard'
    If you want only to enable the Print action, it is sufficient to define:
    -attr BrowserPrintActionList  -val 'dnq.print'
    On retype queues, browser-based message printing is not allowed.
    AllowDrafts <AllowDrafts>
    This attribute is valid only for queue purposes Create and Edit, and specifies whether drafts can be saved on the queue:
    true
    Drafts can be saved on the queue. This is the default.
    false
    Drafts cannot be saved on the queue. The user action Save as Draft is unavailable. Any draft messages currently on the queue can still be processed.
    MonitorThresholdRouting <ThresholdRouting>
    Specify this attribute only if you need to either:
    • Override the default threshold, which is described in Specifying default queue-depth thresholds.
    • Set a threshold for an MER queue family that belongs to an OU for which a default threshold was not configured.
    When the value of this attribute is:
    A positive integer
    If the number of messages (not counting templates) in the main MER queue and its associated queues that are waiting to be routed reaches or exceeds the specified number, an event message with the message ID DNQK1131I is issued.
    0
    No threshold is set for messages that are waiting to be routed, and no event is issued regardless of how many such messages are in the MER queue.
    MonitorThresholdUser <ThresholdUser>
    Specify this attribute only if you need to either:
    • Override the default threshold, which is described in Specifying default queue-depth thresholds.
    • Set a threshold for an MER queue family that belongs to an OU for which a default threshold was not configured.
    When the value of this attribute is:
    A positive integer
    If the number of messages (not counting templates) in the main MER queue and its associated queues that are awaiting user action reaches or exceeds the specified number, an event message with the message ID DNQK1130I is issued.
    0
    No threshold is set for messages that are awaiting user action, and no event is issued regardless of how many such messages are in the MER queue.
  5. Add the TEMPLATEADMIN attribute to all queues with purpose Create. To do this, remove the semicolon (;) from the beginning of the line. Do not add this attribute to any other queue. It is required for granting the right to administrate templates.
  6. Add the CHANGELOCALADDR attribute to all queues with purpose Edit. To do this, remove the semicolon (;) from the beginning of the line. Do not add this attribute to any other queue. It is required for granting the right to change the local address of messages.
  7. The file ou_dnqcecoo.cli also contains commands to create local addresses and custom actions. As needed, you can either:
  8. If required, the unformatted view of a message in MER can be disabled (read only) or even totally removed. In order to change the handling of the unformatted view, the attribute Unformatted can be set for CT DnqERQueue. The following values can be used:
    disable
    The user cannot change a message in unformatted view
    hidden
    The unformatted view is not shown
    The unformatted attribute setting applies to the main queue and all associated queues of that queue.
  9. Run the modified copy of the ou_dnqcecoo.cli script. This requires the access rights provided by the system configuration administrator (DniSA) role: 
    dnicli -i instance -ou SYSOU -s DNI_SYSADM -cft ou_dnqcecoo.cli -cp IBM-1047
  10. Approve and deploy the changes: 
    dnicli -i instance -ou SYSOU -s DNI_SYSADM
app -ou ou
dep -ou ou
If dual authorization is enabled, another user with the appropriate access rights must approve the changes before they can be deployed. If dual authorization is disabled, you can skip approving the changes and immediately deploy them.
After you deploy a new queue:
  • Ensure appropriate access is granted to the users that are to use this queue, see Creating MER Facility roles.
  • Restart the MER enterprise application in the application server to make the new queues visible.
  • Deploy adapted MER routing message flows to ensure that messages are routed to and from the new queue according to your criteria.