Ibm Websphere Message Broker Placement Papers - Ibm Websphere Message Broker Interview Questions and Answers updated on 03.Mar.2024

A broker schema is a symbol space that defines the scope of uniqueness of the names of resources defined within it. The resources are message flows, ESQL files, and mapping files.

The User Name Server is an optional runtime component that provides authentication of users and groups and give an administrative control over who can publish and who can subscribe operations.

The Windows Event Viewer is where WebSphere Message Broker writes records to the local system.

 The mqsicreatemsgdefs command has a bulk import capability, but mqsicreatemsgdefsfromwsdl imports only one WSDL definition at a time.

The Sequence node enables you to receive groups of messages from an input source, and preserve the order in which the messages in each group arrived.

  A message is put to a queue defined as Triggering.

External variables:

  • Also known as user defined properties.
  • Exist for entire life time of a message flow and are visible to all messages passed through the flow.
  • Defined at module or schema level.
  • You have to assign an initial value at the time of declaring an external variable and then can modify the initial value at deployment time by using the BAR editor.

Normal Variables:

  • Have lifetime of just one message pass through a node.
  • Visible to that message only in which it was defined.
  • To define, omit both EXTERNAL and SHARED keyword.

Shared variable:

  • Used to implement in-memory cache in the message flow.
  • Have a long life time and are visible to multiple messages pass through the flow.
  • Exist for the lifetime of Execution group, lifetime of flow or node, lifetime of node’s ESQL that declares the variable.
  • Initialized when the first message pass through the node or flow after broker startup.

  • Root is used in the Database content changing and in Filter node.
  • Output Root is used in the ESQL code for a Compute node that creates a new output message based on the input message.

 The purpose of a filter node is to route a message based on the content dynamically

A correlation name is a field reference that identifies a well-defined starting point in the logical message tree and is used in field references to describe a standard part of the tree format.

Logical message tree is the internal representation of a message.

 The Compute node is used to:

  • Build a new message using a set of assignment statements
  • Copy messages between parsers
  • Convert messages from one code set to another
  • Trform messages from one format to another

Use the Input node as an In terminal for an embedded message flow (a subflow).The MQInput node receives a message from a WebSphere MQ message queue that is defined on the queue manager of the broker. It is the first node of your message flow.

Use CALL keyword to call functions or methods.

Publish/subscribe is a style of messaging application in which the providers of information (publishers) are decoupled from the consumers of that information (subscribers).

  1. When the Destination queue is full
  2. When the Destination queue doesn’t exist
  3. When the incoming message too large
  4. When the Sender is not authorized to use the destination queue.

 A message flow node receives a message, performs a set of actions against the message, passes the original message or the changed message, to the next node in the message flow.

 We can trform and enrich messages by using one or more of the following techniques:




XSL style sheets



  • Through ESQL you can
  • Change the message content.
  • Modify an existing message
  • Create a new message
  • Add dynamic terminals
  • Route a message
  • Propagate a new request

You can populate your message set with message definitions by importing COBOL copybook files, using either the New Message Definition File wizard or the mqsicreatemsgdefs command line utility.

An execution group is a named grouping of message flows that have been assigned to a broker.

 Physical Representation of a message is a Format.

We can access a database from a message flow by using the following nodes:









 A message set is a folder in a message set project that contains a logical grouping of your messages and the objects that comprise them (elements, types, groups).

Routing, Trformation and Integration.

ResetContentDescriptor node request to parse the message with different parser, leaving the message content unchanged.

A correlation name is a field reference referencing a well-defined starting point in the logical message tree and to describe a standard part of the tree format.

There are two types of clients in MQ:

  1. Fat Clients: Does have a local queue manager.
  2. Slim clients: Does not have a local queue manager, whereas the queue manager reside on the server.

The User Name Server is an optional runtime component that provides authentication of users and groups performing publish/subscribe operations.

Even if your messages are self-defining, and do not require modeling, message modeling has the following advantages:

  1. Runtime validation of messages. Without a message model, a parser cannot check whether input and output messages have the correct structure and data values.
  2. Enhanced parsing of XML messages. Although XML is self-defining, all data values are treated as strings if a message model is not used. If a message model is used, the parser is provided with the data type of data values, and can cast the data accordingly.
  3. Improved productivity when writing ESQL. When you are creating ESQL programs for WebSphere Message Broker message flows, the ESQL editor can use message models to provide code completion assistance.
  4. Drag-and-drop operations on message maps. When you are creating message maps for WebSphere Message Broker message flows, the Message Mapping editor uses the message model to populate its source and target views. Without message models, you cannot use the Message Mapping editor.
  5. Reuse of message models, in whole or in part, by creating additional messages that are based on existing messages.
  6. Generation of documentation.
  7. Provision of version control and access control for message models by storing them in a central repository.

  1. AggregateControl
  2. AggregateRequest
  3. AggregateReply

ResetContentDescriptor node request to parse the message with different parser, leaving the message content unchanged.

The SOAP Async Request node sends a Web service request, but the node does not wait for the associated Web service response to be received. This asynchronous functionality enables multiple outbound requests to be made almost in parallel because the outbound request is not blocked waiting for the response.

Whereas, The SOAPRequest node is a synchronous request and response node, which blocks processing after sending the request until the response is received.

Most message formats are not self-defining, and a parser must have access to a predefined model that describes the message, if it is to parse the message correctly. A message model is used by WebSphere Message Broker to model a message format.

The mqsiapplybaroverride command is used to replace configurable values in the broker archive (BAR) with new values that you specify in a properties file.

  Not a single queue manager cannot have two brokers.

Using the mqsideploy command one can deploy the bar files.

 Administrator perspective is used to deploy the flow.

To Connect to the remote broker or local broker and to deploy the message flows onto the Broker.

You can create a message model by using the following methods:

  • Importing an application message format that is described by an XML Schema, XML DTD, C structure, COBOL structure, SCA import or export, or WSDL definition.
  • By creating an empty message model file, then creating your message by using the editors provided in the WebSphere Message Broker Toolkit.
  • By using the Adapter Connection wizard to import EIS metadata.
  • By creating a populated model file from example message data.

 mqsichangebroker command is used to modify broker parameters.

The main components used in Message Broker Name Server are

  1. User Name Server
  2. Configuration Manager
  3. Broker

A message definition file contains the messages, elements, types, and groups which make up a message model within a message set. Every message set requires at least one message definition file to describe its messages. Message definition files use the XML Schema language to describe the logical format of one or more messages.

Group of brokers that coordinate a single configuration manager constitute a Broker Domain.

A multipart message contains one or more other messages within its structure. The contained message is sometimes referred to as an embedded message. A multipart message must contain a group, or a complex type, with its Composition property set to Message.

In Data Source specify the name by which the appropriate database is known on the system on which this message flow is to execute.

  1. Local queue
  2. Remote queue
  3. Trmission queue
  4. Alias queue
  5. Dead letter queue

SCADAInput, HTTPInput, FileInput, Real-timeInput, JMSInput, Custom Input nodes.