Using Apache ActiveMQ Artemis as JMS Broker with webMethods Integration Server

products versions - webMethods Integration Server version: 10.15

Introduction

Apache ActiveMQ Artemis is a Message Broker. It has its origins in JBoss HornetQ project.
It supports multiple protocols:

  • Artemis / HornetQ Native
  • MQTT
  • AMQP
  • STOP
  • OpenWire

It supports connectivity using JMS. For the purpose of this configuration, JMS API is used along with Artemis native protocol.

Apache ActiveMQ Artemis implements a client side JNDI implementation. This implementation requires declaring queues and other properties as part of JNDI configuration on the client.

Note: As per SAG documentation as well as my interaction with support engineers, any JMS client library following JMS 1.1 should work. SAG does not test every JMS broker. Please make sure to test set up sufficiently prior to deploying it in production environment.

Pre-requisite

  • Apache ActiveMQ Artemis version 2.27.1 installed and running.
    • The server should be listening for artemis protocol on a given port. The example uses port 61616 (default port set up by Apache ActiveMQ Artemis)
  • Queue created in Artemis
    • For the Proof-of-concept, the queue is called FirstQueue.
  • Integration Server 10.15 installed and running.
    • Administrator user is required for JNDI / JMS Configuration
  • Designer 10.15 installed and running. Connected to Integration Server.
  • Artemis client jar file (Steps for client-all jar provided below)

Steps to follow

Integration Server Configuration

  • Download artemis-jms-client-all-2.27.1.jar (see Useful link below)

Note: Artemis jar file combines multiple dependencies into a fatjar. This may cause class conflict with existing jar files loaded on Integration Server environment. Please read thru Artemis documentation in detail. The alternative would be to import individual jars and if there is a conflict, isolate and upgrade conflicted jar file and test to see if end solution still works.

  • Copy jar file into Integration Server’s lib/jars/custom folder. e.g. /opt/softwareag/IntegrationServer/instances/default/lib/jars/custom (Refer to Integration Server Administration Guide)
  • Restart Integration Server

JNDI Alias

Create a new JNDI Setting using Integration Server console.
Provide settings as below:

  • JNDI Alias Name: ArtemisJNDI
  • Description: Artemis
  • Initial Context Factory: org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
  • Provider URL: tcp://<server.name>:61616
  • Other properties: queue.queues/FirstQueue=FirstQueue

Key Information:
Artemis does not implement server side JNDI. As a result, it is important to define names of the queues in Other properties.

  • Click Save changes
  • Click on Test Lookup button to review / validate JNDI settings.

JMS Setting

Create a JMS Alias

  • Create a new connection alias using standard JMS Alias step
  • In Connection Protocol Settings → Create Connection using → JNDI Lookup
  • Choose JNDI Alias created in step above
  • Set Connection Factory Lookup Name as QueueConnectionFactory or ConnectionFactory.

Using it in Designer

Reading Messages from JMS queue

Create a JMS Trigger

  • set JMS Connection Alias with same value as created in JMS setting
  • set Destination Name as queues/FirstQueue
  • set Destination Type as queue

Sending a Message into JMS

Add steps to flow service

  • add pub.jms:send to flow service
  • map connectionAlias created in JMSsetting
  • map destinationName as queues/FirstQueue.
  • map destinationType as QUEUE.

Next steps

  • Run Test by sending messages into Artemis.

Useful links | Relevant resources

2 Likes

Hi Chirag,

Iam facing below error:
com.wm.app.b2b.server.jms.JMSSubsystemException: [ISS.0134.9016] Error creating connection factory: javax.naming.NameNotFoundException: ActiveMQJMSConnectionFactory

Could you please let me know what is the correct or default value for Connection Factory Lookup Name ? any where in the ActiveMQ page we can find that ?

below is the configuration:

JNDI look up values:

ConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory
QueueConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQQueueConnectionFactory
TopicConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQTopicConnectionFactory
XAConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQXAConnectionFactory
XAQueueConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQXAQueueConnectionFactory
XATopicConnectionFactory: org.apache.activemq.artemis.jms.client.ActiveMQXATopicConnectionFactory
dynamicQueues: org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory$1
dynamicTopics: org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory$2
queues: org.apache.activemq.artemis.jndi.ReadOnlyContext

Regards,
Sandeep

Can you try using QueueConnectionFactory in place of ActiveMQJMSConnectionFactory as Connection Factory Lookup Name?

2 Likes

Thank u it worked :slight_smile:

1 Like

Just ConnectionFactory should work as well.

@CHIRAG This setup works for 10.7 ?

@siva.dadi I have not tried 10.7, but JMS is mostly functioning same way. I would encourage you to try it.

ActiveMQ and testing doesn’t take much time. Once you have tested/validated, do share your feedback/learning.

1 Like

It didn’t work for 10.7 due to Active MQ jars being compiled with Java class 55 but 10.7 comes with 52. Can you help with libraries supported with 52? My infra team says that 10.7 is not supported with Java class 55. FYI - I tied libraries till 25

Hi Siva,

can you check the ActiveMQ version, please?

Class file version 52 stands for Java 8 and class file version 55 stands for Java 11.

Beginning with ActiveMQ 5.17.x , it requires Java 11 or newer, therefore you will have to downgrade your ActiveMQ version to max 5.16.x
ActiveMQ 6.x will require Java 17 or newer.

See ActiveMQ New build, latest version not working with latest Java for further informations.

Regards,
Holger

1 Like

You could try using Client libraries of ActiveMQ Version 5.16 or check with ActiveMQ forums/support on level of cross compatibility between different clients and versions.

2 Likes

Hi,
thx for the tuto !
Actually i am trying to use a cluster of artemis broker with multiple ISs …
The artemis cluster is fine, there are 2 servers seeing each other, no problem at all.
I have 2 IS servers with the same trigger on each other.
If i enable ONE trigger on a server, no problem, i have an only one copy of my jms.
anycast by the way … it’s a point to point.
But if i enable the same trigger on the second IS server, i have got another copy of the JMS and it’s bad … I need only one consumer like universal message can achieve but it can be IS one or IS two, it’s ok …
With universal messaging, if the triggers are enabled in all the ISs servers, i’ve got only one jms and only one … BTW the property “Exactly once” is disabled and i’ve still got one JMS … How can i do that with artemis if it’s possible ?
I saw sharedclientID doesn’t work anymore with artemis maybe it’s the problem or the fact there is only one connection factory …
Do you have any clue ?
Thx

With sharedclientID do you mean Connection Client ID?

yep !
And i am using Connection Factory Lookup Name : ConnectionFactory, do i need to use QueueConnectionFactory ?
I am using in Other Properties : queue.System_XXXXXXc=System_XXXXX and in the broker.xml :

Artemis version : activemq-all-6.0.1

Edit : If i use QUEUE explicitly, i am missing some JMSs …

Edit2 : It seems you need to use ON_DEMAND in the broker.xml and not STRICT

Edit3 : Working like a charm ! But, now, i have the same connection for multiple consumer per server … The queue is consumed only one time … Good behavior technicaly but bad behavior for our workflows … But if i use multicast topic, i get copies of jms per host … I continue my investigation !
The problem is the multiple host with the same trigger i guess …

Thx

What do you mean with “missing some JMSs”? JMS is an API specification, so this doesn’t make much sense to me.

I am stopping my investigations, artemis is too hard to maintain and setting up with webMethods.
We are keeping UM, it’s more versatile and easy to use.
Thx for your comments.

I have seen several implementations that have used ActiveMQ (not artemis) as JMS broker between Java Apps and webMethods. Using UM should be as good for JMS as long as you are using text messages.

If your usecase was purely webMethods to webMethods - then it makes sense to continue to use UM.

Indeed !
Thx Chirag, i keep UM for now !