The JMS is part of the Suns J2EE specification, thus you may use it on any platform that supports Java. We do not support any other way of invoking it (C++, C#, etc).
The client API that we provide is according to the standard specification. Please have a look at http://java.sun.com/products/jms/tutorial/ for a tutorial.
To use the JMS on windows you will need a Java virtual machine (here is one from sun: http://java.sun.com/j2se/1.4.2/download.html)
Then in order to use the SAP JMS, you will need the following jars in the classpath:
For NW04 and NW04s:
For SAP NetWeaver Application Server, Java EE 5 Edition:
You may find these jars from your NetWeaver installation at:
This is Suns JMS API jar. You can also find the jms.jar in your NetWeaver installation at \usr\sap\<sid>\<instanceid>\j2ee\cluster\bin\ext\jms.
In the jms-factories.xml there are <user-name> and <password> for connection to the queue. When should I use them?
The <user-name> and <password> are for the call to connectionFactory.createConnection(user, password), which is performed by the JMS Connector upon application startup. They will be provided to the security mechanism of the JMS provider. If the user can not be authenticated then a JMSSecurityException will be thrown as per the JMS specification.
You can dynamically create destinations that last as long as the lifetime of the connection, which are known as temporary destinations. Consumers of temporary destinations can be created only from the same connection that created the destination.
The temporary destinations:
- Are intended to facilitate a simple request/reply mechanism.
- Represent a message queue or topic to which a producer can send and from which a consumer can receive messages.
- Exist only for the lifetime of the connection in which they are created.
- Are deleted when the connection is closed, and all messages inside the destination are lost.
- Are not intended to survive a server failure.
- Only consumers created in the same connection as the temporary destination can receive messages from it, although all producers can send messages to it. Although you can easily create temporary destinations dynamically without the help of an administrator, they require as many resources on the provider side as regular destinations, so avoid using temporary destinations extensively.
Use the following source code:
Since SAP NetWeaver 04 SP19, it is possible to configure message redelivery and the delay between two consecutive delivery attempts for queues. When a failure occurs delivering a message, several consecutive attempts are made to deliver the problematic message before it is considered undeliverable (dead). The idea of message redelivery is to allow the application to recover from some temporary error condition that has happened inside the onMessage method. The full process is explained in
. However, if there is no delay between delivery attempts, it is less likely that the application problem would have been fixed before the last delivery attempt. This behavior has been enhanced by introducing configurable redelivery delay. The new queue property is called deliveryDelayInterval and its value is the time in milliseconds between two consecutive message delivery attempts. By default the new property has the value of 2000 milliseconds (2 seconds).