1.What are the features of Message Broker?
Ans:Routing, Transformation and Integration.
2.What is the role of configuration manager?
Ans:Connect to the broker and to deploy the message flows onto the broker.
3.How to create Broker from Command prompt?
Ans: Using mqsicreatebroker command.
4.What are the default properties of MQ Input node?
Ans:Message Domain, Message Set, Message Type, Message Format, Topic.
5.Which nodes are used to change the message in the flow?
Ans:Compute Node, Filter Node and ResetContentDescriptor node.
6.Name 6 built-in nodes in MB Toolkit?
Ans: (i) MQInput node (ii) MQOutput node (iii) Compute node (iv) Database node (v) AggregateControl node (vi)Filter node.
7.How to call the method or function in the eSQL coding?
Ans:Using the "CALL" keyword.
8.What is the Broker Domain?
Ans:Group of brokers that coordinate a single configuration manager constitute a Broker Domain.
9.Name the message formats which MB support?
Ans:XML, TDS, CWF, EDI, SWIFT.
10.What is an Execution Group?
Ans:An execution group is a named grouping of message flows that have been assigned to a broker.
11.Difference between Root and OutputRoot?
Ans:Root is used in the Database content changing and in Filter node. OutputRoot is used in the ESQL code for a Compute node that creates a new output message based on the input message.
12.What is User name Server and where it is defined?
Ans:The User Name Server is an optional runtime component that provides authentication of users and groups performing publish/subscribe operations.
13.How can we see the error log files in broker?
Ans:The Windows Event Viewer is where WebSphere Message Broker writes records to the local system.
14.What are the perspectives there in MB Toolkit? In which perspective we deploy the flow?
Ans:(i) Administration Perspective (ii) Application Development Perspective (iii)Debugging Perspective (iv) Java Perspective . We deploy flows in Administration Perspective .
15.What are the different ways to give input without using MQInput node?
Ans:SCADAInput, HTTPInput, FileInput, Real-timeInput, JMSInput, Custom Input nodes.
16.What is PARSER? Difference between PARSER and FORMAT?
Ans:A Parser is defined as a program that interprets the bit stream of an incoming message and creates an internal representation of it in a tree structure. Ex: MRM parser
A Format is a physical representation of a message. Ex: XML wire format
17.Define Correlation names?
Ans: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.
18.How will we use a Cobol copybook in MB?
Ans: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.
19.What is SCHEMA of broker?
Ans: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.
20.How can you interact with Database using Compute node?
Ans:Specify in Data Source the name by which the appropriate database is known on the system on which this message flow is to execute.
WMQ
1. What are the purposes of using MQ instead of DB?
Sl#
|
WebSphere MQ
|
Database Tables
|
Description
|
1
|
One time transfer per UOW
|
Have to handle multiple connections per UOW
|
Unit of Work(UOW): To generate one EDI message or a transaction the implementation effort involved varies between the two approach.
|
2
|
Out of the box implementation
|
Custom implementation within ESB
|
ESB has native MQ connectivity where-as Database calls require development effort on the scale of 20-40hrs per transaction.DB approach will need access logic custom coded for each transaction within ESB.
|
3
|
Data is not replayable
|
Data is replayable
|
MQ messages are consumed once-and-only once vs. db data can be replayed without additional development effort.
|
4
|
No dependency on network
|
Dependency on network
|
ESB access to database has dependency on network availability.
|
5
|
New implementation for Sterling Integrator(SI)
|
Existing framework for SI
|
MQ connectivity option has to be explored by SI team vs Configurable services for Database connectivity needs to be established within ESB.
|
6
|
Can use same data to route to multiple targets
|
Has to be defined per target
|
MQ ESB can publish information to multiple systems without impacting the existing consumer.
|
7
|
Measurable Performance overhead
|
Performance overhead per transaction will vary per transaction
|
Database connectivity consumes resources within ESB which is comparitively higher than native MQ connectivity.
|
8
|
No rollback of data required
|
Roll back has to be maintained within ESB
|
Concept of Rollback does not apply for MQ connectivity.Custom code to monitor and maintain transactionality has to be defined within ESB for Database based connection.
|
9
|
Decouples ESB and enterprise application. In case of System maintenance of either applications the messages will not fail, but will get queued up and be consumed once the application is back up.
|
Tight coupling between ESB and database. In case database goes down for system maintenance, message will fail in ESB and will have to reprocessed or retry logic needs to be included
|
This will reduce Production Support and troubleshooting effort, and also allows Applications to do maintenance independent of ESB layer.
|
10
|
Speeds up development effort. Once the message contract is finalized each of the developments teams (ESB and enterprise application) can work in parallel without having to rely on either of the teams to complete development and testing.
|
ESB team will still have to rely on tables being created, and access given to DB tables (or rely on application team) to verify messages are being created correctly, and also to trigger messages
|
Once the message contract is finalized each of the developments teams can work in parallel without having to rely on either of the teams to complete development.
|
2. How messages are stored in queue? If it is in file system can we alter messages
(security violation). Can we read messages thru some tools outside MQ?
A: Queued messages can be stored at intermediate nodes until the system is ready to forward them to the next node. At the destination node, the messages are stored in a queue until the receiving application retrieves them from the queue. Message delivery is guaranteed even if the network or application fails. This provides for a reliable communication channel between the applications.
Can we read messages thru some tools out side MQ?
QueueZee is a MS Windows Java application designed for message management, manipulation and analysis of IBM WebSphere MQ messages.
MQ Visual Edit application allows users to view, manipulate and manage messages in a queue of a WebSphere MQ (formally MQSeries) queue manager and presents the data in a simplified format similar to a database utility or spreadsheet program
3. What are the types of Queues?
A: Types Of Queues:
1. Predefined Queues
2. Dynamic Queues
Predefined Queues
1. Local Queue
The queue definition object, created when you define a local queue, holds the definition information of the queue as well as the physical messages put on the queue.
2. Alias Queue
An alias queue is a WebSphere MQ object that you can use to access another queue. The queue resulting from the resolution of an alias name (known as the base queue) can be a local queue, the local definition of a remote queue, or a shared queue (a type of local queue only available on WebSphere MQ for z/OS).
Note: An alias cannot resolve to another alias
3. Remote Queue
To a program, a queue is remote if it is owned by a different queue manager to the one to which the program is connected. Where a communication link has been established, a program can send a message to a remote queue. A program can never get a message from a remote queue.
4. Model Queue
A model queue is a template of a queue definition that you use when creating a dynamic queue. You specify the name of a model queue in the object descriptor (MQOD) of your MQOPEN call. Using the attributes of the model queue, the queue manager dynamically creates a local queue for you.
5.shared queues
6.transmission queues
Dynamic Queues:
In MQSeries to create dynamic queues must define model queue. It works as a template.
1. Temporary Dynamic Queue
· They hold non-persistent messages only
· They are non-recoverable
· They are deleted when Queue manager restarted
· These will created when application issue MQOPEN call on model queue and deleted for application MQCLOSE
2. Permanent Dynamic Queue
· They hold persistent and non-persistent messages
· They are recoverable in the event of system failure
· They are deleted when an application successfully closes the queue using the MQCO_DELETE or MQCO_DELETE_PURGE
· How To Define Model Queue To Create Temporary Dynamic Queue
DEFINE QMODEL(Model_Queue_Name) DEFTYPE(TEMPDYN)
· How To Define Model Queue To Create Permanent Dynamic Queue
DEFINE QMODEL(Model_Queue_name) DEFTYPE(PERMDYN)
4. What are model Queues, How it is created and the purpose?
A: A model queue is a template for queues that you want the queue manager to create dynamically as required. When an application tries to put a message on a model queue, the queue manager dynamically creates a local queue with the same name as the model queue. Queues that are created in this way can either be temporary or permanent.
5. What is remote Queue? How it is operated?
A:Remote queue definitions are definitions on the local queue manager of queues that belong to another queue manager. To send a message to a queue on a remote queue manager, the sender queue manager must have a remote definition of the target queue.
6. How to send a message from one Qmanager to another Qmanager?
A:This section describes the simplest way to send a message between queue managers, including prerequisites and authorizations required. Other methods can also be used to send messages to a remote queue manager.
Before you send a message from one queue manager to another, you need to do the following steps:
1. Check that your chosen communication protocol is available.
2. Start the queue managers.
3. Start the channel initiators.
4. Start the listeners.
You also need to have the correct WebSphere® MQ security authorization to create the objects required.
To send messages from one queue manager to another:
· Define the following objects on the source queue manager:
o Sender channel
o Remote queue definition
o Initiation queue (optional)
o Transmission queue
o Dead-letter queue
· Define the following objects on the target queue manager:
o Receiver channel
o Target queue
o Dead-letter queue
You can use several different methods to define these objects, depending on your WebSphere MQ platform.
7. What is Qmanager cluster?
A:A queue manager cluster is a group of two or more queue managers that are logically associated and can share information with each other. This means that an application can put a message on a cluster queue from any queue manager in the cluster and the message is automatically routed to the queue manager where the cluster queue is defined. The amount of system administration is reduced because the cluster channels that the cluster queue managers use to exchange application messages are automatically defined as required.
Before you can create a new queue manager cluster:
- Create two queue managers that will have the full repositories for the cluster.
- Each full repository queue manager in the cluster must have a running listener.
- You must know the connection details of each full repository queue manager in the cluster because the you are asked to enter these details in the wizard.
8. Types of channels? Difference between different channels?
A:A message channel, which is a unidirectional communications link between two queue managers. WebSphere MQ uses message channels to transfer messages between the queue managers. To send messages in both directions, you must define a channel for each direction.
Types:
1.Sender
A sender channel is a message channel that the queue manager uses to send messages to other queue managers. To send messages using a sender channel, you must also create, on the other queue manager, a receiver channel with the same name as the sender channel. You can also use sender channels with requester channels if you are implementing a "callback" mechanism.
2. Server
A server channel is a message channel that the queue manager uses to send messages to other queue managers. To send messages using a server channel, you must also create, on the other queue manager, a receiver channel with the same name as the server channel.
3. receiver
A receiver channel is a message channel that the queue manager uses to receive messages from other queue managers. To receive messages using a receiver channel, you must also create, on the other queue manager, a sender or a server channel with the same name as this receiver channel..
4. Requester
A requester channel is a message channel that the queue manager uses to send messages to other queue managers. To send messages using a requester channel, you must also create, on the other queue manager, a sender channel if you are implementing a callback mechanism, or a server channel.
5. Cluster-sender
cluster-sender (CLUSSDR) channel definition defines the sending end of a channel on which a cluster queue manager can send cluster information to one of the full repositories.
6. Cluster-receiver
A cluster-receiver (CLUSRCVR) channel definition defines the receiving end of a channel on which a cluster queue manager can receive messages from other queue managers in the cluster. A cluster-receiver channel can also carry information about the cluster—information destined for the repository
9. Use of Alias Queue?
A:Alias queues are not actually queues; they are additional definitions of existing queues. You create alias queue definitions that refer to actual local queues but you can name the alias queue definition differently from the local queue (the base queue). This means that you can change the queues that an application uses without needing to change the application; you just create an alias queue definition that points to the new local queue.
10. What type of storage is used in WMQ?
A:
----------------------------------------------------------------------------------------
11. What is threshold, depth of Queue, Max Queue depth, Max message length of message?
Threshold: If the event queue reaches the max depth limit then the further events will not be stored in the queue. So set the threshold for '% of Queue Occupied' property for the event queues to avoid loss of event message.
Depth of Queue :The pending messages in queue it will be between the range 0 - 999999999.
Max Queue Depth: The value of Maximum Queue Depth represents the maximum number of messages that a queue can hold.
Max message length of message : The MaxMsgLength queue attribute is the maximum length of a message that can be handled by a queue. The default maximum message length on IBM WebSphere MQ is 4 MB.
12. What is Dead letter Queue?
A: Websphere MQ provides the Dead Letter Queue (DLQ) Handler Utility to process undelivered messages, and it can be implemented as a server service object, or triggered whenever a message appears on the DLQ.
13. What is JMS? Which is the provider used? How to use JMS in WMQ?
JMS is the specification provided by Sun for messaging. MQ Queue is the IBM's implementation of JMS. Similary JBoss has its own implementation.JMS Queue is the generic term. The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API[1] for sending messages between two or more clients. It is a messaging standard that allows application components based on the Java Enterprise Edition (Java EE) to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous
14. How messages are given Priority?
You set the priority of a message (in the Priority field of the MQMD structure) when you put the message on a queue. You can set a numeric value for the priority, or you can let the message take the default priority of the queue.
The MsgDeliverySequence attribute of the queue determines whether messages on the queue are stored in FIFO (first in, first out) sequence, or in FIFO within priority sequence. If this attribute is set to MQMDS_PRIORITY, messages are enqueued with the priority specified in the Priority field of their message descriptors; but if it is set to MQMDS_FIFO, messages are enqueued with the default priority of the queue. Messages of equal priority are stored on the queue in order of arrival.
The DefPriority attribute of a queue sets the default priority value for messages being put on that queue. This value is set when the queue is created, but it can be changed afterwards. Alias queues, and local definitions of remote queues, can have different default priorities from the base queues to which they resolve. If there is more than one queue definition in the resolution path (see Name resolution), the default priority is taken from the value (at the time of the put operation) of theDefPriority attribute of the queue specified in the open command.
The value of the MaxPriority attribute of the queue manager is the maximum priority that you can assign to a message processed by that queue manager. You cannot change the value of this attribute. In WebSphere® MQ, the attribute has the value 9; you can create messages having priorities between 0 (the lowest) and 9 (the highest).
15. What is the use of DB in MQ?
WebSphere MQ persistence is always a local filesystem for distributed platforms. On the mainframe there is the possibility of using a DB2 database in a Sysplex with a Coupling Facility but for everything else it is a filesystem.
Also, there is no local persistence for WebSphere MQ clients. Only the queue manager will persist messages.
In the WebSphere family, WebSphere Application Server's System Integration Bus has the ability to use a database for it's message persistence. SIBus is a JMS implementation provided with WAS for exchanging messages in the WAS cell and between WAS instances.
16. Default Qmanager Listener port?
You're changing the queue managers default listener port. Be very careful, because this could cause channel problems, or other unexpected results, which are difficult to debug. Each queue manager is created with the default listener port set to 1414. This default port is used whenever you choose to omit the port number specification on your channel definitions and other commands. If you are going to use a default listener port other than 1414, then you might want to consider using the same default listener port for all of your queue managers.
17. Which are the protocols we can use in WMQ?
SPX,TCP, LU6.2 And NetBIOS
18. How to check which all Qmanagers are running in UNIX, command?
Use
dspmq -m ->The queue manager for which to display details. If you give no name, all queue manager names are displayed.
20. How to find the version in UNIX?
Use the dspmqver command to display WebSphere MQ version and build information.
By default, the dspmqver command displays details of the installation from which it was invoked. A note is displayed if other installations exist; use the -i parameter to display their details.
sh> . /path/to/wmq-7.1/bin/setmqenv -n Installation3
sh> dspmqver -a
21. Where the logs are created in WMQ?
A: The directory in which the log files for a queue manager reside. This must exist on a local device to which the queue manager can write and, preferably, on a different drive from the message queues. Specifying a different drive gives added protection in case of system failure.
The default is:
- C:\Program Files\IBM\WebSphere MQ\log in WebSphere MQ for Windows .
- /var/mqm/log in WebSphere MQ for UNIX and Linux systems.
22. What is triggering?
WebSphere MQ provides a feature that enables an application or channel to be started automatically when there are messages available to retrieve from a queue. A message is put to a queue defined as triggered.
23. What is MCA?
Message Channel Agent A message channel agent (MCA) is a program that controls the sending and receiving of messages. There is one message channel agent at each end of a channel. One MCA takes messages from the transmission queue and puts them on the communication link. The other MCA receives messages and delivers them onto a queue on the remote QMGR A message channel agent is called a caller MCA if it initiated the communication, otherwise it is called a responder MCA. A caller MCA may be associated with a sender, cluster-sender, server (fully qualified), or requester channel. A responder MCA may be associated with any type of message channel, except a cluster sender.
24. What is persistence?
The WebSphere MQ message persistence setting determines if a message survives system failures or a queue manager restart. The persistence attribute can be set in the message descriptor by the putting application, or is can be set using the default persistence attribute of the queue. After the message persistence is set, it retains that setting for the life of the message.
25. What is syncpoint?
Answer 1: Yes, you are understanding it correctly. Transactions are atomic units of work that succeed or fail in their entirety. Syncpoints are the boundaries between the transactions. The subtle difference between a transaction and a syncpoint is that the work done under a transaction can be in-doubt for a period of time whereas the sync point is the state during which the transaction is not in doubt. In the event of failure, the queues are restored to the state which existed at the last syncpoint and then any pending transactions rolled back or, in the case of XA, possibly committed by the resource manager.
The Infocenter page Transaction management and support may explain it better than the page linked in the post.
Answer 2: The data is synchronized by the resource manager(s). For local units of work where messages are the only participants in the transaction, the synchronization occurs only in the queue, and the queue manager acts as both the resource manager and the transaction manager. For global units of work involving messages and database updates in the same transaction, the synchronization occurs in the QMgr and the database which act as resource managers. The transaction manager will either be MQ or an application server and it orchestrates the synchronization between the resource managers.
Regardless of whether the transaction is local or global (sometimes also referred to as single-phase commit or 2-phase commit) the relationship between transactions and syncpoints is the same. The syncpoint is the most recent point in time at which a known state is preserved and to which an in-doubt transaction might be rolled back.
Part -1 :Basics
1. What are advantages of using message broker?
A: Websphere message broker provides services, based on message brokers to allow you to:
- Route a message to several destinations, using rules that act on the contents of one or more of the fields in the message or message header.
- Transform a message, so that applications using different formats can exchange messages in their own formats.
- Store a message, or part of a message, in a database.
- Retrieve a message, or part of a message, from a database.
- Modify the contents of a message; for example, by adding data extracted from a database.
2. Why do you need message broker when you have MQ?
AFAIK message broker transforms messages from one format to another (e.g. JMS to MQ) or routes a message to another place/broker/queue depending on content or topic; whereas MQ is the queue the message ends up on where it's held until it's consumed by some other app. You used to (WMB6) have to have WMB in front of MQ if you wanted your messages transformed/processed before being put on a queue, I don't think this is so much the case now as MQ itself can do some of the WMB functionality now.
OR
------------------------
WebSphere MQ facilitates communication between applications by sending and receiving message data via messaging queues. WebSphere MQ provides a secure and reliable layer of transport for moving data unchanged in the form of messages between applications but it is not aware of the content of the messages.
-----------------------
WebSphere MQ is a solution for application-to-application communication services regardless of where your applications or data reside. Whether on a single server, separate servers of the same type, or separate servers of different architecture types, WebSphere MQ facilitates communications between applications by sending and receiving message data via messaging queues. Applications then use the information in these messages to interact with Web browsers, business logic, and databases. WebSphere MQ provides a secure and reliable transport layer for moving data unchanged in the form of messages between applications but it is not aware of the content of the messages. WebSphere MQ uses a set of small and standard application programming interfaces (APIs) that support a number of programming languages, including Visual Basic, NATURAL, COBOL, Java, and C across all platforms.
WebSphere Message Broker is built to extend WebSphere MQ, and it is capable of understanding the content of each message that it moves through the Broker. Customers can define the set of operations on each message depending on its content. The message processing nodes supplied with WebSphere Message Broker are capable of processing messages from various sources, such as Java Message Service (JMS) providers, HyperText Transfer Protocol (HTTP) calls, or data read from files. By connecting these nodes with each other, customers can define linked operations on a message as it flows from one application to its destination.
Message Broker can do the following:
* Matches and routes communications between services
* Converts between different transport protocols
* Transforms message formats between requestor and service
* Identifies and distributes business events from disparate sources
Together, WebSphere MQ and WebSphere Message Broker deliver a comprehensive publish and subscribe facility, connecting Message Broker’s broad transport and format support to WebSphere MQ’s messaging backbone. WebSphere Message Broker extends the WebSphere MQ publish and subscribe functionality with advanced function such as content-based publish and subscribe by means of an enhanced Publication node. The two products share a common publish and subscribe domain for topic- and content-based operations
3. Tell me few difference between v6.0 and v6.1
4. What is message flow?
A message flow is a sequence of processing steps that run in an integration node when an input message is received. A message flow is a sequence of processing steps that run in the broker when an input message is received.
5. What are the main 3 components of Message Broker?
The 3 main components in IIB/WMB are Runtime, Development and Administration.
Runtime - The broker runtime is the main processing component to which development artifacts are deployed.
Development - The Toolkit is used for development of message flows and other development artifacts.
Administration - Message Broker Explorer is an administration tool used to perform deploys, create brokers or new execution groups, and enable flow monitoring. WMB V8 provides a WebUI tool to view the broker runtime or resources deployed in a browser.
or
------------------------------------------------------------------------------------------------------
The main components used in Message Broker Name Server are
- User Name Server
- Configuration Manager
- Broker
------------------------------------------------------------------------------------------------------
6. What are broker domains?
A: A broker domain is one or more brokers that share a common configuration, together with the single configuration manager that controls them. The configuration manager maintains all configuration details about the brokers in its domain within its internal configuration repository.
7. What is the interface between Toolkit, internal configuration and brokers?
A: The configuration manager functions as the interface between toolkit instances, its internal configuration repository, and a set of brokers executing message flows.
8. What are nodes in message flows?
Message broker nodes are used in Message flows. A message flow node is a processing step in a message flow.
A message flow node receives a message, performs a set of actions against the message, and optionally passes the message on to the next node in the message flow. A message flow node can be a built-in node, a user-defined node, or a subflow node.
A built-in node is a message flow node that is supplied by WebSphere Message Broker. The built-in nodes provide input and output, manipulation and transformation, decision making, collating requests, and error handling and reporting functions.
A user-defined node is an extension to the broker that provides a new message flow node in addition to those supplied with the product. It must be written to the user-defined node API provided by WebSphere Message Broker for both C and Java languages.
A subflow is a directed graph that is composed of message flow nodes and connectors and is designed to be embedded in a message flow or in another subflow. A subflow must include at least one Input node or one Output node. A subflow can be executed by a broker only as part of the message flow in which it is embedded, and therefore cannot be independently deployed.
9. What happens to the running brokers, if configuration manager is down?
The running broker will also be down at the moment when configuration manager is down.
Part-2 (Install&Configure)
1. How do you create broker database in Windows/Linux (commands)
We have the mqsicreatedb command for this, it takes 1 compulsory parameter, this is the minimum number of parameters you need to supply to create a broker database,You could just simply type in mqsicreatedb brtdb this will create a database with no port set to access it, on the current user profile you typed this command, or you could set the port while creating the database in the first place mqsicreatedb brtdb -p 1600, optionally you can also specify a workbench user Id and Password mqsicreatedb brtdb -i wbrkuid -a wbrkpw -e Derby -p 1527 this will creat e a Derby database.
For creating a DB2 database login with administrative privileges and create a database using this command
Create Database brtdb this will create a database and you will have full privileges on it..... to grant privilages to other user you have to use GRANT ALL ON brtdb TO USER UserWITH GRANT OPTION
2. Where can you find the default odbc32.ini file? (location)
A: /install_dir/ODBC32/V5.3 directory
3. What are the 3 important parts of the odbc32.ini file ?
There are four parts that can comprise an ODBC.INI file.The second and third sections are not mandatory for operation. The sections of the ODBC.ini file are listed below.
Sections of the ODBC.INI
------------------------------------
A. ODBC data sources This section contains the name of each data source and the driver name associated with it.
B. Options that apply to all data sources These options are used for tracing and debugging purposes.
C. Default data source section This section contains information about the default data soturce. It will be a copy of one of the data sources listed by name later. It will have a single group in it , called "default."
D. Groups configured for each data source. This group has sections for each data source. All attributes for a particular data source are listed, one per line.
4. what happens, if you do not create the required 'Q's in MQ before running mqsicreate commands?
Checks whether the specified WebSphere® MQ queue manager already exists:
If it does not exist:
If you run this command on z/OS, it reports an error and fails.
If you run this command on Linux, UNIX, orWindows, this command creates a queue manager.
5. What is the command to create a broker?
A: Use the mqsicreatebroker command to create a broker and its associated resources.
6. on mqsicreatebroker command what does the parameter '-j' specifies?
A: -j — Enable publish/subscribe for the broker
7. What does '-s' parameter specifies on mqsicreateconfigmgr command
mqsicreateconfigmgr ConfigmgrName -i ServiceUserID -a ServicePassword
-q QueueManagerName -s UserNameServerQueueManagerName
8. How do you change ConfigurationTimeout and ConfigurationDelayTimeout for a given broker?
Configuration timeout and deloay timeout can be changed by mqsichangebroker using these parameters
-k internalConfigurationTimeout (Optional):
The maximum time (in seconds) that is allowed for an internal configuration change to be processed. For example, it defines the length of time taken within the broker to start an execution group. The response time of each execution group differs according to system load and the load of its own processes. The value must reflect the longest response time that any execution group takes to respond. If the value is too low, the broker returns a negative response, and might issue error messages to the local error log.Specify the value in seconds, in the range 10 to 3600. The default is 60.
-g configurationChangeTimeout (Optional):
The maximum time (in seconds) that is allowed for a user configuration request to be processed. It defines the length of time taken within the broker to apply to an execution group a configuration change that you have initiated. For example, if you deploy a configuration from theworkbench, the broker must respond to the Configuration Manager within this time. A message flow cannot respond to a configuration change while it is processing an application message. An execution group that has been requested to change its configuration returns a negative response to the deployed configuration message if any one of its message flows does not finish processing an application message and apply the configuration change within this timeout. Specify the value in seconds, in the range 10 to 3600. The default is 300. For information about how to set the value for this timeout, see Setting configuration timeouts.
9. What does mqsilist command do ?
Use the mqsilist command to list installed brokers and their associated resources.
The command returns information about the following resources:
-> Local and remote brokers
-> Integration servers defined on the brokers
-> Applications in an integration server
-> Libraries in an integration server
-> All resources that you have deployed to each integration server, including message flows and message model schema files
-> Runtime versioning information for those resources, if applicable
10. After finishing installation and starting the components, w here do you check the logs to see the most recent events.
In the Event log Of the Message Broker Toolkit. and in the Systems ControlPanel>AdministrativeTools>EventViewer>Application category .
11. How do you initilize the environment before starting the broker components?
We must use MQSISTART to start the broker component, this command will start the configured queue manager associated with the broker component if its not already running, no listeners or channels are started with it.
12. How can you add additional environment settings/scripts to the broker environment? or where do place the custom scripts that needs to be sourced while initilizing the broker environment.
A: If you want to run your own additional environment settings, add a script called your_file_name.sh to the broker’s work_path directory which contains the: /common/profiles subdirectory. When you run mqsiprofile again, the command automatically calls the additional user-written scripts in this location. The newly added script will not be picked up if you run an mqsistart command from an existing initialized command shell. work_path identifies the broker’s working directory; if you are unsure of the broker’s work path, enter the following command: echo $MQSI_WORKPATH
-> Issue the mqsiprofile command: . install_dir/bin/mqsiprofile
You must include the period and space preceding the location for this invocation to work correctly. Add this command to your login profile if you want it to be run at the start of every session.
This command accesses additional scripts that you have copied to the common/profiles directory, therefore the environment is initialized for runtime components and other resources such as databases.
-> Start the components that you want to run on this system using the mqsistart command.
=>Running database setup scripts
A broker requires access to a database to maintain operational and state data, and might also require access to user databases from deployed message flows.
When you install a database product on Linux and UNIX systems, some database managers provide a profile to perform the environment set up that the database requires, or provide details of actions that you must take in their documentation.
# If you can update the profile (mqsiprofile script) to provide permanent values for the details that are required (for example, the database server name or the installation directory):
1. Complete the changes to the profile.
2. Copy the profile file to the directory work_path\common\profiles.
# If you cannot update the profile permanently, but need to make changes each time, you must run it independently of the mqsiprofile command:
Run the appropriate profiles to initialize the environment for the database:
DB2: . db2_instance_directory/sqllib/db2profile
Oracle: . ${ORACLE_HOME}/bin/oraenv
Note: If you have installed 64-bit instances of DB2 or 64-bit Oracle databases, you need to complete additional setup steps, including adding 32-bit libraries to the LIBPATH.
-----------------------------------------------------------
13. If you cannot update mqsiprofile for database related information, In what other way can we supply the required information to the broker environment
A:
If you cannot update the profile permanently, but have to change it each time, you must run it independently of the mqsiprofile command:
Run the appropriate profiles to initialize the environment for the database:
For DB2®, issue the following command for the relevant DB2 instance:
. db2_instance_directory/sqllib/db2profile
For Oracle, export ORACLE_HOME and ORACLE_SID, then issue the following command:
. ${ORACLE_HOME}/bin/oraenv
For Sybase, issue the following command, specifying your installation directory:
. Sybase_installation_directory/SYBASE.sh
For Informix®, check the documentation for the client on your broker system for details of the actions that you must take. For example, you might have to specify the following environment variables:
export INFORMIXDIR=/installation_directory_of_informix_client_software
export PATH=${INFORMIXDIR}/bin:${PATH}
export INFORMIXSERVER=server_name
export INFORMIXSQLHOSTS=${INFORMIXDIR}/etc/sqlhosts
export TERMCAP=${INFORMIXDIR}/etc/termcap
export TERM=vt100
export LIBPATH=${INFORMIXDIR}/lib:${INFORMIXDIR}/lib/esql:
${INFORMIXDIR}/lib/cli:$LIBPATH
where server_name is defined in the file sqlhosts (the required value is typically the machine name), and the location of the file sqlhosts is set up as part of the installation process.
To configure your system to run this setup at the start of every session, add these statements to the login profile of the user that is going to run the broker.
----------------------------------------------
