Others
Showing posts with label Others. Show all posts
Showing posts with label Others. Show all posts

How to install and configure Cristie TBMR to do bare metal recovery of Linux servers

04:11 No Comments
Cristie Tivoli Bare Metal Recovery (TBMR) is a third party software which works together with IBM TSM BAclient software to backup system files and regular data files. When disaster occurs, Cristie TBMR with the help of TSM BAclient can able to restore the data files along with the operating system to its current backup state without the OS CD. Cristie TBMR backs up not only the data files, but the operating systems, applications, networks etc. along with all customizations and configurations as they were before the failure. It actually builds a perfect clone of your entire software infrastructure. TBMR backups can be taken periodically, along with configuration information, which includes details of hard disks, network interfaces, etc. It is possible to recover the original system to the same system or to another system with a dissimilar hardware. 

In this post, I will share how to use Cristie TBMR & TSM BAclient to save the system configuration information, backup and recover a Linux machine. TBMR for Linux can be installed on a x86, x86_64 or PPC Linux machine.

 Also Read: 11 tips to increase restore performance

Cristie TBMR Limitations
TBMR for Linux does NOT support
  • Platforms other than Intel.

  • Multi-boot operating systems

  • Recovery of files that are being written to at the time of backup.

How to protect Linux systems using Cristie TBMR and TSM BAclient softwares

1) Install & Configure BA client on the client machine as usual.

2) Install TBMR on the client system you wish to protect.


3) Use the tbmrcfg command to capture and store the configuration of the system. 

4) Use the TSM BA Client to backup the data files & system configuration file generated in the above step to your TSM server.

 Also Read: Use these Exclude options during backup to save storage pool space

Follow these below steps
  • First, the TSM BA client should be configured to backup all files which are required for OS recovery. By default, the /dev directory is not backed up. To make sure this is backed up, the following line should be added to the dsm.sys file:               virtualmountpoint /dev

  • This will create a separate filespace for /dev which will be restored by the recovery        environment.
  • To save the system configuration information of the client machine, by default, the following command  tbmrcfg is used. It is recommended that this is run prior to running each BA client backup to ensure the configuration is up to date.
  • To save configuration information from a machine that boots using grub installed on /dev/sda to the backup location, use:
            tbmrcfg -b grub -d /dev/sda

  • To save configuration information from a machine that boots using grub installed on /dev/hda, use: 
         tbmrcfg -b grub -d /dev/hda

        You can also use man tbmrcfg command to check the syntax.

  • In order to ensure that you can recover to the latest version of the operating system that was installed on your Linux machine, you must ensure that a TSM incremental backup is performed every time the operating system files change. You have to run tbmrcfg commnad to generate new updated system configuration information in /TBMRCFG directory, this must be done before the backup is run to make sure that we have the latest system configuration backup along with client data files. The best recommended way is to add preschedulecmd parameter with tbmrcfg in dsm.sys file value as shown below.
              preschedulecmd tbmrcfg
  • System configuration information is always saved to /TBMRCFG directory, it can't be saved anywhere else. We have to make sure to backup this directory during our regular BA client backups.

How to recover a Linux server using Cristie TBMR and TSM BAclient softwares

Below are the following steps to recover the Linux machine to its current backup state
  • Boot into Recovery environment (using ISO file which you have downloaded) and configure as required.
  • Read Configuration Data from your backup

  • Restore Files from your backup

  • Load additional drivers (if necessary)

  • Reboot into recovered OS
When the client machine is crashed, it can be recovered using the TBMR bootable CD-ROM. This is the same CD from which you have installed the software. You should ensure your machine’s BIOS is set up to boot from CD-ROM. You will see a screen as below.

How to install and configure Cristie TBMR to do bare metal recovery of Linux servers

You can choose which method you want to use for recovering the system, GUI or text based. GUI is the easiest one. If you select the X-window based recovery option, you should see a screen as below.

TBMR on linux recovery

Here also, you can choose Automatic recovery or Manual Recovery option. Before starting you first need to setup network information in the tools tab. Watch the below video to know how to recover an Linux system to its current backup state using Cristie TBMR.

Also Read: How TSM Server determines the eligibility of files during different types of backup ?



Note:
  • If the machine fails to boot after the restore, you can raise a cristie support request. Cristie support will require copies of the log files to diagnose any problems. Log files has exactly what has happened during the recovery on your system. Without them, it is very difficult to troubleshoot. The Location of log files is /var/log/cristie/recovery/
  • In our case, the NIC drivers for the NIC card we are using are not included in the recovery ISO, Cristie can help you to fix this kind of issues, they gave us a new customized recovery ISO file suitable for our environment. So, it is recommended to check the recovery on a test system before implementing on a production server.
  • You can download Cristie TBMR trial version software from their website and test it for 30 days. Then you have to update the license information to extend it. Updating license info can be done online from the portal or manually on client system. As of my experience, they gave good customer service.

Differences between IBM Spectrum Protect (TSM) and EMC Avamar backup tools

00:33 No Comments
Working as a IBM TSM Administrator, it is our job to know the major advantages of Tivoli Storage Manager (TSM) on other backup software tools that are available in the market. Knowing these details will also helps your future career growth and prospects. In this post I will try to put some major advantages of IBM Tivoli Storage Manager over EMC Avamar. This comparison is made between IBM TSM V6 and EMC Avamar V5. There may be changes in these differences (IBM TSM vs EMC Avamar) when the new versions of both the backup tools are released.

EMC AVAMAR Architecture Basic Introduction

  • Avamar is a backup software tool acquired by EMC in November, 2006. This was EMC’s second major acquisition of enterprise level backup software, having acquired Legato in July of 2003.
  • Avamar uses an incremental forever architecture supported by policy based management with versioning, expiration and reclamation.  It can simulate a traditional backup plan that appears to require full periodic backups. 
  • It encrypts data in transit with 128 or 256 AES bit or proprietary encryption for data in transit and optionally at rest, compression, central administration and a dashboard. 
  • The Avamar server runs on a single server for small environments or scales up by adding additional systems and redistributing workload with automatic load balancing.
  • Avamar is based on a grid architecture that stores only a single instance of any unique data for all clients that use the grid servers.  The Avamar client (on the source server that hosts the application) scans its filesystem to identify new or changed files. The client then segments the data and uniquely identifies it using a SHA-1 hashing algorithm. If the client identifies that data segment is new the client sends the hash, called a segment ID, to the Avamar server where it checks if the data segment is new or already stored.  If the data is new to the Avamar server it asks the client to send the data.  
    tsm vs avamar
  • The Avamar server grid stores the data on a node within the grid based on the unique ID.  Avamar is a distributed index based architecture and does not maintain a single meta database, rather it uses the self describing organization of the unique ID’s. The Avamar server takes checkpoints which are snapshots in case a roll back to a previous state is required. 
  • Networker 7.4 SP 1 integrates with Avamar by offering a single agent that can be used for traditional backup using Networker or as an Avamar agent for backup with deduplication.  Networker also provides configuration and management of the Avamar client through the Networker Management Console.
  • When an Avamar agent is used the data is backed up to an Avamar server, it is not backed up to a Networker server.  When the traditional Networker client is used to back data up to a Networker server Avamar is not used as a backend data store for Networker. Avamar integration with Networker is currently limited to agent integration and administration.     

Differences between IBM TSM and EMC AVAMAR Backup Software Tools

Performance

1) EMC Avamar is best supported for small and medium sized enterprises. It does not perform well in large enterprises or in stress full enterprises. Any organization which meet below setup would leads to very slow backup performance.
  • Large, high transaction databases >1TB
  • >10% daily change rates
  • Encrypted, Compressed, or “Noisy” Data
  • Image Files, Videos, X-rays 
Tivoli Storage Manager is proven in its ability to backup large high transaction databases and “difficult” data including data that is encrypted, compressed, image file, videos and X-rays. Many of TSM’s most satisfied customers are heath care, energy and media companies with data intensity levels well beyond typical commercial applications. 

 Also Read: IBM Spectrum Protect (TSM) Basic Free Tutorials

2) Avamar has a performance impact on the customer’s application servers as it is a client side only implementation. Whereas TSM server side deduplication does not impact the application servers performance. TSM client side deduplication where the application server has adequate cycles to devote to deduplication. TSM can support both client and server deduplication to the same storage pool,  getting the benefit of deduplication between application servers that have time to dedupe for themselves and those that don’t. 

Hardware Administration
  • Avamar requires additional hardware and administrative expense for a second backup infrastructure assuming tape support is required either for lower cost disaster recovery or off site storage for long term archive. Whereas IBM TSM’s integrated tape support eliminates the need to create and maintain a second infrastructure to archive to tape, a capability used in most installations.
  • Avamar requires a minimum of a three server configuration for full function.  Separate dedicated systems are required as “Access Nodes” for the database search function and also a separate dedicated system is required for the NDMP Accelerator for backup of Network Appliance filers and it appears an additional dedicated system is also required for backup of EMC Celerra. Whereas TSM only needs a single server to provide its services and can take advantage of servers with multi-core processors for higher levels of scalability and performance. 
Scalabiity
  • Scaling Avamar requires substantial additional systems.  The system that stores the de-duplicated data (“storage node”) is limited to storing 3.3TB of data and is limited to an 18 node system with 52.8TBs of data in standard form. One sophisticated and well supported Avamar user has reported that Amamar tops out at 12 to 13 TB in a cluster (Avamar ‘grid”).   
  • TSM scalability of its disk storage pools has been demonstrated to 30TB using a single TSM server. Differences in the environment, such as average file size and dedupe chunk size, can vary scalability substantially but in this fairly typical TSM environment a TSM metadatabase of 368 GB db supported the 30TB of data in a deduplicated storage pool. In typical operational environments a single TSM server using deduplication is estimated to have scalability several times this size. 
Tape Support
  • Avamar cannot directly write to tape. Avamar itself does not write data directly to tape, rather it uses its Data Transport function to send data to a third party backup product that can then write the data to tape. The Data Transport function is limited to the  use of either Networker or Symantec NetBackup running only on Solaris, Linux or Windows servers (no AIX or HP-UX support) to write the data to tape, requiring a second backup infrastructure to buy, plan, install, operate and maintain. Data Transport is limited to Avamar grids up to 22 TB, which reduces the theoretical scale down for an Avamar Grid from 52.8 TB by nearly 60%.
  • TSM has robust tape support from its many server platforms and its use does not severely limit its scalability and, unlike Avamar, provides the function on TSM avoiding the need for a buy, plan, install, operate and maintain a second backup infrastructure.  
Hierarchal Storage Management (HSM) Support 
  • Avamar has no HSM to offset its scalability limits. Avamar is a disk only backup/restore process and cannot minimize the amount of tier 1 disk used to store unique data. The capacity of the storage node could be stretched by limiting the number of versions of files kept, reducing the ability to recover further back in time. 
  • TSM has built in hierarchical storage management and allows the use of multiple levels of disk, tape and optical storage to provide different levels of service at the minimum expense for storage media.    
Archival Support
  • Avamar has no built-in Archive support, instead of providing built-in support for archiving Avamar has an extra cost option that allows Avamar to be the back end data store for EMC Centera, which is of limited value since Centera has native file level deduplication. 
  • TSM has built in archive support and does not require an expensive additional piece of hardware, such as EMC Centera, to deliver archive support.
Information Lifecycle Management Support 
  • Avamar lacks the ability to actively participate as part of an automated Information Lifecycle Management Process. Applications server and workstations often build up unneeded files over time  that consume disk space on both the primary and backup server.
  • TSM can use automation to archive files identified by Tivoli Storage Productivity Center (TPC) so they don’t take up space on the application system.      
Database checkpoints Frequency
  • Avamar has a less than robust core infrastructure, database checkpoints are taken twice a day and allow roll backs to a previous point in time but there is no  database transaction logging with a roll back/forward recovery process. Falling back to the last checkpoint, where only two checkpoints are taken per day, creates a potentially large recovery exposure where the latest backups are unavailable.
  • TSM uses DB2 and provides the highest level of data integrity to maintain its meta data base with transaction logging and a roll back/forward recovery processes.    
Disaster Recovery Strategies

1) Avamar has limited disaster recovery options for the Avamar  server. Replication to a second Avamar server is an optional module and is expensive. Traditional backup to Networker or other backup software is only practical for at most a daily backup. 

 Also Read: Understanding Management Class Binding and Management Class Rebinding

2) TSM is legendary for the range of choices and depth of its disaster recovery capabilities 
  • Vaulting of TSM database, recovery log, volume history information, device configuration information, DRP file (if using Disaster Recovery. Manager)  and copy pools for storage at an offsite location.
  • Use of TSM server-to-server communications to enable enterprise configuration (multiple TSM servers), enterprise event logging and monitoring, and command routing. 
  • TSM servers installed at multiple locations, optionally setup as peer to peer servers (that is, each server able to recover at the alternate site). 
  • Use of TSM virtual volumes over TCP/IP connection to allow storage of TSM entities (TSM database backups, recovery log backups, and primary and copy storage pools, DRM plan files) on remote target servers. 
  • Use of high bandwidth connections and data replication technology (such as IBM PPRC, EMC SRDF) to support asyschronous/sychronous data replication of TSM databases backups, recovery log backups, TSM database and recovery log mirrors, and storage pools. 
  • Use of remote electronic tape vaulting of TSM database and recovery log backups, primary or copy storage pools. Extended distances can be achieved by using distance technologies, for example, extended SAN, DWDM, IP/WAN channel extenders.
Application Support  
  • Avamar lacks application support for SAP and Informix. 
  • TSM has wide application support including support for SAP and Informix.  
FlashCopy Support
  • Avamar lacks support for disk array copy services (EMC snap or IBM flashcopy).
  • TSM supports IBM Flashcopy for Exchange, DB2 and MySAP on IBM San Volume Controller (SVC), IBM DS6000 and DS8000.    
VMWare Support
  • Avamar recommends their customers to use the newest API to backup VMware.  The use of the new VMware vStorage API for backup was needed by Avamar to overcome  problems with it prior options for VMware support.  Many customers have only recently just shifted to the use of the VMware Consolidated Backup (VCB) for backups and are again likely to take a conservative approach to adoption of the new technology, preferring instead to let bleeding-edge customers pilot the new vStorage API for Data Protection from VMware. Like other backup products Avamar is carrying forward the use of the popular VMware Consolidated Backup (VCB) API but it creates the unacceptable administrative burden of requiring that each virtual machine (VM) must have its own group  to schedule VCB backups which must be setup and maintained one at a time. At one point to bypass the VCB admin issue EMC was recommending the use of the Image backup based on an agent running in an ESX service console, even though this posed a serious performance issue for the service console. 
  • TSM supports the new VMware vStorage API. TSM also continues to support the more popular VMware VCB without the administrative burden.    
Data Security
  • Avamar is a security exposure. The Avamar File System is not able to limit file access on a user-by-user basis. All files stored on a server are viewable by any user with access to Avamar File System.
  • TSM has client level access for restores to provide data security.
Centralized Client Maintenance

1) Avamar lacks automated and centralized client maintenance , just offering “support” for the  push install of the clients on Windows and Mac clients by common systems management tools, such as Microsoft’s Systems Management Server 2003 (SMS).

 Also Read: TSM Administrator Daily routine tasks

2) Like Avamar, TSM does not automate the initial client install. Unlike Avamar TSM through the TSM Admin Center provides a rich set of client software maintenance which can
  • discover  client maintenance levels on the TSM FTP site
  • download needed packages and store them on the TSM server
  • manage packages stored on the TSM server (retention, etc.)
  • select a maintenance level and distribute to a list of clients.  The code will then be distributed based on a predefined schedule.
  • review the client distribution status
Data Deduplication
  • The superficial integration that Avamar has with Networker is an attempt to cover up the inherent disadvantages of having two separate code bases that must be installed and maintained: a legacy product that couldn’t reasonably he enhanced to support built in deduplication and a deduplication product that does not scale well enough to even be used  as a back end data store to provide deduplication for the legacy enterprise data center product. The agents are packaged together and not integrated. Avamar needs its own management facilities and can’t run just using the Networker management function. The monitoring and reporting function Networker provides was so weak that EMC had to acquire Wysdm to support Avamar.  Contrast that with Tivoli’s built-in deduplication which is truly integrated with a multitude of advantages starting with eliminating the need to understand, deploy and manage two completely different infrastructures and ending with eliminating the need to bring in yet a third product to do centralized reporting. 
  • Avamar deduplication to tape has many limitations. EMC recommends its use only for infrequent long term data retention use cases for performance reasons. It does not match the ability of TSM to mix the use of tape and disk in normal operational environments where restores are likely or frequent.
  • Avamar itself does not store the data to tape, it requires the use of either Networker or Symantec NetBackup running only on Solaris, Linux or Windows servers (no AIX or HP-UX support) to write the data to tape after it is deduplicated by Avamar, requiring a second backup infrastructure to buy, plan, install, operate and maintain. 
CPU Throttling
Avamar has CPU throttling to control resource use on the application server. Avamar is limited to the use of client side deduplication and uses CPU throttling in an attempt to not impact the application server. TSM server side deduplication is a better choice when performance concerns exist over using application server resources for deduplication.   

Continuous Data Protection (CDP)
  • Avamar Lacks continuous data protection. Avamar has been positioned by EMC to backup frequent point in time copies by CLARiiON disk snapshot (like IBM Flashcopy) the solution is extremely expensive and still does not provide the frequency of data protection provided by TSM FastBack.
  • Tivoli FastBack has (real time replication) continuous data protection which saves data throughout the day, greatly reducing the amount of data lost compared to the typical use case of nightly backup by Avamar.
Time for Restoration
  • Avamar restore time is lengthy and is not appropriate for application that require higher levels of availability.
  • Tivoli FastBack’s near instant restore does not require the restoration of data from the backup copy to a different disk accusable by the application server, rather with FastBack, the backup data becomes the production data, nearly instantly.
Bare Machine Recover (BMR) Support
  • Avamar lacks integrated bare machine recovery, requiring the use of  a separate product such as EMC HomeBase for restoring the Avamar server in case of disaster.
  • TSM FastBack has integrated Bare Machine Recovery.  

Webshere Message Broker Interview Question and Answers - Part 5

01:58 No Comments
This post contains last 36 Interview Questions including Answers. If you find any answers are wrong , please comment below so that we can update them and help others. Check the next post for more....

101. Exception Handling in MB?
Ans. By using the following nodes
  • Throw node
  • Trace node
  • Try Catch node
102. What is the difference between try catch node and throw node?
Ans. Throw node throws an exception where as a try catch node is used to handle the error, which is raised.

103. Difference between Root and Output Root?
Ans.  Both are correlation names. Root is used in nodes, which do not create a new output where as Output Root is used in a node, which can create a new output node.

104.In route to label node where we will gave label name, and syntax of the label name assignment in processing node?
Ans. By setting the Local Environment variable
Syntax:        
LocalEnvironment.Destination.Routerlist.DestinationData = ‘Label name’;

105. Define SCADA?
Ans. The SCADAInput node is used to receive messages from clients that connect to the broker across the WebSphere MQ Telemetry Transport. SCADA device clients use the MQIsdp protocol to send messages, which are converted by the SCADAInput node into a format recognized by WebSphere Message Broker. The node also establishes the processing environment for these messages.

106. Will broker run on AIX system or not?
Ans. Yes

107. Functionality of FlowOrder node?
Ans. FlowOrder node to control the order in which a message is processed by a message flow. The input message is propagated to the first output terminal and the sequence of nodes connected to this terminal process the message. When that message processing is complete, control returns to the FlowOrder node. If the message processing completes successfully, the input message is propagated to the second output terminal and the sequence of nodes connected to this terminal processes the message.

108. Is there any alternative for MQ to use along with MB?
Ans. No.

109. How to suspend a queue manager in a cluster?
Ans. In the Navigator view (in the Queue Manager Clusters folder), right-click the queue manager, the click Suspend cluster membership...

110. What happens if a message is sent to a local queue, which is filled, and a remote queue, which is filled? Any difference in them?
Ans. The message moves to the relevant default dead letter queue

111. Can we give all the format types in a single message set, If so how?
Ans.  YES.
112. How will you declare an array in MB and how will you retrieve the desired value from an array? Two types of representations?
Ans.
  • Dynamic Arrays
  • Structure-field arrays.
Dynamic Arrays:
Syntax: myDataItem01 CHAR(30)[] {maxSize=5}; 
        
Structure-field arrays:
Record myRecord01Part
10 name[3];
20 firstOne CHAR(20);
20 midOne CHAR(20);
20 lastOne CHAR(20);
End

To retrieve Values:
MyRecord01.name.lastOne[2]
MyRecord01.lastOne [2]
LastOne[2]

113. What are the properties of .bar file and when they are used?
Ans. The unit of deployment to the broker is the broker archive or bar file. The bar file is a zip-format file which can contain a number of different files:
A .cmf file for each message flow. This is a compiled version of the message flow. You can have any number of these files within your bar file.
A. dictionary file for each message set dictionary. You can have any number of these files within your bar file.
A broker.xml file. This file is called the broker deployment descriptor. You can have only one of these files within your bar file. This file, in XML format, resides in the META-INF folder of the zip file and can be modified using a text editor or shell script.
Any number of XML files(.xml) and style sheets (.xsl files) for use with the XMLTransformation node.
Any number of JAR files for use with the Java Compute node.
As a zip-format archive, the broker archive file can also contain any additional files you need. For example, you might want to include Java source files for future reference.

Also Read: Storage Area Network (SAN) Basic Free Tutorials

114. How will you handle an input message with different delimiters between the fields?
Ans. Using MRM domain          

115. What are the advantages of Message broker?
Ans. Comprehensive monitoring using predefined workspaces that provide statistical information such as Current Message Rates, Current Average Message Time, and Sub-flow Statistics.
Comprehensive solution for complex WebSphere MQ environments that enables drill down to problem components
Custom workspaces can be tailored for individual job functions

116. What happens when the queue name is not specified in the MQOutput node?
Ans. Message is backed out.

117. What are the differences between MB 5.0 and 6.0?
Ans. Some additional nodes are added Like Java Compute node.
Configuration manager can be created with out referring database.
Can be installed and configured on Aix also.

118. What is the difference between catch terminal and failure terminal in MQInput node?
Ans.
Catch terminal: The output terminal to which the message is routed if an exception is thrown downstream and caught by this node.
Failure terminal: failure terminal detects an internal error; it propagates the message to that terminal.
The output terminal to which the message is routed if an error occurs. Even if the Validation property is set, messages propagated to this terminal are not validated.

119. How to specify reference keyword in the ESQL and what is the use of it?
Ans. Declare ptr REFERENCE TO InputRoot.xml.emp.eno;
-- Here, ptr refers to a specific field reference
        
120. What is the need of transaction mode property in the compute node?
Ans. The transaction mode for the node. This can be Automatic or Commit. It is valid only if you have selected a database table for input

121. What are the types of data formats that MB will support?
Ans. XML, TDS, CWF.

122. What is the difference between TDS and CWF?
Ans. The Tagged/Delimited String format (TDS) is the physical representation of a message that has a number of data elements separated by tags and delimiters.
Custom Wire Format (CWF) is the physical representation of a message that is composed of a number of fixed format data structures or elements, which are not separated by delimiters

123. Command used to deploy?
Ans. Using mqsideploy

124. What should you do before creating the broker and the configuration manager?
Ans. We have to create the data source name and Queue manager

125. Explain about web services nodes?
Ans. WebSphere MQ Web Services Transport connects Web services and clients that use the HTTP protocol for messaging. A WSDL definition for that service can be imported into a message set using the new WSDL importer.
HTTPInput: This node to receive Web service requests for processing by a message        flow Use the HTTPRequest node to interact with a Web service
SET OutputRoot.HTTPResponseHeader = NULL;
HTTPReply: This node to return a response from the message flow to the Web service client.
Select the Ignore Transport Failures check box if you want transport-related failures to be ignored (for example, if the client is disconnected). If you clear the check box, and a transport-related error occurs, the input message is propagated to the failure terminal. If you clear the check box, you must supply a value for Reply send timeout.
Set the Reply send timeout value if you are not ignoring transport failures. This is the length of time that the node waits for an acknowledgment that the client has received the reply.

126. Explain about JMS nodes?
Ans. JMS Input Node: to receive messages from JMS destinations.
The JMSInput node receives and propagates messages with a JMS message tree. You can set the properties of the JMSInput node to control the way that the JMS messages are received. JMS Output Node: to send messages to JMS destinations

127. Process of clustering and what are the advantages of clustering?
Ans. Grouping up of two or more Queue managers
Advantages: load balancing, reduces network traffic

128. Working of XML Transformation node?
Ans. Used to transform an XML message to another form of XML message, according to the rules provided by an XSL (eXtensible Stylesheet Language) style sheet.
You can use node properties. This ensures that the transformation defined by this single style sheet is applied to every message processed by this node.
You can use the content of the XML data within the message itself. This transforms the message according to a style sheet that the message itself defines. This behavior is only available for XSL and XML files that are located within a Message Flow project.
You can set a value within the LocalEnvironment folder associated with the message. This provides a dynamic choice of style sheet, because you must set this value (in a Compute node) within the message flow after receipt of the message. You can therefore use a variety of inputs to determine which style sheet to use for this message, such as the content of the message data or a value in a database.

129. Configuration of HTTP Input Node?        
Ans.
HTTP INPUT Node:
In URL Selector, put the path part of the URL from which this node receives Web service requests. Do not give the full URL.
Enter the Maximum client wait time timeout interval, as a number of seconds. This is the length of time that the TCP/IP listener that received the input message from the Web service client waits for a response from the HTTPReply node in the message flow. If a response is received within this time, the listener propagates the response to the client. If a response is not received in this time, the listener sends a SOAP Fault message to the client that indicates that its timeout has expired.
Select the Fault Format as one of SOAP 1.1, SOAP 1.2 or HTML.
If the node is to accept secure HTTP, select the Use HTTPS check box.
Select Default in the properties dialog navigator and set values for the properties describing the message domain, message set, message type, and message format that the node uses to determine how to parse the incoming message.
In the Message Domain field, select the name of the parser that you are using from the drop-down list. You can choose from:
  • MRM
  • XML
  • XMLNS
  • XMLNSC
  • JMSMap
  • JMSStream
  • IDOC
  • MIME
  • BLOB
If you are using the MRM or IDOC parser, select the correct message set from the drop-down list in the Message Set field. This list is populated with available message sets when you select MRM or IDOC as the domain.

Leave the Message Set field blank for XML, XMLNS, XMLNSC, JMS, MIME, and BLOB parsers.
If you are using the MRM parser, select the correct message from the drop-down list in Message Type. This list is populated with messages that are defined in the message set that you have selected.
Leave Message Type blank for XML, XMLNS, XMLNSC, JMS, IDOC, MIME, and BLOB parsers.
If you are using the MRM or IDOC parser, select the format of the message from the drop-down list in the Message Format field. This list includes all the physical formats that you have defined for this message set.

Leave the Message Format field blank for XML, XMLNS, XMLNSC, JMS, MIME, and BLOB parsers.

Select Validation in the properties dialog navigator if you want the MRM parser to validate the body of messages against the dictionary generated from the message set. (If a message is propagated to the failure terminal of the node, it is not validated.)

Select General Message Options in the properties dialog navigator. Parse Timing is, by default, set to On Demand. This causes validation to be delayed until it is parsed by partial parsing. If you change this to Immediate, partial parsing is overridden and everything in the message is parsed and validated, except those complex types with a Composition of Choice or Message that cannot be resolved at the time. If you change this to Complete, partial parsing is overridden and everything in the message is parsed and validated; complex types with a Composition of Choice or Message that cannot be resolved at the time cause a validation failure.

Select Description in the properties dialog navigator to enter a short description, a long description, or both.

Click Apply to make the changes to the HTTPInput node without closing the properties dialog. Click OK to apply the changes and close the properties dialog. Click Cancel to close the dialog and discard all the changes that you have made to the properties.

130. Where do you place pass-thru node in message flow?
 Ans. in the sub flows immediate to the input node

131. Features of Message Broker?
Ans. Routing, Transformation, Integration,

132. What is CVS (Concurrent Version System)?
Ans. It is a repository that will store the previous versions.

133. Difference between compute and mapping node?
Ans. In the compute node we can change the headers but in mapping node we can’t

134. What are the properties MQMD and MQRFH2 Headers?
Ans. MQMD are a must headers and are present from starting to end of the message flow but MQRFH2 are optional and are set according to the business need.

135. What are the properties of TRACE Node?
Ans. Destination, File Path, Pattern, Message Catalog and Message Number

136. What are the types of TRACES?

Ans. User trace, service trace, ODBC trace, WebSphere MQ Java Client trace, and Configuration Manager Proxy trace.
Subscribe to: Posts (Atom)