Friday 16 April 2010

MQ v7 example to make connection

Structure:
Qremote -- transmissionQ(XmitQ) -- channel -- RemoteServer:listener -- RemoteServer:Qlocal

Qremote:
===> Just a shadow of remoteQL
runmqsc
def qr(nameQR ex. QRMTYY) rname( nameQL on remote server : QL.AY) rqmname( nameQM remote : QMCYY) +
xmitq(QMCYY)

Note : xmitq is optional, if u use default,by default it will go to xmitq whose name same as rqmname. That is why if no xmitq with same name with rqmname: 'amqsput QremoteName' will show error.
If you use uncommon name for the xmitQ (different name with the rqmname), you must put parameter xmitq there.


XmitQ
==> Queue Gateway of all Qremote using this value XmitQ as parameter
runmqsc
def ql(QMCYY) usage (xmitq)


Channel
==> Defining to where, hostname and port of remote server.
runmqsc
def chl(qmcxx.qmcyy) chltype(sdr) trptype(tcp) conname ('ip(port)') xmitq(qmcYY)

Note : this channel will be used by this xmitQ

>>>>>>>>>>>>>>>>>>>>>
BTW, you need to set deadletterQ as well:
runmqsc
def ql(DQL)
alter qmgr deadq(dlq)
>>>>>>>>>>>>>>>>>>>>>>


AT REMOTE SERVER:

listener
runmqlsr -t TCP -p 90XX -m qmgrname

Note : after this you create channel receiver : def chl(xxx) chltype(rcvr) trptype(tcp)
dont forget to create qlocal (QL.AY)


BACK TO LOCAL SERVER


TESTING:
runmqsc
ping chl (qmcxx.qmcyy) ==> this one only test if remote listener port open
runmqchl -c qmcxx.qmcyy -m qmgrname ==> activate channel (has dependancy on listener port AND correct name of xmitQ existence)


PUTTING MESSAGE:
amqsput Qremote (qmgrname)
==> remember this is just shadow, message will go to xmitQ name related
-=> So check it with amqsbcg/gbr xmitQname (to see if message stuck in local server)
amqsgbr is more concise than amqsbcg.


CHECKING MESSAGE @remote server:
amqsgbr QL.AY (qmgrname)
amqsbcg QL.AY (qmgrname)

NOW, if you wanna set message goes to DeadletterQ (when everything is ok):
amqsput XmitQname
==> because channel doesnt know where to transfer it (unlike QR which has Qlocal of remote server)
==> And of course the DeadletterQ is in the local server.

NOW, if channel failed, and you use that : amqsput XmitQname,
it will go to XmitQ, test by : amqsgbr xmitQname.


ADDITOINALLY:
crtmqm -q qmgrname (make it as default qmgr)

MQ v7 Triggering amqsreq.exe and amqsech.exe

Those files should be in:
D:\Program Files\IBM\WebSphere MQ\tools\c\samples\bin

That "c" dir is created only if you install the "development toolkit" during the instalation,
or you can run it again the setup.exe of MQ, to add this feature.

NOTE: IF U SEARCH FOR AMQSBCG.EXE, IT IS ALSO THERE AFTER THIS FEATURE INSTALLED

After this, it will be put in PATH variable, so you must close the "cmd" windows and open new one "cmd" in order to get the refreshed "PATH" variable.

"cmd" == start - run - cmd

Thursday 15 April 2010

WAS + proxy (edge server)

Excerpt from http://www-10.lotus.com/ldd/lcwiki.nsf/dx/configuring-a-reverse-proxy-server2


Configuring a reverse proxy server (2.0)

Overview
A reverse proxy server intercepts client requests to Lotus Connections servers and, when possible, returns cached data rather than contacting the true destination server. A reverse proxy reduces the amount of traffic that a back-end server must perform to satisfy duplicate requests for data, while at the same time improving the response time for those requests.
You can set up a reverse proxy by using WebSphere Application Server Edge components (formerly Edge Server). Edge components can control client access to Web servers and improve access to Web-based content over the Internet or a corporate intranet.

Infrastructure
The topology in this deployment uses a cluster of Lotus Connections servers connected to a remote HTTP server, a remote database server, and a remote LDAP server. These are deployed in a private network behind a firewall. Client request are intercepted and handled by the transparent proxy server. Users are not aware that a proxy exists in the configuration.

This deployment was tested on a Microsoft Windows Server 2003 platform. The following figure illustrates the topology used in this deployment:

Specifications
The following table lists the specifications of the systems used in this deployment:
Component Software OS System
Reverse Proxy IBM WebSphere Application Server Edge Components 6.1 Windows Pentium IV CPU, 3.0 GHz, 500 MB RAM
Web Server IBM HTTP Server 6.1.13 with SSL enabled Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM
1 Quad-Core CPU, 1.6 GHz, 4 GB RAM
Lotus Connections 1.0.2
Lotus Connections 2.0
IBM WebSphere Application Server 6.1.0.13
IBM WebSphere Application Server 6.1.0.13 Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM
Database DB2 9.1.4
Oracle 10g 10.2.0.3 Windows
Linux 2 Dual-Core CPUs, 2.0 GHz, 8 GB RAM

















Step-by-Step instructions
Before deploying this infrastructure, the product and all related components must be installed.

Installing WebSphere Edge Components

1. Download Edge Components (part number: C88UQML): https://w3-104.ibm.com/software/xl/download/ticket.do?openform
2. Launch the Edge Components launchpad.bat file and install the Caching Proxy component. For more information about installing, see the Edge components information center.
3. Start the proxy service: Click Start > Control Panel > Administrative Tools > Services, and then select IBM Caching Proxy and start the service.
4. Enter the URL of the target Web server: Click Start > All Programs > Edge Components > Caching Proxy > Configuration Wizard. Enter the URL of the Target Web Server, and click Next.
5. Enter a User Name and Password for a new administrator account, and click Next. Click Finish and OK.
6. Open the ibmproxy.conf file (usually located in the \cp\etc\en_US directory) and add the following line to the Start new mapping rules section:

Add Pass /pub/* \cp\server_root\pub\en_US\*


Save the file.
7. Configure the proxy: Open Proxy Configuration > Proxy Settings, select the HTTP check box, and click Submit.
8. Click Proxy Performance, deselect the Run as a pure proxy check box, and click Submit.
9. Restart the proxy server and test the configuration: Open a web browser and navigate to "http://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.


Enabling SSL

A. Create a personal certificate on the proxy server

1. Create a key database for proxy server: Click Start > All Programs > IBM WebSphere > Edge Components > Caching Proxy > Start Key Management Utility.
2. Click Key Database File and select New.
3. Enter the following information and click OK:
Key database type: CMS
File Name: ProxyKey.kdb
Location: C:\ProxyDB
4. At the password prompt, enter your password and select the Stash the password to a file? check box.
5. Create a personal certificate: Click Create > New Self-Signed Certificate....
6. Enter the following information and click OK:
KeyLabel: ProxyCert
Version : X509V3
Key Size : 1024
Common name : Your_Proxy_Server.com
Organization : ibm


B. Import a signer certificate from the Web server

1. Extract the PluginCert.arm file from the IBM HTTP Server. (For more information about IHS, see Edge components information center): Open the plugin-key.kdb file (under C:\IBM\HTTPServer\Plugins\etc\) and click OK. Enter your password when prompted, and click OK.
2. Click WebSphere Plugin Key > Extract Certificate... and enter the following data:
Data type: Base64-encoded ASCII data
Certificate file name: PluginCert.arm
Location: C:\
Click OK.
3. Import the IHS Signer Certificate to the proxy server: Click Start > All Programs > IBM WebSphere > Edge Components > Caching Proxy > Start Key Management Utility, and open the ProxyKey.kdb file.
4. Click Signer Certificates > Add, and enter the following information:
Data type : Base64-encoded ASCII data
Certificate file name : PluginCert.arm
Location : C:\
Click OK
5. When prompted to enter a label, type PluginCert, and click OK.


C. Configure SSL on the proxy server

1. In the proxy server's admin console, open Proxy Configuration > SSL Settings.
2. Select the Enable SSL check box.
3. Select the Attempt to cache content on a secure request check box.
4. Enter the kdb location, for example, c:\ProxyKDB\ProxyKey.kdb, in the Key Ring Database file field.
5. Enter the password file location, for example, c:\ProxyKDB\ProxyKey.sth, in the Key Ring Database Password File field.
6. Click Submit.


D. Modify the ibmproxy.conf file
1. Add the following lines to enable Proxy and ReversePass directives:

Proxy /*
http://venturacn24.cn.ibm.com/* :80


Proxy /*
https://venturacn24.cn.ibm.com/* :443


ReversePass http://Your_HTTP_Server.com/*
http://Your_Proxy_Server.com/*


ReversePass https://Your_HTTP_Server.com/*
https://Your_Proxy_Server.com/*


2. Add the following line to enable the SendRevProxyName directive:

SendRevProxyName yes


3. Add the following lines to enable cache directives (optional):
CacheTimeMargin 0 seconds
CacheQueries Always http://Your_HTTP_Server.com/*
CacheQueries Always https://Your_HTTP_Server.com/*
4. Save the ibmproxy.conf file.
5. Restart the proxy server and test the configuration: Open a web browser and navigate to "https://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy in SSL mode is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.

E. Test the configuration
1. Restart the proxy server.
2. Open a web browser and navigate to "https://Your_Proxy_Server.com/", where is a Lotus Connections feature (such as Activities or Blogs). If the web page for the selected feature appears, the reverse proxy in SSL mode is working correctly.
You can check the reverse proxy logs under: C:\Program Files\IBM\edge\cp\server_root\logs.

Recommended reading

* WebSphere Application Server Concepts, Planning, and Installation for Edge Components: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.edge.doc/welcome.html
* Reverse proxy definition: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzaie/rzaieproxytypes.htm
* WebSphere Application Server Network Deployment: http://www-306.ibm.com/software/webservers/appserv/was/network/edge.html

Ant and Make

Both are "builder" of application.

In instance, Make is used by perl, C, ...

To run it : make Makefile
The makefile contain : the target:dependency:script to run

example:

in C, there are file.C and headerfile.h. file.c is source code. headerfile.h is like library in which there are main function,variable that can be used among the file.c (ex. include stdio.h)

in C, you compile and then linking :
gcc -c thesourcecode then gcc -o theresultprevcommandANDsomelib

in C, when you have (at same folder):
file1.c and header1.h
file2.c and header2.h

to compile : gcc -Wall -ansi -o theprogram code1.c code2.c
Note: see @ bottom page, if you are confused why no need out headerfile.h at above command!!


You'll compile it like this if you dont want to compile all-in-once, example if you just modify one of the file, you dont need to compile all files :

gcc -c file1.c ==> resulting file1.o = a machine code file
gcc -c file2.c
gcc -o theprogram file1.o file2.o

Here are example makefile content:

''''''''''''''''''''''''''''
default: theprogram

code1.o: code1.c header1.h
gcc -Wall -ansi -c code1.c

code2.o: code2.c header2.h
gcc -Wall -ansi -c code2.c

prog: code1.o code2.o
gcc -Wall -ansi -o theprogram code1.o code2.o

clean:
rm code1.o code2.o

cleanall: clean
rm prog
'''''''''''''''''''''''''''''''

target : dependency
script to run

Note: if too long in a row use "\" as splitter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

step beginning : make makefile
will execute the make default, which dependens on theprogram,
so theprogram is run, but dependens on code1.o and code2.o,
so the code1.o and code2.o will be run, the script to get the codeX.c, the dependency.


step final: make clean
to remove the machine code files.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

in perl, as i remember:

make ==> to prepare the environment
make test ==> to test if any dependency failed
make makefile ==> run the instalation
make clean ==> cleanup some junk during instalation

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Ant, is java-based tool, can be use in vary programming, including replacing Make,
it is more advance with more feature.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Excerpt from http://www.unix.com/programming/47881-help-compiling-header-files-c-file-using-gcc.html

There are two basic ways to compile header files in C:

AAA

If the headers are in the same location as the source you include them like this:
Code:
#include "myheader.h"

if they are standard headers then inlude like this:
Code:
#include


then compile with
Code:
gcc -o myoutputfile myoutputfile.c

BBB

If the headers are located in some other (non-standard) location you would include like standard headers:

Code:

#include
and then use the -I (uppercase i ) flag to include the directory containing them.

Code:
gcc -I/path/to/directory/containing/header_name -o myoutputfile myoutputfile.c

or leave them quoted and use on of:
Code:
gcc -iquote /path/to/directory/containing/header_name -o myoutputfile myoutputfile.c

or
Code:
gcc -include /path/to/directory/containing/header_name/header_name.h -o myoutputfile myoutputfile.c

Tuesday 13 April 2010

IHS + WAS + Plugin

Install IHS
==> Put server name as the identification of the "web server name" which will be used for "folder name" of plugin at IHS and WAS, and also log name as unique identity.
==> Put username and password, as it will be used for registering to Http admin.
==> Http admin is a service in windows, but it isnt accessible from browser.
==> Http server is another service created by the installer.

As i remember we dont need to install plugin, since it is along with the IHS installer,
and during the ihs instalation it asked where the WAS directory is.

But incase plugin wasnt there, just install it reside in IHS installer folder called plugins.


On WAS admin console:
==> go to servers = web servers = new
==> Put servername as same as the "web server name" above, as it is a folder name in the ihs plugin config dir.
==> Put hostname as the hostname/DNS name of where the IHS server is.
==> Put the "service name" of IHS correctly as in services.msc (in oder to be able restart webserver using was admin console)


At this point, the plugin is:
1. in IHS is general plugin of WAS default instalation (context root : snoop, hello, etc)
D:\Program Files\IBM\HTTPServer\Plugins\config\webservername

2. in WAS, plugin not available yet.

At WAS console, u must generate plugin (click the webserver and button will be available):
It will be in D:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\win2003Node01Cell\nodes\win2003Node01\servers\"webservername you insert when adding webserver"\

* That folder was created when you add new web server, plugin file will be created under it
* This plugin is only for default_host VH and others if any, but not for the admin_host VH
* admin_host VH is VirtualHost where /ibm/console is (WAS admin console login)
* default_host VH is VirtualHost where /snoop, /hello, /UTC (in my case) are.
* notice there is server.xml there, there you can see the webserver username and decoded password.
* you can decode the WAS user's password by using www.sysman.nl/wasdecoder


At WAS console, u must propagate plugin:
WAS will copy above plugin to IHS plugin - webserver name folder.

Restart the IBM Http service.

Now, u have successfully made it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

For redirecting/loadbalancing the WAS admin console using plugin, i think you must edit it manually the plugin-cfg.xml.

Allowing Web servers to access the administrative console
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tins_configACAccess.html

Procedure

1. Use the administrative console to change the admin_host virtual host group to include the Web server port (80 by default).
1. Click Environment > Virtual Host > admin_host > Host Aliases > New.

The default port that displays is 80, unless you specify a different port during profile creation.
2. Specify the IP address, or the name of the machine that is hosting the HTTP server.

For example, if you installed a WebSphere Application Server product on a machine that is named waslwaj.rtp.ibm.com, specify the name in this field.
2. Click Apply > Save.
3. Stop and restart the application server.

For example, to access the administrative console of a stand-alone application server, stop and restart the server1 process.
To stop server1, open a command window and navigate to the profile_root /bin directory. Then issue the following command:

./stopServer.sh server1

After receiving the following message, you can restart the application server:

Server server1 stop completed.

To start the application server, issue the following command:

./startServer.sh server1

When you receive a message that is similar to the following message, the server1 process is running:

Server server1 open for e-business; process id is 1719

4. Stop and restart a deployment manager.

For example, to access the administrative console of a deployment manager, stop and restart the deployment manager.
To stop the deployment manager, open a command window and navigate to the profile_root /bin directory. Then issue this command:

./stopManager.sh

Then issue the following command to stop the deployment manager:

./stopManager.sh

After receiving the following message, you can restart the deployment manager:

Server dmgr stop completed.

To start the deployment manager, issue the following command:

./startManager.sh

When you receive a message that is similar to the following message, the deployment manager is running:

Server dmgr open for e-business; process id is 1720

5. Edit the plugin-cfg.xml file to include the following entries:






...
...
...









...
...
...

AffinityURLIdentifier="jsessionid" Name="/ibm/console/*"/>

UriGroup="admin_host_server1_SERVER1HOSTserver1_Cluster_URIs" VirtualHostGroup="admin_host"/>


If your HTTP server has an HTTP port other than 80, add an entry to the VirtualHostGroup:



The port variable is your HTTP server port.

Friday 9 April 2010

MQ 7 on windows

After installer launched, the prequisite ask about the Websphere Eclipse Platform 3.3,
you must install it first, by go to the prereqs folder (in the same installer CD as MQ installer),
then run the IES (Ibm eclipse SDK).

Configure:
1. crtmqm qmanager
2. runmqsc qmanager
3. runmqsc qmanager
4. define qlocal(qname)


To test it:
use the amqsput.exe in the bin directory :
amqsput qlocal qmanager (CATCH CATCH qlocal is at caps lock, if you dint put '' when created it)
type some text
enter twice to end it

Use the amqsget command.


>>>>>>>>>>>>>>>>>>>
Now, difference between amqsput and amqsputc, when u use amqsputc u must set this variable first:

set MQSERVER=SYSTEM.DEF.SVRCONN/TCP/127.0.0.1(1414)
where first parameter is channel with type of SVRCONN (other type can result error)

amqsputc qname qmanager
>>>>>>>>>>>>>>>>>>>>

Wednesday 7 April 2010

WAS and MQ

You can test using UTC.ear (reside in deploy tool of WAS instlation folder)

CCSID : usually 850 (this is ID of the qmanager that u will use) You can see at the properties of the qmanager.
This must be put exactly same in the QCF and Q creation at WAS console.

At WAS - servers - you can ignore the Websphere MQ Server (No need to register to here, this is only for zOS mq).


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
HERE IS the PROCEDURE

Excerpt from:
http://activexpert.blog.co.in/2009/09/14/integrate-websphere-application-server-and-mq/

WebSphere Application Server can interoperate with WebSphere MQ in the following ways:

* By configuring WebSphere MQ as an external JMS provider using the WebSphere MQ messaging provider.
* By integrating a service integration bus into a WebSphere MQ network of queue managers using the default messaging provider and WebSphere MQ links.
* By integrating WebSphere MQ for z/OS® queues into a bus using the default messaging provider and a WebSphere MQ server.
WebSphere MQ links provide a traditional WebSphere MQ-style solution to connecting resources. WebSphere MQ servers add the ability to directly access WebSphere MQ queues from within a bus.

Method1: No bus: The WebSphere MQ messaging provider
The WebSphere MQ messaging provider does not use service integration. It provides JMS messaging access to WebSphere MQ directly from WebSphere Application Server.

Method2: Multi-bus: WebSphere MQ network as a foreign bus (using WebSphere MQ links)
A WebSphere MQ link provides an indirect connection between a service integration bus and a queue manager within a WebSphere MQ messaging network. With this type of connection, the messaging bus is seen by the WebSphere MQ network as a virtual queue manager, and the WebSphere MQ network is seen by service integration as a messaging bus. A Websphere MQ link allows WebSphere Application Server applications to send point-to-point messages to WebSphere MQ queues (defined as destinations in the service integration bus), and allows WebSphere MQ applications to send point-to-point messages to destinations in the service integration bus (defined as remote queues in WebSphere MQ). The link also allows WebSphere Application Server applications to subscribe to messages published by WebSphere MQ applications, and WebSphere MQ applications to subscribe to messages published by WebSphere Application Server applications. The link converts messages between the formats used by WebSphere Application Server and those used by WebSphere MQ, and handles data conversion of messages.

Method3: Single-bus: Queue manager as a bus member (a WebSphere MQ server)
A WebSphere MQ server provides a direct connection between service integration messaging engines in WebSphere Application Server and queue managers or queue sharing groups in WebSphere MQ for z/OS. WebSphere MQ server is designed to exploit the high availability, and optimum load balancing characteristics provided by a WebSphere MQ for z/OS network. WebSphere MQ server defines the connection and quality of service properties used for the connection, and also ensures that messages are converted between the formats used by WebSphere Application Server, and those used by WebSphere MQ.

=> Installation instructions for setting up a new WebSphere MQ installation to interoperate with WebSphere Application Server.

1. Install a supported version of WebSphere MQ
2. Follow the WebSphere MQ instructions for verifying your installation setup.
3. Configure WebSphere Application Server and WebSphere MQ to interoperate effectively.
4. At Node scope (not Server scope) set the WebSphere Application Server MQ_INSTALL_ROOT environment variable to the directory where WebSphere MQ is installed. WebSphere Application Server uses the MQ_INSTALL_ROOT setting to find the WebSphere MQ libraries for the WebSphere MQ messaging provider. If you use the default messaging provider and configure a WebSphere MQ server bus member, the bus uses the MQ_INSTALL_ROOT setting to establish a direct binding to WebSphere MQ rather than a TCP/IP network connection.
5. At Cell scope or Node scope, set the WebSphere Application Server MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN environment variable to True. This allows application server startup to automatically take account of changes that are made to the MQ_INSTALL_ROOT environment variable and WebSphere MQ JMS client libraries while the application server is stopped. If you do not set this variable, you must restart the application server a second time after any changes of this type, to enable the application to perform messaging using the WebSphere MQ messaging provider.

* Configuring a unified connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider that you want to support the destination.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Connection factories to display a table of existing unified connection factories, with a summary of their properties.
5. To view or change the properties of an existing unified connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the connection factory into the namespace.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the unified JMS connection factory for more details.
3. Click Apply. This defines the JMS connection factory to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the unified JMS connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a queue connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the queue connection factory that you want to configure.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Queue connection factories to display a table of existing queue connection factories, with a summary of their properties.
5. To view or change the properties of an existing queue connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the connection factory into the namespace.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the queue connection factory for more details.
3. Click Apply. This defines the connection factory to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the queue connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a topic connection factory for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the topic connection factory that you want to configure.
3. Optional: Change the Scope setting to the level at which the connection factory is visible to applications.
4. In the contents pane, under Additional Properties, click Topic connection factories to display a table listing any existing topic connection factories, with a summary of their properties.
5. To view or change the properties of an existing topic connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties. You can specify other properties, as described in a later step.
Name
The name by which this topic connection factory is known for administrative purposes within IBM® WebSphere Application Server.
JNDI Name
The JNDI name that is used to bind the topic connection factory into the name space.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the topic connection factory for more details.
3. Click Apply. This defines the destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the topic connection factory, according to your needs.
7. Optional: Change connection pool properties and session pool properties, according to your needs.
8. Configure a non-default SSL repertoire. To do this, specify a custom property on the connection factory with name ssl.repertoire and a value of the name of the repertoire alias to be used. A list of available repertoire aliases can be found by navigating to Security > SSL certificate and key management > SSL configurations . For WebSphere MQ the only settings in the SSL configuration that are used are:
* Location of the Trust store and its password
* Location of the Key store and its password
Information about supported SSL cipher suites is ignored by the WebSphere MQ client.
9. Click OK.
10. Save any changes to the master configuration.
11. To have the changed configuration take effect, stop then restart the application server.

* Configuring a queue for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the queue destination that you want to configure.
3. Optional: Change the Scope setting to the level at which the JMS destination is visible to applications.
4. In the contents pane, under Additional Properties, click Queues to display a table of existing queue destinations, with a summary of their properties.
5. To view or change the properties of an existing queue destination, click its name in the list. Otherwise, to create a new queue, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties.
Name
The name by which this queue destination is known for administrative purposes within IBM® WebSphere Application Server.
JNDI name
The JNDI name that is used to bind the queue destination into the namespace.
Base Queue Name
The name of the queue to which messages are sent, on the queue manager specified by the Base Queue Manager Name property.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the queue destination for more details.
3. Click Apply. This defines the queue destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the queue destination, according to your needs.
7. Optional: If you want WebSphere Application Server to try to use the WebSphere MQ queue manager’s remote administration utilities to create the queue, configure the WebSphere MQ Queue Connection properties.
If you have already created your underlying queue in WebSphere MQ using its administration tools (such as runmqsc or MQ Explorer), you do not need to configure any of the WebSphere MQ Queue Connection properties. You only need to configure these properties if you want WebSphere Application Server to try to use the WebSphere MQ queue manager’s remote administration utilities to create the queue.
To be able to browse or change these MQ Config properties, you must have installed the WebSphere MQ client. If you have not done this, the administrative console displays messages like the following:
The WMQQueueDefiner MBean has encountered an error.
WMSG0331E: The MQ Client is required for this functionality, but it is not installed.
Note: For any changes to these properties to take effect on the queue manager, the WebSphere MQ Queue Manager on which the queue resides (or will reside) must be configured for remote administration and be running.
For more details about these properties, see WebSphere MQ config properties for the queue destination.
8. Click OK.
9. Save any changes to the master configuration.
10. To have the changed configuration take effect, stop then restart the application server.

* Configuring a topic for the WebSphere MQ messaging provider
1. In the navigation pane, click Resources > JMS > JMS providers.
2. Select the WebSphere MQ messaging provider for the topic destination that you want to configure.
3. Optional: Change the Scope setting to the level at which the topic destination is visible to applications.
4. In the contents pane, under Additional Properties, click Topics to display a table of existing topic destinations, with a summary of their properties.
5. To view or change the properties of an existing topic destination, click its name in the list. Otherwise, to create a new topic destination, complete the following steps:
1. Click New in the content pane.
2. Specify the following required properties. You can specify other properties, as described in a later step.
Name
The name by which this topic destination is known for administrative purposes within IBM® WebSphere Application Server.
JNDI Name
The JNDI name that is used to bind the topic destination into the namespace.
Base Topic Name
The name of the WebSphere MQ topic to which messages are sent.
CCSID
The coded character set identifier for use with the WebSphere MQ queue manager; for example: 850. See the properties for the topic destination for more details.
3. Click Apply. This defines the topic destination to WebSphere Application Server, and enables you to view or change additional properties.
6. Optional: Change properties for the topic destination, according to your needs.
7. Click OK.
8. Save any changes to the master configuration.
9. To have the changed configuration take effect, stop then restart the application server.

* Configuring WebSphere MQ connection pooling
1. Display the Message Listener Service properties for the application server
1. In the navigation pane, click Servers > Application Servers
2. In the content pane, click the name of the application server.
3. Under Additional Properties, click Message Listener Service properties.
2. Select Custom Properties, to enable WebSphere MQ connection pooling, add the following custom properties:
MQJMS.POOLING.THRESHOLD
The maximum number of unused connections in the pool.
MQJMS.POOLING.TIMEOUT
The timeout in milliseconds for unused connections in the pool.
3. Click OK.
4. Save any changes to the master configuration.
5. To have the changed configuration take effect, stop then restart the application server.

WAS + MQ

Follow the instruction

1. Service integration :make the BUS and Q destination point
2. Resource : make the Q connection factory and Q (and relate it with above value)
3. You can follow the Service integration Bus breadcrumb till you find the message in the Q pool.
(the message is readable)

To test use this:

1. install apps called Universal Test client (UTC.ear) at install-root\deploytool\itp\plugins\com.ibm.ws.ast.st.utc_6.1.6.v200811230003\IBMUTC.ear

this tool can be used to verify the Q in the pool.

WAS + TDS

From TDS:
A. installing the IBM TDS.
B. installing the WASembedded-IBMTDS
C. start the instance in the services.msc.
D. start the server1 in the TDS profile WAS.
E. go to TDS admin console : http://localhost:12100/IDSWebApp/IDSjsp/Login.jsp?showConsoleAdminLogin=true
F. default user:superadmin passwd: secret
G. Register the instance LDAP you want (ex. localhost 389)
H. Then you can manage this LDAP localhost 389 by the url
G. user: cn=...(usually root) passwd:.... (depends on what you put during the installation)
I. Go to server admininstration, add suffix ex. o=nehalorg
J. Go to directory management - manage entry : add o=nehalorg (parent leaves it empty) at the value you can put it same nehalorg (so there wudnt be multiple values).
K. From here you can create our own LDAP structure.
L. if you want to add an object (ex. class=person)and get "invalid dn entry". make sure in the relative dn you dint just put the calue, do like this "cn=value" (eihter it is cn or o or ou or whatever, you can see it right under it, there is one mandatory value, if it is cn then you put cn)


From WAS:
A. Security -> secure admin and infra -> available realm = standaolne ldap ==> set and then configure

B. primary admin user name =
a.either full DN (cn=wasuserPerson,ou=brno,o=nehalorg) or
b.the value (wasuserperson)
(only after you modify the "advance ldap setting" filter like cn=%v , notice %v is value).
At this time, WAS change the type to "custom ldap" instead of IBM TDS (uid=%v, objectclass=ePerson).

C. put the BaseDN (as the point to start search).
D. Bind DN is not necessary,it is only for anonymous connection.
E. restart java.
F. if you changed the "advance ldap setting" then you can use the value, instead of the long dn.
G. case doesnt sensitive.

NOTE:
1. SECJ0369E: Authentication failed when using LTPA. The exception is javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - Inappropriate Authentication].
==> This means you use "user" which has no passwd attribute (it depends on the object class)

2. LdapRegistryI E SECJ0361E: Authentication failed for wasuserinet because user is not found in the registry.
==> if you have ensured that you use full dn, and this still appears, This means you need to configure the ldap filter search in "advance ldap setting".